From jpmacker@gmail.com Fri Nov 6 11:44:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912283A69DE for ; Fri, 6 Nov 2009 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtIEz0KmGygy for ; Fri, 6 Nov 2009 11:44:18 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id DDE9A3A6817 for ; Fri, 6 Nov 2009 11:44:18 -0800 (PST) Received: by pwj20 with SMTP id 20so358177pwj.29 for ; Fri, 06 Nov 2009 11:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=wX2uCfXUbgd6FL6t0mQUehGmizrfRLM+MCCgHLr5JpQ=; b=t+DWE4YrSnSbFKQ0HPdLiD0J+WdfB8VFaC2urGYms7L911pFBODqeixThmKBFFGYy9 iAQ+1KbDXRJHTcvytdhR4BE4/3mGebKyzcm9g5QaBbuXWAzbPZ/27iq5mD3qJAuoqDaO /wQnPCpEZSczQ9Kj/6/NcCmzyDF8LA6Xfghy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rpC9Lw22YtyfcFCSoSIFokDiizqS3RuPAkMpt0juGURhga5om8lylyYpbsZ8PzBEE4 VLpIGxEQ2Bewz4f3igP4XgEnc1PlxyfP0XUwX253PyNX+eRo5NTHcgkspwcKndYV8neS 4kxJ/JqgWn0FCXbcm+en8AfktE6pTnws0nhNo= MIME-Version: 1.0 Received: by 10.142.249.6 with SMTP id w6mr481513wfh.346.1257536679176; Fri, 06 Nov 2009 11:44:39 -0800 (PST) Date: Fri, 6 Nov 2009 14:44:39 -0500 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Draft meeting agenda posted X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:44:19 -0000 I posted a draft agenda last night and will upload presentation materials as I receive them. Please provide any feedback or recommendations you might have. -Joe From ian.chakeres@gmail.com Fri Nov 6 12:24:33 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02FB3A69F1 for ; Fri, 6 Nov 2009 12:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wofesX8cJLnZ for ; Fri, 6 Nov 2009 12:24:33 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 0AC003A6823 for ; Fri, 6 Nov 2009 12:24:32 -0800 (PST) Received: by qyk41 with SMTP id 41so652891qyk.29 for ; Fri, 06 Nov 2009 12:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=vlvDEuvJ0fLZjDyK1Vq2/6e4VjaGmdlUGCjBgOe30A8=; b=rkr9F8fS+RbrW3kscbzMwzlxYBo2qkFMNE3BSua8wCBBNs+W2lPZD7u9zGGOQuzzm8 4YwulXxUhQxfy19OoXk4wSxhtTdjqLBEmKUJPjSku1g/htWqrNtOW7DIt6vjD+mltRcK D97q+f76p+5xyl5KkvJuAwUzXnS52GnxJ4CpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=evkmQrTZuYk29r+A1XzTgk+sTi9sy8++wsXtYkhcC9O4YPq8ZwuObA/wIAre+XgFNU zHwJWcZ1wAC+fl0YGJNlSxejwYsEo1ibLMoMC6kVfnYoMCk949FD4Q7pzpVanTia+loK n25q4BvwWFppdeEYD/T5qKUAFOIZyHTBfYbpA= MIME-Version: 1.0 Received: by 10.229.2.19 with SMTP id 19mr669852qch.94.1257539093075; Fri, 06 Nov 2009 12:24:53 -0800 (PST) In-Reply-To: References: From: Ian Chakeres Date: Fri, 6 Nov 2009 15:24:33 -0500 Message-ID: <374005f30911061224s3409dfcfy455332316d986d0d@mail.gmail.com> To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Joseph Macker Subject: Re: [manet] Draft meeting agenda posted X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:24:33 -0000 The draft agenda can be found at http://www.ietf.org/proceedings/09nov/agenda/manet.txt. Ian Chakeres On Fri, Nov 6, 2009 at 2:44 PM, Joseph Macker wrote: > I posted a draft agenda last night and will upload presentation > materials as I receive them. > Please provide any feedback or recommendations you might have. > > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From jpmacker@gmail.com Sat Nov 7 09:50:43 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71583A6358 for ; Sat, 7 Nov 2009 09:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyBCRyuavkbT for ; Sat, 7 Nov 2009 09:50:43 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C09013A6851 for ; Sat, 7 Nov 2009 09:50:41 -0800 (PST) Received: by pzk42 with SMTP id 42so1544877pzk.31 for ; Sat, 07 Nov 2009 09:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=9NLl/r3SScEFoJre4pv2/g3x3Bw2NCnnxGUvHXU7Gsw=; b=njzYZoQe9rqIrm/rZPfCo0RTwbvdWPuPxj+TZYzAAvcnNVugGfrDk9vog5vfcWGKPz BEDzMENTilI3I6rUl9S3SB6QRs8W5aDj4Zo9LxeHhOOuEfJQgl9S2H7rwriVDoLH7zDX K0t8DWcOzAsBf/gFlKjZfo3kvN25Bwi5SQDmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ecTgO5/PVcW7jW11N0eZiywfpir6vccEvnMxKNJghlMYZN+V7zJLtQA/JSyCNAWjRn dIixVAfjrybDjR8bVE3ad7IkJIYRr3CEiMKhOTWjdxuvq2K47AwU7vIGRRApNcsRr9Pf kLF3u1F0Gs0FzMj+DZXeGgF4a6uEenKui5kfk= MIME-Version: 1.0 Received: by 10.142.60.5 with SMTP id i5mr585628wfa.285.1257616264095; Sat, 07 Nov 2009 09:51:04 -0800 (PST) Date: Sat, 7 Nov 2009 12:51:04 -0500 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Added Ulrich's security extension briefs to agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 17:50:43 -0000 I just added Ulrich's security extension briefs to agenda and uploaded. For some reason the text version is delayed showing up from the meeting materials to the proceedings link (there might be some background cron job at work here,etc) but the pdf slides are correct now and I'll check the text version later. -Joe From hrogge@googlemail.com Sun Nov 8 00:32:27 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5753A6783 for ; Sun, 8 Nov 2009 00:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p7R5NGM-6yQ for ; Sun, 8 Nov 2009 00:32:26 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0F3713A6781 for ; Sun, 8 Nov 2009 00:32:25 -0800 (PST) Received: by ewy3 with SMTP id 3so2259314ewy.37 for ; Sun, 08 Nov 2009 00:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=hvJOVg21ibBDlSx4eAuvSxn2/KBi4EqbJZG2o+5+29c=; b=ParzivHveO0enzLK63+hTZ1gUW6Rzr8GMl6K7GcfLfdFQJrFLPf20NgPCl7hxhwMEJ QkDx3CgwwS7yt3QtoQksUIECs/U8DrxSrK/EQ80v7sVVjoTJzxEmW09A6Z3yKRUevix4 hNMOPGXkuS8w+5y2TNbHeP/RjvhsY7mUQopnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=t6uMdEHijOzchGkwDkKbUp+W7QGhHc9FC7qWuI+xJWVzGl40SEiDgLmHVvO6pxfXFi rFo7kK2DVgRckiV0DPWw3hZGSmKONthRb+YWYN8MNLLzm+Ub3dI6yes9jMWwev0iLyd/ r5Buq3WsC/gIT80Ns75MJz+Y9c0JJtpKqWJk4= Received: by 10.213.45.144 with SMTP id e16mr7318190ebf.99.1257669166533; Sun, 08 Nov 2009 00:32:46 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm3054867eyf.7.2009.11.08.00.32.45 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 00:32:45 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Sun, 8 Nov 2009 09:32:39 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart114336354.yV4imh66WV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911080932.44283.hrogge@googlemail.com> Subject: [manet] Work on ETX-Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 08:32:27 -0000 --nextPart114336354.yV4imh66WV Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, after being away from all OLSR work for a week I have started working on th= e=20 text for an ETX-Draft which could be included into the OLSRv2 RFC later. It= 's=20 a simple 'exponential aging' based ETX implementation. The text is in a pretty rough state at the moment, I will have to do a litt= le=20 bit more work before we (Aaron, Emmanuel Baccelli and me) can publish a fir= st=20 draft on the list. Sorry that the draft zero is not ready for IETF. Henning Rogge --nextPart114336354.yV4imh66WV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkr2giwACgkQcenvcwAcHWfIAwCfUN41LpEbfSKu9ifvb3K5keF5 D9gAmwaxb0qOwlDlZbeGgpvxdrioIOpR =FCEI -----END PGP SIGNATURE----- --nextPart114336354.yV4imh66WV-- From teco@inf-net.nl Sun Nov 8 17:33:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9075428C0F0 for ; Sun, 8 Nov 2009 17:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.096 X-Spam-Level: * X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4iiVxpF6yzB for ; Sun, 8 Nov 2009 17:33:17 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 631F428C0E1 for ; Sun, 8 Nov 2009 17:33:16 -0800 (PST) Received: (qmail 21444 invoked from network); 9 Nov 2009 02:33:39 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 9 Nov 2009 02:33:39 +0100 From: "Teco Boot" To: Date: Mon, 9 Nov 2009 10:33:01 +0900 Message-ID: <004a01ca60dc$a9e06ed0$fda14c70$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpg3I/OwigB74q0QBqXFPmCO0dBRA== Content-Language: nl x-cr-hashedpuzzle: 1ec= Ap5F CVHg C3i+ DHSb DOjr EYFN EdvR EhXd EnDe E4kS FAdu FDjM Fpn5 Gtjj KPfb; 1; bQBhAG4AZQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {BD367D44-4805-4F79-9667-1DB5677678FE}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Mon, 09 Nov 2009 01:32:55 GMT; TgBIAEQAUAA6ACAATABpAG4AawAgAHEAdQBhAGwAaQB0AHkAIABiAGEAcwBlAGQAIABvAG4AIABzAGUAcQAtAG4AdQBtAA== x-cr-puzzleid: {BD367D44-4805-4F79-9667-1DB5677678FE} Subject: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:33:18 -0000 In NHDP-11 14.4, it is suggested that a node should receive all sequential packet sequence numbers from its neighbors. I think this is an invalid assumption. A node could send packets out of multiple interfaces. Sequence numbers are per packet, not (per packet, per interface). Teco. From teco@inf-net.nl Sun Nov 8 18:07:01 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96703A68D6 for ; Sun, 8 Nov 2009 18:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.096 X-Spam-Level: * X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdbvEyjueXLM for ; Sun, 8 Nov 2009 18:07:01 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AF6EA3A67B0 for ; Sun, 8 Nov 2009 18:07:00 -0800 (PST) Received: (qmail 13235 invoked from network); 9 Nov 2009 03:07:23 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 9 Nov 2009 03:07:23 +0100 From: "Teco Boot" To: References: <59787.62.140.137.20.1253430926.squirrel@webmail.inf-net.nl> In-Reply-To: <59787.62.140.137.20.1253430926.squirrel@webmail.inf-net.nl> Date: Mon, 9 Nov 2009 11:06:45 +0900 Message-ID: <005101ca60e1$6007ea40$2017bec0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco5wjw0+N0rZlAgQiKf81fn9dzE2QnGy6jQ Content-Language: nl Cc: manet@ietf.org Subject: [manet] NHDP: all addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:07:01 -0000 Hi Chris, You wrote: >Fundamentally, all that needs to change in NHDP is >- A relaxation of address reuse, but with the important caveat above. >- A relaxation of required address inclusion, with the condition > noted above. Is this implemented in -11? It still says "All network addresses in a router's Local Interface Set". And: * Network addresses that include all source addresses of any IP datagrams sent by the router on any MANET interface. I mentioned anycast addresses. Better not to include these in a hello protocol. I also highly prefer optimization, where the MANET router *only* advertises summary prefixes, if available. This is applicable when multiple interfaces are used, and doesn't harm the simple boxes using only one. On: * All other network addresses of the router which are to be made known to any other router for any reason. When there is no need for NHDP, let us not mandate including them in hello messages. Teco. From henning.rogge@fkie.fraunhofer.de Sun Nov 8 22:28:01 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAFE3A69D0 for ; Sun, 8 Nov 2009 22:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb0ewuyCUg2u for ; Sun, 8 Nov 2009 22:28:00 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id AAC063A69BD for ; Sun, 8 Nov 2009 22:28:00 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7Njk-0004RW-Na; Mon, 09 Nov 2009 07:28:24 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7Njk-0002Lg-EN; Mon, 09 Nov 2009 07:28:24 +0100 From: Henning Rogge To: manet@ietf.org Date: Mon, 9 Nov 2009 07:28:16 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; i686; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> In-Reply-To: <004a01ca60dc$a9e06ed0$fda14c70$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart27951789.rmAHhhhOI3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911090728.21198.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10002/Mon Nov 9 02:05:15 2009) by mailguard.fgan.de X-Scan-Signature: ad1983844cdfc65af3eaa1381589e1d9 Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:28:01 -0000 --nextPart27951789.rmAHhhhOI3 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 9 2009 02:33:01 Teco Boot wrote: > In NHDP-11 14.4, it is suggested that a node should > receive all sequential packet sequence numbers from > its neighbors. > I think this is an invalid assumption. A node could > send packets out of multiple interfaces. Sequence > numbers are per packet, not (per packet, per interface). Packet sequence numbers should be interface specific I think. It doesn't ma= ke=20 sense to make them node specific. Unfortunately Teco is right, we specified them differently in packetbb: o The field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart27951789.rmAHhhhOI3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr3toAACgkQRIfGfFXsz+C5fgCeOh3tIXvX8qka5BSg5nQDwp9z slgAn04HGsFEqsn4E2D/8FLwQTGGPQl1 =Fhnk -----END PGP SIGNATURE----- --nextPart27951789.rmAHhhhOI3-- From henning.rogge@fkie.fraunhofer.de Sun Nov 8 23:46:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2539E28C1D3 for ; Sun, 8 Nov 2009 23:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPg3HlOmaqIi for ; Sun, 8 Nov 2009 23:46:18 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 0C7C728C1CD for ; Sun, 8 Nov 2009 23:46:17 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7OxV-0001m8-4S; Mon, 09 Nov 2009 08:46:41 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7OxU-0002ci-PZ; Mon, 09 Nov 2009 08:46:40 +0100 From: Henning Rogge To: manet@ietf.org Date: Mon, 9 Nov 2009 08:46:32 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; i686; ; ) References: <59787.62.140.137.20.1253430926.squirrel@webmail.inf-net.nl> <005101ca60e1$6007ea40$2017bec0$@nl> In-Reply-To: <005101ca60e1$6007ea40$2017bec0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3210385.80k7n9k8zT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911090846.37741.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10002/Mon Nov 9 02:05:15 2009) by mailguard.fgan.de X-Scan-Signature: 342e94ff8fe4d6b52457860454fe5b62 Cc: Chris.Dearlove@baesystems.com Subject: Re: [manet] NHDP: all addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:46:19 -0000 --nextPart3210385.80k7n9k8zT Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 9 2009 03:06:45 Teco Boot wrote: > Hi Chris, >=20 > You wrote: > >Fundamentally, all that needs to change in NHDP is > >- A relaxation of address reuse, but with the important caveat above. > >- A relaxation of required address inclusion, with the condition > > noted above. >=20 > Is this implemented in -11? > It still says "All network addresses in a router's Local Interface Set". > And: > * Network addresses that include all source addresses of any IP > datagrams sent by the router on any MANET interface. >=20 > I mentioned anycast addresses. Better not to include these in a hello > protocol. > I also highly prefer optimization, where the MANET router *only* advertis= es > summary prefixes, if available. This is applicable when multiple interfac= es > are used, and doesn't harm the simple boxes using only one. >=20 > On: > * All other network addresses of the router which are to be made > known to any other router for any reason. >=20 > When there is no need for NHDP, let us not mandate including them in > hello messages. I think the idea behind this two points is that you can do two-hop routing= =20 even if you have not received TCs from your 2-hop neighbors. Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3210385.80k7n9k8zT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr3yNgACgkQRIfGfFXsz+CFswCgg38YYeKa2f4r0++Z2ZYnByDR fKYAnRtDIPbT/coZnuX51JF7xktkDhX2 =2uei -----END PGP SIGNATURE----- --nextPart3210385.80k7n9k8zT-- From teco@inf-net.nl Sun Nov 8 23:56:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B953A69F0 for ; Sun, 8 Nov 2009 23:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70+eqJI1GTWk for ; Sun, 8 Nov 2009 23:56:13 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 661FE3A695C for ; Sun, 8 Nov 2009 23:56:13 -0800 (PST) Received: (qmail 21683 invoked from network); 9 Nov 2009 08:56:36 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 9 Nov 2009 08:56:36 +0100 From: "Teco Boot" To: "'Henning Rogge'" , References: <59787.62.140.137.20.1253430926.squirrel@webmail.inf-net.nl> <005101ca60e1$6007ea40$2017bec0$@nl> <200911090846.37741.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911090846.37741.henning.rogge@fkie.fraunhofer.de> Date: Mon, 9 Nov 2009 16:55:56 +0900 Message-ID: <00bc01ca6112$28712610$79537230$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphEMqa3qVB3KutTg6l/HFPzJX3xQAAKeWQ Content-Language: nl Cc: Chris.Dearlove@baesystems.com Subject: Re: [manet] NHDP: all addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:56:14 -0000 >-----Oorspronkelijk bericht----- >Van: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >Verzonden: maandag 9 november 2009 16:47 >Aan: manet@ietf.org >CC: Teco Boot; Chris.Dearlove@baesystems.com >Onderwerp: Re: [manet] NHDP: all addresses > >On Mon November 9 2009 03:06:45 Teco Boot wrote: >> Hi Chris, >> >> You wrote: >> >Fundamentally, all that needs to change in NHDP is >> >- A relaxation of address reuse, but with the important caveat = above. >> >- A relaxation of required address inclusion, with the condition >> > noted above. >> >> Is this implemented in -11? >> It still says "All network addresses in a router's Local Interface >Set". >> And: >> * Network addresses that include all source addresses of any IP >> datagrams sent by the router on any MANET interface. >> >> I mentioned anycast addresses. Better not to include these in a hello >> protocol. >> I also highly prefer optimization, where the MANET router *only* >advertises >> summary prefixes, if available. This is applicable when multiple >interfaces >> are used, and doesn't harm the simple boxes using only one. >> >> On: >> * All other network addresses of the router which are to be made >> known to any other router for any reason. >> >> When there is no need for NHDP, let us not mandate including them in >> hello messages. >I think the idea behind this two points is that you can do two-hop >routing >even if you have not received TCs from your 2-hop neighbors. I discussed this with Justin few minutes ago. There might be an issue with reachability when the node does not send a TC, but leave this to its MPRs. These MPRs needs the prefixes. I don't like this mixed up neighborhood discovery and routing, but we have to look at it in more detail. Teco. > >Henning Rogge >-- >Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >Kommunikation, Informationsverarbeitung und Ergonomie FKIE >Kommunikationssysteme (KOM) >Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >Telefon +49 228 9435-263, Fax +49 228 9435 685 >mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From root@core3.amsl.com Mon Nov 9 00:00:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 93B853A6A01; Mon, 9 Nov 2009 00:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109080001.93B853A6A01@core3.amsl.com> Date: Mon, 9 Nov 2009 00:00:01 -0800 (PST) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-olsrv2-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2 Author(s) : U. Herberg, et al. Filename : draft-ietf-manet-olsrv2-mib-01.txt Pages : 67 Date : 2009-11-08 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring and managing aspects of the Optimized Link State Routing protocol version 2. The Optimized Link State Routing MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting Mobile Ad-Hoc Networks routing problems. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-olsrv2-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08235624.I-D@ietf.org> --NextPart-- From Chris.Dearlove@baesystems.com Mon Nov 9 01:39:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD3F3A693E for ; Mon, 9 Nov 2009 01:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGUTQSef00yH for ; Mon, 9 Nov 2009 01:39:46 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C5A9A3A6B18 for ; Mon, 9 Nov 2009 01:39:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,707,1249254000"; d="scan'208";a="31810741" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 09:39:56 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA99e34O014910; Mon, 9 Nov 2009 09:40:03 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 09:39:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 09:39:52 -0000 Message-ID: In-Reply-To: <005101ca60e1$6007ea40$2017bec0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: all addresses thread-index: Aco5wjw0+N0rZlAgQiKf81fn9dzE2QnGy6jQABB/AiA= References: <59787.62.140.137.20.1253430926.squirrel@webmail.inf-net.nl> <005101ca60e1$6007ea40$2017bec0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 09 Nov 2009 09:39:56.0694 (UTC) FILETIME=[98FB6360:01CA6120] Cc: manet@ietf.org Subject: Re: [manet] NHDP: all addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:39:47 -0000 > Is this implemented in -11? Yes. > It still says "All network addresses in a router's Local Interface Set". Yes. That's what the Local Interface Set is, all the addresses you need to include. If you don't need to include it, don't put it in the Local Interface Set. Now then Section 6 (before Section 6.1) says It is not necessary to include all addresses of an interface in the Local Information Base, and hence in HELLO messages. However any address that may be the source address of an IP datagram sent from that interface MUST be included (and at least one address MUST be included). A protocol using this specification MAY add additional requirements to these, e.g. that any address that may be the destination address of an IP datagram is also included. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 9 01:57:03 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C563A6B1D for ; Mon, 9 Nov 2009 01:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOXp1TB3viwd for ; Mon, 9 Nov 2009 01:57:02 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 6A6BA3A68FF for ; Mon, 9 Nov 2009 01:57:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,707,1249254000"; d="scan'208";a="31817270" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 09:57:28 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA99vZsm028425; Mon, 9 Nov 2009 09:57:35 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 09:57:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 09:57:26 -0000 Message-ID: In-Reply-To: <004a01ca60dc$a9e06ed0$fda14c70$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: Acpg3I/OwigB74q0QBqXFPmCO0dBRAARj6xQ References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , X-OriginalArrivalTime: 09 Nov 2009 09:57:28.0435 (UTC) FILETIME=[0BDE5430:01CA6123] Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:57:03 -0000 > Sequence numbers are per packet, not (per packet, per interface). Packet sequence numbers are how you choose to use them. Not even in the intended usage section of RFC 5444 does it say either. If you want to use them in this way then, like OLSRv1, they would need to be per interface, and it would be a good idea to say that. But it's permissible. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 9 02:00:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5783A68FE for ; Mon, 9 Nov 2009 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lJNFSzj9HuM for ; Mon, 9 Nov 2009 02:00:10 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 988393A6869 for ; Mon, 9 Nov 2009 02:00:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,707,1249254000"; d="scan'208";a="31818271" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 10:00:36 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9A0hiD030775; Mon, 9 Nov 2009 10:00:43 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:00:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 10:00:35 -0000 Message-ID: In-Reply-To: <200911090728.21198.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphBd2OEvOpRCJrQrWffqWXhZlXBQAHUPFA References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 09 Nov 2009 10:00:36.0623 (UTC) FILETIME=[7C0989F0:01CA6123] Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:00:11 -0000 Bother, I missed this one, both them and now. That requires some thought. Thanks to Teco for pointing this out. This was not the intent of course, I think this got put in in the various editing to pass reviews and was badly specified. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 09 November 2009 06:28 To: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num On Mon November 9 2009 02:33:01 Teco Boot wrote: > In NHDP-11 14.4, it is suggested that a node should > receive all sequential packet sequence numbers from > its neighbors. > I think this is an invalid assumption. A node could > send packets out of multiple interfaces. Sequence > numbers are per packet, not (per packet, per interface). Packet sequence numbers should be interface specific I think. It doesn't ma= ke=20 sense to make them node specific. Unfortunately Teco is right, we specified them differently in packetbb: o The field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Mon Nov 9 02:17:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BED3A6B34 for ; Mon, 9 Nov 2009 02:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZIcET9gd3bQ for ; Mon, 9 Nov 2009 02:17:30 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 8BE883A6B35 for ; Mon, 9 Nov 2009 02:17:30 -0800 (PST) Received: by fxm7 with SMTP id 7so914937fxm.29 for ; Mon, 09 Nov 2009 02:17:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.150.66 with SMTP id x2mr3281308bkv.9.1257761873030; Mon, 09 Nov 2009 02:17:53 -0800 (PST) In-Reply-To: References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> Date: Mon, 9 Nov 2009 19:17:53 +0900 Message-ID: <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:17:32 -0000 I agree with Teco that issue is important, also for my performance section in MIBs. Ulrich On Mon, Nov 9, 2009 at 7:00 PM, Dearlove, Christopher (UK) wrote: > Bother, I missed this one, both them and now. > > That requires some thought. Thanks to Teco for pointing this out. > This was not the intent of course, I think this got put in in the > various editing to pass reviews and was badly specified. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 =A0Fax: +44 1245 242124 > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Henning Rogge > Sent: 09 November 2009 06:28 > To: manet@ietf.org > Subject: Re: [manet] NHDP: Link quality based on seq-num > > On Mon November 9 2009 02:33:01 Teco Boot wrote: >> In NHDP-11 14.4, it is suggested that a node should >> receive all sequential packet sequence numbers from >> its neighbors. >> I think this is an invalid assumption. A node could >> send packets out of multiple interfaces. Sequence >> numbers are per packet, not (per packet, per interface). > Packet sequence numbers should be interface specific I think. It doesn't = make > sense to make them node specific. > > Unfortunately Teco is right, we specified them differently in packetbb: > > =A0 o =A0The field, if present, contains a sequence number > =A0 =A0 =A0that is incremented by 1 for each packet generated by a node. = =A0The > =A0 =A0 =A0sequence number after 65535 is 0. =A0In other words, the seque= nce > =A0 =A0 =A0number "wraps" in the usual way. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, =A0 Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From Chris.Dearlove@baesystems.com Mon Nov 9 03:03:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7633A684F for ; Mon, 9 Nov 2009 03:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKXa8VhJUWOb for ; Mon, 9 Nov 2009 03:03:13 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 531673A680D for ; Mon, 9 Nov 2009 03:03:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,707,1249254000"; d="scan'208";a="31841620" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 11:03:39 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9B3kPC015346; Mon, 9 Nov 2009 11:03:46 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:03:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 11:03:39 -0000 Message-ID: In-Reply-To: <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphJexhm10snUBYSjqWMPD2drdd5wABiXbA References: <004a01ca60dc$a9e06ed0$fda14c70$@nl><200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" X-OriginalArrivalTime: 09 Nov 2009 11:03:39.0249 (UTC) FILETIME=[4AA87610:01CA612C] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:03:14 -0000 My, not fully worked out, thought is that per interface packet sequence numbers should be allowed, or even preferred. That leaves a procedural issue of how to get from where we are to where we want to be. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Ulrich Herberg Sent: 09 November 2009 10:18 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. I agree with Teco that issue is important, also for my performance section in MIBs. Ulrich On Mon, Nov 9, 2009 at 7:00 PM, Dearlove, Christopher (UK) wrote: > Bother, I missed this one, both them and now. > > That requires some thought. Thanks to Teco for pointing this out. > This was not the intent of course, I think this got put in in the > various editing to pass reviews and was badly specified. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 =A0Fax: +44 1245 242124 > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge > Sent: 09 November 2009 06:28 > To: manet@ietf.org > Subject: Re: [manet] NHDP: Link quality based on seq-num > > On Mon November 9 2009 02:33:01 Teco Boot wrote: >> In NHDP-11 14.4, it is suggested that a node should >> receive all sequential packet sequence numbers from >> its neighbors. >> I think this is an invalid assumption. A node could >> send packets out of multiple interfaces. Sequence >> numbers are per packet, not (per packet, per interface). > Packet sequence numbers should be interface specific I think. It = doesn't make > sense to make them node specific. > > Unfortunately Teco is right, we specified them differently in = packetbb: > > =A0 o =A0The field, if present, contains a sequence = number > =A0 =A0 =A0that is incremented by 1 for each packet generated by a = node. =A0The > =A0 =A0 =A0sequence number after 65535 is 0. =A0In other words, the = sequence > =A0 =A0 =A0number "wraps" in the usual way. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, =A0 Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Nov 9 05:11:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443483A67E9 for ; Mon, 9 Nov 2009 05:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrrrEI5xaIHw for ; Mon, 9 Nov 2009 05:11:09 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 57AD43A67AE for ; Mon, 9 Nov 2009 05:11:09 -0800 (PST) Received: by bwz23 with SMTP id 23so3372204bwz.29 for ; Mon, 09 Nov 2009 05:11:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.8.65 with SMTP id g1mr8491223bkg.153.1257772287911; Mon, 09 Nov 2009 05:11:27 -0800 (PST) In-Reply-To: References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> Date: Mon, 9 Nov 2009 22:11:27 +0900 Message-ID: <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:11:10 -0000 On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) wrote: > My, not fully worked out, thought is that per interface > packet sequence numbers should be allowed, or even > preferred. That leaves a procedural issue of how to get > from where we are to where we want to be. I agree that we should allow packet sequence numbers per interface. At the moment, I cannot think about a good reason for not preferring them, but maybe there is... Ulrich From teco@inf-net.nl Mon Nov 9 06:31:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DE928C14B for ; Mon, 9 Nov 2009 06:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dLHnl6CKTvO for ; Mon, 9 Nov 2009 06:31:38 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 604333A6AE5 for ; Mon, 9 Nov 2009 06:31:38 -0800 (PST) Received: (qmail 13117 invoked from network); 9 Nov 2009 15:32:01 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 15:32:01 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> In-Reply-To: <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> Date: Mon, 9 Nov 2009 23:31:16 +0900 Message-ID: <007a01ca6149$65b09a60$3111cf20$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphPjuk7uMH0320TXm/z0bDwYf7BAACm80w Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:31:39 -0000 What if someone defines a reliable transport and suppress repeating messages? Are we sure we want to use missing sequence numbers as indication of missed packets? What if other reasons caused the loss, e.g. tail drop during congestion caused by the MANET protocol itself? Teco. >-----Oorspronkelijk bericht----- >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >Ulrich Herberg >Verzonden: maandag 9 november 2009 22:11 >Aan: Dearlove, Christopher (UK) >CC: manet@ietf.org >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > >On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) > wrote: >> My, not fully worked out, thought is that per interface >> packet sequence numbers should be allowed, or even >> preferred. That leaves a procedural issue of how to get >> from where we are to where we want to be. > >I agree that we should allow packet sequence numbers per interface. At >the moment, I cannot think about a good reason for not preferring >them, but maybe there is... > > >Ulrich >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Nov 9 06:37:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7DE3A680C for ; Mon, 9 Nov 2009 06:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.068 X-Spam-Level: X-Spam-Status: No, score=-6.068 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-cNmR5zm9L8 for ; Mon, 9 Nov 2009 06:37:25 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 288D83A63C9 for ; Mon, 9 Nov 2009 06:37:25 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7VNL-0007VU-T8; Mon, 09 Nov 2009 15:37:47 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7VNL-00051G-JN; Mon, 09 Nov 2009 15:37:47 +0100 From: Henning Rogge To: manet@ietf.org Date: Mon, 9 Nov 2009 15:37:39 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; i686; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> In-Reply-To: <007a01ca6149$65b09a60$3111cf20$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart52409226.qi52WHiQ8X"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911091537.44362.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10002/Mon Nov 9 02:05:15 2009) by mailguard.fgan.de X-Scan-Signature: b1467e4067045b82e2ed93aca61069d0 Cc: "'Dearlove, Christopher \(UK\)'" Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:37:26 -0000 --nextPart52409226.qi52WHiQ8X Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 9 2009 15:31:16 Teco Boot wrote: > What if someone defines a reliable transport and suppress > repeating messages? > Are we sure we want to use missing sequence numbers as > indication of missed packets? > What if other reasons caused the loss, e.g. tail drop during > congestion caused by the MANET protocol itself? Packet Sequence numbers have the same "range" as a linklocal IP, so I don't= =20 see any problem with reliable transports. Such a transport would be built=20 "below" packetbb, so the mechanism should be transparent to packetbb. Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart52409226.qi52WHiQ8X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr4KTMACgkQRIfGfFXsz+Bm2gCfYKtl25U/rCme64NmHeoSEhTD I/0An1993W2vubfkytAAVPZM4m0dGHC5 =GfCf -----END PGP SIGNATURE----- --nextPart52409226.qi52WHiQ8X-- From ietf@thomasclausen.org Mon Nov 9 06:38:27 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B54E3A6A2D for ; Mon, 9 Nov 2009 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAEU-r6mCaIX for ; Mon, 9 Nov 2009 06:38:26 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 60EFE3A680C for ; Mon, 9 Nov 2009 06:38:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0B0FD4302C6; Mon, 9 Nov 2009 06:38:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 024FF4302C2; Mon, 9 Nov 2009 06:38:51 -0800 (PST) Message-Id: <5C357A89-9986-4072-A11A-BA9BB9116ABD@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <007a01ca6149$65b09a60$3111cf20$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 23:38:49 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> X-Mailer: Apple Mail (2.936) Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:38:27 -0000 Teco, I think that "counting packets" is one tool that may be used, but by no means *the* tool to be used in all situations. If you're running over a lower layer with known delivery/drop properties and the ability to extract "other information" describing how good the link is (SNR, ...), then that "other information" would be a better choice for when setting quality. Thomas On Nov 9, 2009, at 11:31 PM, Teco Boot wrote: > What if someone defines a reliable transport and suppress > repeating messages? > Are we sure we want to use missing sequence numbers as > indication of missed packets? > What if other reasons caused the loss, e.g. tail drop during > congestion caused by the MANET protocol itself? > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >> Ulrich Herberg >> Verzonden: maandag 9 november 2009 22:11 >> Aan: Dearlove, Christopher (UK) >> CC: manet@ietf.org >> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >> >> On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) >> wrote: >>> My, not fully worked out, thought is that per interface >>> packet sequence numbers should be allowed, or even >>> preferred. That leaves a procedural issue of how to get >>> from where we are to where we want to be. >> >> I agree that we should allow packet sequence numbers per interface. >> At >> the moment, I cannot think about a good reason for not preferring >> them, but maybe there is... >> >> >> Ulrich >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Nov 9 06:41:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BFD13A63C9 for ; Mon, 9 Nov 2009 06:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zC+2xj2UwHQ for ; Mon, 9 Nov 2009 06:41:07 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 689C23A6774 for ; Mon, 9 Nov 2009 06:41:07 -0800 (PST) Received: by bwz23 with SMTP id 23so3466387bwz.29 for ; Mon, 09 Nov 2009 06:41:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.156.19 with SMTP id u19mr39677bkw.62.1257777690015; Mon, 09 Nov 2009 06:41:30 -0800 (PST) In-Reply-To: <007a01ca6149$65b09a60$3111cf20$@nl> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> Date: Mon, 9 Nov 2009 23:41:29 +0900 Message-ID: <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:41:08 -0000 Teco, On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot wrote: > What if someone defines a reliable transport and suppress > repeating messages? In that case, that mechanism of using packet seq. numbers would not work. But I think this is okay, since the NHDP draft does not mandate this mechanism. If one decides to use packet sequence numbers for indicating lost packets, one probably has to assume a non-reliable transport transport protocol such as UDP. > Are we sure we want to use missing sequence numbers as > indication of missed packets? No, we don't want to mandate it. It is just *one* possible way, under certain assumptions (no reliable transport protocol). > What if other reasons caused the loss, e.g. tail drop during > congestion caused by the MANET protocol itself? Well, in that case the router will face problems anyway, since it does not receive control traffic any more. Ulrich > > Teco. > >>-----Oorspronkelijk bericht----- >>Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>Ulrich Herberg >>Verzonden: maandag 9 november 2009 22:11 >>Aan: Dearlove, Christopher (UK) >>CC: manet@ietf.org >>Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >> >>On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) >> wrote: >>> My, not fully worked out, thought is that per interface >>> packet sequence numbers should be allowed, or even >>> preferred. That leaves a procedural issue of how to get >>> from where we are to where we want to be. >> >>I agree that we should allow packet sequence numbers per interface. At >>the moment, I cannot think about a good reason for not preferring >>them, but maybe there is... >> >> >>Ulrich >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > From ulrich@herberg.name Mon Nov 9 06:44:38 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F71B3A6942 for ; Mon, 9 Nov 2009 06:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnmdCWXDPEmF for ; Mon, 9 Nov 2009 06:44:37 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 280E03A692E for ; Mon, 9 Nov 2009 06:44:36 -0800 (PST) Received: by bwz23 with SMTP id 23so3470238bwz.29 for ; Mon, 09 Nov 2009 06:45:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.34.3 with SMTP id j3mr5344629bkd.23.1257777899995; Mon, 09 Nov 2009 06:44:59 -0800 (PST) In-Reply-To: <200911091537.44362.henning.rogge@fkie.fraunhofer.de> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> Date: Mon, 9 Nov 2009 23:44:59 +0900 Message-ID: <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:44:38 -0000 On Mon, Nov 9, 2009 at 11:37 PM, Henning Rogge wrote: > On Mon November 9 2009 15:31:16 Teco Boot wrote: >> What if someone defines a reliable transport and suppress >> repeating messages? >> Are we sure we want to use missing sequence numbers as >> indication of missed packets? >> What if other reasons caused the loss, e.g. tail drop during >> congestion caused by the MANET protocol itself? > Packet Sequence numbers have the same "range" as a linklocal IP, so I don't > see any problem with reliable transports. Such a transport would be built > "below" packetbb, so the mechanism should be transparent to packetbb. I don't see the relation to LL here. I think what Teco means is that if NHDP runs on a reliable transport, a very bad link (that needs many retransmissions of HELLOs) still would appear as perfect link to NDHP, because no packetbb packet is lost. So, of course the transport protocol is transparent to NHDP, but using packet seq. no. as measure of number of lost packets would not make sense any more. Ulrich From Chris.Dearlove@baesystems.com Mon Nov 9 06:47:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4663A6A05 for ; Mon, 9 Nov 2009 06:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfaAdgaazoMW for ; Mon, 9 Nov 2009 06:47:18 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 730643A63C9 for ; Mon, 9 Nov 2009 06:47:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,708,1249254000"; d="scan'208";a="31918888" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 14:47:43 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9Elo8t019868; Mon, 9 Nov 2009 14:47:50 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:47:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 14:47:38 -0000 Message-ID: In-Reply-To: <007a01ca6149$65b09a60$3111cf20$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphPjuk7uMH0320TXm/z0bDwYf7BAACm80wAABgTfA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 09 Nov 2009 14:47:44.0114 (UTC) FILETIME=[986C0D20:01CA614B] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:47:19 -0000 > What if someone defines a reliable transport and suppress > repeating messages? There are many ways in which this is not relevant - NHDP messages are local broadcast. If you have a reliable local broadcast mechanism to unknown recipients, I think we'd like to know. - The transport mechanism sees packets, not messages. These are much less likely to be repeats. but even messages may not be repeated, due to e.g. message sequence numbers and security mechanisms. - It's no business of the transport mechanism to do this. There are reasons to repeat messages due to mobility, trying to find unknown nodes etc. > Are we sure we want to use missing sequence numbers as > indication of missed packets? It's an option. Nothing in that area is something that must be done. It's not my first choice of options, I think there are better ones. But that doesn't make it unusable. > What if other reasons caused the loss, e.g. tail drop during > congestion caused by the MANET protocol itself? If your congestion gets to the point where sufficient dropping is occurring to make this happen, then there is a real problem in any case, especially if (as one should) give routing signalling a better than average priority. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 9 06:50:44 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6499E3A63C9 for ; Mon, 9 Nov 2009 06:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gKA-lf9dMII for ; Mon, 9 Nov 2009 06:50:43 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4324C3A681C for ; Mon, 9 Nov 2009 06:50:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,708,1249254000"; d="scan'208";a="31920954" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 14:51:09 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9EpGwq022706; Mon, 9 Nov 2009 14:51:16 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:51:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 14:51:03 -0000 Message-ID: In-Reply-To: <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphSzhKKdL8+rjMSeW7DLq72SQnEQAAIAGA References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , "Henning Rogge" X-OriginalArrivalTime: 09 Nov 2009 14:51:09.0528 (UTC) FILETIME=[12DBBD80:01CA614C] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:50:44 -0000 > I think what Teco means is that > if NHDP runs on a reliable transport, a very bad link (that needs many > retransmissions of HELLOs) still would appear as perfect link to NDHP, > because no packetbb packet is lost. So, of course the transport > protocol is transparent to NHDP, but using packet seq. no. as measure > of number of lost packets would not make sense any more. If you have such a reliable transport layer (except I don't believe in it because it's not unicast, but ignore that for now) then I would want the retransmission rates from that transport layer as a supplement or replacement to packet sequence number. It's not alone in that - I'd like all the information I can get. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Mon Nov 9 06:53:59 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C008E3A685E for ; Mon, 9 Nov 2009 06:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh5wBcATRYya for ; Mon, 9 Nov 2009 06:53:59 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 8CE9E3A63C9 for ; Mon, 9 Nov 2009 06:53:58 -0800 (PST) Received: by bwz23 with SMTP id 23so3480524bwz.29 for ; Mon, 09 Nov 2009 06:54:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.156.3 with SMTP id u3mr2345422bkw.179.1257778462626; Mon, 09 Nov 2009 06:54:22 -0800 (PST) In-Reply-To: References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> Date: Mon, 9 Nov 2009 23:54:22 +0900 Message-ID: <25c114b90911090654s440a1dffie29275152468f4ab@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:53:59 -0000 On Mon, Nov 9, 2009 at 11:51 PM, Dearlove, Christopher (UK) wrote: >> I think what Teco means is that >> if NHDP runs on a reliable transport, a very bad link (that needs many >> retransmissions of HELLOs) still would appear as perfect link to NDHP, >> because no packetbb packet is lost. So, of course the transport >> protocol is transparent to NHDP, but using packet seq. no. as measure >> of number of lost packets would not make sense any more. > > If you have such a reliable transport layer (except I don't > believe in it because it's not unicast, but ignore that for > now) I think this was more a theoretical assumption... > then I would want the retransmission rates from that > transport layer as a supplement or replacement to packet > sequence number. It's not alone in that - I'd like all the > information I can get. Yes, true. But this would require some cross-layer information. I agree that in that case, it would be necessary to get some information from the transport protocol. Ulrich From teco@inf-net.nl Mon Nov 9 07:03:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5ED13A6925 for ; Mon, 9 Nov 2009 07:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR2GisvAGHml for ; Mon, 9 Nov 2009 07:03:14 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 80CC83A672E for ; Mon, 9 Nov 2009 07:03:13 -0800 (PST) Received: (qmail 11843 invoked from network); 9 Nov 2009 16:03:32 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 16:03:32 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> In-Reply-To: <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> Date: Tue, 10 Nov 2009 00:02:56 +0900 Message-ID: <009e01ca614d$cceadac0$66c09040$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphSsckGc4B5RtaQ2m0hbHn1evokwAAoFag Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:03:14 -0000 Hi Ulrich, >-----Oorspronkelijk bericht----- >Van: Ulrich Herberg [mailto:ulrich@herberg.name] >Verzonden: maandag 9 november 2009 23:41 >Aan: Teco Boot >CC: Dearlove, Christopher (UK); manet@ietf.org >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > >Teco, > >On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot wrote: >> What if someone defines a reliable transport and suppress >> repeating messages? > >In that case, that mechanism of using packet seq. numbers would not >work. But I think this is okay, since the NHDP draft does not mandate >this mechanism. If one decides to use packet sequence numbers for >indicating lost packets, one probably has to assume a non-reliable >transport transport protocol such as UDP. You missed my point. The protocol would suppress the repeated info. > >> Are we sure we want to use missing sequence numbers as >> indication of missed packets? > >No, we don't want to mandate it. It is just *one* possible way, under >certain assumptions (no reliable transport protocol). But it is an impossible way, as defined today in the spec. > >> What if other reasons caused the loss, e.g. tail drop during >> congestion caused by the MANET protocol itself? > >Well, in that case the router will face problems anyway, since it does >not receive control traffic any more. And send more traffic. See a nearby museum for what can happen if a system is speeding up its own explosion. Teco. > >Ulrich > >> >> Teco. >> >>>-----Oorspronkelijk bericht----- >>>Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>Ulrich Herberg >>>Verzonden: maandag 9 november 2009 22:11 >>>Aan: Dearlove, Christopher (UK) >>>CC: manet@ietf.org >>>Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >>> >>>On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) >>> wrote: >>>> My, not fully worked out, thought is that per interface >>>> packet sequence numbers should be allowed, or even >>>> preferred. That leaves a procedural issue of how to get >>>> from where we are to where we want to be. >>> >>>I agree that we should allow packet sequence numbers per interface. At >>>the moment, I cannot think about a good reason for not preferring >>>them, but maybe there is... >>> >>> >>>Ulrich >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www.ietf.org/mailman/listinfo/manet >> >> From ietf@thomasclausen.org Mon Nov 9 07:08:30 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3BE3A687D for ; Mon, 9 Nov 2009 07:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41-RXZAiT4nx for ; Mon, 9 Nov 2009 07:08:29 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 04BFE3A6838 for ; Mon, 9 Nov 2009 07:08:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9E9A74302F3; Mon, 9 Nov 2009 07:08:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 80B264302D9; Mon, 9 Nov 2009 07:08:54 -0800 (PST) Message-Id: <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <009e01ca614d$cceadac0$66c09040$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 00:08:52 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> X-Mailer: Apple Mail (2.936) Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:08:30 -0000 On Nov 10, 2009, at 12:02 AM, Teco Boot wrote: > Hi Ulrich, > >> -----Oorspronkelijk bericht----- >> Van: Ulrich Herberg [mailto:ulrich@herberg.name] >> Verzonden: maandag 9 november 2009 23:41 >> Aan: Teco Boot >> CC: Dearlove, Christopher (UK); manet@ietf.org >> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >> >> Teco, >> >> On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot wrote: >>> What if someone defines a reliable transport and suppress >>> repeating messages? >> >> In that case, that mechanism of using packet seq. numbers would not >> work. But I think this is okay, since the NHDP draft does not mandate >> this mechanism. If one decides to use packet sequence numbers for >> indicating lost packets, one probably has to assume a non-reliable >> transport transport protocol such as UDP. > > You missed my point. > The protocol would suppress the repeated info. > Then I do not understand. Your L2 (or "something-behaving-as-L2") below IP is reliable. That's fine, you'll get 100% of packets across. A great L2 and a great feat if you can do reliable broadcast to an unknown recipient set (I'd like to learn more if you have one at hand). >>> Are we sure we want to use missing sequence numbers as >>> indication of missed packets? >> >> No, we don't want to mandate it. It is just *one* possible way, under >> certain assumptions (no reliable transport protocol). > > But it is an impossible way, as defined today in the spec. How so? Your L2 does not lend itself to "counting packets" - so you won't, you'll use something else (more appropriate to your L2) for establishing the quality. This is not only enabled by the spec, but even recommended. >>> What if other reasons caused the loss, e.g. tail drop during >>> congestion caused by the MANET protocol itself? >> >> Well, in that case the router will face problems anyway, since it >> does >> not receive control traffic any more. > > And send more traffic. See a nearby museum for what can happen if a > system > is speeding up its own explosion. I think that's an inappropriate reference. I also think that it's an inappropriate and incorrect characterization of what NHDP would do.... Thomas > > Teco. > > >> >> Ulrich >> >>> >>> Teco. >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>> Ulrich Herberg >>>> Verzonden: maandag 9 november 2009 22:11 >>>> Aan: Dearlove, Christopher (UK) >>>> CC: manet@ietf.org >>>> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >>>> >>>> On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) >>>> wrote: >>>>> My, not fully worked out, thought is that per interface >>>>> packet sequence numbers should be allowed, or even >>>>> preferred. That leaves a procedural issue of how to get >>>>> from where we are to where we want to be. >>>> >>>> I agree that we should allow packet sequence numbers per >>>> interface. At >>>> the moment, I cannot think about a good reason for not preferring >>>> them, but maybe there is... >>>> >>>> >>>> Ulrich >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Mon Nov 9 07:10:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C2E3A6B5A for ; Mon, 9 Nov 2009 07:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1NdHd9bO-v4 for ; Mon, 9 Nov 2009 07:10:13 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 77E893A696A for ; Mon, 9 Nov 2009 07:10:11 -0800 (PST) Received: (qmail 19712 invoked from network); 9 Nov 2009 16:10:33 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 16:10:33 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , "'Henning Rogge'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> In-Reply-To: <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> Date: Tue, 10 Nov 2009 00:09:56 +0900 Message-ID: <009f01ca614e$c7d970e0$578c52a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphSzcyDzwlZPcRTySaJuiFzQlFLgAApB/w Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:10:14 -0000 Hi Ulrich, >-----Oorspronkelijk bericht----- >Van: Ulrich Herberg [mailto:ulrich@herberg.name] >Verzonden: maandag 9 november 2009 23:45 >Aan: Henning Rogge >CC: manet@ietf.org; Teco Boot; Dearlove, Christopher (UK) >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > >On Mon, Nov 9, 2009 at 11:37 PM, Henning Rogge > wrote: >> On Mon November 9 2009 15:31:16 Teco Boot wrote: >>> What if someone defines a reliable transport and suppress >>> repeating messages? >>> Are we sure we want to use missing sequence numbers as >>> indication of missed packets? >>> What if other reasons caused the loss, e.g. tail drop during >>> congestion caused by the MANET protocol itself? > >> Packet Sequence numbers have the same "range" as a linklocal IP, so I >don't >> see any problem with reliable transports. Such a transport would be >built >> "below" packetbb, so the mechanism should be transparent to packetbb. > >I don't see the relation to LL here. I think what Teco means is that >if NHDP runs on a reliable transport, a very bad link (that needs many >retransmissions of HELLOs) still would appear as perfect link to NDHP, >because no packetbb packet is lost. So, of course the transport >protocol is transparent to NHDP, but using packet seq. no. as measure >of number of lost packets would not make sense any more. Yes, this is an example the mechanism breaks. I had IP layer in mind, like PIM over TCP. PIM started with repeating advertisements, but for scalability and other reasons, the protocol is extended for using reliable transfer (draft-ietf-pim-port). In my MANETs, I have low bandwidth high costs links and cannot afford the repeating MANET messages over it. With reliable multicast (or unicast, if the link is P2P), I could suppress. Sequence numbers may break this idea. Teco. > >Ulrich From teco@inf-net.nl Mon Nov 9 07:17:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7609D3A69EB for ; Mon, 9 Nov 2009 07:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIL4cx9h9Cxy for ; Mon, 9 Nov 2009 07:17:41 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 3939F3A6838 for ; Mon, 9 Nov 2009 07:17:40 -0800 (PST) Received: (qmail 26769 invoked from network); 9 Nov 2009 16:18:03 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 16:18:03 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> In-Reply-To: Date: Tue, 10 Nov 2009 00:17:26 +0900 Message-ID: <00a001ca614f$d4172e00$7c458a00$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphPjuk7uMH0320TXm/z0bDwYf7BAACm80wAABgTfAAASZzIA== Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:17:42 -0000 Hi Chris, >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: maandag 9 november 2009 23:48 >Aan: Teco Boot; Ulrich Herberg >CC: manet@ietf.org >Onderwerp: RE: [manet] NHDP: Link quality based on seq-num > >> What if someone defines a reliable transport and suppress >> repeating messages? > >There are many ways in which this is not relevant >- NHDP messages are local broadcast. If you have a reliable > local broadcast mechanism to unknown recipients, I think > we'd like to know. PGM and NORM can do the job. >- The transport mechanism sees packets, not messages. These > are much less likely to be repeats. but even messages may > not be repeated, due to e.g. message sequence numbers and > security mechanisms. Yes, see other posting. Why are the sequence numbers incremented For each packet? Sorry, it could be written in the draft and I have overlooked it. >- It's no business of the transport mechanism to do this. > There are reasons to repeat messages due to mobility, trying > to find unknown nodes etc. For hello, especially incremental hello, reliable multicast doesn't help. For TC, it is another story. >> Are we sure we want to use missing sequence numbers as >> indication of missed packets? > >It's an option. Nothing in that area is something that must >be done. It's not my first choice of options, I think there >are better ones. But that doesn't make it unusable. After the fix, I can agree. >> What if other reasons caused the loss, e.g. tail drop during >> congestion caused by the MANET protocol itself? > >If your congestion gets to the point where sufficient dropping >is occurring to make this happen, then there is a real problem in >any case, especially if (as one should) give routing signalling >a better than average priority. Yes, but broadcast queues with infinite depth have drawbacks to. Especially when giving priority to it. At least, we need some form of shaping or fair queuing. Teco. >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** From teco@inf-net.nl Mon Nov 9 07:22:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7953A6B19 for ; Mon, 9 Nov 2009 07:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpLXuTZW85+s for ; Mon, 9 Nov 2009 07:22:52 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 3F0363A6B12 for ; Mon, 9 Nov 2009 07:22:51 -0800 (PST) Received: (qmail 32707 invoked from network); 9 Nov 2009 16:23:14 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 16:23:14 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> <25c114b90911090654s440a1dffie29275152468f4ab@mail.gmail.com> In-Reply-To: <25c114b90911090654s440a1dffie29275152468f4ab@mail.gmail.com> Date: Tue, 10 Nov 2009 00:22:34 +0900 Message-ID: <00a101ca6150$8d43cff0$a7cb6fd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphTIde8euRUe+jRSm2RNy4IOjm8QAA3mAA Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:22:53 -0000 >-----Oorspronkelijk bericht----- >Van: Ulrich Herberg [mailto:ulrich@herberg.name] >Verzonden: maandag 9 november 2009 23:54 >Aan: Dearlove, Christopher (UK) >CC: Henning Rogge; manet@ietf.org; Teco Boot >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > >On Mon, Nov 9, 2009 at 11:51 PM, Dearlove, Christopher (UK) > wrote: >>> I think what Teco means is that >>> if NHDP runs on a reliable transport, a very bad link (that needs >many >>> retransmissions of HELLOs) still would appear as perfect link to >NDHP, >>> because no packetbb packet is lost. So, of course the transport >>> protocol is transparent to NHDP, but using packet seq. no. as measure >>> of number of lost packets would not make sense any more. >> >> If you have such a reliable transport layer (except I don't >> believe in it because it's not unicast, but ignore that for >> now) > >I think this was more a theoretical assumption... > >> then I would want the retransmission rates from that >> transport layer as a supplement or replacement to packet >> sequence number. It's not alone in that - I'd like all the >> information I can get. > >Yes, true. But this would require some cross-layer information. I >agree that in that case, it would be necessary to get some information >from the transport protocol. NACK based reliable multicast does not provide the info that is needed. But yes, the info that becomes available could be used for MPR selection. The idea is more serious than theoretical assumption. When the performance of MANETs degrades due to TC load, we could take a look at this. Teco. > >Ulrich From teco@inf-net.nl Mon Nov 9 07:39:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349063A684A for ; Mon, 9 Nov 2009 07:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MhY3R0rlZCE for ; Mon, 9 Nov 2009 07:39:14 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C9AC028C13A for ; Mon, 9 Nov 2009 07:39:13 -0800 (PST) Received: (qmail 16949 invoked from network); 9 Nov 2009 16:39:36 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 16:39:36 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> In-Reply-To: <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> Date: Tue, 10 Nov 2009 00:38:57 +0900 Message-ID: <00a801ca6152$d6c46c50$844d44f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphTpBQdgYyHaBrTcmryp+PSEBbkQAAfnyw Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:39:15 -0000 >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >Verzonden: dinsdag 10 november 2009 0:09 >Aan: Teco Boot >CC: 'Ulrich Herberg'; 'Dearlove, Christopher (UK)'; manet@ietf.org >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > > >On Nov 10, 2009, at 12:02 AM, Teco Boot wrote: > >> Hi Ulrich, >> >>> -----Oorspronkelijk bericht----- >>> Van: Ulrich Herberg [mailto:ulrich@herberg.name] >>> Verzonden: maandag 9 november 2009 23:41 >>> Aan: Teco Boot >>> CC: Dearlove, Christopher (UK); manet@ietf.org >>> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >>> >>> Teco, >>> >>> On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot wrote: >>>> What if someone defines a reliable transport and suppress >>>> repeating messages? >>> >>> In that case, that mechanism of using packet seq. numbers would not >>> work. But I think this is okay, since the NHDP draft does not mandate >>> this mechanism. If one decides to use packet sequence numbers for >>> indicating lost packets, one probably has to assume a non-reliable >>> transport transport protocol such as UDP. >> >> You missed my point. >> The protocol would suppress the repeated info. >> > >Then I do not understand. Your L2 (or "something-behaving-as-L2") >below IP is reliable. That's fine, you'll get 100% of packets across. 100% delivery ratio is the goal of reliable multicast. But at cost of delay and other annoying aspects. It runs at layer 4 (instead of UDP or vanilla IP). >A great L2 and a great feat if you can do reliable broadcast to an >unknown recipient set (I'd like to learn more if you have one at hand). > >>>> Are we sure we want to use missing sequence numbers as >>>> indication of missed packets? >>> >>> No, we don't want to mandate it. It is just *one* possible way, under >>> certain assumptions (no reliable transport protocol). >> >> But it is an impossible way, as defined today in the spec. > >How so? Your L2 does not lend itself to "counting packets" - so you >won't, you'll use something else (more appropriate to your L2) for >establishing the quality. > >This is not only enabled by the spec, but even recommended. Back to my first comment, the spec needs a fix. Then, we can recommend to use it. But only when sequence numbers are used. We could regret this in the future, when working on optimizing TC load. >>>> What if other reasons caused the loss, e.g. tail drop during >>>> congestion caused by the MANET protocol itself? >>> >>> Well, in that case the router will face problems anyway, since it >>> does >>> not receive control traffic any more. >> >> And send more traffic. See a nearby museum for what can happen if a >> system >> is speeding up its own explosion. > >I think that's an inappropriate reference. I've seen network meltdowns, including MANETs. This meltdown term is borrowed from nuclear catastrophes. >I also think that it's an inappropriate and incorrect characterization >of what NHDP would do.... Did I say so? But yes, network meltdowns due to chain reaction is a real world concern. It is definitely not specific to NHDP/OLSR. But these are also not immune. Can we go back to my first comment, and fix this minor issue? Teco. > >Thomas > > >> >> Teco. >> >> >>> >>> Ulrich >>> >>>> >>>> Teco. >>>> >>>>> -----Oorspronkelijk bericht----- >>>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>>> Ulrich Herberg >>>>> Verzonden: maandag 9 november 2009 22:11 >>>>> Aan: Dearlove, Christopher (UK) >>>>> CC: manet@ietf.org >>>>> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >>>>> >>>>> On Mon, Nov 9, 2009 at 8:03 PM, Dearlove, Christopher (UK) >>>>> wrote: >>>>>> My, not fully worked out, thought is that per interface >>>>>> packet sequence numbers should be allowed, or even >>>>>> preferred. That leaves a procedural issue of how to get >>>>>> from where we are to where we want to be. >>>>> >>>>> I agree that we should allow packet sequence numbers per >>>>> interface. At >>>>> the moment, I cannot think about a good reason for not preferring >>>>> them, but maybe there is... >>>>> >>>>> >>>>> Ulrich >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Mon Nov 9 07:47:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765EC3A6B7B for ; Mon, 9 Nov 2009 07:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC2u+LiZ7e80 for ; Mon, 9 Nov 2009 07:47:27 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9E8A93A6B67 for ; Mon, 9 Nov 2009 07:47:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C386243046C; Mon, 9 Nov 2009 07:47:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9610C430A70; Mon, 9 Nov 2009 07:47:52 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <00a801ca6152$d6c46c50$844d44f0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 00:47:50 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> X-Mailer: Apple Mail (2.936) Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:47:28 -0000 On Nov 10, 2009, at 12:38 AM, Teco Boot wrote: > > >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >> Verzonden: dinsdag 10 november 2009 0:09 >> Aan: Teco Boot >> CC: 'Ulrich Herberg'; 'Dearlove, Christopher (UK)'; manet@ietf.org >> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >> >> >> On Nov 10, 2009, at 12:02 AM, Teco Boot wrote: >> >>> Hi Ulrich, >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: Ulrich Herberg [mailto:ulrich@herberg.name] >>>> Verzonden: maandag 9 november 2009 23:41 >>>> Aan: Teco Boot >>>> CC: Dearlove, Christopher (UK); manet@ietf.org >>>> Onderwerp: Re: [manet] NHDP: Link quality based on seq-num >>>> >>>> Teco, >>>> >>>> On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot wrote: >>>>> What if someone defines a reliable transport and suppress >>>>> repeating messages? >>>> >>>> In that case, that mechanism of using packet seq. numbers would not >>>> work. But I think this is okay, since the NHDP draft does not >>>> mandate >>>> this mechanism. If one decides to use packet sequence numbers for >>>> indicating lost packets, one probably has to assume a non-reliable >>>> transport transport protocol such as UDP. >>> >>> You missed my point. >>> The protocol would suppress the repeated info. >>> >> >> Then I do not understand. Your L2 (or "something-behaving-as-L2") >> below IP is reliable. That's fine, you'll get 100% of packets across. > > 100% delivery ratio is the goal of reliable multicast. > But at cost of delay and other annoying aspects. > It runs at layer 4 (instead of UDP or vanilla IP). However, if you run it for NHDP, it would effectively look as a "very good L2", yes? > > >> A great L2 and a great feat if you can do reliable broadcast to an >> unknown recipient set (I'd like to learn more if you have one at >> hand). >> >>>>> Are we sure we want to use missing sequence numbers as >>>>> indication of missed packets? >>>> >>>> No, we don't want to mandate it. It is just *one* possible way, >>>> under >>>> certain assumptions (no reliable transport protocol). >>> >>> But it is an impossible way, as defined today in the spec. >> >> How so? Your L2 does not lend itself to "counting packets" - so you >> won't, you'll use something else (more appropriate to your L2) for >> establishing the quality. >> >> This is not only enabled by the spec, but even recommended. > > Back to my first comment, the spec needs a fix. Then, we can recommend > to use it. But only when sequence numbers are used. > We could regret this in the future, when working on optimizing TC > load. What do you suggest to fix in the spec? If it does say "you MUST use sequence number counting", then the spec is wrong. If the spec says that "sequence number counting MAY be used, if nothing better is available", then I am not sure what's wrong? Thomas From Chris.Dearlove@baesystems.com Mon Nov 9 08:52:57 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA143A69B2 for ; Mon, 9 Nov 2009 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9-uFDKMXH8Z for ; Mon, 9 Nov 2009 08:52:57 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D2D153A67B2 for ; Mon, 9 Nov 2009 08:52:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,709,1249254000"; d="scan'208";a="31960819" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 16:53:22 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9GrTJC016150; Mon, 9 Nov 2009 16:53:29 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 16:53:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 16:53:22 -0000 Message-ID: In-Reply-To: <009f01ca614e$c7d970e0$578c52a0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphSzcyDzwlZPcRTySaJuiFzQlFLgAApB/wAAPOouA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> <009f01ca614e$c7d970e0$578c52a0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" , "Henning Rogge" X-OriginalArrivalTime: 09 Nov 2009 16:53:23.0059 (UTC) FILETIME=[25FBC430:01CA615D] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:52:57 -0000 > In my MANETs, I have low bandwidth high costs links and cannot afford > the repeating MANET messages over it. Change the message intervals, possibly adaptively. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 9 08:55:55 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8C43A6A29 for ; Mon, 9 Nov 2009 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqMhUHmOLR1b for ; Mon, 9 Nov 2009 08:55:54 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 34A343A69B2 for ; Mon, 9 Nov 2009 08:55:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,709,1249254000"; d="scan'208";a="31961612" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 09 Nov 2009 16:56:20 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA9GuR8I018008; Mon, 9 Nov 2009 16:56:27 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 16:56:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 16:56:20 -0000 Message-ID: In-Reply-To: <00a801ca6152$d6c46c50$844d44f0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphTpBQdgYyHaBrTcmryp+PSEBbkQAAfnywAAM1OIA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Heide Clausen" X-OriginalArrivalTime: 09 Nov 2009 16:56:20.0558 (UTC) FILETIME=[8FC7F6E0:01CA615D] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:55:55 -0000 > Can we go back to my first comment, and fix this minor issue? Assuming that's the "packet sequence numbers should be per interface, not per node/router to be useful" then yes. I'm not sure what the appropriate procedure is (errata to RFC 5444?). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ietf@thomasclausen.org Mon Nov 9 09:00:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3108D3A6B05 for ; Mon, 9 Nov 2009 09:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DESc3d8in7gz for ; Mon, 9 Nov 2009 09:00:10 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3C0FA3A67C2 for ; Mon, 9 Nov 2009 09:00:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DE2DB4303DE; Mon, 9 Nov 2009 09:00:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C86FB4303B8; Mon, 9 Nov 2009 09:00:35 -0800 (PST) Message-Id: <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> From: Thomas Heide Clausen To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 02:00:32 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:00:11 -0000 On Nov 10, 2009, at 1:56 AM, Dearlove, Christopher (UK) wrote: >> Can we go back to my first comment, and fix this minor issue? > > Assuming that's the "packet sequence numbers should be > per interface, not per node/router to be useful" then > yes. I'm not sure what the appropriate procedure is > (errata to RFC 5444?). > Unless I recall a really good reason for it being as it is in 5444, then I agree with Chris. We talked earlier today and couldn't recall any justifications, so it might just have slipped through the editing cracks (drat!). Give me a couple of days after this IETF to dig through my archives of notes - failing any discoveries, we issue an errata? Thomas From teco@inf-net.nl Mon Nov 9 11:48:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DA63A68C1 for ; Mon, 9 Nov 2009 11:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv8mTZh+NFjf for ; Mon, 9 Nov 2009 11:48:01 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 35CC43A682B for ; Mon, 9 Nov 2009 11:48:00 -0800 (PST) Received: (qmail 1384 invoked from network); 9 Nov 2009 20:48:18 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 20:48:18 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> In-Reply-To: Date: Tue, 10 Nov 2009 04:47:39 +0900 Message-ID: <00bb01ca6175$94a10950$bde31bf0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 x-cr-puzzleid: {450609F7-A38A-4A42-BCDC-4FF24E24ABD7} x-cr-hashedpuzzle: EMRm I+Vf J3dA LBmk SCL5 V1vR WNDg YtiS ZCQj aT6g ekub lfAE mEnL mbpi nsoh sgTT; 4; YwBoAHIAaQBzAC4AZABlAGEAcgBsAG8AdgBlAEAAYgBhAGUAcwB5AHMAdABlAG0AcwAuAGMAbwBtADsAaQBlAHQAZgBAAHQAaABvAG0AYQBzAGMAbABhAHUAcwBlAG4ALgBvAHIAZwA7AG0AYQBuAGUAdABAAGkAZQB0AGYALgBvAHIAZwA7AHUAbAByAGkAYwBoAEAAaABlAHIAYgBlAHIAZwAuAG4AYQBtAGUA; Sosha1_v1; 7; {450609F7-A38A-4A42-BCDC-4FF24E24ABD7}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Mon, 09 Nov 2009 19:47:17 GMT; UgBFADoAIABbAG0AYQBuAGUAdABdACAATgBIAEQAUAA6ACAATABpAG4AawAgAHEAdQBhAGwAaQB0AHkAIABiAGEAcwBlAGQAIABvAG4AIABzAGUAcQAtAG4AdQBtAA== Thread-Index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOg Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:48:02 -0000 Hi Thomas, >>>>>> What if someone defines a reliable transport and suppress >>>>>> repeating messages? >>>>> >>>>> In that case, that mechanism of using packet seq. numbers would not >>>>> work. But I think this is okay, since the NHDP draft does not >>>>> mandate >>>>> this mechanism. If one decides to use packet sequence numbers for >>>>> indicating lost packets, one probably has to assume a non-reliable >>>>> transport transport protocol such as UDP. >>>> >>>> You missed my point. >>>> The protocol would suppress the repeated info. >>>> >>> >>> Then I do not understand. Your L2 (or "something-behaving-as-L2") >>> below IP is reliable. That's fine, you'll get 100% of packets across. >> >> 100% delivery ratio is the goal of reliable multicast. >> But at cost of delay and other annoying aspects. >> It runs at layer 4 (instead of UDP or vanilla IP). > >However, if you run it for NHDP, it would effectively look as a "very >good L2", yes? Yes. I did not suggest exchanging hello messages over it. For TCs, originated from over the place, it would make sense. OSPF tackles the problem from the other end of the spectrum, here we have only the reliable LSA transfer. >>> A great L2 and a great feat if you can do reliable broadcast to an >>> unknown recipient set (I'd like to learn more if you have one at >>> hand). >>> >>>>>> Are we sure we want to use missing sequence numbers as >>>>>> indication of missed packets? >>>>> >>>>> No, we don't want to mandate it. It is just *one* possible way, >>>>> under >>>>> certain assumptions (no reliable transport protocol). >>>> >>>> But it is an impossible way, as defined today in the spec. >>> >>> How so? Your L2 does not lend itself to "counting packets" - so you >>> won't, you'll use something else (more appropriate to your L2) for >>> establishing the quality. >>> >>> This is not only enabled by the spec, but even recommended. >> >> Back to my first comment, the spec needs a fix. Then, we can recommend >> to use it. But only when sequence numbers are used. >> We could regret this in the future, when working on optimizing TC >> load. > >What do you suggest to fix in the spec? If it does say "you MUST use >sequence number counting", then the spec is wrong. If the spec says >that "sequence number counting MAY be used, if nothing better is >available", then I am not sure what's wrong? I recommend using hello messages sequence numbers only. It need more thoughts, but what about using hello msg-seq-num? Hello messages could have msg-seq-num per interface. Then, we have the timer based detection and the sequence number detection, both using hello messages. We need a RFC5444 errata on msg-seq-num if we use this. I think it makes sense to have hello incrementing msg-seq-num per interface and incrementing TC msg-seq-num per message. The errata would say incrementing sequence numbers for 1-hop advertized messages and packets must have per interface numberspaces. For TCs, I prefer not incrementing the msg-seq-num for repeating, identical messages. Then, suppression or reliable transfer with regenerating the repeating messages becomes doable. Also, the receiving node has better knowledge on having a topology update or not, by checking the sequence number only. Little gain here, but still. With this approach, the OLSR spec would say the repeating TC message is not regenerated each time send out. The mechanism shall be implemented on a generating node A for support for a suppressing node B. So it needs implementation on all nodes for interoperability. Teco. From teco@inf-net.nl Mon Nov 9 11:53:36 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30573A68D1 for ; Mon, 9 Nov 2009 11:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU7ySOyJYWWv for ; Mon, 9 Nov 2009 11:53:36 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7B8BD3A67C2 for ; Mon, 9 Nov 2009 11:53:35 -0800 (PST) Received: (qmail 6308 invoked from network); 9 Nov 2009 20:53:54 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 20:53:54 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> <009f01ca614e$c7d970e0$578c52a0$@nl> In-Reply-To: Date: Tue, 10 Nov 2009 04:53:15 +0900 Message-ID: <00bc01ca6176$5cc01d90$164058b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphSzcyDzwlZPcRTySaJuiFzQlFLgAApB/wAAPOouAABfbrIA== Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:53:36 -0000 >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: dinsdag 10 november 2009 1:53 >Aan: Teco Boot; Ulrich Herberg; Henning Rogge >CC: manet@ietf.org >Onderwerp: RE: [manet] NHDP: Link quality based on seq-num > >> In my MANETs, I have low bandwidth high costs links and cannot afford >> the repeating MANET messages over it. > >Change the message intervals, possibly adaptively. This won't work in a heterogeneous network. On parts in the MANET, we can afford and take the benefits of high rate repeating messages, where in other parts this would overwhelm the link. The hop-limit feature is helping somewhat, but not sufficient. Teco. From hrogge@googlemail.com Mon Nov 9 12:09:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F503A68F8 for ; Mon, 9 Nov 2009 12:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqC8rEQHFMKA for ; Mon, 9 Nov 2009 12:09:46 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 0B73D3A694E for ; Mon, 9 Nov 2009 12:09:36 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so245450eyf.51 for ; Mon, 09 Nov 2009 12:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=SnV21xE81CyEvwJ5hHbpnGNYP9YZlN62XhbenypB7z4=; b=rvHOXIG1Lxi1+hBNgvubIqKX0pr46atuZO11gtFK/6LonXppgM9cx95aspddix/FTb VjtCZkmLZu44qciNxaZuR2yhVyAT7cKV7RbU7fIKcdO3ILp3Kq/wE1FnlgqhlAwwZAjN YFgQa8iBM9E9BbSovnZielJcnv2AmZWMzTJj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=sACJC8a0pmtU0BgNUX88dnMPW9R1CYUuGr7PszExH5HgfaAoXoc0JLjmqmUiupDxO0 uJgDx4ojUMnyv0LmMJ294NwxuBNbwj5pgjrCFtpK4sTWb5oNDdpTfCF7frInF6jcLjyA kWTl6hCb+p116FFNvp+5JJB0z9yez3kDIkbYY= Received: by 10.213.26.140 with SMTP id e12mr3916411ebc.0.1257797397846; Mon, 09 Nov 2009 12:09:57 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 24sm65165eyx.45.2009.11.09.12.09.56 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 12:09:56 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Mon, 9 Nov 2009 21:09:45 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <00bb01ca6175$94a10950$bde31bf0$@nl> In-Reply-To: <00bb01ca6175$94a10950$bde31bf0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1836740.6vGqVyngKP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911092109.50512.hrogge@googlemail.com> Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:09:47 -0000 --nextPart1836740.6vGqVyngKP Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 09 November 2009 20:47:39 schrieb Teco Boot: > Hi Thomas, > I recommend using hello messages sequence numbers only. I thought we were talking about packet sequence numbers. Message sequence=20 numbers are something totally different. > It need more thoughts, but what about using hello msg-seq-num? > Hello messages could have msg-seq-num per interface. Then, we > have the timer based detection and the sequence number detection, > both using hello messages. > We need a RFC5444 errata on msg-seq-num if we use this. > I think it makes sense to have hello incrementing msg-seq-num per > interface and incrementing TC msg-seq-num per message. The errata > would say incrementing sequence numbers for 1-hop advertized messages > and packets must have per interface numberspaces. I don't think that makes sense Teco. =20 > For TCs, I prefer not incrementing the msg-seq-num for repeating, > identical messages. Then, suppression or reliable transfer with > regenerating the repeating messages becomes doable. > Also, the receiving node has better knowledge on having a topology > update or not, by checking the sequence number only. Little gain here, > but still. That's why TCs have an answer-set number. > With this approach, the OLSR spec would say the repeating TC message is > not regenerated each time send out. The mechanism shall be implemented > on a generating node A for support for a suppressing node B. So it needs > implementation on all nodes for interoperability. I think you are really mixing up multiple sequence numbers in OLSR. At the= =20 moment we have three different numbers: 1.) packet sequence numbers. They have some kind of "link local scope" and = can=20 be used for estimating the packet loss on a link. 2.) message sequence numbers. These are "end to end", generated by the=20 originator of the message and are used for duplicate detection. 3.) answer set numbers. They are only in the TCs and are increased every ti= mes=20 the topology information a nodes sends has changed. Henning Rogge --nextPart1836740.6vGqVyngKP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkr4dw4ACgkQcenvcwAcHWenFgCgg1tykYeurPF2FBgO2Cbb3rKH fswAn0fSXOXiCfEeKCO262Fuubm/0iL1 =bU1z -----END PGP SIGNATURE----- --nextPart1836740.6vGqVyngKP-- From teco@inf-net.nl Mon Nov 9 14:46:57 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DF728C0EF for ; Mon, 9 Nov 2009 14:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgfNnbHnn4dq for ; Mon, 9 Nov 2009 14:46:57 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 91EEC3A69BC for ; Mon, 9 Nov 2009 14:46:56 -0800 (PST) Received: (qmail 8101 invoked from network); 9 Nov 2009 23:47:19 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 9 Nov 2009 23:47:19 +0100 From: "Teco Boot" To: "'Henning Rogge'" , References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <00bb01ca6175$94a10950$bde31bf0$@nl> <200911092109.50512.hrogge@googlemail.com> In-Reply-To: <200911092109.50512.hrogge@googlemail.com> Date: Tue, 10 Nov 2009 07:46:36 +0900 Message-ID: <00d501ca618e$966bd4e0$c3437ea0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpheJzpP1fWFfUzTWmKzZEdqMIRJwAE5KLQ Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:46:57 -0000 Hi Henning, >-----Oorspronkelijk bericht----- >Van: Henning Rogge [mailto:hrogge@googlemail.com] >Verzonden: dinsdag 10 november 2009 5:10 >Aan: manet@ietf.org >CC: Teco Boot; 'Thomas Heide Clausen'; 'Dearlove, Christopher (UK)' >Onderwerp: Re: [manet] NHDP: Link quality based on seq-num > >Am Montag 09 November 2009 20:47:39 schrieb Teco Boot: >> Hi Thomas, >> I recommend using hello messages sequence numbers only. >I thought we were talking about packet sequence numbers. Message >sequence >numbers are something totally different. Yes. But my recommendation is to use msg-seq-num. I'm not sure all packets send via an interface are received by all neighbors. For hello's, I'll say this is a valid assumption. Or we can make it mandatory for NHDP. I heard Justin the other day promoting PacketBB for a very different application. What if I write a draft on multicast joins / prunes, that uses unicast? >> It need more thoughts, but what about using hello msg-seq-num? >> Hello messages could have msg-seq-num per interface. Then, we >> have the timer based detection and the sequence number detection, >> both using hello messages. >> We need a RFC5444 errata on msg-seq-num if we use this. >> I think it makes sense to have hello incrementing msg-seq-num per >> interface and incrementing TC msg-seq-num per message. The errata >> would say incrementing sequence numbers for 1-hop advertized messages >> and packets must have per interface numberspaces. >I don't think that makes sense Teco. > >> For TCs, I prefer not incrementing the msg-seq-num for repeating, >> identical messages. Then, suppression or reliable transfer with >> regenerating the repeating messages becomes doable. >> Also, the receiving node has better knowledge on having a topology >> update or not, by checking the sequence number only. Little gain here, >> but still. >That's why TCs have an answer-set number. It must have been the product of jet-lag, readability of the draft and a TLV for just a seq-num. By the way, did you mean the sequence number as value in TLV CONT_SEQ_NUM, called ANSN?. > >> With this approach, the OLSR spec would say the repeating TC message >is >> not regenerated each time send out. The mechanism shall be implemented >> on a generating node A for support for a suppressing node B. So it >needs >> implementation on all nodes for interoperability. >I think you are really mixing up multiple sequence numbers in OLSR. At >the >moment we have three different numbers: > >1.) packet sequence numbers. They have some kind of "link local scope" >and can >be used for estimating the packet loss on a link. IMHO this is not always true. >2.) message sequence numbers. These are "end to end", generated by the >originator of the message and are used for duplicate detection. OK. But then, are they mandatory for TC? >3.) answer set numbers. They are only in the TCs and are increased every >times >the topology information a nodes sends has changed. Is this OLSRv2? I need more time to read this over. Teco. From ulrich@herberg.name Mon Nov 9 16:51:45 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7CE3A69CB for ; Mon, 9 Nov 2009 16:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IeWyPpfVi7l for ; Mon, 9 Nov 2009 16:51:44 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6E7663A69C1 for ; Mon, 9 Nov 2009 16:51:44 -0800 (PST) Received: by bwz23 with SMTP id 23so4057595bwz.29 for ; Mon, 09 Nov 2009 16:52:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.150.66 with SMTP id x2mr4311010bkv.9.1257814326987; Mon, 09 Nov 2009 16:52:06 -0800 (PST) In-Reply-To: <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> Date: Tue, 10 Nov 2009 09:52:06 +0900 Message-ID: <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:51:45 -0000 Thomas, On Tue, Nov 10, 2009 at 2:00 AM, Thomas Heide Clausen wrote: >[..] >> Assuming that's the "packet sequence numbers should be >> per interface, not per node/router to be useful" then >> yes. I'm not sure what the appropriate procedure is >> (errata to RFC 5444?). >> > > Unless I recall a really good reason for it being as it is in 5444, then I > agree with Chris. We talked earlier today and couldn't recall any > justifications, so it might just have slipped through the editing cracks > (drat!). > > Give me a couple of days after this IETF to dig through my archives of notes > - failing any discoveries, we issue an errata? Yes, I think that should be considered. Using packet seq number per interface instead of per node should solve the problem. Ulrich From ulrich@herberg.name Mon Nov 9 16:57:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250053A69DE for ; Mon, 9 Nov 2009 16:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMV62PlPVEc3 for ; Mon, 9 Nov 2009 16:57:10 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 33B4F3A6959 for ; Mon, 9 Nov 2009 16:57:10 -0800 (PST) Received: by bwz23 with SMTP id 23so4060468bwz.29 for ; Mon, 09 Nov 2009 16:57:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.150.69 with SMTP id x5mr4377968bkv.197.1257814651925; Mon, 09 Nov 2009 16:57:31 -0800 (PST) In-Reply-To: <200911092109.50512.hrogge@googlemail.com> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <00bb01ca6175$94a10950$bde31bf0$@nl> <200911092109.50512.hrogge@googlemail.com> Date: Tue, 10 Nov 2009 09:57:31 +0900 Message-ID: <25c114b90911091657w3d75ab99me02dfaaadf757376@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:57:11 -0000 On Tue, Nov 10, 2009 at 5:09 AM, Henning Rogge wrote: > I think you are really mixing up multiple sequence numbers in OLSR. At the > moment we have three different numbers: Are we talking about OLSR or OLSRv2 here? I assume the latter... > 1.) packet sequence numbers. They have some kind of "link local scope" and can > be used for estimating the packet loss on a link. > > 2.) message sequence numbers. These are "end to end", generated by the > originator of the message and are used for duplicate detection. > > 3.) answer set numbers. They are only in the TCs and are increased every times > the topology information a nodes sends has changed. This is an accurate description (besides that it's not "answer set number", but "Advertised Neighbor Sequence Number" or ANSN). Ulrich From ietf@thomasclausen.org Mon Nov 9 16:59:54 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E56F3A6870 for ; Mon, 9 Nov 2009 16:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J33GANXvJX6T for ; Mon, 9 Nov 2009 16:59:53 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 8C2753A682A for ; Mon, 9 Nov 2009 16:59:53 -0800 (PST) Received: from host-25-26.meeting.ietf.org ([133.93.25.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1N7f5n-0001kZ-La; Tue, 10 Nov 2009 01:00:19 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 133.93.25.26 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/uGw2RB0Wgv3lOj9dHQIuP Message-Id: <4D0A069E-3B54-4DDA-AF40-404CC9A532CE@thomasclausen.org> From: Thomas Heide Clausen To: Ulrich Herberg In-Reply-To: <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 10:00:14 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:59:54 -0000 On Nov 10, 2009, at 9:52 AM, Ulrich Herberg wrote: > Thomas, > > On Tue, Nov 10, 2009 at 2:00 AM, Thomas Heide Clausen > wrote: >> [..] >>> Assuming that's the "packet sequence numbers should be >>> per interface, not per node/router to be useful" then >>> yes. I'm not sure what the appropriate procedure is >>> (errata to RFC 5444?). >>> >> >> Unless I recall a really good reason for it being as it is in 5444, >> then I >> agree with Chris. We talked earlier today and couldn't recall any >> justifications, so it might just have slipped through the editing >> cracks >> (drat!). >> >> Give me a couple of days after this IETF to dig through my archives >> of notes >> - failing any discoveries, we issue an errata? > > Yes, I think that should be considered. Using packet seq number per > interface instead of per node should solve the problem. > Agree. I just want to check that it's like it is "by accident" and not "by forgotten reason" :) Thomas From jdean@itd.nrl.navy.mil Mon Nov 9 20:40:52 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCAF3A6820 for ; Mon, 9 Nov 2009 20:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUKs-zm9HKEj for ; Mon, 9 Nov 2009 20:40:52 -0800 (PST) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id EC98F3A680F for ; Mon, 9 Nov 2009 20:40:51 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id nAA4f9l2030950; Mon, 9 Nov 2009 23:41:09 -0500 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009110923410905652 ; Mon, 09 Nov 2009 23:41:09 -0500 From: "Justin Dean" To: "'Ulrich Herberg'" , "'Thomas Heide Clausen'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> In-Reply-To: <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> Date: Mon, 9 Nov 2009 23:38:52 -0500 Message-ID: <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphoBsNdKbns9JQRPSS6F66Rn+d1AAHzSqQ Content-Language: en-us Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:40:52 -0000 I understand the argument for changing packet sequence numbers from global space to interface spaces, and think I have actually made this argument in the past, but I have a nagging feeling that there is some drawback which we are currently missing. Aggregated interface reception perhaps? Justin > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Ulrich Herberg > Sent: Monday, November 09, 2009 7:52 PM > To: Thomas Heide Clausen > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] NHDP: Link quality based on seq-num > > Thomas, > > On Tue, Nov 10, 2009 at 2:00 AM, Thomas Heide Clausen > wrote: > >[..] > >> Assuming that's the "packet sequence numbers should be > >> per interface, not per node/router to be useful" then > >> yes. I'm not sure what the appropriate procedure is > >> (errata to RFC 5444?). > >> > > > > Unless I recall a really good reason for it being as it is in 5444, > then I > > agree with Chris. We talked earlier today and couldn't recall any > > justifications, so it might just have slipped through the editing > cracks > > (drat!). > > > > Give me a couple of days after this IETF to dig through my archives > of notes > > - failing any discoveries, we issue an errata? > > Yes, I think that should be considered. Using packet seq number per > interface instead of per node should solve the problem. > > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Nov 9 23:59:03 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E564828C123 for ; Mon, 9 Nov 2009 23:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjyKA5S4Y9Rk for ; Mon, 9 Nov 2009 23:59:02 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9DC913A6A5C for ; Mon, 9 Nov 2009 23:59:02 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7ldN-0004vN-G9; Tue, 10 Nov 2009 08:59:25 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7ldN-0003CH-6X; Tue, 10 Nov 2009 08:59:25 +0100 From: Henning Rogge To: manet@ietf.org Date: Tue, 10 Nov 2009 08:59:16 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; i686; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911092109.50512.hrogge@googlemail.com> <00d501ca618e$966bd4e0$c3437ea0$@nl> In-Reply-To: <00d501ca618e$966bd4e0$c3437ea0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6107824.LlcEry3W1Y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911100859.21849.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10007/Tue Nov 10 05:25:38 2009) by mailguard.fgan.de X-Scan-Signature: d30200c21c60a9b233cad81e378f9ae8 Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:59:04 -0000 --nextPart6107824.LlcEry3W1Y Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 9 2009 23:46:36 Teco Boot wrote: > Hi Henning, > >I thought we were talking about packet sequence numbers. Message > >sequence > >numbers are something totally different. >=20 > Yes. But my recommendation is to use msg-seq-num. I'm not sure > all packets send via an interface are received by all neighbors. > For hello's, I'll say this is a valid assumption. Or we can make > it mandatory for NHDP. I heard Justin the other day promoting > PacketBB for a very different application. What if I write a > draft on multicast joins / prunes, that uses unicast? The packetbb IANA RFC 5498 suggests to use a linklocal multicast group for= =20 sending NHDP/OLSRv2/... packets. So I think it's mandatory that all=20 transmitted TCs will be received by all neighbors. > >> It need more thoughts, but what about using hello msg-seq-num? > >> Hello messages could have msg-seq-num per interface. Then, we > >> have the timer based detection and the sequence number detection, > >> both using hello messages. > >> We need a RFC5444 errata on msg-seq-num if we use this. > >> I think it makes sense to have hello incrementing msg-seq-num per > >> interface and incrementing TC msg-seq-num per message. The errata > >> would say incrementing sequence numbers for 1-hop advertized messages > >> and packets must have per interface numberspaces. > > > >I don't think that makes sense Teco. > > > >> For TCs, I prefer not incrementing the msg-seq-num for repeating, > >> identical messages. Then, suppression or reliable transfer with > >> regenerating the repeating messages becomes doable. > >> Also, the receiving node has better knowledge on having a topology > >> update or not, by checking the sequence number only. Little gain here, > >> but still. > > > >That's why TCs have an answer-set number. > It must have been the product of jet-lag, readability of the draft and > a TLV for just a seq-num. By the way, did you mean the sequence number > as value in TLV CONT_SEQ_NUM, called ANSN?. Yes, sorry... ANSN (advertised neighbor sequence number) =20 > >> With this approach, the OLSR spec would say the repeating TC message > > > >is > > > >> not regenerated each time send out. The mechanism shall be implemented > >> on a generating node A for support for a suppressing node B. So it > > > >needs > > > >> implementation on all nodes for interoperability. > > > >I think you are really mixing up multiple sequence numbers in OLSR. At > >the > >moment we have three different numbers: > > > >1.) packet sequence numbers. They have some kind of "link local scope" > >and can > >be used for estimating the packet loss on a link. >=20 > IMHO this is not always true. It can be used to estimate the packet loss on the layer NHDP/OLSRv2 is work= ing=20 on. Of course this is not the true packet loss if you have a retransmission= on=20 a lower layer. > >2.) message sequence numbers. These are "end to end", generated by the > >originator of the message and are used for duplicate detection. >=20 > OK. But then, are they mandatory for TC? > >3.) answer set numbers. They are only in the TCs and are increased every > >times > >the topology information a nodes sends has changed. >=20 > Is this OLSRv2? > I need more time to read this over. OLSRv2 draft, section 8.2: A TC message MUST contain: =2E... o and elements, as specified in [RFC5444]. =2E.. o A single Message TLV with Type :=3D CONT_SEQ_NUM, and Type Extension :=3D COMPLETE or Type Extension :=3D INCOMPLETE, as specified in Section 8.2.1 (for complete and incomplete TC messages, respectively) except that the latter MAY be omitted if the message does not contain any addresses associated with a TLV with Type =3D NBR_ADDR_TYPE or Type =3D GATEWAY. So yes, message sequence numbers and CONT_SEQ_NUM (which contains the ANSN)= =20 are mandatory for TCs. Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart6107824.LlcEry3W1Y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr5HVUACgkQRIfGfFXsz+BRwQCfY+b5cubexu35L3EehOUYUOAb a1wAn1P99aykf49kdzYRACFZJ4ehAI+A =I+3n -----END PGP SIGNATURE----- --nextPart6107824.LlcEry3W1Y-- From henning.rogge@fkie.fraunhofer.de Tue Nov 10 00:28:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2B43A6A63 for ; Tue, 10 Nov 2009 00:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaSxj7QtD78L for ; Tue, 10 Nov 2009 00:28:32 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id DB30C3A6A2E for ; Tue, 10 Nov 2009 00:28:31 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7m5u-00059j-Sw; Tue, 10 Nov 2009 09:28:54 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7m5u-0003MA-Je; Tue, 10 Nov 2009 09:28:54 +0100 From: Henning Rogge To: manet@ietf.org Date: Tue, 10 Nov 2009 09:28:40 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> In-Reply-To: <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1727224.Po97fmeAS3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911100928.51433.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10007/Tue Nov 10 05:25:38 2009) by mailguard.fgan.de X-Scan-Signature: b1467e4067045b82e2ed93aca61069d0 Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:28:32 -0000 --nextPart1727224.Po97fmeAS3 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 10 2009 05:38:52 Justin Dean wrote: > I understand the argument for changing packet sequence numbers from global > space to interface spaces, and think I have actually made this argument in > the past, but I have a nagging feeling that there is some drawback which = we > are currently missing. Aggregated interface reception perhaps? Hmm... what is the advantage of using packet sequence numbers per node instead of = per=20 interface ? Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1727224.Po97fmeAS3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr5JDgACgkQRIfGfFXsz+CRowCfTFqs4S1V0f+mtZkYu+uqHYNY B6QAnRZ0YlADVfKSkirDfnymeV1iOSKY =hRIX -----END PGP SIGNATURE----- --nextPart1727224.Po97fmeAS3-- From teco@inf-net.nl Tue Nov 10 06:04:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5909728C0ED for ; Tue, 10 Nov 2009 06:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1oKQ0fbkwXM for ; Tue, 10 Nov 2009 06:04:46 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 40A6D28C0E0 for ; Tue, 10 Nov 2009 06:04:45 -0800 (PST) Received: (qmail 26642 invoked from network); 10 Nov 2009 15:05:09 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 10 Nov 2009 15:05:09 +0100 From: "Teco Boot" To: "'Henning Rogge'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911100928.51433.henning.rogge@fkie.fraunhofer.de> Date: Tue, 10 Nov 2009 23:04:30 +0900 Message-ID: <016d01ca620e$cf184960$6d48dc20$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acph3+WIakxB0wlXTzevw+/XitUQ2AALf3/Q Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:04:47 -0000 >On Tue November 10 2009 05:38:52 Justin Dean wrote: >> I understand the argument for changing packet sequence numbers from >global >> space to interface spaces, and think I have actually made this >argument in >> the past, but I have a nagging feeling that there is some drawback >which we >> are currently missing. Aggregated interface reception perhaps? Henning: >Hmm... >what is the advantage of using packet sequence numbers per node instead >of per >interface ? If two interfaces are on same medium, we have the aggregation. There are other issues with such a setup, e.g. per_interface_MPR. Is this scenario analyzed before? Teco. From henning.rogge@fkie.fraunhofer.de Tue Nov 10 06:48:01 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309F128C18E for ; Tue, 10 Nov 2009 06:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNNlqgx-0izq for ; Tue, 10 Nov 2009 06:48:00 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 4490C28C125 for ; Tue, 10 Nov 2009 06:48:00 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7s16-00040Y-EH; Tue, 10 Nov 2009 15:48:20 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7s16-0005MB-3L; Tue, 10 Nov 2009 15:48:20 +0100 From: Henning Rogge To: "Teco Boot" Date: Tue, 10 Nov 2009 15:48:11 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> In-Reply-To: <016d01ca620e$cf184960$6d48dc20$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7314983.W7nqz9IOSC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911101548.16805.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10009/Tue Nov 10 13:25:46 2009) by mailguard.fgan.de X-Scan-Signature: b1467e4067045b82e2ed93aca61069d0 Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:48:01 -0000 --nextPart7314983.W7nqz9IOSC Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 10 2009 15:04:30 Teco Boot wrote: > If two interfaces are on same medium, we have the aggregation. > There are other issues with such a setup, e.g. per_interface_MPR. > Is this scenario analyzed before? You mean two interfaces sharing a physical interface but kept separate (for= =20 example with VLANs) ? I still don't see any advantage of a "per node" packe= t=20 sequence number. Maybe you can explain your scenario and the advantage of t= he=20 "per node" thing a little bit more ? Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart7314983.W7nqz9IOSC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr5fSsACgkQRIfGfFXsz+DEBwCgj3xObvFnodcHxNZ4JNGmN8uf qBUAmwVqlWNLXh/NMSJA3AOGUj7kTokH =unav -----END PGP SIGNATURE----- --nextPart7314983.W7nqz9IOSC-- From ubairhamid@gmail.com Tue Nov 10 09:23:55 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E5C28C1FD for ; Tue, 10 Nov 2009 09:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdgxyll47qaW for ; Tue, 10 Nov 2009 09:23:54 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 74B2428C207 for ; Tue, 10 Nov 2009 09:23:54 -0800 (PST) Received: by pwi6 with SMTP id 6so153738pwi.29 for ; Tue, 10 Nov 2009 09:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1kOzoBgICgYVNDJPbeOHoqAd0mCzvJ43uxHb7wc2SY0=; b=Td8hlSjI6T/NjEmpAKgbNdoSKfZ68kZwiLWnSqK4g1E930Z1MAa/Hljubh8a+P0/bh HouSD7Psq0DBTYKIsF4vBwiciSxh48Db63Lcl4iMktog9TRL9KhvxviN/PD8hlKSu7NZ krfCf4ozySm03fY5rts8YQXA58lL03hP0Zj+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VVolLQ+cynhaGcPmD9PkZ6klH+3oylojqKU24TTrvAiWjEXfXqB+WV53ARZcHeKNK/ Rbfzhgv5oBpxvY/VB8DHkGik1yGgCelRKor8lt1Z97mL0CURBS5b6qt/pORvBVhgrICb Nc+oQ5irBj6X+scYhm+GQ1XM0etsi7wXYFrvI= MIME-Version: 1.0 Received: by 10.142.62.12 with SMTP id k12mr39383wfa.138.1257873857028; Tue, 10 Nov 2009 09:24:17 -0800 (PST) Date: Tue, 10 Nov 2009 09:24:17 -0800 Message-ID: <4a7798a30911100924l6aaee550q572c306e95b5e4d@mail.gmail.com> From: Ubair Hamid To: manet@ietf.org Content-Type: multipart/alternative; boundary=001636e0ae116ba19304780794df Subject: [manet] precursor list confusion in AODV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:23:55 -0000 --001636e0ae116ba19304780794df Content-Type: text/plain; charset=ISO-8859-1 Hi all We are implementing AODV for our graduation project. I have confusion regarding precursor list maintained in the routing table which is mentioned in the RFC 3651. Also as the RFC does not say much about it, please tell IS it a linked list? Does it contain more than one entry for one Route Table Entry (as it is a list). Also what would be the entries of the precursor list in the following case. Especially elaborate precursor list for Node C. Note only adjacent nodes are connected i.e. in range of each other. Thanks in advance. Source 1 \ F \ G \ H \ Source 2 ------- A ------- B ------- C ------ D ------ E ------ Destination / i / J / K / Source 3 --001636e0ae116ba19304780794df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGkgYWxsPGRpdj48YnI+PC9kaXY+PGRpdj5XZSBhcmUgaW1wbGVtZW50aW5nIEFPRFYgZm9yIG91 ciBncmFkdWF0aW9uIHByb2plY3QuIEkgaGF2ZSBjb25mdXNpb24gcmVnYXJkaW5nIHByZWN1cnNv ciBsaXN0IG1haW50YWluZWQgaW4gdGhlIHJvdXRpbmcgdGFibGUgd2hpY2ggaXMgbWVudGlvbmVk IGluIHRoZSBSRkMgMzY1MS4gQWxzbyBhcyB0aGUgUkZDIGRvZXMgbm90IHNheSBtdWNoIGFib3V0 IGl0LCBwbGVhc2UgdGVsbCBJU6BpdCBhIGxpbmtlZCBsaXN0PyBEb2VzIGl0IGNvbnRhaW4gbW9y ZSB0aGFuIG9uZSBlbnRyeSBmb3Igb25lIFJvdXRlIFRhYmxlIEVudHJ5IChhcyBpdCBpcyBhIGxp c3QpLqBBbHNvIHdoYXQgd291bGQgYmUgdGhlIGVudHJpZXMgb2YgdGhlIHByZWN1cnNvciBsaXN0 IGluIHRoZSBmb2xsb3dpbmcgY2FzZS4gRXNwZWNpYWxseSBlbGFib3JhdGUgcHJlY3Vyc29yIGxp c3QgZm9yIE5vZGUgQy4gTm90ZSBvbmx5IGFkamFjZW50IG5vZGVzIGFyZSBjb25uZWN0ZWQgaS5l LiBpbiByYW5nZSBvZiBlYWNoIG90aGVyLiBUaGFua3MgaW4gYWR2YW5jZS48L2Rpdj4KPGRpdj6g PC9kaXY+PGRpdj6goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBTb3VyY2UgMTwvZGl2PjxkaXY+ oKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBcPC9kaXY+PGRpdj6goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBGPC9kaXY+PGRpdj6goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoFw8L2Rpdj48ZGl2PqCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIEc8L2Rpdj4KPGRpdj6goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIFw8L2Rpdj48ZGl2PqCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoEg8L2Rpdj48ZGl2PqCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgXDwvZGl2PjxkaXY+U291cmNlIDIgLS0tLS0tLSBBIC0tLS0tLS0gQiAtLS0tLS0tIEMg LS0tLS0tIEQgLS0tLS0tIEUgLS0tLS0tIERlc3RpbmF0aW9uPC9kaXY+CjxkaXY+oKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAvPC9kaXY+PGRpdj6goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaTwvZGl2PjxkaXY+oKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCAvPC9kaXY+PGRpdj6goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoKBKPC9kaXY+PGRpdj6goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKCgoC88L2Rpdj4KPGRpdj6goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgoKBLPC9kaXY+PGRpdj6goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIC88 L2Rpdj48ZGl2PqCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIFNvdXJjZSAzPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+Cg== --001636e0ae116ba19304780794df-- From teco@inf-net.nl Tue Nov 10 14:04:07 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAB028C1D0 for ; Tue, 10 Nov 2009 14:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCTMRKnsEUtk for ; Tue, 10 Nov 2009 14:04:06 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 54BD428C1BD for ; Tue, 10 Nov 2009 14:04:05 -0800 (PST) Received: (qmail 29611 invoked from network); 10 Nov 2009 23:04:30 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 10 Nov 2009 23:04:30 +0100 From: "Teco Boot" To: "'Henning Rogge'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911101548.16805.henning.rogge@fkie.fraunhofer.de> Date: Wed, 11 Nov 2009 07:03:50 +0900 Message-ID: <01c001ca6251$c5efa390$51ceeab0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiFOEqhXKTVlsUS3eX8wGoZWqkZQAO+i9w Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:04:07 -0000 >On Tue November 10 2009 15:04:30 Teco Boot wrote: >> If two interfaces are on same medium, we have the aggregation. >> There are other issues with such a setup, e.g. per_interface_MPR. >> Is this scenario analyzed before? >You mean two interfaces sharing a physical interface but kept separate >(for >example with VLANs) ? Not isolated with VLANs. Assume box with multiple radios, attached to directional antennas. > I still don't see any advantage of a "per node" >packet >sequence number. The discussion is what to do, per packet seq-num or (per packet per interface). Using the latter can be dangerous in this scenario, as a neighbor could get both packets and will get mixed up by the two seq-nums, as they are not nicely ordered anymore. Teco. From ulrich@herberg.name Tue Nov 10 15:44:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38E43A6A18 for ; Tue, 10 Nov 2009 15:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOPZV5zS84Lu for ; Tue, 10 Nov 2009 15:44:48 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id EDA5B3A6782 for ; Tue, 10 Nov 2009 15:44:47 -0800 (PST) Received: by fxm7 with SMTP id 7so591509fxm.29 for ; Tue, 10 Nov 2009 15:45:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.153.197 with SMTP id l5mr247808bkw.109.1257896712389; Tue, 10 Nov 2009 15:45:12 -0800 (PST) In-Reply-To: <01c001ca6251$c5efa390$51ceeab0$@nl> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> Date: Wed, 11 Nov 2009 08:45:12 +0900 Message-ID: <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:44:48 -0000 Teco, On Wed, Nov 11, 2009 at 7:03 AM, Teco Boot wrote: >[...] > The discussion is what to do, per packet seq-num or > (per packet per interface). Using the latter can be > dangerous in this scenario, as a neighbor could get > both packets and will get mixed up by the two seq-nums, > as they are not nicely ordered anymore. But would that matter? We still have message sequence numbers to detect duplicate messages (the message sequence number is created per router). And we have the ANSN to detected which TCs are newer. I do not see how that could be harmful. Can you describe an example? Ulrich From teco@inf-net.nl Tue Nov 10 15:56:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDD33A6960 for ; Tue, 10 Nov 2009 15:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.174 X-Spam-Level: X-Spam-Status: No, score=0.174 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRMVjCdehh-b for ; Tue, 10 Nov 2009 15:56:48 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7D1AD3A63C9 for ; Tue, 10 Nov 2009 15:56:47 -0800 (PST) Received: (qmail 23588 invoked from network); 11 Nov 2009 00:57:12 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 11 Nov 2009 00:57:12 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> In-Reply-To: <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> Date: Wed, 11 Nov 2009 08:56:33 +0900 Message-ID: <01d801ca6261$83ec6d60$8bc54820$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiX9ncRFWq99InQhm3yQP8+o2gLwAAJWgw Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:56:48 -0000 >>[...] >> The discussion is what to do, per packet seq-num or >> (per packet per interface). Using the latter can be >> dangerous in this scenario, as a neighbor could get >> both packets and will get mixed up by the two seq-nums, >> as they are not nicely ordered anymore. > >But would that matter? We still have message sequence numbers to >detect duplicate messages (the message sequence number is created per >router). And we have the ANSN to detected which TCs are newer. I do >not see how that could be harmful. Can you describe an example? What brings pkt-seq-num? What happens when router receives msg A on int A, and discard because not being MPR. Then it receives msg A on int B, and discard because seen before on int A, but is MPR. MPR broken? Teco. From ulrich@herberg.name Tue Nov 10 16:24:58 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776683A6877 for ; Tue, 10 Nov 2009 16:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a-qjIwtXn4W for ; Tue, 10 Nov 2009 16:24:57 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A4A8F28C0EF for ; Tue, 10 Nov 2009 16:24:55 -0800 (PST) Received: by bwz23 with SMTP id 23so611640bwz.29 for ; Tue, 10 Nov 2009 16:25:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.10.20 with SMTP id n20mr757624bkn.161.1257899120028; Tue, 10 Nov 2009 16:25:20 -0800 (PST) In-Reply-To: <01d801ca6261$83ec6d60$8bc54820$@nl> References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> Date: Wed, 11 Nov 2009 09:25:19 +0900 Message-ID: <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:24:58 -0000 On Wed, Nov 11, 2009 at 8:56 AM, Teco Boot wrote: >>>[...] >>But would that matter? We still have message sequence numbers to >>detect duplicate messages (the message sequence number is created per >>router). And we have the ANSN to detected which TCs are newer. I do >>not see how that could be harmful. Can you describe an example? > > What brings pkt-seq-num? I think they bring nothing if not used for something like a link quality mechanism. Note that neither NHDP nor OLSRv2 forces them to be used. The only place where NHDP mentions packet sequence numbers is: "If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss." The OLSRv2 draft does not mention packet sequence numbers (correct me if I am wrong). > > What happens when router receives msg A on int A, and discard > because not being MPR. Then it receives msg A on int B, and discard > because seen before on int A, but is MPR. MPR broken? But discarding a message is only based on message sequence number, not packet sequence number. Ulrich From teco@inf-net.nl Tue Nov 10 17:30:56 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C283A691F for ; Tue, 10 Nov 2009 17:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.316 X-Spam-Level: X-Spam-Status: No, score=0.316 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhoO7jVfgBAe for ; Tue, 10 Nov 2009 17:30:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B02B13A69C5 for ; Tue, 10 Nov 2009 17:30:55 -0800 (PST) Received: (qmail 25056 invoked from network); 11 Nov 2009 02:31:18 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 11 Nov 2009 02:31:18 +0100 From: "Teco Boot" To: References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> In-Reply-To: <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> Date: Wed, 11 Nov 2009 10:30:40 +0900 Message-ID: <01eb01ca626e$a95a4330$fc0ec990$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiZXPywke6MCtIT++xL7NY+w3htwAB3wUQ Content-Language: nl Subject: [manet] MPR and multiple interfaces on same medium X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:30:57 -0000 (new thread) I asked: > What happens when router receives msg A on int A, and discard > because not being MPR. Then it receives msg A on int B, and > discard because seen before on int A, but is MPR. MPR broken? Response appreciated. Teco. From ietf@thomasclausen.org Tue Nov 10 17:33:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80093A6BC8 for ; Tue, 10 Nov 2009 17:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYJR6RJZky3F for ; Tue, 10 Nov 2009 17:33:41 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 346943A6BC7 for ; Tue, 10 Nov 2009 17:33:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 32E5343032A; Tue, 10 Nov 2009 17:34:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A6BC6430328; Tue, 10 Nov 2009 17:34:08 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <01eb01ca626e$a95a4330$fc0ec990$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 10:34:05 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> <01eb01ca626e$a95a4330$fc0ec990$@nl> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] MPR and multiple interfaces on same medium X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:33:41 -0000 On Nov 11, 2009, at 10:30 AM, Teco Boot wrote: > (new thread) > > I asked: >> What happens when router receives msg A on int A, and discard >> because not being MPR. Then it receives msg A on int B, and >> discard because seen before on int A, but is MPR. MPR broken? > Response appreciated. No, that is not a problem - the selection algorithm proposed in OLSR and OLSRv2 handles this correctly. Thomas From teco@inf-net.nl Tue Nov 10 19:05:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E285B3A68C9 for ; Tue, 10 Nov 2009 19:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAOtXGRdzgb7 for ; Tue, 10 Nov 2009 19:05:13 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C38363A67D2 for ; Tue, 10 Nov 2009 19:05:12 -0800 (PST) Received: (qmail 29724 invoked from network); 11 Nov 2009 04:05:32 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 11 Nov 2009 04:05:32 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> <01eb01ca626e$a95a4330$fc0ec990$@nl> In-Reply-To: Date: Wed, 11 Nov 2009 12:04:45 +0900 Message-ID: <01ec01ca627b$d3246e40$796d4ac0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpibxNozOjNCVVlRemY9U6XzkH+5wAClrWQ Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] MPR and multiple interfaces on same medium X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:05:14 -0000 Thanks. It seems this is another scenario requiring per interface MPR. I still do not like it, but having this scenario leads me towards acceptance. But MPR still doesn't support my Ethernet scenario posted months ago. Reading back OLSRv2-10, I think text around "Received Set" needs revision. It is not "received", but "received via symmetric link". Messages could be received via asymmetric link and be processed. This is OK. But then, the message is in Processed Set and not in Received Set. This looks not obvious, and can lead to misunderstanding. At leased, 6.4.1 needs adjustment, and I prefer more text wherever Received set is mentioned. or rename it, to such as MPR_Received Set or Received_SL Set. Teco. >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >Verzonden: woensdag 11 november 2009 10:34 >Aan: Teco Boot >CC: manet@ietf.org >Onderwerp: Re: [manet] MPR and multiple interfaces on same medium > > >On Nov 11, 2009, at 10:30 AM, Teco Boot wrote: > >> (new thread) >> >> I asked: >>> What happens when router receives msg A on int A, and discard >>> because not being MPR. Then it receives msg A on int B, and >>> discard because seen before on int A, but is MPR. MPR broken? >> Response appreciated. > >No, that is not a problem - the selection algorithm proposed in OLSR >and OLSRv2 handles this correctly. > >Thomas From ietf@thomasclausen.org Tue Nov 10 19:10:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121853A6807 for ; Tue, 10 Nov 2009 19:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7BZsYY0YsdM for ; Tue, 10 Nov 2009 19:10:19 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 95E4628C28A for ; Tue, 10 Nov 2009 19:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 682B4430338; Tue, 10 Nov 2009 19:10:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id DEE8843032F; Tue, 10 Nov 2009 19:10:43 -0800 (PST) Message-Id: <43002DD8-4FCC-4790-88E9-7B80DC7F426D@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <01ec01ca627b$d3246e40$796d4ac0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 12:10:41 +0900 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> <01eb01ca626e$a95a4330$fc0ec990$@nl> <01ec01ca627b$d3246e40$796d4ac0$@nl> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] MPR and multiple interfaces on same medium X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:10:20 -0000 On Nov 11, 2009, at 12:04 PM, Teco Boot wrote: > Thanks. It seems this is another scenario requiring per interface MPR. > I still do not like it, but having this scenario leads me towards > acceptance. But MPR still doesn't support my Ethernet scenario posted > months ago. > I have been running OLSR and OLSRv2 over also Ethernets for years,. Can you remind me, what's not working? Thomas >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >> Verzonden: woensdag 11 november 2009 10:34 >> Aan: Teco Boot >> CC: manet@ietf.org >> Onderwerp: Re: [manet] MPR and multiple interfaces on same medium >> >> >> On Nov 11, 2009, at 10:30 AM, Teco Boot wrote: >> >>> (new thread) >>> >>> I asked: >>>> What happens when router receives msg A on int A, and discard >>>> because not being MPR. Then it receives msg A on int B, and >>>> discard because seen before on int A, but is MPR. MPR broken? >>> Response appreciated. >> >> No, that is not a problem - the selection algorithm proposed in OLSR >> and OLSRv2 handles this correctly. >> >> Thomas > From teco@inf-net.nl Tue Nov 10 19:26:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5E428C266 for ; Tue, 10 Nov 2009 19:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk7nEfgsO1Gr for ; Tue, 10 Nov 2009 19:26:31 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 53B163A6807 for ; Tue, 10 Nov 2009 19:26:31 -0800 (PST) Received: (qmail 11976 invoked from network); 11 Nov 2009 04:26:56 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 11 Nov 2009 04:26:56 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl> <25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> <25c114b90911101625m4711b137r7e6ea9f86fc62812@mail.gmail.com> <01eb01ca626e$a95a4330$fc0ec990$@nl> <01ec01ca627b$d3246e40$796d4ac0$@nl> <43002DD8-4FCC-4790-88E9-7B80DC7F426D@thomasclausen.org> In-Reply-To: <43002DD8-4FCC-4790-88E9-7B80DC7F426D@thomasclausen.org> Date: Wed, 11 Nov 2009 12:26:17 +0900 Message-ID: <01ed01ca627e$d06ff540$714fdfc0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpifI+1HTIdbNmJTDSWwlJvkQ7nOwAADO/w Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] MPR and Ethernet - use case where MPR is broken X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:26:32 -0000 (new thread) As far as I know there is a MPR over Ethernet use case with MPR problems. The scenario was discussed as follow-up on: http://www.ietf.org/mail-archive/web/manet/current/msg11061.html Thomas, I remember you thought there was a mechanism for a fix. Maybe you had jitter in mind, but IMHO this is not a real solution. Especially when SMF is in use. Here the scenario: +---+ +--------+ +---+ /| B |---| switch |---| E |\ / +---+ +--------+ +---+ \ +---+/ | \+---+ | A | | | F | +---+\ | /+---+ \ +---+ +--------+ +---+ / \| C |---| switch |---| D |/ +---+ +--------+ +---+ Network B-C-D-E is full connected. B selects D as MPR. C selects E as MPR. Packets sent by B are received by E before received by D. Packets sent by C are received by D before received by E. The delay between the switches can be quite large. I mentioned the same scenario can be set up with whatever L2 technology, including sub-IP MANETs. Teco. From Chris.Dearlove@baesystems.com Wed Nov 11 01:47:52 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BAE28C14C for ; Wed, 11 Nov 2009 01:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnOaEWGomaOs for ; Wed, 11 Nov 2009 01:47:52 -0800 (PST) Received: from ukmta3.baesystems.com (unknown [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D078E28C14F for ; Wed, 11 Nov 2009 01:47:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32301880" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 09:48:09 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAB9mGLQ017861; Wed, 11 Nov 2009 09:48:16 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:48:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 09:47:36 -0000 Message-ID: In-Reply-To: <00bc01ca6176$5cc01d90$164058b0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphSzcyDzwlZPcRTySaJuiFzQlFLgAApB/wAAPOouAABfbrIABPovMA References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <200911091537.44362.henning.rogge@fkie.fraunhofer.de> <25c114b90911090644y17e1bfd5mee6354aabc5bdb08@mail.gmail.com> <009f01ca614e$c7d970e0$578c52a0$@nl> <00bc01ca6176$5cc01d90$164058b0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2009 09:48:10.0489 (UTC) FILETIME=[14220690:01CA62B4] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:47:52 -0000 You do not have to use the same intervals in all parts of the network. You trade off bandwidth and responsiveness of course, but this does not have to be the same across the whole network, and if it is heterogeneous this may well be appropriate. Of course that still leaves the fastest rate TC messages impacting on the whole network, so decisions can't entirely be local. The abilities for both variable (possibly adaptive) and variable hop-count (Fisheye/HSLS) mechanisms may also help. But if you have a heterogeneous network with quite different characteristics you have problems to solve in any case. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: 09 November 2009 19:53 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: RE: [manet] NHDP: Link quality based on seq-num *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: dinsdag 10 november 2009 1:53 >Aan: Teco Boot; Ulrich Herberg; Henning Rogge >CC: manet@ietf.org >Onderwerp: RE: [manet] NHDP: Link quality based on seq-num > >> In my MANETs, I have low bandwidth high costs links and cannot afford >> the repeating MANET messages over it. > >Change the message intervals, possibly adaptively. This won't work in a heterogeneous network. On parts in the MANET, we can afford and take the benefits of high rate repeating messages, where in other parts this would overwhelm the link. The hop-limit feature is helping somewhat, but not sufficient. Teco. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 01:52:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A5F28C161 for ; Wed, 11 Nov 2009 01:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acs73cjxe4FC for ; Wed, 11 Nov 2009 01:52:12 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9875128C15F for ; Wed, 11 Nov 2009 01:52:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32303391" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 09:52:39 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAB9qkcx021177; Wed, 11 Nov 2009 09:52:46 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:52:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 09:52:07 -0000 Message-ID: In-Reply-To: <00bb01ca6175$94a10950$bde31bf0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl> <00bb01ca6175$94a10950$bde31bf0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Heide Clausen" X-OriginalArrivalTime: 11 Nov 2009 09:52:40.0400 (UTC) FILETIME=[B5032D00:01CA62B4] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:52:13 -0000 > For TCs, I prefer not incrementing the msg-seq-num for repeating, > identical messages. That does not work. The TC message sequence number is there to manage duplicates in flooding. Make it constant, and no second copy of a message will ever be delivered and the network will disintegrate. Freshness of information is in the ANSN. The message sequence number does a different job. NHDP/OLSRv2 are designed for unreliable networks. If you have a reliable network you may want to redesign, but I see no evidence that a reliable local broadcast mechanism is anything other than a thought experiment. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 02:00:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2372628C2F2 for ; Wed, 11 Nov 2009 02:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4QIGr85R2lG for ; Wed, 11 Nov 2009 02:00:15 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 016FB28C2B2 for ; Wed, 11 Nov 2009 02:00:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32306080" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 10:00:42 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABA0lBD027265; Wed, 11 Nov 2009 10:00:48 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:00:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 10:00:09 -0000 Message-ID: In-Reply-To: <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphoBsNdKbns9JQRPSS6F66Rn+d1AAHzSqQAD2Tv6A= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl> <25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com> <009e01ca614d$cceadac0$66c09040$@nl> <81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org> <00a801ca6152$d6c46c50$844d44f0$@nl> <1B8D0245-11C9-4D97-8EF4-F1710E60FABC@thomasclausen.org> <25c114b90911091652w5504849fp4645b89e7ebdedff@mail.gmail.com> <007801ca61bf$b4a8ce50$1dfa6af0$@nrl.navy.mil> From: "Dearlove, Christopher (UK)" To: "Justin Dean" , "Ulrich Herberg" , "Thomas Heide Clausen" X-OriginalArrivalTime: 11 Nov 2009 10:00:42.0006 (UTC) FILETIME=[D4126B60:01CA62B5] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:00:16 -0000 There is a question as to whether we change completely, or change to A or B. That is partly a question about errata as well as technical. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Justin Dean [mailto:jdean@itd.nrl.navy.mil] Sent: 10 November 2009 04:39 To: 'Ulrich Herberg'; 'Thomas Heide Clausen' Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: RE: [manet] NHDP: Link quality based on seq-num *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I understand the argument for changing packet sequence numbers from global space to interface spaces, and think I have actually made this argument in the past, but I have a nagging feeling that there is some drawback which we are currently missing. Aggregated interface reception perhaps? Justin > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Ulrich Herberg > Sent: Monday, November 09, 2009 7:52 PM > To: Thomas Heide Clausen > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] NHDP: Link quality based on seq-num > > Thomas, > > On Tue, Nov 10, 2009 at 2:00 AM, Thomas Heide Clausen > wrote: > >[..] > >> Assuming that's the "packet sequence numbers should be > >> per interface, not per node/router to be useful" then > >> yes. I'm not sure what the appropriate procedure is > >> (errata to RFC 5444?). > >> > > > > Unless I recall a really good reason for it being as it is in 5444, > then I > > agree with Chris. We talked earlier today and couldn't recall any > > justifications, so it might just have slipped through the editing > cracks > > (drat!). > > > > Give me a couple of days after this IETF to dig through my archives > of notes > > - failing any discoveries, we issue an errata? > > Yes, I think that should be considered. Using packet seq number per > interface instead of per node should solve the problem. > > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 02:14:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1863A6A6F for ; Wed, 11 Nov 2009 02:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwb7hl3A6wyF for ; Wed, 11 Nov 2009 02:14:02 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 41D1C3A6A57 for ; Wed, 11 Nov 2009 02:13:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32310438" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 10:14:20 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABAEQ3B004788; Wed, 11 Nov 2009 10:14:27 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:14:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 10:13:47 -0000 Message-ID: In-Reply-To: <01d801ca6261$83ec6d60$8bc54820$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcpiX9ncRFWq99InQhm3yQP8+o2gLwAAJWgwABWyiBA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911100928.51433.henning.rogge@fkie.fraunhofer.de> <016d01ca620e$cf184960$6d48dc20$@nl> <200911101548.16805.henning.rogge@fkie.fraunhofer.de> <01c001ca6251$c5efa390$51ceeab0$@nl><25c114b90911101545n31335cdp27020cbabe13bb96@mail.gmail.com> <01d801ca6261$83ec6d60$8bc54820$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 11 Nov 2009 10:14:20.0858 (UTC) FILETIME=[BC2551A0:01CA62B7] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:14:02 -0000 > What happens when router receives msg A on int A, and discard > because not being MPR. Then it receives msg A on int B, and discard > because seen before on int A, but is MPR. MPR broken? MPR is not broken. What happens is described in the specification. That it works is proved in INRIA reports on MPRs. Note that what matters with MPRs is not that a destination X gets a message from a node Y that picked it as an MPR, it's that it gets it at all. Getting it via node Z is quite acceptable. (This is, incidentally, at the heart of why flooding MPRs are per interface.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Wed Nov 11 03:10:44 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212FF28C307 for ; Wed, 11 Nov 2009 03:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpuPkGzPDNbM for ; Wed, 11 Nov 2009 03:10:43 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id D8C663A68CB for ; Wed, 11 Nov 2009 03:10:42 -0800 (PST) Received: (qmail 24978 invoked from network); 11 Nov 2009 12:11:02 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 11 Nov 2009 12:11:02 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl> <00bb01ca6175$94a10950$bde31bf0$@nl> In-Reply-To: Date: Wed, 11 Nov 2009 20:10:23 +0900 Message-ID: <022e01ca62bf$a664a610$f32df230$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUA== Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:10:44 -0000 You are right on thought experiment. Because I have reasons for this. Can I afford repeating messages over a costly link? (pay per MB) How to run a large OLSR domain with some small bandwidth links? What matters is prevent blocking future enhancements, that optimize TC via those links. The building blocks in my thought experiment are fast topology database synchronization after restart or merged networks and partial update TC messages (e.g. seq-num only). I'm not sure on lost TC msg recovery. MPR selection prefers fewest relay nodes, at cost of potential high loss ratio (depending on LQ implementation, algorithm etc.). It is a choice between more MPR redundancy or more robust transfer over lossy links. For multicast I don't see much happen at L2 for this. So we could define something. Not today :-) Neither block it. Teco. >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: woensdag 11 november 2009 18:52 >Aan: Teco Boot; Thomas Heide Clausen >CC: manet@ietf.org >Onderwerp: RE: [manet] NHDP: Link quality based on seq-num > >> For TCs, I prefer not incrementing the msg-seq-num for repeating, >> identical messages. > >That does not work. The TC message sequence number is there >to manage duplicates in flooding. Make it constant, and no >second copy of a message will ever be delivered and the network >will disintegrate. > >Freshness of information is in the ANSN. The message sequence >number does a different job. NHDP/OLSRv2 are designed for >unreliable networks. If you have a reliable network you may >want to redesign, but I see no evidence that a reliable >local broadcast mechanism is anything other than a thought >experiment. > >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 03:15:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9520B3A6810 for ; Wed, 11 Nov 2009 03:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIrF1HTwZb0R for ; Wed, 11 Nov 2009 03:15:28 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 637EF3A63EC for ; Wed, 11 Nov 2009 03:15:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32330451" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 11:15:54 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABBG1EC018063; Wed, 11 Nov 2009 11:16:01 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:15:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 11:15:22 -0000 Message-ID: In-Reply-To: <022e01ca62bf$a664a610$f32df230$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP: Link quality based on seq-num thread-index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKg References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2009 11:15:54.0899 (UTC) FILETIME=[55F73E30:01CA62C0] Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:15:29 -0000 > MPR selection prefers fewest relay nodes Not so. MPR selection may be according to any algorithm that creates a set with the required properties (loosely, coverage of all strict two hop nodes). A small, or smallest, set is generally a good idea, but if an operator has a better idea he is free to use it. (The example algorithm generally has - but is not guaranteed to have - minimal properties. But it is not mandated in any way.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From philippe.jacquet@inria.fr Wed Nov 11 03:45:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C0D28C30A for ; Wed, 11 Nov 2009 03:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4c2U8drkGXK for ; Wed, 11 Nov 2009 03:45:48 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id A34AD28C308 for ; Wed, 11 Nov 2009 03:45:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249250400"; d="scan'208";a="37908694" Received: from avelizy-152-1-33-29.w82-120.abo.wanadoo.fr (HELO [192.168.0.4]) ([82.120.124.29]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Nov 2009 12:46:13 +0100 Message-Id: <1CFE3E08-037C-4EA7-A2F1-20F9AAF4F420@inria.fr> From: jacquet To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 11 Nov 2009 12:53:38 +0100 References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> X-Mailer: Apple Mail (2.935.3) Cc: manet@ietf.org Subject: Re: [manet] NHDP: Link quality based on seq-num X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:45:48 -0000 I will add that the MPR selection gives all flexibilities according to =20= interface performance, in particular when the interfaces show very =20 different performance between them or within them, as proposed in most =20= Teco's examples. Philippe Le 11 nov. 09 =E0 12:15, Dearlove, Christopher (UK) a =E9crit : >> MPR selection prefers fewest relay nodes > > Not so. MPR selection may be according to any algorithm that > creates a set with the required properties (loosely, coverage > of all strict two hop nodes). A small, or smallest, set is > generally a good idea, but if an operator has a better idea > he is free to use it. > > (The example algorithm generally has - but is not guaranteed > to have - minimal properties. But it is not mandated in any way.) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Wed Nov 11 03:49:25 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD513A680D for ; Wed, 11 Nov 2009 03:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZiA8IHwbavp for ; Wed, 11 Nov 2009 03:49:24 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 405193A67D7 for ; Wed, 11 Nov 2009 03:49:24 -0800 (PST) Received: (qmail 29468 invoked from network); 11 Nov 2009 12:49:43 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 11 Nov 2009 12:49:43 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> In-Reply-To: Date: Wed, 11 Nov 2009 20:49:03 +0900 Message-ID: <024901ca62c5$0d896d30$289c4790$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGA= Content-Language: nl Cc: manet@ietf.org Subject: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:49:25 -0000 (passed to new thread) I said "depending on algorithm", so I agree. But there is a large OLSRv1 community that complains on RFC default behavior. In OLSRv2, the Link Quality defaults are "LQ disabled". This, with the default / example MPR selection algorithm works the way I meant. We have here the same issue as link metrics: people implement the RFC, test it (or run production immediately) and complain. I am looking forward to text on ETX. Then, we have NLQ. With adding N2LQ in the hellos, we have more info for MPR selection for providing low loss. Teco. >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: woensdag 11 november 2009 20:15 >Aan: Teco Boot >CC: manet@ietf.org >Onderwerp: RE: [manet] NHDP: Link quality based on seq-num > >> MPR selection prefers fewest relay nodes > >Not so. MPR selection may be according to any algorithm that >creates a set with the required properties (loosely, coverage >of all strict two hop nodes). A small, or smallest, set is >generally a good idea, but if an operator has a better idea >he is free to use it. > >(The example algorithm generally has - but is not guaranteed >to have - minimal properties. But it is not mandated in any way.) > >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 03:55:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394023A680D for ; Wed, 11 Nov 2009 03:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXxKLMldwLVr for ; Wed, 11 Nov 2009 03:55:03 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4C74C3A695A for ; Wed, 11 Nov 2009 03:55:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,722,1249254000"; d="scan'208";a="32345836" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 11:55:31 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABBtbhY015335; Wed, 11 Nov 2009 11:55:38 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:55:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 11:54:58 -0000 Message-ID: In-Reply-To: <024901ca62c5$0d896d30$289c4790$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default LQ and example MPR thread-index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGAAAIU0gA== References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> <024901ca62c5$0d896d30$289c4790$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2009 11:55:31.0634 (UTC) FILETIME=[DE9C3920:01CA62C5] Cc: manet@ietf.org Subject: Re: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:55:04 -0000 > In OLSRv2, the Link Quality defaults are "LQ disabled". This, > with the default / example MPR selection algorithm works the > way I meant. It is not the default, it is an example. Frankly, we've made a lot of tools available for people who either have unusual characteristics, or expertise to get more out of what they have. (That's including link metrics. Yes, they aren't in place, but they will be in OLSRv2, once we can actually get NHDP - whose WGLC period is long over - out of the door to the IESG.) That's the best we can do to cover the range of possibilities. If people run unusual cases, and ignore all of this, there's not much we can do about that. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Wed Nov 11 04:24:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EAD3A6961 for ; Wed, 11 Nov 2009 04:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk9iJ-XWL1ol for ; Wed, 11 Nov 2009 04:24:12 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 0F0013A685C for ; Wed, 11 Nov 2009 04:24:11 -0800 (PST) Received: (qmail 29176 invoked from network); 11 Nov 2009 13:24:36 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 11 Nov 2009 13:24:36 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> <024901ca62c5$0d896d30$289c4790$@nl> In-Reply-To: Date: Wed, 11 Nov 2009 21:23:57 +0900 Message-ID: <024f01ca62c9$ecdd38f0$c697aad0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGAAAIU0gAAAaLEw Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:24:13 -0000 > there's not much we can do about that. Small adjustments may have large effects. I suggest adjusting the defaults to: === 14.4. Updating Link Quality A router SHOULD update link quality based on any information available to it. Particular cases that MAY be used include: (skip) 15.4. Link Quality Interface Parameters If link quality is changed, then parameter values will depend on the link quality process. If link quality is not changed, then: o HYST_ACCEPT := 0.8 o HYST_REJECT := 0.3 o INITIAL_QUALITY := 0.5 o INITIAL_PENDING := true === I'm fine with better defaults, whatever that may be. It hasn't much meaning anyway, as there is no provided mechanism. And the SHOULD above is a MUST. If LQ is not updated, the link is not used. For an alternative MPR selection, this is not a small adjustment. I'll postpone to after seen ETX text. Teco. From Chris.Dearlove@baesystems.com Wed Nov 11 05:24:45 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D5928C17E for ; Wed, 11 Nov 2009 05:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMcWlltl3GIO for ; Wed, 11 Nov 2009 05:24:45 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C97F028C11B for ; Wed, 11 Nov 2009 05:24:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,723,1249254000"; d="scan'208";a="32374968" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 13:25:12 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABDPJax014452; Wed, 11 Nov 2009 13:25:19 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:25:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 13:24:39 -0000 Message-ID: In-Reply-To: <024f01ca62c9$ecdd38f0$c697aad0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default LQ and example MPR thread-index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGAAAIU0gAAAaLEwAALWMbA= References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> <024901ca62c5$0d896d30$289c4790$@nl> <024f01ca62c9$ecdd38f0$c697aad0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2009 13:25:13.0224 (UTC) FILETIME=[6649B080:01CA62D2] Cc: manet@ietf.org Subject: Re: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:24:45 -0000 Default values of 0.8 and 0.3 are meaningless if you haven't (and we neither can nor want to) define the meaning of the scale. That's why we specifically changed defaults from OLSRv1. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: 11 November 2009 12:24 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: RE: [manet] Default LQ and example MPR *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. > there's not much we can do about that. Small adjustments may have large effects. I suggest adjusting the defaults to: === 14.4. Updating Link Quality A router SHOULD update link quality based on any information available to it. Particular cases that MAY be used include: (skip) 15.4. Link Quality Interface Parameters If link quality is changed, then parameter values will depend on the link quality process. If link quality is not changed, then: o HYST_ACCEPT := 0.8 o HYST_REJECT := 0.3 o INITIAL_QUALITY := 0.5 o INITIAL_PENDING := true === I'm fine with better defaults, whatever that may be. It hasn't much meaning anyway, as there is no provided mechanism. And the SHOULD above is a MUST. If LQ is not updated, the link is not used. For an alternative MPR selection, this is not a small adjustment. I'll postpone to after seen ETX text. Teco. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Nov 11 10:02:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4386428C144 for ; Wed, 11 Nov 2009 10:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6n3MgFVSFv0 for ; Wed, 11 Nov 2009 10:02:47 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2CAE328C133 for ; Wed, 11 Nov 2009 10:02:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,724,1249254000"; d="scan'208";a="32457691" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2009 18:03:15 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nABI3M4Y012973 for ; Wed, 11 Nov 2009 18:03:22 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 18:03:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 18:02:42 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hope the MANET meeting goes well thread-index: Acpi+SoF/PC+Om/DTr+pZ6dsT2iy6Q== From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 11 Nov 2009 18:03:16.0241 (UTC) FILETIME=[3E241010:01CA62F9] Subject: [manet] Hope the MANET meeting goes well X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 18:02:48 -0000 Unfortunately I couldn't make it to Hiroshima. All the best with the meeting - I won't be particpating remotely, the timezones really don't work. But the NHDP/OLSRv2 authorship is represented, so that should be OK. Hope to see you in Anaheim. By then I hope NHDP will be with the RFC Editor and the OLSRv2 draft will have metrics incorporated and be being reviewed. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From root@core3.amsl.com Wed Nov 11 15:45:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE4EA3A69B8; Wed, 11 Nov 2009 15:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091111234501.EE4EA3A69B8@core3.amsl.com> Date: Wed, 11 Nov 2009 15:45:01 -0800 (PST) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-nhdp-mib-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the Neighborhood Discovery Protocol Author(s) : U. Herberg, et al. Filename : draft-ietf-manet-nhdp-mib-02.txt Pages : 68 Date : 2009-11-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-11153226.I-D@ietf.org> --NextPart-- From hamid.mukhtar@gmail.com Wed Nov 11 21:31:35 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44BE3A67EB for ; Wed, 11 Nov 2009 21:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAK2xF2RonUm for ; Wed, 11 Nov 2009 21:31:35 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 1B0C93A63EB for ; Wed, 11 Nov 2009 21:31:34 -0800 (PST) Received: by pxi42 with SMTP id 42so1316566pxi.5 for ; Wed, 11 Nov 2009 21:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=eC51AoO6If/r0JZKne+28cBVFrHKmMJm4+TKl09T3+k=; b=xFHHfbOmbKNARNoEJ/1IKvj9QEWKzavwERhYCKT2fgh6QXw09PUJJpjm2e8pnkv4nG nHYMziqGJWfmFr7RDxgCJONZEg/w1qki+ahlpzWIvJBqUBI7JplH1ZpskgI3SC8XuA51 ymPlfpYgpqW4EqYZ2p6DuYQT8OLufe6psTYo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Ws8D387UFReLjMf4Ex6VC042i80zh2Xf4BeERlhs+/s32iuq47z12xGbA8bdQ5r2Wa efai54jSysnWx7bPqu6RBUgdXWTBR57uO9wmi8JWCw9nkejDhbeZpmZCkqpieZWjpGcL yyzkRGIMW4XbPy1FhngAjC9mdHJg5avHRoE3s= MIME-Version: 1.0 Received: by 10.142.4.39 with SMTP id 39mr264071wfd.128.1258003920501; Wed, 11 Nov 2009 21:32:00 -0800 (PST) From: Hamid Mukhtar Date: Thu, 12 Nov 2009 14:31:45 +0900 Message-ID: To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] publication reference X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:31:35 -0000 Hi, Here is the reference to the publication I talked about during the meeting. I just got the reference yesterday and I am currently reviewing it myself. @InProceedings{CKC09, author = "H. Choi and N. Kim and H. Cha", title = "{6LoWPAN-SNMP: Simple Network Management Protocol for 6LoWPAN}", booktitle = "Proc. 11th IEEE Conference on High Performance Computing and Communicatins", month = jun, year = "2009", publisher = "IEEE", } SNMP is datagram oriented and we believe that the implementations can be pretty lightweight. We would also appreciate reviews and comments on our ID which covers the applicability of SNMP for 6LoWPANs (http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-02). Thanks, Hamid From ulrich@herberg.name Wed Nov 11 21:43:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E2D3A68F4 for ; Wed, 11 Nov 2009 21:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIsuHUYZntrX for ; Wed, 11 Nov 2009 21:43:10 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id D675F3A687B for ; Wed, 11 Nov 2009 21:43:09 -0800 (PST) Received: by fxm7 with SMTP id 7so1854117fxm.29 for ; Wed, 11 Nov 2009 21:43:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.32.213 with SMTP id e21mr1405691bkd.34.1258004612507; Wed, 11 Nov 2009 21:43:32 -0800 (PST) Date: Thu, 12 Nov 2009 14:43:32 +0900 Message-ID: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:43:10 -0000 Hi, as mentioned during my presentation of security extensions to packetbb and NHDP, here are my drafts: http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 Feel free to read them and give me comments. Thanks Ulrich From henning.rogge@fkie.fraunhofer.de Thu Nov 12 23:34:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BC83A697D for ; Thu, 12 Nov 2009 23:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueGU5+9oQDYi for ; Thu, 12 Nov 2009 23:34:13 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id C23563A6977 for ; Thu, 12 Nov 2009 23:34:13 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N8qg5-0007Kg-Gw for manet@ietf.org; Fri, 13 Nov 2009 08:34:41 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N8qg5-0006GO-78 for manet@ietf.org; Fri, 13 Nov 2009 08:34:41 +0100 From: Henning Rogge To: manet@ietf.org Date: Fri, 13 Nov 2009 08:34:32 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1416945.12iGruxVUx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911130834.38163.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10021/Fri Nov 13 06:07:53 2009) by mailguard.fgan.de X-Scan-Signature: 52e07e0af4405bded81fc5fcc507a670 Subject: [manet] Wireshark packet dissector for packetbb X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 07:34:15 -0000 --nextPart1416945.12iGruxVUx Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, my packetbb dissector for wireshark was just committed to the development=20 repository. See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D4118 for details. Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1416945.12iGruxVUx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr9DAgACgkQRIfGfFXsz+BzywCgn6Vid2T6d4fxXbrHnE2usx3F b9sAoJKnrs5/G+UK/5m7XbXpBw7EyX3p =Aot8 -----END PGP SIGNATURE----- --nextPart1416945.12iGruxVUx-- From teco@inf-net.nl Thu Nov 12 16:45:22 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883FB3A6A2B for ; Thu, 12 Nov 2009 16:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.315 X-Spam-Level: X-Spam-Status: No, score=0.315 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLIc1yv+tmhO for ; Thu, 12 Nov 2009 16:45:21 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6EE363A6961 for ; Thu, 12 Nov 2009 16:45:20 -0800 (PST) Received: (qmail 25194 invoked from network); 13 Nov 2009 01:45:48 +0100 Received: from host-19-89.meeting.ietf.org (HELO M90Teco) (133.93.19.89) by server9.hosting2go.nl with SMTP; 13 Nov 2009 01:45:48 +0100 From: "Teco Boot" To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> In-Reply-To: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> Date: Fri, 13 Nov 2009 09:45:12 +0900 Message-ID: <001e01ca63fa$a30f6770$e92e3650$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQAnyxjA Content-Language: nl x-cr-hashedpuzzle: j04= AcCa AzSl BqdC B4oC DSan Eh9O FJfg F65F F7bJ GQ5p GSF3 G2Z4 HArG JCIz KEQN; 1; bQBhAG4AZQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D6FC0776-85BB-4088-83C2-CCDDBF61B6DC}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 13 Nov 2009 00:45:07 GMT; RABZAE0ATwAgAGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzAA== x-cr-puzzleid: {D6FC0776-85BB-4088-83C2-CCDDBF61B6DC} X-Mailman-Approved-At: Fri, 13 Nov 2009 03:54:36 -0800 Subject: [manet] DYMO implementations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:45:22 -0000 There is a list of DYMO implementations on http://ianchak.com/dymo/ 6 versions are public. EK-DYMO seems to be private or dead. http://http//www7.informatik.uni-erlangen.de/~sommer/omnet/ should be: http://www7.informatik.uni-erlangen.de/~sommer/omnet/ Question: are these updated to recent I-D version? Teco. From teco@inf-net.nl Mon Nov 16 12:18:21 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36AD3A6B00 for ; Mon, 16 Nov 2009 12:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrIe+6W9lQnM for ; Mon, 16 Nov 2009 12:18:21 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id A7A173A6AFF for ; Mon, 16 Nov 2009 12:18:20 -0800 (PST) Received: (qmail 28407 invoked from network); 16 Nov 2009 21:18:07 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 16 Nov 2009 21:18:07 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> In-Reply-To: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> Date: Mon, 16 Nov 2009 21:17:32 +0100 Message-ID: <008a01ca66f9$e61c3aa0$b254afe0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aaw Content-Language: nl Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:18:21 -0000 Hi Ulrich, I'll comment on sec-threats first. This would line out what needs to be done. At first, I would like to distinguish networks that have L2 protection and those who have not. For the firsts, we could skip the whole thing. Then, we want to know what to protect, and against who. Let's say we have the good guys and the bad guys. The question is, do the bad guys think the good guys are the bad guys? In other words, are there multiple groups on the same medium? Do we want to separate those with crypto? Or use some kind of identifier? After more analysis of threats, I expect a demand for protecting packets, not messages. Messages are updated along the path, only by the good guys. For OLSR, there is only the hop-count and hop-limit being updated. For DYMO, there is a lot more. Who knows what future brings. Regards, Teco. >-----Oorspronkelijk bericht----- >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >Ulrich Herberg >Verzonden: donderdag 12 november 2009 6:44 >Aan: manet@ietf.org >Onderwerp: [manet] Security drafts > >Hi, > >as mentioned during my presentation of security extensions to packetbb >and NHDP, here are my drafts: > >http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 >http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt >http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 > > >Feel free to read them and give me comments. > >Thanks >Ulrich >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Nov 16 12:51:36 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC7F3A6884 for ; Mon, 16 Nov 2009 12:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4sjZd9ukbWb for ; Mon, 16 Nov 2009 12:51:35 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 13D043A67EE for ; Mon, 16 Nov 2009 12:51:34 -0800 (PST) Received: by bwz23 with SMTP id 23so6214844bwz.29 for ; Mon, 16 Nov 2009 12:51:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.25.71 with SMTP id y7mr4523851bkb.67.1258404688931; Mon, 16 Nov 2009 12:51:28 -0800 (PST) In-Reply-To: <008a01ca66f9$e61c3aa0$b254afe0$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> Date: Mon, 16 Nov 2009 21:51:28 +0100 Message-ID: <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:51:36 -0000 Hi Teco, thanks for your comments. On Mon, Nov 16, 2009 at 9:17 PM, Teco Boot wrote: > Hi Ulrich, > > I'll comment on sec-threats first. This would line out what needs > to be done. > > At first, I would like to distinguish networks that have L2 protection > and those who have not. For the firsts, we could skip the whole thing. I disagree. L2 protection does not guarantee end-to-end authentication. Consider an example where a router A receives a forwarded TC (originator is router C) message from router B. If only L2 security is used, router A has no means to be sure that the message really originates from C (because e.g. it does not know whether there is an L2 protection between B and C). But I agree with you that it could be worth mentioning L2 protection in the draft, possibly explaining why it does not solve all problems (notably end-to-end security). > Then, we want to know what to protect, and against who. Let's say we > have the good guys and the bad guys. The question is, do the bad guys > think the good guys are the bad guys? In other words, are there > multiple groups on the same medium? Do we want to separate those > with crypto? Or use some kind of identifier? First, keep in mind that in my framework the assumption is: good guy == has a valid key to sign/validate messages bad guy == does not have such a key So, if there are some routers in a MANET that do not possess the right key ("bad guy"), they are not able to sign messages correctly. Thus, all HELLO/TC messages they send will be ignored by the "good guys". Another issue is that several signatures can be added to a message in the current specification. One thing I need to think about more is what happens if part of these signatures are correct, and another part is incorrect (or cannot be validated because the receiving router of such a message does not have a valid key or does not know the signature algorithm). Do we want to to enforce that _all_ signatures must be valid, or is it sufficient that at least one signature is valid? Or should we limit the number of signatures to one? > After more analysis of threats, I expect a demand for protecting packets, > not messages. That would be like an L2 protection. Indeed, as an additional measure that could be interesting to provide. > Messages are updated along the path, only by the good guys. > For OLSR, there is only the hop-count and hop-limit being updated. For > DYMO, there is a lot more. Who knows what future brings. Yes, as mentioned in the slides, I will have a closer look into DYMO in order to understand the necessities of protecting DYMO. Ulrich > > Regards, Teco. > > >>-----Oorspronkelijk bericht----- >>Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>Ulrich Herberg >>Verzonden: donderdag 12 november 2009 6:44 >>Aan: manet@ietf.org >>Onderwerp: [manet] Security drafts >> >>Hi, >> >>as mentioned during my presentation of security extensions to packetbb >>and NHDP, here are my drafts: >> >>http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 >>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt >>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 >> >> >>Feel free to read them and give me comments. >> >>Thanks >>Ulrich >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > From teco@inf-net.nl Mon Nov 16 13:06:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A2A3A68C2 for ; Mon, 16 Nov 2009 13:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.675 X-Spam-Level: *** X-Spam-Status: No, score=3.675 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM5B9K1KUxot for ; Mon, 16 Nov 2009 13:06:26 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 89C083A68BE for ; Mon, 16 Nov 2009 13:06:24 -0800 (PST) Received: (qmail 8105 invoked from network); 16 Nov 2009 22:06:16 +0100 Received: from unknown (HELO M90Teco) (62.140.137.97) by server9.hosting2go.nl with SMTP; 16 Nov 2009 22:06:16 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> <024901ca62c5$0d896d30$289c4790$@nl> <024f01ca62c9$ecdd38f0$c697aad0$@nl> In-Reply-To: Date: Mon, 16 Nov 2009 22:05:40 +0100 Message-ID: <009101ca6700$a098cd70$e1ca6850$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGAAAIU0gAAAaLEwAALWMbABC1DjUA== Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:06:26 -0000 >Default values of 0.8 and 0.3 are meaningless if you >haven't (and we neither can nor want to) define the >meaning of the scale. That's why we specifically >changed defaults from OLSRv1. The LQ parameters are dimensionless. The OLSRv1 defaults are not that bad. >> A router SHOULD update link quality based on any information >> available More important: the change from MAY to SHOULD. My experience is that having LQ is crucial on those link types that are our primary concern. Teco. From teco@inf-net.nl Mon Nov 16 13:18:56 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8353A6B29 for ; Mon, 16 Nov 2009 13:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.375 X-Spam-Level: ** X-Spam-Status: No, score=2.375 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dundj0nClwyi for ; Mon, 16 Nov 2009 13:18:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 81B603A69B5 for ; Mon, 16 Nov 2009 13:18:54 -0800 (PST) Received: (qmail 19987 invoked from network); 16 Nov 2009 22:18:50 +0100 Received: from unknown (HELO M90Teco) (62.140.137.97) by server9.hosting2go.nl with SMTP; 16 Nov 2009 22:18:50 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> In-Reply-To: <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> Date: Mon, 16 Nov 2009 22:18:12 +0100 Message-ID: <009201ca6702$61efa010$25cee030$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/w Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:18:56 -0000 Hi Ulrich, I ask for keeping things simple. I don't believe in end-to-end security. Why are relayed messages by bad guys interesting? Why a security mechanism, far more complex than all what exists today, without a request for it? One of the principles in security space is checking identity before validating the authentication / integrity hash. Maybe the other node is just member of another group. Is this principle history? Teco. >-----Oorspronkelijk bericht----- >Van: Ulrich Herberg [mailto:ulrich@herberg.name] >Verzonden: maandag 16 november 2009 21:51 >Aan: Teco Boot >CC: manet@ietf.org >Onderwerp: Re: [manet] Security drafts > >Hi Teco, > >thanks for your comments. > >On Mon, Nov 16, 2009 at 9:17 PM, Teco Boot wrote: >> Hi Ulrich, >> >> I'll comment on sec-threats first. This would line out what needs >> to be done. >> >> At first, I would like to distinguish networks that have L2 protection >> and those who have not. For the firsts, we could skip the whole thing. > >I disagree. L2 protection does not guarantee end-to-end >authentication. Consider an example where a router A receives a >forwarded TC (originator is router C) message from router B. If only >L2 security is used, router A has no means to be sure that the >message really originates from C (because e.g. it does not know >whether there is an L2 protection between B and C). >But I agree with you that it could be worth mentioning L2 protection >in the draft, possibly explaining why it does not solve all problems >(notably end-to-end security). > > >> Then, we want to know what to protect, and against who. Let's say we >> have the good guys and the bad guys. The question is, do the bad guys >> think the good guys are the bad guys? In other words, are there >> multiple groups on the same medium? Do we want to separate those >> with crypto? Or use some kind of identifier? > >First, keep in mind that in my framework the assumption is: >good guy == has a valid key to sign/validate messages >bad guy == does not have such a key > >So, if there are some routers in a MANET that do not possess the right >key ("bad guy"), they are not able to sign messages correctly. Thus, >all HELLO/TC messages they send will be ignored by the "good guys". >Another issue is that several signatures can be added to a message in >the current specification. One thing I need to think about more is >what happens if part of these signatures are correct, and another part >is incorrect (or cannot be validated because the receiving router of >such a message does not have a valid key or does not know the >signature algorithm). Do we want to to enforce that _all_ signatures >must be valid, or is it sufficient that at least one signature is >valid? Or should we limit the number of signatures to one? > > >> After more analysis of threats, I expect a demand for protecting >packets, >> not messages. > >That would be like an L2 protection. Indeed, as an additional measure >that could be interesting to provide. > >> Messages are updated along the path, only by the good guys. >> For OLSR, there is only the hop-count and hop-limit being updated. For >> DYMO, there is a lot more. Who knows what future brings. > >Yes, as mentioned in the slides, I will have a closer look into DYMO >in order to understand the necessities of protecting DYMO. > >Ulrich > >> >> Regards, Teco. >> >> >>>-----Oorspronkelijk bericht----- >>>Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>Ulrich Herberg >>>Verzonden: donderdag 12 november 2009 6:44 >>>Aan: manet@ietf.org >>>Onderwerp: [manet] Security drafts >>> >>>Hi, >>> >>>as mentioned during my presentation of security extensions to packetbb >>>and NHDP, here are my drafts: >>> >>>http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 >>>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt >>>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 >>> >>> >>>Feel free to read them and give me comments. >>> >>>Thanks >>>Ulrich >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www.ietf.org/mailman/listinfo/manet >> >> From ulrich@herberg.name Tue Nov 17 01:00:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74E93A6887 for ; Tue, 17 Nov 2009 01:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysojImo6GOI6 for ; Tue, 17 Nov 2009 01:00:01 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 63E273A6808 for ; Tue, 17 Nov 2009 01:00:01 -0800 (PST) Received: by fxm7 with SMTP id 7so6715142fxm.29 for ; Tue, 17 Nov 2009 00:59:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.175.83 with SMTP id w19mr4837095bkz.24.1258448394288; Tue, 17 Nov 2009 00:59:54 -0800 (PST) In-Reply-To: <009201ca6702$61efa010$25cee030$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> Date: Tue, 17 Nov 2009 09:59:54 +0100 Message-ID: <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:00:03 -0000 Hi Teco, On Mon, Nov 16, 2009 at 10:18 PM, Teco Boot wrote: > Hi Ulrich, > > I ask for keeping things simple. I think that my framework is very simple. But please, if you find any possible simplifications in the framework (while preserving the same security), point them out to me. > I don't believe in end-to-end security. What about IPsec, TLS, SSL, SSH? They are all end-to-end and widely used. And coming back to your first comment, I believe that IPsec is far more complicated than my proposed framework. > Why are relayed messages > by bad guys interesting? Because if you do not have end-to-end security, you don't know whether this message comes from a bad guy or not. The most you can say is that the last hop (i.e. the router that relays a message) is a "good guy". > Why a security mechanism, far more complex > than all what exists today, without a request for it? Why is it far more complex? I assume that if you add up the number of pages of all IPsec RFCs, you would agree that my framework is not very complex. (I know, IPsec serves another purpose... just for showing you that my framework is not that complex). Talking about "a request for it". I have heard from several members of the WG that they are interested in such security. As soon as MANET routing protocols will be used outside of testbeds, I think that we need some security. > One of the principles in security space is checking identity before > validating the authentication / integrity hash. Maybe the other node > is just member of another group. Is this principle history? No, it is not. This is exactly what my framework does. The identity of a message originator is checked first, before the integrity of the message is verified. Maybe I should that make clearer in the text, though. I will soon release a new version of the drafts, including all comments that I get from the mailing list. Thanks Ulrich > > >>-----Oorspronkelijk bericht----- >>Van: Ulrich Herberg [mailto:ulrich@herberg.name] >>Verzonden: maandag 16 november 2009 21:51 >>Aan: Teco Boot >>CC: manet@ietf.org >>Onderwerp: Re: [manet] Security drafts >> >>Hi Teco, >> >>thanks for your comments. >> >>On Mon, Nov 16, 2009 at 9:17 PM, Teco Boot wrote: >>> Hi Ulrich, >>> >>> I'll comment on sec-threats first. This would line out what needs >>> to be done. >>> >>> At first, I would like to distinguish networks that have L2 protection >>> and those who have not. For the firsts, we could skip the whole thing. >> >>I disagree. L2 protection does not guarantee end-to-end >>authentication. Consider an example where a router A receives a >>forwarded TC (originator is router C) message from router B. If only >>L2 security is used, router =A0A has no means to be sure that the >>message really originates from C (because e.g. it does not know >>whether there is an L2 protection between B and C). >>But I agree with you that it could be worth mentioning L2 protection >>in the draft, possibly explaining why it does not solve all problems >>(notably end-to-end security). >> >> >>> Then, we want to know what to protect, and against who. Let's say we >>> have the good guys and the bad guys. The question is, do the bad guys >>> think the good guys are the bad guys? In other words, are there >>> multiple groups on the same medium? Do we want to separate those >>> with crypto? Or use some kind of identifier? >> >>First, keep in mind that in my framework the assumption is: >>good guy =3D=3D has a valid key to sign/validate messages >>bad guy =3D=3D does not have such a key >> >>So, if there are some routers in a MANET that do not possess the right >>key ("bad guy"), they are not able to sign messages correctly. Thus, >>all HELLO/TC messages they send will be ignored by the "good guys". >>Another issue is that several signatures can be added to a message in >>the current specification. One thing I need to think about more is >>what happens if part of these signatures are correct, and another part >>is incorrect (or cannot be validated because the receiving router of >>such a message does not have a valid key or does not know the >>signature algorithm). Do we want to to enforce that _all_ signatures >>must be valid, or is it sufficient that at least one signature is >>valid? Or should we limit the number of signatures to one? >> >> >>> After more analysis of threats, I expect a demand for protecting >>packets, >>> not messages. >> >>That would be like an L2 protection. Indeed, as an additional measure >>that could be interesting to provide. >> >>> Messages are updated along the path, only by the good guys. >>> For OLSR, there is only the hop-count and hop-limit being updated. For >>> DYMO, there is a lot more. Who knows what future brings. >> >>Yes, as mentioned in the slides, I will have a closer look into DYMO >>in order to understand the necessities of protecting DYMO. >> >>Ulrich >> >>> >>> Regards, Teco. >>> >>> >>>>-----Oorspronkelijk bericht----- >>>>Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>>Ulrich Herberg >>>>Verzonden: donderdag 12 november 2009 6:44 >>>>Aan: manet@ietf.org >>>>Onderwerp: [manet] Security drafts >>>> >>>>Hi, >>>> >>>>as mentioned during my presentation of security extensions to packetbb >>>>and NHDP, here are my drafts: >>>> >>>>http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 >>>>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt >>>>http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 >>>> >>>> >>>>Feel free to read them and give me comments. >>>> >>>>Thanks >>>>Ulrich >>>>_______________________________________________ >>>>manet mailing list >>>>manet@ietf.org >>>>https://www.ietf.org/mailman/listinfo/manet >>> >>> > > From henning.rogge@fkie.fraunhofer.de Tue Nov 17 01:12:51 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0757A3A69FD for ; Tue, 17 Nov 2009 01:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKxJ3yjP5kQO for ; Tue, 17 Nov 2009 01:12:49 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id B92B73A6782 for ; Tue, 17 Nov 2009 01:12:49 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAK7C-0003tO-TE; Tue, 17 Nov 2009 10:12:47 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAK7C-0002ox-ID; Tue, 17 Nov 2009 10:12:46 +0100 From: Henning Rogge To: manet@ietf.org Date: Tue, 17 Nov 2009 10:12:33 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> In-Reply-To: <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3959131.G2CrCIJ0YS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171012.39026.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 8f2ff0f8b29b56656e548972f548b16c Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:12:51 -0000 --nextPart3959131.G2CrCIJ0YS Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 09:59:54 Ulrich Herberg wrote: > > Hi Ulrich, > > > > I ask for keeping things simple. >=20 > I think that my framework is very simple. But please, if you find any > possible simplifications in the framework (while preserving the same > security), point them out to me. >=20 > > I don't believe in end-to-end security. >=20 > What about IPsec, TLS, SSL, SSH? They are all end-to-end and widely > used. And coming back to your first comment, I believe that IPsec is > far more complicated than my proposed framework. I think we must differentiate between "internal" and "external" attackers. External attackers are much easier to defend against. They don't have acces= s=20 to a part of your cryptographic data and are not allowed to participate in= =20 your network. You can use a link-layer authentication and encryption to kee= p=20 an external attacker out of your network. Internal attackers are much more difficult to defend against. They are usin= g a=20 legal node of your network as a starting platform for their attacks. Becaus= e=20 of this they are able to inject traffic into your network and read much of = the=20 internal state of the routing. You need mesh-wide authentication and end-to- end encryption to have SOME defense against an internal attacker. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3959131.G2CrCIJ0YS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEABECAAYFAksCaQIACgkQRIfGfFXsz+BymQCYtzyk8M8KIw39JgRIjg+DKIqj LgCgk+85SIEj+F5pO6zPRAtIX8M3lAE= =IjfN -----END PGP SIGNATURE----- --nextPart3959131.G2CrCIJ0YS-- From Chris.Dearlove@baesystems.com Tue Nov 17 01:33:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1493A6A9D for ; Tue, 17 Nov 2009 01:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvfTb6vjodal for ; Tue, 17 Nov 2009 01:33:17 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0C64E3A67C2 for ; Tue, 17 Nov 2009 01:33:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33330642" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 09:33:15 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAH9XMjV012492; Tue, 17 Nov 2009 09:33:23 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:33:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 09:32:59 -0000 Message-ID: In-Reply-To: <009101ca6700$a098cd70$e1ca6850$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default LQ and example MPR thread-index: AcphVAFG99qVyyf1SbCTbuyzfkxXfAAGQdOgAFHB+EAAAiVhUAAAyyKgAADOYGAAAIU0gAAAaLEwAALWMbABC1DjUAAaNNcg References: <004a01ca60dc$a9e06ed0$fda14c70$@nl> <200911090728.21198.henning.rogge@fkie.fraunhofer.de> <25c114b90911090217x4c4091e8oe3de0c5837a49826@mail.gmail.com> <25c114b90911090511x312e6418qba14665fc4d52076@mail.gmail.com> <007a01ca6149$65b09a60$3111cf20$@nl><25c114b90911090641l686a0a0re4c2add23c75092@mail.gmail.com><009e01ca614d$cceadac0$66c09040$@nl><81170054-FBFA-493E-AC5A-C62279D47815@thomasclausen.org><00a801ca6152$d6c46c50$844d44f0$@nl><00bb01ca6175$94a10950$bde31bf0$@nl> <022e01ca62bf$a664a610$f32df230$@nl> <024901ca62c5$0d896d30$289c4790$@nl> <024f01ca62c9$ecdd38f0$c697aad0$@nl> <009101ca6700$a098cd70$e1ca6850$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 17 Nov 2009 09:33:14.0886 (UTC) FILETIME=[FCCA5A60:01CA6768] Cc: manet@ietf.org Subject: Re: [manet] Default LQ and example MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:33:18 -0000 The MAY to SHOULD thing is a tricky one. Personally I would agree that you should (lower case should). But back when this was put together, there were some opinions not wanting to use link quality, and the MAY, together with other wordings (noting that if link quality never changes you don't need to record it) was a compromise that kept consensus. I'd rather not re-open that, despite personally being happy with SHOULD. There is also an argument that this is not an interoperability issue, it's entirely local to a router and is a quality of implementation issue, and those don't need to be stressed as strongly. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: 16 November 2009 21:06 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: RE: [manet] Default LQ and example MPR *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. >Default values of 0.8 and 0.3 are meaningless if you >haven't (and we neither can nor want to) define the >meaning of the scale. That's why we specifically >changed defaults from OLSRv1. The LQ parameters are dimensionless. The OLSRv1 defaults are not that bad. >> A router SHOULD update link quality based on any information >> available More important: the change from MAY to SHOULD. My experience is that having LQ is crucial on those link types that are our primary concern. Teco. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Tue Nov 17 01:33:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5422C3A6A9D for ; Tue, 17 Nov 2009 01:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt+rFlYupzwS for ; Tue, 17 Nov 2009 01:33:18 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 023B83A69FD for ; Tue, 17 Nov 2009 01:33:17 -0800 (PST) Received: (qmail 11855 invoked from network); 17 Nov 2009 10:33:14 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 10:33:14 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , "'Henning Rogge'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> <200911171012.39026.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911171012.39026.henning.rogge@fkie.fraunhofer.de> Date: Tue, 17 Nov 2009 10:32:40 +0100 Message-ID: <000701ca6768$fa0ac530$ee204f90$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnZiR9P3sZWR8STZqM5p+NLfgxzwAAM/JQ Content-Language: nl Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:33:19 -0000 Let's start with the basic stuff, protection against external attackers, where we are in an open network (no L2 security). I think we shall use packet authentication only, this will work for all packetBB protocols. Having this, we don't need more for 1-hop messages, like NHDP and DYMO. Before we work on more complex cases, I want to see the threat analysis and need for protecting messages, I don't get it now. I did not see practical end-to-end security for any routing protocol=20 before. I can tell I've seen a lot of those. Do we accept a message from a bad guy, when the message looks OK? On IPsec: it is reasonably easy to deploy. This is very different for protecting routing protocols. Key management is mostly pain in the ass. This is for group key management in general.=20 Let's see what happens with KARP. Teco. >-----Oorspronkelijk bericht----- >Van: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >Verzonden: dinsdag 17 november 2009 10:13 >Aan: manet@ietf.org >CC: Ulrich Herberg; Teco Boot >Onderwerp: Re: [manet] Security drafts > >On Tue November 17 2009 09:59:54 Ulrich Herberg wrote: >> > Hi Ulrich, >> > >> > I ask for keeping things simple. >> >> I think that my framework is very simple. But please, if you find any >> possible simplifications in the framework (while preserving the same >> security), point them out to me. >> >> > I don't believe in end-to-end security. >> >> What about IPsec, TLS, SSL, SSH? They are all end-to-end and widely >> used. And coming back to your first comment, I believe that IPsec is >> far more complicated than my proposed framework. >I think we must differentiate between "internal" and "external" >attackers. > >External attackers are much easier to defend against. They don't have >access >to a part of your cryptographic data and are not allowed to participate >in >your network. You can use a link-layer authentication and encryption to >keep >an external attacker out of your network. > >Internal attackers are much more difficult to defend against. They are >using a >legal node of your network as a starting platform for their attacks. >Because >of this they are able to inject traffic into your network and read much >of the >internal state of the routing. You need mesh-wide authentication and >end-to- >end encryption to have SOME defense against an internal attacker. > >Henning Rogge > >-- >Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >Kommunikation, Informationsverarbeitung und Ergonomie FKIE >Kommunikationssysteme (KOM) >Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >Telefon +49 228 9435-263, Fax +49 228 9435 685 >mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From Chris.Dearlove@baesystems.com Tue Nov 17 01:39:49 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079FD3A6B9D for ; Tue, 17 Nov 2009 01:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCUQPwAE1b+c for ; Tue, 17 Nov 2009 01:39:48 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id F190C3A67EA for ; Tue, 17 Nov 2009 01:39:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33332871" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 09:39:46 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAH9drT8017540; Tue, 17 Nov 2009 09:39:54 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:39:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 09:39:44 -0000 Message-ID: In-Reply-To: <008a01ca66f9$e61c3aa0$b254afe0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAByfRwA= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" , X-OriginalArrivalTime: 17 Nov 2009 09:39:45.0586 (UTC) FILETIME=[E5AA7120:01CA6769] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:39:49 -0000 > At first, I would like to distinguish networks that have L2 protection > and those who have not. For the firsts, we could skip the whole thing. Not necessarily so. Consider for example an 802.11 network with what is, in effect, a shared secret key across the network. I may find that security worth having (it's there, use it, and it has some other advantages) but not sufficient. I want to add some L3 security that improves on it, with individual keys. >From an L3 point of view, yes, in some systems L3 security may not be needed. But it's not as simple as that just being having L2 security. > After more analysis of threats, I expect a demand for protecting packets, > not messages. In OLSR, protecting messages gives end to end security, while protecting packets gives hop by hop security. There can be some advantages in the former. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Nov 17 01:45:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A113B3A6B9D for ; Tue, 17 Nov 2009 01:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQnycH8VU9eo for ; Tue, 17 Nov 2009 01:45:04 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 8B0D83A696F for ; Tue, 17 Nov 2009 01:45:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33334526" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 09:45:03 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAH9jAh1021707; Tue, 17 Nov 2009 09:45:10 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:45:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 09:45:01 -0000 Message-ID: In-Reply-To: <009201ca6702$61efa010$25cee030$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/wABpG5+A= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl><25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 17 Nov 2009 09:45:02.0793 (UTC) FILETIME=[A2BC6390:01CA676A] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:45:05 -0000 > I don't believe in end-to-end security. But others do. And we want mechanisms for those that do. > Why are relayed messages by bad guys interesting? I would ask why relayed messages by bad guys could be harmful. And I can do that. > Why a security mechanism, far more complex > than all what exists today, without a request for it? How do you know who's requested what? Maybe the people working here have other people behind them who want such things but don't go round discussing their specific needs. The intent of the draft is a framework which can be used to do many things. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Tue Nov 17 01:48:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A4E3A69CE for ; Tue, 17 Nov 2009 01:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPTcmABtWwcp for ; Tue, 17 Nov 2009 01:48:19 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B463B3A681B for ; Tue, 17 Nov 2009 01:48:18 -0800 (PST) Received: (qmail 24859 invoked from network); 17 Nov 2009 10:48:15 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 10:48:15 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> In-Reply-To: Date: Tue, 17 Nov 2009 10:47:41 +0100 Message-ID: <001001ca676b$1316bfa0$39443ee0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAByfRwAAAG5TwA== Content-Language: nl Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:48:19 -0000 Thanks, we need such analysis in a threats draft. Teco. >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: dinsdag 17 november 2009 10:40 >Aan: Teco Boot; Ulrich Herberg; manet@ietf.org >Onderwerp: RE: [manet] Security drafts > >> At first, I would like to distinguish networks that have L2 protection > >> and those who have not. For the firsts, we could skip the whole thing. > >Not necessarily so. > >Consider for example an 802.11 network with what is, in effect, a >shared secret key across the network. I may find that security worth >having (it's there, use it, and it has some other advantages) but not >sufficient. I want to add some L3 security that improves on it, with >individual keys. > >From an L3 point of view, yes, in some systems L3 security may not be >needed. But it's not as simple as that just being having L2 security. > >> After more analysis of threats, I expect a demand for protecting >packets, >> not messages. > >In OLSR, protecting messages gives end to end security, while protecting >packets gives hop by hop security. There can be some advantages in the >former. > >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** From teco@inf-net.nl Tue Nov 17 01:52:43 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C013A6A9D for ; Tue, 17 Nov 2009 01:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asEA2t4r74v4 for ; Tue, 17 Nov 2009 01:52:42 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 252233A69DD for ; Tue, 17 Nov 2009 01:52:41 -0800 (PST) Received: (qmail 28716 invoked from network); 17 Nov 2009 10:52:39 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 10:52:39 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl><25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> In-Reply-To: Date: Tue, 17 Nov 2009 10:52:04 +0100 Message-ID: <001101ca676b$b0774ad0$1165e070$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/wABpG5+AAAErIcA== Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:52:43 -0000 What to do when a bad guy strips authentication, manipulates and forward? And adjust hop-count / hop-limit and forward? I ask this, for being included in the threats draft. We need a document on specific needs. Teco. >-----Oorspronkelijk bericht----- >Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >Verzonden: dinsdag 17 november 2009 10:45 >Aan: Teco Boot; Ulrich Herberg >CC: manet@ietf.org >Onderwerp: RE: [manet] Security drafts > >> I don't believe in end-to-end security. > >But others do. And we want mechanisms for those that do. > >> Why are relayed messages by bad guys interesting? > >I would ask why relayed messages by bad guys could be harmful. >And I can do that. > >> Why a security mechanism, far more complex >> than all what exists today, without a request for it? > >How do you know who's requested what? Maybe the people working >here have other people behind them who want such things but >don't go round discussing their specific needs. The intent of >the draft is a framework which can be used to do many things. > >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** From Chris.Dearlove@baesystems.com Tue Nov 17 01:53:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2263A69CE for ; Tue, 17 Nov 2009 01:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG0K4M3F2wwf for ; Tue, 17 Nov 2009 01:53:03 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2D6A73A682E for ; Tue, 17 Nov 2009 01:53:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33337580" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 09:53:01 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAH9r92k028171; Tue, 17 Nov 2009 09:53:09 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:53:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 09:53:00 -0000 Message-ID: In-Reply-To: <000701ca6768$fa0ac530$ee204f90$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: AcpnZiR9P3sZWR8STZqM5p+NLfgxzwAAM/JQAAD73JA= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><009201ca6702$61efa010$25cee030$@nl><25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com><200911171012.39026.henning.rogge@fkie.fraunhofer.de> <000701ca6768$fa0ac530$ee204f90$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" , "Henning Rogge" , X-OriginalArrivalTime: 17 Nov 2009 09:53:01.0097 (UTC) FILETIME=[BFD3C990:01CA676B] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:53:04 -0000 > I think we shall use packet authentication only, this will work for all > packetBB protocols. OK, here's one specific example of the advantage of end to end security over hop by hop security used for something like TC messages in OLSR. I'm a bad guy. I capture node X and have access to its internals. End to end, I can forge messages from node X. Not good. Hop by hop, I can forge messages from any node, as forwarded by node X. Even worse. My point is not that that's the only reason, but it is an illustration of how end to end and hop by hop are different. And some people want the end to end. Note that had you been arguing to keep end to end and not have hop by hop I'd have disagreed with that too. As a "toolbox" draft, we want hammers and screwdrivers. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Tue Nov 17 02:00:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7693A6813 for ; Tue, 17 Nov 2009 02:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpJuoLDbUSsi for ; Tue, 17 Nov 2009 02:00:04 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 510B03A69CE for ; Tue, 17 Nov 2009 02:00:04 -0800 (PST) Received: by bwz23 with SMTP id 23so6746995bwz.29 for ; Tue, 17 Nov 2009 01:59:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.154.131 with SMTP id o3mr4530124bkw.66.1258451999535; Tue, 17 Nov 2009 01:59:59 -0800 (PST) In-Reply-To: <001101ca676b$b0774ad0$1165e070$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <001101ca676b$b0774ad0$1165e070$@nl> Date: Tue, 17 Nov 2009 10:59:59 +0100 Message-ID: <25c114b90911170159l3c2e6621ta6cee65a151891e@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:00:05 -0000 Teco, On Tue, Nov 17, 2009 at 10:52 AM, Teco Boot wrote: > What to do when a bad guy strips authentication, manipulates and forward? In that case, the bad guy is not able to sign the message again (remember: "bad guy" == guy who does not possess a valid key). The forwarded message will thus be ignored by routers receiving such a forged message. > And adjust hop-count / hop-limit and forward? > I ask this, for being included in the threats draft. > > We need a document on specific needs. I will definitely rework the threats draft to include some more explanations, such as an explanation why we need end-to-end security. This will be particularly important for the upcoming OLSRv2-sec-threats document. Ulrich > > Teco. > >>-----Oorspronkelijk bericht----- >>Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >>Verzonden: dinsdag 17 november 2009 10:45 >>Aan: Teco Boot; Ulrich Herberg >>CC: manet@ietf.org >>Onderwerp: RE: [manet] Security drafts >> >>> I don't believe in end-to-end security. >> >>But others do. And we want mechanisms for those that do. >> >>> Why are relayed messages by bad guys interesting? >> >>I would ask why relayed messages by bad guys could be harmful. >>And I can do that. >> >>> Why a security mechanism, far more complex >>> than all what exists today, without a request for it? >> >>How do you know who's requested what? Maybe the people working >>here have other people behind them who want such things but >>don't go round discussing their specific needs. The intent of >>the draft is a framework which can be used to do many things. >> >>******************************************************************** >>This email and any attachments are confidential to the intended >>recipient and may also be privileged. If you are not the intended >>recipient please delete it from your system and notify the sender. >>You should not copy it or use it for any purpose nor disclose or >>distribute its contents to any other person. >>******************************************************************** > > From Chris.Dearlove@baesystems.com Tue Nov 17 02:02:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A7E3A681B for ; Tue, 17 Nov 2009 02:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uKRWdBdyGSN for ; Tue, 17 Nov 2009 02:02:11 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4866C3A67A3 for ; Tue, 17 Nov 2009 02:02:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33341404" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 10:02:10 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAHA2Hr4003512; Tue, 17 Nov 2009 10:02:17 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 10:02:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 10:02:08 -0000 Message-ID: In-Reply-To: <001101ca676b$b0774ad0$1165e070$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/wABpG5+AAAErIcAAAQJig References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl><25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <001101ca676b$b0774ad0$1165e070$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 17 Nov 2009 10:02:09.0519 (UTC) FILETIME=[06B657F0:01CA676D] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:02:12 -0000 > What to do when a bad guy strips authentication, manipulates and forward? If we're running in a network with authentication, any unauthenticated message will get dropped, so unless I'm missing the point of the example, that's OK. > And adjust hop-count / hop-limit and forward? That can be an issue. (I assume we're considering authentication that excludes there, and an attacker that just adjusts these.) I can see more than one attack that way. One possible counter to that - I'm not recommending it, I'm just noting it - is applying both end to end and hop by hop authentication, as the latter will cover hop count and limit. There's another form of counter discussed in the SMF draft I believe. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Tue Nov 17 02:09:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA5D28C205 for ; Tue, 17 Nov 2009 02:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KhyaV5mUsSu for ; Tue, 17 Nov 2009 02:09:04 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id AC9BE28C0E7 for ; Tue, 17 Nov 2009 02:09:01 -0800 (PST) Received: by bwz23 with SMTP id 23so6755928bwz.29 for ; Tue, 17 Nov 2009 02:08:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.25.207 with SMTP id a15mr6534171bkc.8.1258452537128; Tue, 17 Nov 2009 02:08:57 -0800 (PST) In-Reply-To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <001101ca676b$b0774ad0$1165e070$@nl> Date: Tue, 17 Nov 2009 11:08:57 +0100 Message-ID: <25c114b90911170208x3ce03b84q9da11f08bb9d177f@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:09:05 -0000 Chris, On Tue, Nov 17, 2009 at 11:02 AM, Dearlove, Christopher (UK) wrote: >[...] > >> And adjust hop-count / hop-limit and forward? > > That can be an issue. (I assume we're considering authentication that > excludes there, and an attacker that just adjusts these.) I can see > more than one attack that way. > > One possible counter to that - I'm not recommending it, I'm just > noting it - is applying both end to end and hop by hop authentication, > as the latter will cover hop count and limit. There's another form of > counter discussed in the SMF draft I believe. Yes, indeed, that can be an issue which needs to be discussed, since hop-count and hop-limit fields are blanked (set to 0) before signing the message (in the upcoming OLSRv2-sec draft) Ulrich From teco@inf-net.nl Tue Nov 17 02:26:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830633A691D for ; Tue, 17 Nov 2009 02:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FKLXbzGpniN for ; Tue, 17 Nov 2009 02:26:12 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 594BD3A686D for ; Tue, 17 Nov 2009 02:26:12 -0800 (PST) Received: (qmail 24060 invoked from network); 17 Nov 2009 11:26:08 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 11:26:08 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" , "'Henning Rogge'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><009201ca6702$61efa010$25cee030$@nl><25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com><200911171012.39026.henning.rogge@fkie.fraunhofer.de> <000701ca6768$fa0ac530$ee204f90$@nl> In-Reply-To: Date: Tue, 17 Nov 2009 11:25:34 +0100 Message-ID: <002301ca6770$5e0c6870$1a253950$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnZiR9P3sZWR8STZqM5p+NLfgxzwAAM/JQAAD73JAAAKLDMA== Content-Language: nl Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:26:13 -0000 >Note that had you been arguing to keep end to end and not have hop by >hop I'd have disagreed with that too. As a "toolbox" draft, we want >hammers and screwdrivers. I am not against a tool-box. I say: keep it simple, especially start with the simple case. Agreed that protecting packets works OK for NHDP, DYMO and the basics for OLSR? I have my thoughts on signature checks, this needs some form of PKI. Not really candidate for an ad hoc network. Teco. From teco@inf-net.nl Tue Nov 17 02:30:56 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4E928C0F6 for ; Tue, 17 Nov 2009 02:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55EYSoDghikO for ; Tue, 17 Nov 2009 02:30:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id A17ED28C0F1 for ; Tue, 17 Nov 2009 02:30:55 -0800 (PST) Received: (qmail 28035 invoked from network); 17 Nov 2009 11:30:53 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 11:30:53 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl><25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <001101ca676b$b0774ad0$1165e070$@nl> In-Reply-To: Date: Tue, 17 Nov 2009 11:30:18 +0100 Message-ID: <002a01ca6771$0792b160$16b81420$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/wABpG5+AAAErIcAAAQJigAAD+bEA= Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:30:56 -0000 >> What to do when a bad guy strips authentication, manipulates and >forward? > >If we're running in a network with authentication, any unauthenticated >message will get dropped, so unless I'm missing the point of the >example, >that's OK. I didn't read unprotected packets are dropped on the floor. This could be a mode of operation. I had the other mode in mind, then the bad guy injects false information with unprotected messages. Also to be included in the threats document. Teco. From Chris.Dearlove@baesystems.com Tue Nov 17 02:36:01 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCB528C21E for ; Tue, 17 Nov 2009 02:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXCncJf3HUga for ; Tue, 17 Nov 2009 02:36:01 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0069928C129 for ; Tue, 17 Nov 2009 02:36:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33354985" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 10:35:59 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAHAa6PG029900; Tue, 17 Nov 2009 10:36:07 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 10:35:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 10:35:57 -0000 Message-ID: In-Reply-To: <002301ca6770$5e0c6870$1a253950$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: AcpnZiR9P3sZWR8STZqM5p+NLfgxzwAAM/JQAAD73JAAAKLDMAAA2+5A References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><009201ca6702$61efa010$25cee030$@nl><25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com><200911171012.39026.henning.rogge@fkie.fraunhofer.de><000701ca6768$fa0ac530$ee204f90$@nl> <002301ca6770$5e0c6870$1a253950$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" , "Henning Rogge" , X-OriginalArrivalTime: 17 Nov 2009 10:35:58.0768 (UTC) FILETIME=[C03D2B00:01CA6771] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:36:02 -0000 > Agreed that protecting packets works OK for NHDP, DYMO and the > basics for OLSR? As end to end may be superior, I would not agree with excluding it. > I have my thoughts on signature checks, this needs some form of PKI. > Not really candidate for an ad hoc network. Various people, including the authors of this draft, and maybe ourselves, have some ideas as to what one might do. Whether they involve PKI may depend on how you define that term. (Actually if the I stands for infrastructure then they may well not be PKI.) But also maybe we aren't going to discuss our thoughts right now. But they may well fit in a good general framework. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:40:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8611F28C239 for ; Tue, 17 Nov 2009 02:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esgsGDOcP0jY for ; Tue, 17 Nov 2009 02:40:15 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id A47D828C22D for ; Tue, 17 Nov 2009 02:40:15 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALTo-0003C2-Q9; Tue, 17 Nov 2009 11:40:12 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALTo-0003Ty-As; Tue, 17 Nov 2009 11:40:12 +0100 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Tue, 17 Nov 2009 11:40:05 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <002301ca6770$5e0c6870$1a253950$@nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3195790.b8n2G4Xaoy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171140.06022.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 03aa31d695fb3eb984fab57667d62e5a Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:40:16 -0000 --nextPart3195790.b8n2G4Xaoy Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:35:57 Dearlove, Christopher (UK) wrote: > > Agreed that protecting packets works OK for NHDP, DYMO and the > > basics for OLSR? >=20 > As end to end may be superior, I would not agree with excluding it. I agree to this, we must not exclude end to end security. "End to end" and "link based" security have different goal, and there are n= ot=20 even mutual exclusive ! So discussing BOTH of them is important in my oppinion. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3195790.b8n2G4Xaoy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCfYUACgkQRIfGfFXsz+CL+ACfTi51IDvtDaH7S47lwwkB+1VD KMoAmgIMz3vE1HcOTo7jbGP9erPckwR1 =9ila -----END PGP SIGNATURE----- --nextPart3195790.b8n2G4Xaoy-- From Chris.Dearlove@baesystems.com Tue Nov 17 02:40:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F281A28C242 for ; Tue, 17 Nov 2009 02:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbGIoVdAtPlC for ; Tue, 17 Nov 2009 02:40:39 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 20E5028C23A for ; Tue, 17 Nov 2009 02:40:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33356512" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 10:40:37 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAHAej6G000743; Tue, 17 Nov 2009 10:40:45 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 10:40:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2009 10:40:35 -0000 Message-ID: In-Reply-To: <002a01ca6771$0792b160$16b81420$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: Acpm/pH1PlNPjYm/T4ig9snAxVUEtAAAke/wABpG5+AAAErIcAAAQJigAAD+bEAAAGrJ8A== References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl><25c114b90911161251qe9bc28cu2c4d7bf89396ca54@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <001101ca676b$b0774ad0$1165e070$@nl> <002a01ca6771$0792b160$16b81420$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 17 Nov 2009 10:40:37.0268 (UTC) FILETIME=[663CE540:01CA6772] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:40:41 -0000 > I didn't read unprotected packets are dropped on the floor. There's no point in not giving unprotected packets a hard time. The easiest hard time is just to drop them, and in systems I'd be most interested in, that would be the right thing to do. There could be possibilities in, for example, recording both authenticated and unauthenticated messages and doing some sort of "only use unauthenticated when no authenticated is known". But that would be quite a bit of work to get to be safe (in the sense of e.g. not looping in a routing protocol) and you'd have to have a real use case to make that work worthwhile. In the absence of such a case, dropping is the way to go. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Nov 17 02:42:21 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1743A6911 for ; Tue, 17 Nov 2009 02:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0AyR9e8r1pg for ; Tue, 17 Nov 2009 02:42:20 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 153E428C245 for ; Tue, 17 Nov 2009 02:42:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,757,1249254000"; d="scan'208";a="33357005" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Nov 2009 10:42:06 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAHAgDII002152; Tue, 17 Nov 2009 10:42:14 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 10:42:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Nov 2009 10:42:05 -0000 Message-ID: In-Reply-To: <200911171140.06022.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts thread-index: AcpncllWq6EYB8i+SoqdO5ggisEjWQAABZ4g References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <002301ca6770$5e0c6870$1a253950$@nl> <200911171140.06022.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 17 Nov 2009 10:42:06.0190 (UTC) FILETIME=[9B3D50E0:01CA6772] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:42:21 -0000 I think I made the same point elsewhere. But just in case not, to be clear, yes, we should have a framework that handles using one, the other, or both together. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 17 November 2009 10:40 To: Dearlove, Christopher (UK) Cc: Teco Boot; Ulrich Herberg; manet@ietf.org Subject: Re: [manet] Security drafts On Tue November 17 2009 11:35:57 Dearlove, Christopher (UK) wrote: > > Agreed that protecting packets works OK for NHDP, DYMO and the > > basics for OLSR? >=20 > As end to end may be superior, I would not agree with excluding it. I agree to this, we must not exclude end to end security. "End to end" and "link based" security have different goal, and there are n= ot=20 even mutual exclusive ! So discussing BOTH of them is important in my oppinion. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:44:46 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF33A3A69DA for ; Tue, 17 Nov 2009 02:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bHkCpnqeUfE for ; Tue, 17 Nov 2009 02:44:45 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id C4C173A69D1 for ; Tue, 17 Nov 2009 02:44:45 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALYB-0004ZO-77; Tue, 17 Nov 2009 11:44:43 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALYA-0003Y7-TT; Tue, 17 Nov 2009 11:44:42 +0100 From: Henning Rogge To: manet@ietf.org Date: Tue, 17 Nov 2009 11:44:37 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <002a01ca6771$0792b160$16b81420$@nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1621376.RepNnYJRHV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171144.37509.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:44:46 -0000 --nextPart1621376.RepNnYJRHV Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:40:35 Dearlove, Christopher (UK) wrote: > > I didn't read unprotected packets are dropped on the floor. >=20 > There's no point in not giving unprotected packets a hard time. > The easiest hard time is just to drop them, and in systems I'd > be most interested in, that would be the right thing to do. >=20 > There could be possibilities in, for example, recording both > authenticated and unauthenticated messages and doing some sort > of "only use unauthenticated when no authenticated is known". > But that would be quite a bit of work to get to be safe (in the > sense of e.g. not looping in a routing protocol) and you'd have > to have a real use case to make that work worthwhile. In the > absence of such a case, dropping is the way to go. We could regard non-signed messages as "second class citizens" so that fore= ign=20 nodes can join a secured network without disrupting it. This would be simil= ar=20 to having multiple routing tables, one for the secure network part and one = for=20 the rest of it. Of course unsigned messages for nodes we know signing messages should be=20 ignored. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1621376.RepNnYJRHV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCfpUACgkQRIfGfFXsz+DyMQCdFzRAi3gluW65kQaKG8/YrZAm HQcAnjsFjHRxCPaUhrHovNhFbWKV3HKV =WMuZ -----END PGP SIGNATURE----- --nextPart1621376.RepNnYJRHV-- From teco@inf-net.nl Tue Nov 17 03:00:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F88D3A6A88 for ; Tue, 17 Nov 2009 03:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.191 X-Spam-Level: X-Spam-Status: No, score=0.191 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPdGAr7w1xkr for ; Tue, 17 Nov 2009 03:00:10 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 31DEA3A693C for ; Tue, 17 Nov 2009 03:00:09 -0800 (PST) Received: (qmail 20571 invoked from network); 17 Nov 2009 12:00:05 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 12:00:05 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <002301ca6770$5e0c6870$1a253950$@nl> <200911171140.06022.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Date: Tue, 17 Nov 2009 11:59:31 +0100 Message-ID: <004e01ca6775$1c243550$546c9ff0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpncllWq6EYB8i+SoqdO5ggisEjWQAABZ4gAACVFuA= Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:00:11 -0000 >I think I made the same point elsewhere. But just in case not, >to be clear, yes, we should have a framework that handles using >one, the other, or both together. I think the postings provide useful input for improving the security drafts. This was my intention. I'm looking forward to updated versions. Thanks, Teco From ulrich@herberg.name Tue Nov 17 03:03:01 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EC03A6915 for ; Tue, 17 Nov 2009 03:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn4KXkoSs4Ca for ; Tue, 17 Nov 2009 03:03:01 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 133B13A6806 for ; Tue, 17 Nov 2009 03:03:00 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so2287277eyd.51 for ; Tue, 17 Nov 2009 03:02:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.1.28 with SMTP id 28mr2006813ebd.8.1258455775523; Tue, 17 Nov 2009 03:02:55 -0800 (PST) In-Reply-To: <004e01ca6775$1c243550$546c9ff0$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <002301ca6770$5e0c6870$1a253950$@nl> <200911171140.06022.henning.rogge@fkie.fraunhofer.de> <004e01ca6775$1c243550$546c9ff0$@nl> Date: Tue, 17 Nov 2009 12:02:55 +0100 Message-ID: <25c114b90911170302t50efaf81t8396b21f3a498709@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:03:02 -0000 On Tue, Nov 17, 2009 at 11:59 AM, Teco Boot wrote: >>I think I made the same point elsewhere. But just in case not, >>to be clear, yes, we should have a framework that handles using >>one, the other, or both together. > > I think the postings provide useful input for improving the security > drafts. This was my intention. I'm looking forward to updated versions. Indeed, thanks a lot for all the comments. I will work on updated versions of the drafts. Ulrich From budden@nps.edu Tue Nov 17 09:44:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBB03A6AE2 for ; Tue, 17 Nov 2009 09:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfNj0omO6G9x for ; Tue, 17 Nov 2009 09:44:19 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 4820C3A6A58 for ; Tue, 17 Nov 2009 09:44:19 -0800 (PST) Received: from [172.20.57.107] ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:44:17 -0800 From: Rex Buddenberg To: Henning Rogge In-Reply-To: <200911171012.39026.henning.rogge@fkie.fraunhofer.de> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> <200911171012.39026.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain Date: Tue, 17 Nov 2009 09:44:32 -0800 Message-Id: <1258479872.17184.205.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 (2.26.1-2.fc11) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2009 17:44:17.0941 (UTC) FILETIME=[9623C450:01CA67AD] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:44:20 -0000 On Tue, 2009-11-17 at 10:12 +0100, Henning Rogge wrote: > On Tue November 17 2009 09:59:54 Ulrich Herberg wrote: > > > Hi Ulrich, > > > > > I don't believe in end-to-end security. End-end security is the ONLY long term solution to content security. Infrastructure protection only protects infrastructure. > > > > External attackers are much easier to defend against. They don't have access > to a part of your cryptographic data and are not allowed to participate in > your network. You can use a link-layer authentication and encryption to keep > an external attacker out of your network. > > Internal attackers are much more difficult to defend against. This is the problem to focus on. For all practical purposes, we have to assume that everybody -- Bad Guys included -- is on the internet. They're all insiders. ... or will be in due time. > > What about IPsec, TLS, SSL, SSH? - all are end-end as far as the internet is concerned. - IPsec's scope is single enclave, TLS/SSL scope is single TCP connection. The shortcomings here are that there's lots of untrusted OS software out there that sees unprotected data. SSH (and more elegantly, S/MIME) are more completely end-end. But.... all is outside of scope for this group. End-end security is absolutely necessary. But again, probably outside scope for MANET. -- Rex Buddenberg Naval Postgraduate School Code IS/Bu Monterey, Ca 93943 831/656-3576 From ulrich@herberg.name Tue Nov 17 10:00:59 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EAF3A6AE5 for ; Tue, 17 Nov 2009 10:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUr1Ihh4yAe1 for ; Tue, 17 Nov 2009 10:00:58 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 0C3023A6AE8 for ; Tue, 17 Nov 2009 10:00:57 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so61255eyd.51 for ; Tue, 17 Nov 2009 10:00:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.100.167 with SMTP id y39mr2577493ebn.51.1258480852445; Tue, 17 Nov 2009 10:00:52 -0800 (PST) In-Reply-To: <1258479872.17184.205.camel@localhost.localdomain> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <009201ca6702$61efa010$25cee030$@nl> <25c114b90911170059w6091212ar4de550ed5036d62f@mail.gmail.com> <200911171012.39026.henning.rogge@fkie.fraunhofer.de> <1258479872.17184.205.camel@localhost.localdomain> Date: Tue, 17 Nov 2009 19:00:52 +0100 Message-ID: <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> From: Ulrich Herberg To: Rex Buddenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:00:59 -0000 Rex, On Tue, Nov 17, 2009 at 6:44 PM, Rex Buddenberg wrote= : >> > > I don't believe in end-to-end security. > > End-end security is the ONLY long term solution to content security. > Infrastructure protection only protects infrastructure. Yes, end-to-end protection is very important. >> > >> >> External attackers are much easier to defend against. They don't have ac= cess >> to a part of your cryptographic data and are not allowed to participate = in >> your network. You can use a link-layer authentication and encryption to = keep >> an external attacker out of your network. >> >> Internal attackers are much more difficult to defend against. > > This is the problem to focus on. =A0For all practical purposes, we have t= o > assume that everybody -- Bad Guys included -- is on the internet. > They're all insiders. =A0... or will be in due time. > >> > What about IPsec, TLS, SSL, SSH? > > =A0 =A0 =A0 =A0- all are end-end as far as the internet is concerned. > =A0 =A0 =A0 =A0- IPsec's scope is single enclave, TLS/SSL scope is single= TCP > connection. =A0The shortcomings here are that there's lots of untrusted O= S > software out there that sees unprotected data. =A0SSH (and more elegantly= , > S/MIME) are more completely end-end. =A0But.... all is outside of scope > for this group. Yes, I agree they are out of scope for MANET WG. > > End-end security is absolutely necessary. =A0But again, probably outside > scope for MANET. But do you think that the proposed framework is in scope for MANET? Ulrich From henning.rogge@fkie.fraunhofer.de Tue Nov 17 22:45:57 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231513A68F7 for ; Tue, 17 Nov 2009 22:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UJy9DWFim0h for ; Tue, 17 Nov 2009 22:45:56 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id EBAAC3A6358 for ; Tue, 17 Nov 2009 22:45:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAeIZ-0005aO-Sl; Wed, 18 Nov 2009 07:45:51 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAeIZ-0000dl-Jg; Wed, 18 Nov 2009 07:45:51 +0100 From: Henning Rogge To: Ulrich Herberg Date: Wed, 18 Nov 2009 07:45:43 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> In-Reply-To: <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1693348.F1R2Hz3uZV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911180745.48511.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10037/Wed Nov 18 03:15:38 2009) by mailguard.fgan.de X-Scan-Signature: 4752504f224081e57c30a21c7b02e935 Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 06:45:57 -0000 --nextPart1693348.F1R2Hz3uZV Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 19:00:52 Ulrich Herberg wrote: > > End-end security is absolutely necessary. But again, probably outside > > scope for MANET. >=20 > But do you think that the proposed framework is in scope for MANET? Could we maybe agree that "mesh-wide" routing security (and not only hop-by- hop) is in scope for MANET ? Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1693348.F1R2Hz3uZV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksDmBcACgkQRIfGfFXsz+B/bgCfZOyd1aH+Yq7ADUBCFUHMBM7j f0YAn1SvxqnkjjijciB1LgBAFCsv4yBB =umDn -----END PGP SIGNATURE----- --nextPart1693348.F1R2Hz3uZV-- From teco@inf-net.nl Tue Nov 17 23:05:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865173A6A69 for ; Tue, 17 Nov 2009 23:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id annlqmr9EY1j for ; Tue, 17 Nov 2009 23:05:19 -0800 (PST) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 7393D3A6359 for ; Tue, 17 Nov 2009 23:05:19 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 18 Nov 2009 08:05:17 +0100 From: "Teco Boot" To: "'Henning Rogge'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911180745.48511.henning.rogge@fkie.fraunhofer.de> Date: Wed, 18 Nov 2009 08:05:13 +0100 Message-ID: <009f01ca681d$7975bd20$6c613760$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpoGtenrKIPJr2WRH64YBouT5zeaAAAa3Fg Content-Language: nl X-OriginalArrivalTime: 18 Nov 2009 07:05:17.0317 (UTC) FILETIME=[7BC29350:01CA681D] Cc: 'Rex Buddenberg' , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 07:05:20 -0000 >> > End-end security is absolutely necessary. But again, probably >outside >> > scope for MANET. >> >> But do you think that the proposed framework is in scope for MANET? >Could we maybe agree that "mesh-wide" routing security (and not only >hop-by- >hop) is in scope for MANET ? Yes, I agree the scope is limited to mesh or better: MANET protocol. Question is: handling security hop by hop, with for example shared key? I think: this perfectly fits NHDP, DYMO (all DV protocols) and the basics of OLSR. Then the question is: do we need more? Some say so, so we can go for it. But this can be a huge effort to deploy, especially in MANETs. That is the reason I am conservative on this. One important principle in security is: minimize (keep it simple and robust). Teco. From henning.rogge@fkie.fraunhofer.de Wed Nov 18 00:02:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7513A67A2 for ; Wed, 18 Nov 2009 00:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpzHsUZ+tp46 for ; Wed, 18 Nov 2009 00:02:41 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 59A6C3A67EC for ; Wed, 18 Nov 2009 00:02:40 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAfUn-0000vP-5Y; Wed, 18 Nov 2009 09:02:33 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAfUm-0000yq-Nz; Wed, 18 Nov 2009 09:02:32 +0100 From: Henning Rogge To: "Teco Boot" Date: Wed, 18 Nov 2009 09:02:21 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> In-Reply-To: <009f01ca681d$7975bd20$6c613760$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7193387.mH31FZbNv8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911180902.27287.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10038/Wed Nov 18 06:41:45 2009) by mailguard.fgan.de X-Scan-Signature: 2577de289e0484eccb48b316b05ab48b Cc: 'Rex Buddenberg' , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 08:02:42 -0000 --nextPart7193387.mH31FZbNv8 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed November 18 2009 08:05:13 Teco Boot wrote: > Yes, I agree the scope is limited to mesh or better: MANET protocol. > Question is: handling security hop by hop, with for example shared key? Working with a shared key does not do routing security. Defending against a= n=20 externel attacker can be done with Layer-2 security (link encryption). > I think: this perfectly fits NHDP, DYMO (all DV protocols) and the basics > of OLSR. Then the question is: do we need more? Routing attacks on NHDP from inside the network are based on forged NHDP=20 messages. You cannot prevent an attack like this with a shared group key. > Some say so, so we can go > for it. But this can be a huge effort to deploy, especially in MANETs. Yes, finding a good tradeoff between security and performance in not easy. > That is the reason I am conservative on this. One important principle > in security is: minimize (keep it simple and robust). Simple and robust, yes... minimize ? Hmm... Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart7193387.mH31FZbNv8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksDqg0ACgkQRIfGfFXsz+AlDACfePEoql5oZ5Cz8sybngfxL8gu TP8AoIBJmOdtaGbGmcpVsQAaiz+jtWyt =ZaYy -----END PGP SIGNATURE----- --nextPart7193387.mH31FZbNv8-- From ulrich@herberg.name Wed Nov 18 00:08:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393883A6820 for ; Wed, 18 Nov 2009 00:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmNa+JzltWkA for ; Wed, 18 Nov 2009 00:08:17 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 2D8DA3A694C for ; Wed, 18 Nov 2009 00:08:17 -0800 (PST) Received: by fxm7 with SMTP id 7so881749fxm.29 for ; Wed, 18 Nov 2009 00:08:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.32.204 with SMTP id e12mr305248bkd.51.1258531691949; Wed, 18 Nov 2009 00:08:11 -0800 (PST) In-Reply-To: <009f01ca681d$7975bd20$6c613760$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> Date: Wed, 18 Nov 2009 09:08:11 +0100 Message-ID: <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 08:08:18 -0000 Teco On Wed, Nov 18, 2009 at 8:05 AM, Teco Boot wrote: >>> > End-end security is absolutely necessary. =A0But again, probably >>outside >>> > scope for MANET. >>> >>> But do you think that the proposed framework is in scope for MANET? >>Could we maybe agree that "mesh-wide" routing security (and not only >>hop-by- >>hop) is in scope for MANET ? > > Yes, I agree the scope is limited to mesh or better: MANET protocol. > Question is: handling security hop by hop, with for example shared key? > I think: this perfectly fits NHDP, DYMO (all DV protocols) and the basics > of OLSR. Then the question is: do we need more? Some say so, so we can go > for it. But this can be a huge effort to deploy, especially in MANETs. > That is the reason I am conservative on this. One important principle > in security is: minimize (keep it simple and robust). I agree with you that we should keep it simple. However, in order to achieve robustness of the security solution, we need end-to-end protection. Otherwise, many security attacks will still be possible, and we would not gain much. Just to give to an example: How would you avoid identity spoofing and link spoofing of TC messages when not using end-to-end protection? A router that receives a TC message has no means of telling whether that message is "good" or "bad". That router only knows that it is forwarded from a "good" relay, but nothing about the originator. Ulrich From teco@inf-net.nl Wed Nov 18 06:59:44 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38833A6AB1 for ; Wed, 18 Nov 2009 06:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1fhImOIn2zx for ; Wed, 18 Nov 2009 06:59:44 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 96C673A696C for ; Wed, 18 Nov 2009 06:59:43 -0800 (PST) Received: (qmail 29369 invoked from network); 18 Nov 2009 15:59:40 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 18 Nov 2009 15:59:40 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> In-Reply-To: <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> Date: Wed, 18 Nov 2009 15:59:06 +0100 Message-ID: <003301ca685f$be9a1030$3bce3090$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpoJkdvWQbJbVKJSNK99ZmqYNAv4wANxpZQ Content-Language: nl Cc: 'Rex Buddenberg' , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:59:44 -0000 Hi, >-----Oorspronkelijk bericht----- >Van: Ulrich Herberg [mailto:ulrich@herberg.name] >Verzonden: woensdag 18 november 2009 9:08 >Aan: Teco Boot >CC: Henning Rogge; Rex Buddenberg; manet@ietf.org >Onderwerp: Re: [manet] Security drafts > >Teco > >On Wed, Nov 18, 2009 at 8:05 AM, Teco Boot wrote: >>>> > End-end security is absolutely necessary. =A0But again, probably >>>outside >>>> > scope for MANET. >>>> >>>> But do you think that the proposed framework is in scope for MANET? >>>Could we maybe agree that "mesh-wide" routing security (and not only >>>hop-by- >>>hop) is in scope for MANET ? >> >> Yes, I agree the scope is limited to mesh or better: MANET protocol. >> Question is: handling security hop by hop, with for example shared >key? >> I think: this perfectly fits NHDP, DYMO (all DV protocols) and the >basics >> of OLSR. Then the question is: do we need more? Some say so, so we = can >go >> for it. But this can be a huge effort to deploy, especially in = MANETs. >> That is the reason I am conservative on this. One important principle >> in security is: minimize (keep it simple and robust). > >I agree with you that we should keep it simple. However, in order to >achieve robustness of the security solution, we need end-to-end >protection.=20 Please use other wording. Maybe you meant multi-hop router to router. This is not (always) end-to-end. > Otherwise, many security attacks will still be possible, >and we would not gain much. Just to give to an example: How would you >avoid identity spoofing and link spoofing of TC messages when not >using end-to-end protection? The bad guy cannot spoof, if not having the pre-shared key. Protecting the pre-shared key could be problematic. Group-key updates in a MANET is also difficult. Black list distribution=20 is another problem. Because you left out key management, we can't discuss this in detail. > A router that receives a TC message has >no means of telling whether that message is "good" or "bad". That >router only knows that it is forwarded from a "good" relay, but >nothing about the originator. It is all about trust. If the TC has traveled only trusted neighbors, what is the problem? Yes, how do we know a node somewhat far away did not invalidate the TC, but the TC was malformed? But what is the problem here, the network is affected by this misbehaving node already? You may come up with a scenario, where invalidating such messages is important. But I think the costs for this is extremely high and the benefit is low. I say: shoot down this invalid TC near to the place where it was get corrupted. Every hop it took after that is a hop too far. Teco. From Chris.Dearlove@baesystems.com Wed Nov 18 09:25:24 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C189E3A6A0F for ; Wed, 18 Nov 2009 09:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY45KpriusvQ for ; Wed, 18 Nov 2009 09:25:23 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 69D7C3A6A06 for ; Wed, 18 Nov 2009 09:25:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,766,1249254000"; d="scan'208";a="33725143" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 18 Nov 2009 17:25:19 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAIHPQoN008736; Wed, 18 Nov 2009 17:25:26 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 17:25:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2009 17:25:17 -0000 Message-ID: In-Reply-To: <003301ca685f$be9a1030$3bce3090$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpoJkdvWQbJbVKJSNK99ZmqYNAv4wANxpZQAASoW1A= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl><25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 18 Nov 2009 17:25:18.0690 (UTC) FILETIME=[19819C20:01CA6874] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:25:24 -0000 > Please use other wording. Maybe you meant multi-hop router to router. > This is not (always) end-to-end. If an OLSR router creates a TC message, which travels (as a TC message, but in different packets) multiple hops to another OLSR router, and the receiving OLSR router verifies that the originating OLSR router did create that message (assuming no failure of the security mechanism) then that is end to end with regard to that message. It's not end to end with regard to host applications attached to those routers of course. But within the RFC 5444 context, end to end is a reasonable way to view it. It's not my document, so what wording it should use I'm not fussed by, whether it uses end to end (but could note what that means - basically RFC 5444 message generating end to RFC 5444 message processing end) or something else. > The bad guy cannot spoof, if not having the pre-shared key. Pre-shared key is an assumption that we do not all share. But the point of the framework is that pre-shared key is an option. But only an option. > Because you left out key management, we can't discuss this in > detail. The point is to make this independent of that. If A and B have a security association such that if A signs a message then B will be able to tell that the signature is valid, one part of the problem is to enable that signature to be attached to that message and delivered with it. How the security association is set up is (as far as concerned here) Somebody Else's Problem. > It is all about trust. If the TC has traveled only trusted neighbors, > what is the problem? Is trust transitive? I know in my early days at the IETF I sat in a meeting, of I now know not what WG, where two people were arguing past each other, and that was because one would have answered that question no and the other would have said partly. > You may come up with a scenario, where invalidating such messages > is important. But I think the costs for this is extremely high and > the benefit is low. I say: shoot down this invalid TC near to the > place where it was get corrupted. Every hop it took after that is > a hop too far. That may stop me getting some messages. And that may be a good idea. But it still leaves me with a chain of verifications I may choose not to accept, I'd rather have it from the horse's mouth. Here's just one reason why. Suppose a bad guy (TM) manages to spoof being node A. (Note that I'm not using a single shared key - and yes, I can do that - so the bad guy can't directly pretend to be anyone without information I'm not even going to put in the MANET.) Then with end to end signatures all he can do is create messages claiming to be from node A. But with hop by hop signatures he can create and inject message claiming to be from nodes B to Z. Even if I work out that A is not to be trusted, I'm left with a mess of I don't know what is trustworthy or not. With the end to end I know what came from or about A, and I can bin that, and the rest of the stuff is still good. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ietf@thomasclausen.org Wed Nov 18 09:38:09 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3A63A69FF for ; Wed, 18 Nov 2009 09:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-KKCRvoVvfE for ; Wed, 18 Nov 2009 09:38:08 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 70C8E3A6996 for ; Wed, 18 Nov 2009 09:38:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0BE4D4303AA; Wed, 18 Nov 2009 09:38:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-90-209.w92-140.abo.wanadoo.fr [92.140.105.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 580E54303DA; Wed, 18 Nov 2009 09:38:05 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 18:38:02 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl><25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:38:09 -0000 On Nov 18, 2009, at 6:25 PM, Dearlove, Christopher (UK) wrote: >> Please use other wording. Maybe you meant multi-hop router to router. >> This is not (always) end-to-end. > > If an OLSR router creates a TC message, which travels (as a TC > message, but in different packets) multiple hops to another > OLSR router, and the receiving OLSR router verifies that the > originating OLSR router did create that message (assuming no > failure of the security mechanism) then that is end to end > with regard to that message. It's not end to end with regard > to host applications attached to those routers of course. But > within the RFC 5444 context, end to end is a reasonable way > to view it. It's not my document, so what wording it should > use I'm not fussed by, whether it uses end to end (but could > note what that means - basically RFC 5444 message generating > end to RFC 5444 message processing end) or something else. I think you are both right here, Teco, Chris - this is a matter which we need to be clear on in the document(s). Thanks for bringing it to our attention. >> The bad guy cannot spoof, if not having the pre-shared key. > > Pre-shared key is an assumption that we do not all share. But > the point of the framework is that pre-shared key is an option. > But only an option. It is *an* option that provides something different than e.g. asymmetric keys - e.g. identity verification. The point is, that these I-Ds shall not make a position (at this juncture) on which is "the way" but rather try to frame as much as possible as common ground for both. >> Because you left out key management, we can't discuss this in >> detail. > > The point is to make this independent of that. If A and B have > a security association such that if A signs a message then B > will be able to tell that the signature is valid, one part of > the problem is to enable that signature to be attached to that > message and delivered with it. How the security association is > set up is (as far as concerned here) Somebody Else's Problem. I agree. As far as these I-Ds are concerned, this is a SEP. I know of deployments where there is a long tradition of out-of-band key distribution (ever bought a car? what did the dealer hand you when you handed him the cheque? :) )-- and others where this is unacceptable. I believe that it is recognized that both the choice of cryptographic system and key management is very deployment specific. What we should be trying to do in these I-Ds is to discuss the common set of things that can be accomplished, assuming that the SEP is indeed handled by Somebody Else ;) But all good, and thanks for the discussions on these matters - keep 'em coming. Thomas From ulrich@herberg.name Wed Nov 18 13:10:35 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A110D3A6ABD; Wed, 18 Nov 2009 13:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ1EHYD1e-VY; Wed, 18 Nov 2009 13:10:34 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id D5B293A6A88; Wed, 18 Nov 2009 13:10:33 -0800 (PST) Received: by bwz23 with SMTP id 23so1711257bwz.29 for ; Wed, 18 Nov 2009 13:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.24.2 with SMTP id t2mr6819247bkb.65.1258578625234; Wed, 18 Nov 2009 13:10:25 -0800 (PST) Date: Wed, 18 Nov 2009 22:10:23 +0100 Message-ID: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> From: Ulrich Herberg To: 6lowpan <6lowpan@ietf.org>, manet@ietf.org, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] SNMP optimizations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:10:36 -0000 Hi, I am sending this message to the 6lowpan, ROLL and MANET mailing list, since I think this topic concerns all three working groups, and I am not sure in which WG this is to be tackled. During the MANET WG meeting and also during an OLSRv2 Interop workshop, we had discussions about SNMP deployments in such ad-hoc networks we are dealing with. The issue that was raised (and which is also described in draft-hamid-6lowpan-snmp-optimizations) is that SNMP may be too memory-/CPU-/bandwidth-consuming for low-power devices. However, a solution for monitoring and management of these devices is desired (and also required by IETF). The before-mentioned draft describes very well how to optimize SNMP for running it on 6lowpan devices, and shows that the SNMP payload can fit into 6lowpan packets. However, it is unclear whether the code footprint of SNMP implementations can fit into the memory of small devices. From discussions with several persons from the MANET WG, I conclude that for MANET the same problem exists. (and I think for ROLL, too?) I have several questions that came to my mind about this topic: - First of all, to which WG does this issue belong to? Or is it -- as I suppose -- a common problem for the three working groups addressed in this mail? - Is this really an issue? Are there implementations of SNMP (maybe not open-source) that can be run on very small devices such as considered in 6lowpan/ROLL/MANET? Is there any experimental (or theoretical) analysis whether SNMP (or any other standardized management protocol) can run on these devices? - If SNMP cannot be used for small devices, how can we manage and monitor these devices then? (e.g. using proxies, different message formats such as proposed in 6lowapp, etc.). Do we need a different lightweight protocol for management? - Can we provide SNMP not only on a single device, but for a whole network? That might need an aggregator device that runs full SNMP and collects the data from the low power devices. This would imply to monitor statistics of a whole network (e.g. number of links, average throughput, average path-length, etc.) - What kind of objects should be provided in a MIB running on a MANET/6lowpan/ROLL device? This might be specific to the routing protocol, but there can be commonalities. Regards, Ulrich From teco@inf-net.nl Wed Nov 18 23:19:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5127B3A68B5 for ; Wed, 18 Nov 2009 23:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxW+7FNwqijQ for ; Wed, 18 Nov 2009 23:19:11 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 2702D3A6768 for ; Wed, 18 Nov 2009 23:19:10 -0800 (PST) Received: (qmail 14926 invoked from network); 19 Nov 2009 08:19:06 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 19 Nov 2009 08:19:06 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl><25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> In-Reply-To: Date: Thu, 19 Nov 2009 08:18:32 +0100 Message-ID: <001801ca68e8$920457e0$b60d07a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpoJkdvWQbJbVKJSNK99ZmqYNAv4wANxpZQAASoW1AAHXDMIA== Content-Language: nl Cc: 'Rex Buddenberg' , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:19:12 -0000 >> It is all about trust. If the TC has traveled only trusted neighbors, >> what is the problem? > >Is trust transitive? More thoughts on this, with TC in mind. All nodes shall have synced LSDB, otherwise the network is loopy. So all nodes shall accept or reject an invalid message. So the neighbors of the node that corrupted the message shall drop it on the floor. There is no olsr-sec draft yet, but I assume such behavior written down. Now we have some options what to do. Just drop the invalid messages? Drop the whole packets? Invalidate the node that forwarded such messages, and tear down the links to such? Forever or hold-down period? Publish entries for revocation list? I say the bad guy shall be isolated at least. Now I see a benefit of signed messages. A node that is taken over by the bad guys gang, and is transformed into an assassin, is to be isolated. Meanwhile, it can only cause some local damage. Teco. From ulrich@herberg.name Thu Nov 19 01:25:03 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810A13A67EC for ; Thu, 19 Nov 2009 01:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVfE6lq4BsST for ; Thu, 19 Nov 2009 01:25:02 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 7823E3A67B8 for ; Thu, 19 Nov 2009 01:25:02 -0800 (PST) Received: by fxm7 with SMTP id 7so2191132fxm.29 for ; Thu, 19 Nov 2009 01:24:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.34.5 with SMTP id j5mr3484741bkd.5.1258622697289; Thu, 19 Nov 2009 01:24:57 -0800 (PST) In-Reply-To: <001801ca68e8$920457e0$b60d07a0$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> Date: Thu, 19 Nov 2009 10:24:57 +0100 Message-ID: <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:25:03 -0000 Teco, On Thu, Nov 19, 2009 at 8:18 AM, Teco Boot wrote: >>> It is all about trust. If the TC has traveled only trusted neighbors, >>> what is the problem? >> >>Is trust transitive? > > More thoughts on this, with TC in mind. > All nodes shall have synced LSDB, otherwise the network is loopy. > So all nodes shall accept or reject an invalid message. > So the neighbors of the node that corrupted the message shall > drop it on the floor. There is no olsr-sec draft yet, but I assume > such behavior written down. As for the NHDP-sec draft, the plan for the OLSR-sec draft is to provide another cause for TC messages to be rejected (as allowed by the NHDP/OLSRv2 specs) (cf section 12.1 of the OLSRv2-draft). This will be very similar to the NHDP-sec draft. > Now we have some options what to do. Just drop the invalid messages? > Drop the whole packets? I think that this decision is rather to be placed into the NHDP draft, since the NHDP-sec draft only hooks into NHDP and provides a reason for rejecting messages (as in section 12.1 of NHDP). In that section, NHDP says: "An invalid message MUST be silently discarded, without updating the router's Information Bases." So if we want to allow the whole packet to be dropped if a message is invalid, we should put it in the NHDP draft, and not in the NHDP-sec draft. I let the authors of NHDP express their opinion... > Invalidate the node that forwarded such > messages, and tear down the links to such? Forever or hold-down > period? Publish entries for revocation list? > I say the bad guy shall be isolated at least. This is an interesting point. I fear, however, that allowing to block an originator forever leads to another attack. A malicious router simply sends a few unsigned (or badly signed) messages claiming to originate from another router. Thus, this router will be removed from the Routing Set. So an attacker could easily disturb the topology. Keep in mind that the only gain for tearing down a link (and thus to reject incoming messages of a given source address without checking the signature) is to save time for processing signatures. What could be done is to enforce a minimum interval for incoming messages (similar to MIN_INTERVAL for outgoing messages). If messages from a source arrive more frequently, they are ignored. Are there any opinions on such a mechanism? > Now I see a benefit of signed messages. A node that is taken over > by the bad guys gang, and is transformed into an assassin, is to be > isolated. Meanwhile, it can only cause some local damage. It depends, what you mean by "taken over". If an attacker gains access to the key chain and is thus able to correctly sign messages, the framework will not help in any way -- the "bad guy" would appear as a "good guy" and cannot be isolated as all messages it signs are valid. Ulrich From thomas@thomasclausen.org Thu Nov 19 01:49:25 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26093A6934 for ; Thu, 19 Nov 2009 01:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6n8RiK407RP for ; Thu, 19 Nov 2009 01:49:24 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DF5883A68F9 for ; Thu, 19 Nov 2009 01:49:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 36C4143064D; Thu, 19 Nov 2009 01:49:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 8B08743064C; Thu, 19 Nov 2009 01:49:21 -0800 (PST) Message-Id: <159F9682-6A75-4805-AD31-5F5358E05B1C@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <001801ca68e8$920457e0$b60d07a0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 10:49:19 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl><25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> X-Mailer: Apple Mail (2.936) Cc: 'Rex Buddenberg' , "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:49:25 -0000 Teco, All good comments. I won't pretend to answer to your questions, as I don't know that I know the ultimate answers ;) I'd just bounce a couple of thoughts out and off you for discussion I do know that there are uses for situations where a given network may maintain two topologies: one "secured" and one "not secured". Thus, one topology may reject a given entry in the LSDB while another topology in the same router may accept and use it, depending on the validation of signatures. A blanket "throw away a message which doesn't validate, also without forwarding" would, I think, disable this functioning. Consequently, this holds also for "throw away a packet which contains a message where the signature doesn't validate". On the latter (looking beyond simply OLSRv2/NHDP), throwing away a whole packet because a signature in any contained message doesn't validate wouldn't work, I think: it would assume that all routers would be equipped to parse (at least, to the point of verifying signatures) all possible message types. I would not expect that to hold true with various extensions and their new message types. Even if the packetbb-sec signature TLV was used for all messages, an intermediate might not have the necessary keys for validation (e.g. if the extension assumed endrouter-to-endrouter only, and therefore didn't share keys around to all intermediaries). I'd like that whatever we do be flexible enough to accommodate at least the deployments/requirements that we can identify for current system -- and, preferably, those which we can reasonably project will emerge. Cheers, Thomas On Nov 19, 2009, at 8:18 AM, Teco Boot wrote: >>> It is all about trust. If the TC has traveled only trusted >>> neighbors, >>> what is the problem? >> >> Is trust transitive? > > More thoughts on this, with TC in mind. > All nodes shall have synced LSDB, otherwise the network is loopy. > So all nodes shall accept or reject an invalid message. > So the neighbors of the node that corrupted the message shall > drop it on the floor. There is no olsr-sec draft yet, but I assume > such behavior written down. > Now we have some options what to do. Just drop the invalid messages? > Drop the whole packets? Invalidate the node that forwarded such > messages, and tear down the links to such? Forever or hold-down > period? Publish entries for revocation list? > I say the bad guy shall be isolated at least. > > Now I see a benefit of signed messages. A node that is taken over > by the bad guys gang, and is transformed into an assassin, is to be > isolated. Meanwhile, it can only cause some local damage. > > Teco. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Nov 19 01:50:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52DA3A68F9 for ; Thu, 19 Nov 2009 01:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGy++uRdTFdr for ; Thu, 19 Nov 2009 01:50:25 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 935593A6A7D for ; Thu, 19 Nov 2009 01:50:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33819391" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 09:50:21 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJ9oSAI013186; Thu, 19 Nov 2009 09:50:28 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:50:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 09:50:18 -0000 Message-ID: In-Reply-To: <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: Acpo+irgD4C/x9i4SPu9r4rkNxVQlgAAj7BQ References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , "Teco Boot" X-OriginalArrivalTime: 19 Nov 2009 09:50:20.0406 (UTC) FILETIME=[B4DFC960:01CA68FD] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:50:26 -0000 > So if we want to allow the whole packet to be dropped if a message is > invalid, we should put it in the NHDP draft, and not in the NHDP-sec > draft. I let the authors of NHDP express their opinion... It's not as simple as that. The multiplexing method in RFC 5444 means that NHDP doesn't even see non-HELLO messages in a packet, and by the time it sees a message the packet has been distributed to the appropriate protocols. So if you wanted this behaviour - which is inappropriate in many cases, but may be appropriate in some - then it needs to be in a security for RFC 5444 draft, not a security for NHDP/OLSRv2 draft. In fact I think that's what we need, with specific comments for NHDP/OLSRv2 in separate drafts, but the bulk in a protocol agnostic document. > This is an interesting point. I fear, however, that allowing to block > an originator forever leads to another attack. A malicious router > simply sends a few unsigned (or badly signed) messages claiming to > originate from another router. Thus, this router will be removed from > the Routing Set. All revocation mechanisms are a security threat, and any simple "I've seen a bad message apparently from X, so X is bad" is a very poor revocation mechanism, and not one to be used. Any decision to blacklist a node needs more than that. I think this is an area that needs more expertise than I'm aware of here. > It depends, what you mean by "taken over". If an attacker gains access > to the key chain and is thus able to correctly sign messages, the > framework will not help in any way -- the "bad guy" would appear as a > "good guy" and cannot be isolated as all messages it signs are valid. There are however different cases of this as I noted in an earlier email. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Nov 19 02:03:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A1C3A6A74 for ; Thu, 19 Nov 2009 02:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP1Ef5zYRJB4 for ; Thu, 19 Nov 2009 02:03:01 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 2B7A73A694C for ; Thu, 19 Nov 2009 02:03:01 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB3qj-0001UA-E0; Thu, 19 Nov 2009 11:02:49 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB3qj-0001SU-4S; Thu, 19 Nov 2009 11:02:49 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 11:02:37 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> In-Reply-To: <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1269214.jZqYTdrWvn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191102.45900.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10045/Thu Nov 19 05:48:20 2009) by mailguard.fgan.de X-Scan-Signature: 9bea0208ff5bf14e461e230ff4736cfe Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:03:02 -0000 --nextPart1269214.jZqYTdrWvn Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 10:24:57 Ulrich Herberg wrote: > This is an interesting point. I fear, however, that allowing to block > an originator forever leads to another attack. A malicious router > simply sends a few unsigned (or badly signed) messages claiming to > originate from another router. Unsigned or badly signed messages/packets should NEVER be used to block a n= ode=20 if the capability exists to forge your own MAC/Source-IP. You simply don't= =20 have any information where the message is coming from, the only thing you c= an=20 do is to call a higher layer (Help, I'm getting lot's of forged messages !). The only exception I see is if you receive a message with a bad signature b= ut=20 the package was signed correctly. In this case it's clear that the forwardi= ng=20 node is either a stupid attacker or malfunctioning, so you could remove it. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1269214.jZqYTdrWvn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFF70ACgkQRIfGfFXsz+C7IACfYPL4t17VDaoYeHS0v2lqpttL /n8AnRwn9jnKgKKNAIe1o/7CMkcGA/Ua =C648 -----END PGP SIGNATURE----- --nextPart1269214.jZqYTdrWvn-- From thomas@thomasclausen.org Thu Nov 19 02:03:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8AE3A6A74 for ; Thu, 19 Nov 2009 02:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj7fdvHIYSG0 for ; Thu, 19 Nov 2009 02:03:18 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 32B543A6887 for ; Thu, 19 Nov 2009 02:03:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7FBCA43064D; Thu, 19 Nov 2009 02:03:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id EA35143064C; Thu, 19 Nov 2009 02:03:14 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:03:12 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:03:19 -0000 On Nov 19, 2009, at 10:50 AM, Dearlove, Christopher (UK) wrote: >> So if we want to allow the whole packet to be dropped if a message is >> invalid, we should put it in the NHDP draft, and not in the NHDP-sec >> draft. I let the authors of NHDP express their opinion... > > It's not as simple as that. The multiplexing method in RFC 5444 > means that NHDP doesn't even see non-HELLO messages in a packet, > and by the time it sees a message the packet has been distributed > to the appropriate protocols. So if you wanted this behaviour > - which is inappropriate in many cases, but may be appropriate in > some - then it needs to be in a security for RFC 5444 draft, not > a security for NHDP/OLSRv2 draft. In fact I think that's what we > need, with specific comments for NHDP/OLSRv2 in separate drafts, > but the bulk in a protocol agnostic document. Incidentally, you are right - this was the reason that we started by publishing the packetbb-sec I-D. Initially, this contains almost only the TLV specifications; however I agree that it is natural to extend this to cover other "protocol-agnostic" matters. Incidentally, I suspect that these (in my opinion) will be relatively few: I can think of no situation where dropping a whole packet if a contained message doesn't validate would make sense - or rather, I can think of many counter-examples where it definitely wouldn't.... In terms of the way forward, it appears clear to me that discussing things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - and allow us to extract the general/agnostic matters. Which means, we have to accelerate getting the olsrv2-sec I-D polished and out, and preferably also a dymo-sec I-D (is there a DYMO expert in the house who'd like to chip in on that?) >> This is an interesting point. I fear, however, that allowing to block >> an originator forever leads to another attack. A malicious router >> simply sends a few unsigned (or badly signed) messages claiming to >> originate from another router. Thus, this router will be removed from >> the Routing Set. > > All revocation mechanisms are a security threat, and any simple > "I've seen a bad message apparently from X, so X is bad" is a > very poor revocation mechanism, and not one to be used. Any > decision to blacklist a node needs more than that. I think this > is an area that needs more expertise than I'm aware of here. I second this. Not only are revocation mechanisms scary, I think that they also are (as with key distribution) very deployment specific too. Thomas >> It depends, what you mean by "taken over". If an attacker gains >> access >> to the key chain and is thus able to correctly sign messages, the >> framework will not help in any way -- the "bad guy" would appear as a >> "good guy" and cannot be isolated as all messages it signs are valid. > > There are however different cases of this as I noted in an earlier > email. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Thu Nov 19 02:05:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED95B3A6A89 for ; Thu, 19 Nov 2009 02:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMbUr2nuV9WC for ; Thu, 19 Nov 2009 02:05:05 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 34F813A6B1C for ; Thu, 19 Nov 2009 02:05:05 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB3sr-0001WJ-AH; Thu, 19 Nov 2009 11:05:01 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB3sq-0001TC-QT; Thu, 19 Nov 2009 11:05:00 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 11:04:57 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <001801ca68e8$920457e0$b60d07a0$@nl> <159F9682-6A75-4805-AD31-5F5358E05B1C@thomasclausen.org> In-Reply-To: <159F9682-6A75-4805-AD31-5F5358E05B1C@thomasclausen.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1662172.HJ3pfgkoKA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191104.57676.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10045/Thu Nov 19 05:48:20 2009) by mailguard.fgan.de X-Scan-Signature: 0f287e88b12fb29766ba98e7b870a51f Cc: 'Rex Buddenberg' , "'Dearlove, Christopher \(UK\)'" , Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:05:09 -0000 --nextPart1662172.HJ3pfgkoKA Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 10:49:19 Thomas Heide Clausen wrote: > All good comments. I won't pretend to answer to your questions, as I > don't know that I know the ultimate answers ;) I'd just bounce a > couple of thoughts out and off you for discussion >=20 > I do know that there are uses for situations where a given network may > maintain two topologies: one "secured" and one "not secured". Thus, > one topology may reject a given entry in the LSDB while another > topology in the same router may accept and use it, depending on the > validation of signatures. Yes, we could do this, as long as unsigned messages cannot change the state= =20 delivered by signed messages. =20 > A blanket "throw away a message which doesn't validate, also without > forwarding" would, I think, disable this functioning. Yes. > Consequently, > this holds also for "throw away a packet which contains a message > where the signature doesn't validate". A packet should be only thrown away completely if the packet signature is=20 wrong (if it contains a packet signature). =20 Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1662172.HJ3pfgkoKA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFGEkACgkQRIfGfFXsz+CZ+wCgl1FN7E3/xi5uWS0NoffQCioh Cf0AoKbfSIbRCvCzt4yMfUm29rl0QPig =U9qU -----END PGP SIGNATURE----- --nextPart1662172.HJ3pfgkoKA-- From thomas@thomasclausen.org Thu Nov 19 02:07:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9D03A6A74 for ; Thu, 19 Nov 2009 02:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG9oCFgNAEFA for ; Thu, 19 Nov 2009 02:07:47 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 776803A6A6C for ; Thu, 19 Nov 2009 02:07:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C5C0D43064D; Thu, 19 Nov 2009 02:07:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 781C243064C; Thu, 19 Nov 2009 02:07:44 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Henning Rogge In-Reply-To: <200911191102.45900.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:07:42 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <200911191102.45900.henning.rogge@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:07:48 -0000 On Nov 19, 2009, at 11:02 AM, Henning Rogge wrote: > On Thu November 19 2009 10:24:57 Ulrich Herberg wrote: >> This is an interesting point. I fear, however, that allowing to block >> an originator forever leads to another attack. A malicious router >> simply sends a few unsigned (or badly signed) messages claiming to >> originate from another router. > Unsigned or badly signed messages/packets should NEVER be used to =20 > block a node > if the capability exists to forge your own MAC/Source-IP. You simply =20= > don't > have any information where the message is coming from, the only =20 > thing you can > do is to call a higher layer (Help, I'm getting lot's of forged =20 > messages !). > > The only exception I see is if you receive a message with a bad =20 > signature but > the package was signed correctly. In this case it's clear that the =20 > forwarding > node is either a stupid attacker or malfunctioning, so you could =20 > remove it. > Or, maybe, that the forwarding node was not equipped to validate the =20 signature. E.g. a protocol extension using a message type unknown to =20 the forwarder, and where the "key-space" is proper to the extension =20 (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to =20 OLSRv1, though) where this is the case. I'd not even consider "good packet signature, bad message signature" =20 as a reason to remove the sender of the packet. Thomas > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Nov 19 02:13:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B583A6831 for ; Thu, 19 Nov 2009 02:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U4qHFRkEJbw for ; Thu, 19 Nov 2009 02:13:10 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id F24433A68D3 for ; Thu, 19 Nov 2009 02:13:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33827690" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:13:02 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJADAfr030454; Thu, 19 Nov 2009 10:13:10 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:13:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:13:01 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: Acpo/4UdHEj45vJZSKOZPR3/To5zFAAAL8oA References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Nov 2009 10:13:02.0148 (UTC) FILETIME=[E0892040:01CA6900] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:13:11 -0000 > I can think > of no situation where dropping a whole packet if a contained message > doesn't validate would make sense There are always two cases of "doesn't validate" to consider - Has signature, signature is bad. - Doesn't have signature. You can afford to be harsher in the former case than the latter. Whether that extends to dropping a whole packet is another matter. > In terms of the way forward, it appears clear to me that discussing > things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - > and allow us to extract the general/agnostic matters. Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts that an aim is exactly that, given the RFC 5444 multiplexing framework. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Nov 19 02:14:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0E33A694C for ; Thu, 19 Nov 2009 02:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBWvbFa2vyfR for ; Thu, 19 Nov 2009 02:14:41 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id D24443A68D3 for ; Thu, 19 Nov 2009 02:14:40 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB429-0004PQ-R2; Thu, 19 Nov 2009 11:14:37 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB429-0001ZC-Hp; Thu, 19 Nov 2009 11:14:37 +0100 From: Henning Rogge To: Thomas Heide Clausen Date: Thu, 19 Nov 2009 11:14:34 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191102.45900.henning.rogge@fkie.fraunhofer.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1721150.GopR3phGoC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191114.34159.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10045/Thu Nov 19 05:48:20 2009) by mailguard.fgan.de X-Scan-Signature: d42e7dfe6399d6e5eb526d1844917fec Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:14:42 -0000 --nextPart1721150.GopR3phGoC Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote: > > Unsigned or badly signed messages/packets should NEVER be used to > > block a node > > if the capability exists to forge your own MAC/Source-IP. You simply > > don't > > have any information where the message is coming from, the only > > thing you can > > do is to call a higher layer (Help, I'm getting lot's of forged > > messages !). > > > > The only exception I see is if you receive a message with a bad > > signature but > > the package was signed correctly. In this case it's clear that the > > forwarding > > node is either a stupid attacker or malfunctioning, so you could > > remove it. >=20 > Or, maybe, that the forwarding node was not equipped to validate the > signature. E.g. a protocol extension using a message type unknown to > the forwarder, and where the "key-space" is proper to the extension > (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to > OLSRv1, though) where this is the case. >=20 > I'd not even consider "good packet signature, bad message signature" > as a reason to remove the sender of the packet. I think this would depend on the policy of the network. Maybe you drop the node at once (because you have mandatory signature check= ing=20 on all nodes), maybe you just drop the message and inform your IDS "got bad= =20 message signature from node X forwarded by node Y". Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1721150.GopR3phGoC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFGooACgkQRIfGfFXsz+Cw+wCfSvYD50/qIKT5SNGFRCGk02Mh hsEAoKmOazZtV4jqto+Ei8iV5yugegDW =1WJU -----END PGP SIGNATURE----- --nextPart1721150.GopR3phGoC-- From thomas@thomasclausen.org Thu Nov 19 02:16:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79913A68D3 for ; Thu, 19 Nov 2009 02:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E092JqYJkg5f for ; Thu, 19 Nov 2009 02:16:30 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DA8163A6831 for ; Thu, 19 Nov 2009 02:16:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D5AE43064D; Thu, 19 Nov 2009 02:16:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D0A51430622; Thu, 19 Nov 2009 02:16:27 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Henning Rogge In-Reply-To: <200911191114.34159.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:16:25 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191102.45900.henning.rogge@fkie.fraunhofer.de> <200911191114.34159.henning.rogge@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:16:32 -0000 On Nov 19, 2009, at 11:14 AM, Henning Rogge wrote: > On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote: > >>> Unsigned or badly signed messages/packets should NEVER be used to >>> block a node >>> if the capability exists to forge your own MAC/Source-IP. You simply >>> don't >>> have any information where the message is coming from, the only >>> thing you can >>> do is to call a higher layer (Help, I'm getting lot's of forged >>> messages !). >>> >>> The only exception I see is if you receive a message with a bad >>> signature but >>> the package was signed correctly. In this case it's clear that the >>> forwarding >>> node is either a stupid attacker or malfunctioning, so you could >>> remove it. >> >> Or, maybe, that the forwarding node was not equipped to validate the >> signature. E.g. a protocol extension using a message type unknown to >> the forwarder, and where the "key-space" is proper to the extension >> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to >> OLSRv1, though) where this is the case. >> >> I'd not even consider "good packet signature, bad message signature" >> as a reason to remove the sender of the packet. > I think this would depend on the policy of the network. > > Maybe you drop the node at once (because you have mandatory =20 > signature checking > on all nodes), maybe you just drop the message and inform your IDS =20 > "got bad > message signature from node X forwarded by node Y". > Right, I agree. This is rather deployment/policy dependent. We just =20 need to make sure that we not enforce a behavior that excludes useful =20= behaviors. Thomas > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From thomas@thomasclausen.org Thu Nov 19 02:18:07 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3093A6893 for ; Thu, 19 Nov 2009 02:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPtQK4wTK3-L for ; Thu, 19 Nov 2009 02:18:06 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D30363A6831 for ; Thu, 19 Nov 2009 02:18:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C0D443064D; Thu, 19 Nov 2009 02:18:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A6A4E430622; Thu, 19 Nov 2009 02:18:03 -0800 (PST) Message-Id: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> From: Thomas Heide Clausen To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:18:01 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:18:07 -0000 On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: >> I can think >> of no situation where dropping a whole packet if a contained message >> doesn't validate would make sense > > There are always two cases of "doesn't validate" to consider > - Has signature, signature is bad. > - Doesn't have signature. > > You can afford to be harsher in the former case than the latter. > Whether that extends to dropping a whole packet is another matter. Actually, I made a comment to this effect to Henning and on the list just now - not even in that case is it (always) reasonable to drop the packet, as the forwarder might just be an innocent bystander not able to validate the contained messages that it forwards. >> In terms of the way forward, it appears clear to me that discussing >> things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - > >> and allow us to extract the general/agnostic matters. > > Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific > drafts > that an aim is exactly that, given the RFC 5444 multiplexing > framework. I could live with that, Ulrich? From henning.rogge@fkie.fraunhofer.de Thu Nov 19 02:28:27 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85F13A6A89 for ; Thu, 19 Nov 2009 02:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iloaVqA8Yds for ; Thu, 19 Nov 2009 02:28:26 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id A69DF3A6A7D for ; Thu, 19 Nov 2009 02:28:26 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB4FT-0000IZ-Oj; Thu, 19 Nov 2009 11:28:23 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB4FT-0001ew-FF; Thu, 19 Nov 2009 11:28:23 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 11:28:09 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> In-Reply-To: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1468647.dZvQyCrFQ5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191128.20190.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10045/Thu Nov 19 05:48:20 2009) by mailguard.fgan.de X-Scan-Signature: a8e2f18599482a3592288cf2106a6f9f Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:28:27 -0000 --nextPart1468647.dZvQyCrFQ5 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 11:18:01 Thomas Heide Clausen wrote: > On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: > > You can afford to be harsher in the former case than the latter. > > Whether that extends to dropping a whole packet is another matter. >=20 > Actually, I made a comment to this effect to Henning and on the list > just now - not even in that case is it (always) reasonable to drop the > packet, as the forwarder might just be an innocent bystander not able > to validate the contained messages that it forwards. I think the signatures will get even more important in combination with the= =20 state-machine-drafts mentioned at IETF. Together they would allow to check = for=20 misbehaving nodes and trigger alerts to an IDS infrastructure (or a local=20 response daemon). Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1468647.dZvQyCrFQ5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFHbkACgkQRIfGfFXsz+D67gCgmlSi0IMJBbTqY6nKkmygDZ6Y 0EMAn1qmB/R5ysU8Rnug80nls7iQLgGT =GH7d -----END PGP SIGNATURE----- --nextPart1468647.dZvQyCrFQ5-- From Chris.Dearlove@baesystems.com Thu Nov 19 02:28:30 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6FD28C16D for ; Thu, 19 Nov 2009 02:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY6wiogx3Xw3 for ; Thu, 19 Nov 2009 02:28:30 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C464728C142 for ; Thu, 19 Nov 2009 02:28:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33834225" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:28:27 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJASZVQ010029; Thu, 19 Nov 2009 10:28:35 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:28:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:28:26 -0000 Message-ID: In-Reply-To: <200911191114.34159.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppASE02/1IhCn1Szi6bZ/DoUqrTAAANVxA References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191102.45900.henning.rogge@fkie.fraunhofer.de> <200911191114.34159.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Nov 2009 10:28:26.0823 (UTC) FILETIME=[07AF5570:01CA6903] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:28:30 -0000 > Maybe you drop the node at once (because you have mandatory signature checking > on all nodes) The parenthesis is the key comment here - everything (not just this) depends on your situation. This makes it, in a generic document and even in an NHDP or OLSRv2 specific document pretty much impossible to say "you must always do this" and hard or worse to list all possible options. Some possible options, and possibly the most obvious ones, can be listed. An OLSRv2 issue when using message signatures is: if a node gets a message which it should forward, but not process (there are at least two ways that can happen) should it check the signature? I think the answer to that one isn't obvious, there are arguments both ways. Which means there might be circumstances for either answer. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Thu Nov 19 02:32:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C1C3A6887 for ; Thu, 19 Nov 2009 02:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY37VPRmOfE7 for ; Thu, 19 Nov 2009 02:32:31 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 5FCDE3A682E for ; Thu, 19 Nov 2009 02:32:31 -0800 (PST) Received: by fxm7 with SMTP id 7so2254491fxm.29 for ; Thu, 19 Nov 2009 02:32:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.5.138 with SMTP id 10mr7130242bkv.110.1258626742721; Thu, 19 Nov 2009 02:32:22 -0800 (PST) In-Reply-To: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> Date: Thu, 19 Nov 2009 11:32:22 +0100 Message-ID: <25c114b90911190232x6239fa77p9379bd19c41c24ef@mail.gmail.com> From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:32:32 -0000 Thomas, On Thu, Nov 19, 2009 at 11:18 AM, Thomas Heide Clausen wrote: > > On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: > >>> I can think >>> of no situation where dropping a whole packet if a contained message >>> doesn't validate would make sense >> >> There are always two cases of "doesn't validate" to consider >> - Has signature, signature is bad. >> - Doesn't have signature. >> >> You can afford to be harsher in the former case than the latter. >> Whether that extends to dropping a whole packet is another matter. > > Actually, I made a comment to this effect to Henning and on the list just > now - not even in that case is it (always) reasonable to drop the packet, as > the forwarder might just be an innocent bystander not able to validate the > contained messages that it forwards. Yes, I second this. >>> In terms of the way forward, it appears clear to me that discussing >>> things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - >> >>> and allow us to extract the general/agnostic matters. >> >> Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts >> that an aim is exactly that, given the RFC 5444 multiplexing framework. > > I could live with that, Ulrich? Yes, me too. Ulrich From Chris.Dearlove@baesystems.com Thu Nov 19 02:33:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FB928C142 for ; Thu, 19 Nov 2009 02:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkZvRSYL6XWR for ; Thu, 19 Nov 2009 02:33:28 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B962D28C12F for ; Thu, 19 Nov 2009 02:33:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33836157" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:33:25 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJAXXLl013937; Thu, 19 Nov 2009 10:33:33 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:33:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:33:24 -0000 Message-ID: In-Reply-To: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppAZtsULSqy6wcRQWX3Zkiuy2F1wAAXuSg References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Nov 2009 10:33:24.0875 (UTC) FILETIME=[B95675B0:01CA6903] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:33:28 -0000 >> There are always two cases of "doesn't validate" to consider >> - Has signature, signature is bad. >> - Doesn't have signature. >> >> You can afford to be harsher in the former case than the latter. >> Whether that extends to dropping a whole packet is another matter. > Actually, I made a comment to this effect to Henning and on the list > just now - not even in that case is it (always) reasonable to drop the > packet, as the forwarder might just be an innocent bystander not able > to validate the contained messages that it forwards. That's a third case. My first case is that the message has a signature, I can validate signatures, and that signature is wrong. But if A sends to B sends to C then C can get the first case because B was the third case. Or due to one of the behaviours in my last email. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From thomas@thomasclausen.org Thu Nov 19 02:34:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEB428C142 for ; Thu, 19 Nov 2009 02:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d2SOZv91-zd for ; Thu, 19 Nov 2009 02:34:04 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A872328C16E for ; Thu, 19 Nov 2009 02:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F013C43064F; Thu, 19 Nov 2009 02:34:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D15D943064C; Thu, 19 Nov 2009 02:34:01 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Henning Rogge In-Reply-To: <200911191128.20190.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:33:59 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> <200911191128.20190.henning.rogge@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:34:05 -0000 On Nov 19, 2009, at 11:28 AM, Henning Rogge wrote: > On Thu November 19 2009 11:18:01 Thomas Heide Clausen wrote: >> On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: >>> You can afford to be harsher in the former case than the latter. >>> Whether that extends to dropping a whole packet is another matter. >> >> Actually, I made a comment to this effect to Henning and on the list >> just now - not even in that case is it (always) reasonable to drop =20= >> the >> packet, as the forwarder might just be an innocent bystander not able >> to validate the contained messages that it forwards. > > I think the signatures will get even more important in combination =20 > with the > state-machine-drafts mentioned at IETF. Working on it, should not be long - but glad that you think they will =20= be useful ;) Thomas > Together they would allow to check for > misbehaving nodes and trigger alerts to an IDS infrastructure (or a =20= > local > response daemon). > > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From thomas@thomasclausen.org Thu Nov 19 02:35:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8222E28C162 for ; Thu, 19 Nov 2009 02:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snJRuK07MArp for ; Thu, 19 Nov 2009 02:35:25 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CCEE328C16E for ; Thu, 19 Nov 2009 02:35:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2849943064C; Thu, 19 Nov 2009 02:35:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0A39D430622; Thu, 19 Nov 2009 02:35:21 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:35:19 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> X-Mailer: Apple Mail (2.936) Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:35:26 -0000 On Nov 19, 2009, at 11:33 AM, Dearlove, Christopher (UK) wrote: >>> There are always two cases of "doesn't validate" to consider >>> - Has signature, signature is bad. >>> - Doesn't have signature. >>> >>> You can afford to be harsher in the former case than the latter. >>> Whether that extends to dropping a whole packet is another matter. > >> Actually, I made a comment to this effect to Henning and on the list >> just now - not even in that case is it (always) reasonable to drop >> the > >> packet, as the forwarder might just be an innocent bystander not able > >> to validate the contained messages that it forwards. > > That's a third case. My first case is that the message has a > signature, > I can validate signatures, and that signature is wrong. But if A sends > to B sends to C then C can get the first case because B was the third > case. Or due to one of the behaviours in my last email. We probably should enumerate these cases explicitly in the OLSRv2-sec I-D? Thomas From Chris.Dearlove@baesystems.com Thu Nov 19 02:37:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC0428C184 for ; Thu, 19 Nov 2009 02:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIzQMGlh1M0w for ; Thu, 19 Nov 2009 02:37:26 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id BD94728C182 for ; Thu, 19 Nov 2009 02:37:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33837341" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:37:23 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJAbVYn016704; Thu, 19 Nov 2009 10:37:31 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:37:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:37:22 -0000 Message-ID: In-Reply-To: <200911191128.20190.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppAw9HtyB1OE0nRiKr/dsrKkdtpAAAL5ug References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> <200911191128.20190.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 19 Nov 2009 10:37:22.0978 (UTC) FILETIME=[47421820:01CA6904] Cc: Rex Buddenberg , Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:37:26 -0000 > I think the signatures will get even more important in combination with the > state-machine-drafts mentioned at IETF. Together they would allow to check for > misbehaving nodes and trigger alerts to an IDS infrastructure (or a local > response daemon). If you have any infrastructure. But it's never enough to know that there appear to be mis-signed messages from node X, you need more. However every possibility for what that more might be that I've thought of (though I haven't thought too much about it) has a problem that I've also thought of, so I'm not in a position to suggest what that more might be (except, as always, it depends on other things). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Thu Nov 19 02:37:52 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE1128C180 for ; Thu, 19 Nov 2009 02:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG+yvPWtmc8r for ; Thu, 19 Nov 2009 02:37:51 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 9672728C17E for ; Thu, 19 Nov 2009 02:37:51 -0800 (PST) Received: by fxm7 with SMTP id 7so2259686fxm.29 for ; Thu, 19 Nov 2009 02:37:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.5.138 with SMTP id 10mr7136148bkv.110.1258627065975; Thu, 19 Nov 2009 02:37:45 -0800 (PST) In-Reply-To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> Date: Thu, 19 Nov 2009 11:37:45 +0100 Message-ID: <25c114b90911190237g19cde35ei8c6f7d2373af00de@mail.gmail.com> From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:37:52 -0000 Thomas, On Thu, Nov 19, 2009 at 11:35 AM, Thomas Heide Clausen wrote: > > On Nov 19, 2009, at 11:33 AM, Dearlove, Christopher (UK) wrote: > >>>> There are always two cases of "doesn't validate" to consider >>>> - Has signature, signature is bad. >>>> - Doesn't have signature. >>>> >>>> You can afford to be harsher in the former case than the latter. >>>> Whether that extends to dropping a whole packet is another matter. >> >>> Actually, I made a comment to this effect to Henning and on the list >>> just now - not even in that case is it (always) reasonable to drop the >>> packet, as the forwarder might just be an innocent bystander not able >>> to validate the contained messages that it forwards. >> >> That's a third case. My first case is that the message has a signature, >> I can validate signatures, and that signature is wrong. But if A sends >> to B sends to C then C can get the first case because B was the third >> case. Or due to one of the behaviours in my last email. > > We probably should enumerate these cases explicitly in the OLSRv2-sec I-D? Yes, thanks for pointing out these three cases. They should be explained in the OLSRv2-sec ID. Ulrich From Chris.Dearlove@baesystems.com Thu Nov 19 02:47:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44B63A682E for ; Thu, 19 Nov 2009 02:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCklFFTyBn9T for ; Thu, 19 Nov 2009 02:47:11 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D9FA83A6820 for ; Thu, 19 Nov 2009 02:47:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33841055" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:47:08 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJAlF0H023960; Thu, 19 Nov 2009 10:47:16 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:47:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:47:06 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppBAIyuH4wC5e8QIm1yn8sG1/SKwAAFb0Q References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <1258479872.17184.205.camel@localhost.localdomain> <25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com> <200911180745.48511.henning.rogge@fkie.fraunhofer.de> <009f01ca681d$7975bd20$6c613760$@nl> <25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com> <003301ca685f$be9a1030$3bce3090$@nl> <001801ca68e8$920457e0$b60d07a0$@nl> <25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com> <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Nov 2009 10:47:07.0279 (UTC) FILETIME=[A38759F0:01CA6905] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:47:12 -0000 There are some more, including - It has a signature and the signature is good (not all cases are failures!). - It has a signature, but all I needed to do was forward it, so I didn't bother checking the signature, though I could have done. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 19 November 2009 10:35 To: Dearlove, Christopher (UK) Cc: Rex Buddenberg; manet@ietf.org Subject: Re: [manet] Security drafts *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. On Nov 19, 2009, at 11:33 AM, Dearlove, Christopher (UK) wrote: >>> There are always two cases of "doesn't validate" to consider >>> - Has signature, signature is bad. >>> - Doesn't have signature. >>> >>> You can afford to be harsher in the former case than the latter. >>> Whether that extends to dropping a whole packet is another matter. > >> Actually, I made a comment to this effect to Henning and on the list >> just now - not even in that case is it (always) reasonable to drop >> the > >> packet, as the forwarder might just be an innocent bystander not able > >> to validate the contained messages that it forwards. > > That's a third case. My first case is that the message has a > signature, > I can validate signatures, and that signature is wrong. But if A sends > to B sends to C then C can get the first case because B was the third > case. Or due to one of the behaviours in my last email. We probably should enumerate these cases explicitly in the OLSRv2-sec I-D? Thomas ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Nov 19 03:37:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BBB28C125 for ; Thu, 19 Nov 2009 03:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AGiHju8Ws7Y for ; Thu, 19 Nov 2009 03:37:07 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 3CEBF28C0E5 for ; Thu, 19 Nov 2009 03:37:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33860657" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 11:37:05 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJBbCLf030705; Thu, 19 Nov 2009 11:37:12 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:37:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 11:37:03 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppBAIyuH4wC5e8QIm1yn8sG1/SKwAAFb0QAAGHiWA= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><1258479872.17184.205.camel@localhost.localdomain><25c114b90911171000s61af2462p5688ccfeb03fd9f3@mail.gmail.com><200911180745.48511.henning.rogge@fkie.fraunhofer.de><009f01ca681d$7975bd20$6c613760$@nl><25c114b90911180008n3055703fv9fc848205ccaac41@mail.gmail.com><003301ca685f$be9a1030$3bce3090$@nl><001801ca68e8$920457e0$b60d07a0$@nl><25c114b90911190124p73b36acdwaa1a45a808cafe39@mail.gmail.com><0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> From: "Dearlove, Christopher (UK)" To: "Dearlove, Christopher (UK)" , "Thomas Heide Clausen" X-OriginalArrivalTime: 19 Nov 2009 11:37:04.0486 (UTC) FILETIME=[9E00D860:01CA690C] Cc: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 11:37:08 -0000 I'll make one more point that I think matters before trying to move on from this discussion, at least for this morning. OLSRv2 has a processing/forwarding engine that decides whether a message should be processed, forwarded, both, or neither. Messages that are to be processed need to be verified (if possible, which I'm assuming is the case here). Messages that are to be forwarded but not processed may or may not be verified, but here I'll assume that they are if it matters. That leaves messages to be neither processed nor forwarded. There's actually no need to verify them cryptographically, they are going to be discarded with no effect anyway. So why waste the effort doing so? OK, that's OLSRv2. But that says that even if we have a generic RFC 5444 approach, with a packet demultiplexer and message distributor, the right place for signature verification isn't necessarily in that. Now possibly an architecture including OLSRv2 might want to reuse that message processing/forwarding engine from OLSRv2 (it includes message type in it for at least a specialised case thereof, of extensions to OLSRv2, but could apply to other protocols with similar rquirements). That might be the place for message signature checking. Packet signature checking probably (almost certainly) belongs in the RFC 5444 demultiplexer. Note however that I'm not suggesting mandating that processing/forwarding engine for all MANET protocols. I think DYMO could be specified in such a way as to use it, but that might necessitate considering some DYMO messages as one hop then processing may generate a very similar message (obviously created from it for efficiency) rather than multi-hop modified before forwarding (which also necessitates a signature change - or if considered a new message, a new signature). But note that I'm not 100% certain of everything about DYMO I've just said - but that's my point, I'm not suggesting mandating the OLSRv2 engine. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Nov 19 03:48:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C633A6870 for ; Thu, 19 Nov 2009 03:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP7K3Rfagcsu for ; Thu, 19 Nov 2009 03:48:29 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id CA3AF3A6781 for ; Thu, 19 Nov 2009 03:48:28 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB5Ut-0006Z7-CK; Thu, 19 Nov 2009 12:48:23 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB5Ut-00029i-2q; Thu, 19 Nov 2009 12:48:23 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 12:48:15 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1501873.mtarGmB4UR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191248.19893.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10045/Thu Nov 19 05:48:20 2009) by mailguard.fgan.de X-Scan-Signature: 0a4bd1cc3f83d53cde7bef5b38d78774 Cc: Rex Buddenberg , "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 11:48:30 -0000 --nextPart1501873.mtarGmB4UR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 12:37:03 Dearlove, Christopher (UK) wrote: > OLSRv2 has a processing/forwarding engine that decides whether > a message should be processed, forwarded, both, or neither. >=20 > Messages that are to be processed need to be verified (if > possible, which I'm assuming is the case here). Messages that > are to be forwarded but not processed may or may not be > verified, but here I'll assume that they are if it matters. I think it matters that forwarded messages are checked for signatures too. = If=20 not the attacker will have the ability to poison the forwarding duplicate=20 check, so that correct signed messages will not be forwarded anymore. =20 > That leaves messages to be neither processed nor forwarded. > There's actually no need to verify them cryptographically, > they are going to be discarded with no effect anyway. So > why waste the effort doing so? That's right, as long as we know that we do not need to forward/process the= m=20 because we checked that message that lead to this. =20 > OK, that's OLSRv2. But that says that even if we have a > generic RFC 5444 approach, with a packet demultiplexer > and message distributor, the right place for signature > verification isn't necessarily in that. >=20 > Now possibly an architecture including OLSRv2 might want > to reuse that message processing/forwarding engine from > OLSRv2 (it includes message type in it for at least a > specialised case thereof, of extensions to OLSRv2, but > could apply to other protocols with similar rquirements). > That might be the place for message signature checking. > Packet signature checking probably (almost certainly) > belongs in the RFC 5444 demultiplexer. >=20 > Note however that I'm not suggesting mandating that > processing/forwarding engine for all MANET protocols. > I think DYMO could be specified in such a way as to > use it, but that might necessitate considering some > DYMO messages as one hop then processing may generate > a very similar message (obviously created from it for > efficiency) rather than multi-hop modified before > forwarding (which also necessitates a signature change > - or if considered a new message, a new signature). > But note that I'm not 100% certain of everything about > DYMO I've just said - but that's my point, I'm not > suggesting mandating the OLSRv2 engine. I think we should (if possible) check all messages that change any kind of= =20 internal database in any way... even the duplicate/processing set. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1501873.mtarGmB4UR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFMH8ACgkQRIfGfFXsz+DyCACdFu79UyDSmw7J3tNSx5+ehMgz 5oYAnjydJJccINibfhTFd/W8bvjzo7Jz =f+FS -----END PGP SIGNATURE----- --nextPart1501873.mtarGmB4UR-- From Chris.Dearlove@baesystems.com Thu Nov 19 03:58:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AADF3A6A35 for ; Thu, 19 Nov 2009 03:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhAyS4+vJnel for ; Thu, 19 Nov 2009 03:58:13 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 440043A69C4 for ; Thu, 19 Nov 2009 03:58:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33867621" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 11:58:11 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJBwIIr013772; Thu, 19 Nov 2009 11:58:18 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:58:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 11:58:09 -0000 Message-ID: In-Reply-To: <200911191248.19893.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppDjiiUY0Cx2rNSzinr99/zW46QQAABl7g References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 19 Nov 2009 11:58:10.0509 (UTC) FILETIME=[909C9FD0:01CA690F] Cc: Rex Buddenberg , Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 11:58:14 -0000 >> Messages that are to be processed need to be verified (if >> possible, which I'm assuming is the case here). Messages that >> are to be forwarded but not processed may or may not be >> verified, but here I'll assume that they are if it matters. > I think it matters that forwarded messages are checked for signatures too. If > not the attacker will have the ability to poison the forwarding duplicate > check, so that correct signed messages will not be forwarded anymore. Good point. > I think we should (if possible) check all messages that change any kind of > internal database in any way... even the duplicate/processing set. OK, I can buy that. That is however an aside to the main point I was making, on the architectural relationship of - The RFC 5444 demultiplexer (which can incorporate packet signature verification). - OLSRv2's processing and forwarding mechanism. - The rest of OLSRv2, and any extensions to OLSRv2. - Other MANET protocols, which may or may not want to use OLSRv2's processing and forwarding mechanism (or a copy thereof, or an adaption thereof). - Message signature verification. One point I didn't make was that NHDP does not need to use the OLSRv2 mechanism, HELLO messages aren't forwarded and are just processed when received (or not if a signature fails). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Nov 19 04:09:23 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A203A6B23 for ; Thu, 19 Nov 2009 04:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPJiG6g7KhrQ for ; Thu, 19 Nov 2009 04:09:21 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id DD4283A6B27 for ; Thu, 19 Nov 2009 04:09:20 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB5p7-0003vu-Mq; Thu, 19 Nov 2009 13:09:17 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NB5p7-0002HD-Dn; Thu, 19 Nov 2009 13:09:17 +0100 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Thu, 19 Nov 2009 13:09:09 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6842111.Mqu9EEil2E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191309.14315.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10046/Thu Nov 19 11:54:00 2009) by mailguard.fgan.de X-Scan-Signature: 054ccd22e44c7b570fe3109fd6105c99 Cc: Rex Buddenberg , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:09:23 -0000 --nextPart6842111.Mqu9EEil2E Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 19 2009 12:58:09 Dearlove, Christopher (UK) wrote: > > I think we should (if possible) check all messages that change any > > kind of internal database in any way... even the > > duplicate/processing set. >=20 > OK, I can buy that. >=20 > That is however an aside to the main point I was making, on the > architectural relationship of > - The RFC 5444 demultiplexer (which can incorporate > packet signature verification). If we put the packet signature verification there (which would be a good=20 place), we need a mechanism to tell the packetbb-dependant protocolls if a= =20 message was in a signed packet or if it was badly signed. This might lead=20 NHDP, DYMO or OLSRv2 to use another set of databases (or to flag the entrie= s). > - OLSRv2's processing and forwarding mechanism. > - The rest of OLSRv2, and any extensions to OLSRv2. > - Message signature verification. Yes, in terms of security (and depending on the security policy) this=20 components could be tightly connected. We need some information channel=20 between them. > - Other MANET protocols, which may or may not want > to use OLSRv2's processing and forwarding mechanism > (or a copy thereof, or an adaption thereof). > One point I didn't make was that NHDP does not need > to use the OLSRv2 mechanism, HELLO messages aren't > forwarded and are just processed when received > (or not if a signature fails). Right, but it still needs to check incoming message signatures if the packe= t=20 was not/badly signed or the packet signature does not belong to the origina= tor=20 of the message. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart6842111.Mqu9EEil2E Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksFNWUACgkQRIfGfFXsz+DUNQCeMnWdcdztulqtUaKcTc/n2D7n r/kAn2sHfFuTMp/igG2gExQl6YVLaxwX =GYQo -----END PGP SIGNATURE----- --nextPart6842111.Mqu9EEil2E-- From Chris.Dearlove@baesystems.com Thu Nov 19 04:15:03 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81A828C12F for ; Thu, 19 Nov 2009 04:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG83CoyY2unQ for ; Thu, 19 Nov 2009 04:15:03 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D26AC3A6B25 for ; Thu, 19 Nov 2009 04:15:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33873469" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 12:15:00 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJCF8uv025690; Thu, 19 Nov 2009 12:15:08 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:14:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 12:14:59 -0000 Message-ID: In-Reply-To: <200911191309.14315.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppESA9rbCb+qvJSK6CD0TQ5m8y2wAACnvQ References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 19 Nov 2009 12:14:59.0987 (UTC) FILETIME=[EA4EBE30:01CA6911] Cc: Rex Buddenberg , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:15:04 -0000 >> - The RFC 5444 demultiplexer (which can incorporate >> packet signature verification). > If we put the packet signature verification there (which would be a good > place), we need a mechanism to tell the packetbb-dependant protocolls if a > message was in a signed packet or if it was badly signed. If the packet badly signed, we dump it and the protocols never see any of its messages. In some cases we may also dump the packet if unsigned, but if not then the protocols can, in principle, deduce this for themselves by that they (according to RFC 5444) get a copy of the packet header. Of course it might instead be preferable to remove the signature from the packet header as copied and flag that fact separately. Or that could be an implementation issue. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From robert.cole@jhuapl.edu Thu Nov 19 06:41:48 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AAB3A68AF; Thu, 19 Nov 2009 06:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaB2qnKV7Cek; Thu, 19 Nov 2009 06:41:47 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id C8A8328C0F8; Thu, 19 Nov 2009 06:41:42 -0800 (PST) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.35047878; Thu, 19 Nov 2009 09:40:30 -0500 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 19 Nov 2009 09:41:32 -0500 From: "Cole, Robert G." To: Ulrich Herberg , 6lowpan <6lowpan@ietf.org>, "manet@ietf.org" , "roll@ietf.org" Date: Thu, 19 Nov 2009 09:41:30 -0500 Thread-Topic: [manet] SNMP optimizations Thread-Index: Acpok58TtW4sKSpDQS2tzvjWYhSwMQAkjpvA Message-ID: <0A8F66C42F49E448A40E99946404EE5B717B8531D1@aplesstar.dom1.jhuapl.edu> References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> In-Reply-To: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "andy@netconfcentral.com" Subject: Re: [manet] SNMP optimizations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:41:48 -0000 Ulrich, The was some prior related work in the RMON WG on the RAQMON model (RFCs 47= 10 and 4711). This monitoring framework was explicitly designed to monitor= low-power, hand held devices, e.g., phones. Dan was one of the co-authors= . Folks may want to read thru these RFCs. Thanks, Bob -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of U= lrich Herberg Sent: Wednesday, November 18, 2009 4:10 PM To: 6lowpan; manet@ietf.org; roll@ietf.org Subject: [manet] SNMP optimizations Hi, I am sending this message to the 6lowpan, ROLL and MANET mailing list, sinc= e I think this topic concerns all three working groups, and I am not sure i= n which WG this is to be tackled. During the MANET WG meeting and also during an OLSRv2 Interop workshop, we = had discussions about SNMP deployments in such ad-hoc networks we are deali= ng with. The issue that was raised (and which is also described in draft-ha= mid-6lowpan-snmp-optimizations) is that SNMP may be too memory-/CPU-/bandwi= dth-consuming for low-power devices. However, a solution for monitoring and management of these devices is desir= ed (and also required by IETF). The before-mentioned draft describes very w= ell how to optimize SNMP for running it on 6lowpan devices, and shows that = the SNMP payload can fit into 6lowpan packets. However, it is unclear whether the code footprint of SNMP implementations c= an fit into the memory of small devices. From discussions with several pers= ons from the MANET WG, I conclude that for MANET the same problem exists. (= and I think for ROLL, too?) I have several questions that came to my mind about this topic: - First of all, to which WG does this issue belong to? Or is it -- as I sup= pose -- a common problem for the three working groups addressed in this mai= l? - Is this really an issue? Are there implementations of SNMP (maybe not ope= n-source) that can be run on very small devices such as considered in 6lowp= an/ROLL/MANET? Is there any experimental (or theoretical) analysis whether SNMP (or any other standardized management pr= otocol) can run on these devices? - If SNMP cannot be used for small devices, how can we manage and monitor t= hese devices then? (e.g. using proxies, different message formats such as p= roposed in 6lowapp, etc.). Do we need a different lightweight protocol for = management? - Can we provide SNMP not only on a single device, but for a whole network= ? That might need an aggregator device that runs full SNMP and collects the= data from the low power devices. This would imply to monitor statistics of= a whole network (e.g. number of links, average throughput, average path-le= ngth, etc.) - What kind of objects should be provided in a MIB running on a MANET/6low= pan/ROLL device? This might be specific to the routing protocol, but there = can be commonalities. Regards, Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From kavithaammayappan@gmail.com Thu Nov 19 02:37:59 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7494E28C17C for ; Thu, 19 Nov 2009 02:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8utb6ui06Ldb for ; Thu, 19 Nov 2009 02:37:56 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 6F46C28C18C for ; Thu, 19 Nov 2009 02:37:56 -0800 (PST) Received: by pzk6 with SMTP id 6so1434462pzk.29 for ; Thu, 19 Nov 2009 02:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Rt/t2JovqFlRCBge/jBhrS+UCU15o3iKoOIQMiyOZmY=; b=RKiYF2wXPYkLnBlaKhwVdQvP3G0XgsryEDooggmw3L55yBsjMkZ9NFfkSDPrACLkG5 316ItCDCKYLMm+8F8cFvq7U/e1D2VbbT5SJl5h561eNRMTd7z6hxI2BmuFpu4+Ggc5U7 VeS+nBlLwunB1wujEVfvuw+2QNSOd4QvcH/WE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=b65dfObIP6P9WHnhkX+uXdB7h9Iw/zgI1I1xnZFlYcvfhaf1SIOg1zNw/v/PcldDVR ankxqf18B4NSLgLiWzqJUU1TTGB7c3Cob0aEyIOFU1Rn2DGGODHKGVV5IYHo/oS0ehIP caIU5bEKsHyQJfvb9uZISpVZnGQiIBMuczRlg= MIME-Version: 1.0 Received: by 10.142.249.2 with SMTP id w2mr1420663wfh.198.1258627071839; Thu, 19 Nov 2009 02:37:51 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2009 16:07:51 +0530 Message-ID: <87772ea0911190237t45ce9bd9oda65d89c33bbb7c1@mail.gmail.com> From: Kavitha Ammayappan To: manet@ietf.org Content-Type: multipart/alternative; boundary=00504502ce958590260478b6f3e8 X-Mailman-Approved-At: Thu, 19 Nov 2009 08:09:47 -0800 Subject: Re: [manet] manet Digest, Vol 67, Issue 22 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:37:59 -0000 --00504502ce958590260478b6f3e8 Content-Type: text/plain; charset=UTF-8 I would like to put forth my view about the usage of signatures for claiming security in MANET. Why should we look in to some other alternative instead of signatures for claiming security in MANET as it consumes much energy? Regards Kavitha Ammayappan On Thu, Nov 19, 2009 at 3:58 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/manet > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send manet mailing list submissions to > manet@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/manet > or, via email, send a message with subject or body 'help' to > manet-request@ietf.org > > You can reach the person managing the list at > manet-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of manet digest..." > > > Today's Topics: > > 1. Re: Security drafts (Henning Rogge) > 2. Re: Security drafts (Thomas Heide Clausen) > 3. Re: Security drafts (Dearlove, Christopher (UK)) > 4. Re: Security drafts (Henning Rogge) > 5. Re: Security drafts (Thomas Heide Clausen) > 6. Re: Security drafts (Thomas Heide Clausen) > 7. Re: Security drafts (Henning Rogge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Nov 2009 11:04:57 +0100 > From: Henning Rogge > Subject: Re: [manet] Security drafts > To: manet@ietf.org > Cc: 'Rex Buddenberg' , "'Dearlove, Christopher > \(UK\)'" , Thomas Heide > Clausen > > Message-ID: <200911191104.57676.henning.rogge@fkie.fraunhofer.de> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu November 19 2009 10:49:19 Thomas Heide Clausen wrote: > > All good comments. I won't pretend to answer to your questions, as I > > don't know that I know the ultimate answers ;) I'd just bounce a > > couple of thoughts out and off you for discussion > > > > I do know that there are uses for situations where a given network may > > maintain two topologies: one "secured" and one "not secured". Thus, > > one topology may reject a given entry in the LSDB while another > > topology in the same router may accept and use it, depending on the > > validation of signatures. > Yes, we could do this, as long as unsigned messages cannot change the state > delivered by signed messages. > > > A blanket "throw away a message which doesn't validate, also without > > forwarding" would, I think, disable this functioning. > Yes. > > > Consequently, > > this holds also for "throw away a packet which contains a message > > where the signature doesn't validate". > A packet should be only thrown away completely if the packet signature is > wrong (if it contains a packet signature). > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 197 bytes > Desc: This is a digitally signed message part. > Url : < > http://www.ietf.org/mail-archive/web/manet/attachments/20091119/916c7e46/attachment.sig > > > > ------------------------------ > > Message: 2 > Date: Thu, 19 Nov 2009 11:07:42 +0100 > From: Thomas Heide Clausen > Subject: Re: [manet] Security drafts > To: Henning Rogge > Cc: Rex Buddenberg , "Dearlove, Christopher > \(UK\)" , manet@ietf.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > > On Nov 19, 2009, at 11:02 AM, Henning Rogge wrote: > > > On Thu November 19 2009 10:24:57 Ulrich Herberg wrote: > >> This is an interesting point. I fear, however, that allowing to block > >> an originator forever leads to another attack. A malicious router > >> simply sends a few unsigned (or badly signed) messages claiming to > >> originate from another router. > > Unsigned or badly signed messages/packets should NEVER be used to > > block a node > > if the capability exists to forge your own MAC/Source-IP. You simply > > don't > > have any information where the message is coming from, the only > > thing you can > > do is to call a higher layer (Help, I'm getting lot's of forged > > messages !). > > > > The only exception I see is if you receive a message with a bad > > signature but > > the package was signed correctly. In this case it's clear that the > > forwarding > > node is either a stupid attacker or malfunctioning, so you could > > remove it. > > > > Or, maybe, that the forwarding node was not equipped to validate the > signature. E.g. a protocol extension using a message type unknown to > the forwarder, and where the "key-space" is proper to the extension > (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to > OLSRv1, though) where this is the case. > > I'd not even consider "good packet signature, bad message signature" > as a reason to remove the sender of the packet. > > Thomas > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-263, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > ------------------------------ > > Message: 3 > Date: Thu, 19 Nov 2009 10:13:01 -0000 > From: "Dearlove, Christopher (UK)" > Subject: Re: [manet] Security drafts > To: "Thomas Heide Clausen" > Cc: Rex Buddenberg , manet@ietf.org > Message-ID: > > Content-Type: text/plain; charset=us-ascii > > > I can think > > of no situation where dropping a whole packet if a contained message > > doesn't validate would make sense > > There are always two cases of "doesn't validate" to consider > - Has signature, signature is bad. > - Doesn't have signature. > > You can afford to be harsher in the former case than the latter. > Whether that extends to dropping a whole packet is another matter. > > > In terms of the way forward, it appears clear to me that discussing > > things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - > > > and allow us to extract the general/agnostic matters. > > Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts > that an aim is exactly that, given the RFC 5444 multiplexing framework. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > ------------------------------ > > Message: 4 > Date: Thu, 19 Nov 2009 11:14:34 +0100 > From: Henning Rogge > Subject: Re: [manet] Security drafts > To: Thomas Heide Clausen > Cc: Rex Buddenberg , "Dearlove, Christopher > \(UK\)" , manet@ietf.org > Message-ID: <200911191114.34159.henning.rogge@fkie.fraunhofer.de> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote: > > > > Unsigned or badly signed messages/packets should NEVER be used to > > > block a node > > > if the capability exists to forge your own MAC/Source-IP. You simply > > > don't > > > have any information where the message is coming from, the only > > > thing you can > > > do is to call a higher layer (Help, I'm getting lot's of forged > > > messages !). > > > > > > The only exception I see is if you receive a message with a bad > > > signature but > > > the package was signed correctly. In this case it's clear that the > > > forwarding > > > node is either a stupid attacker or malfunctioning, so you could > > > remove it. > > > > Or, maybe, that the forwarding node was not equipped to validate the > > signature. E.g. a protocol extension using a message type unknown to > > the forwarder, and where the "key-space" is proper to the extension > > (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to > > OLSRv1, though) where this is the case. > > > > I'd not even consider "good packet signature, bad message signature" > > as a reason to remove the sender of the packet. > I think this would depend on the policy of the network. > > Maybe you drop the node at once (because you have mandatory signature > checking > on all nodes), maybe you just drop the message and inform your IDS "got bad > message signature from node X forwarded by node Y". > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 197 bytes > Desc: This is a digitally signed message part. > Url : < > http://www.ietf.org/mail-archive/web/manet/attachments/20091119/d11ea6f3/attachment.sig > > > > ------------------------------ > > Message: 5 > Date: Thu, 19 Nov 2009 11:16:25 +0100 > From: Thomas Heide Clausen > Subject: Re: [manet] Security drafts > To: Henning Rogge > Cc: Rex Buddenberg , "Dearlove, Christopher > \(UK\)" , manet@ietf.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > > On Nov 19, 2009, at 11:14 AM, Henning Rogge wrote: > > > On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote: > > > >>> Unsigned or badly signed messages/packets should NEVER be used to > >>> block a node > >>> if the capability exists to forge your own MAC/Source-IP. You simply > >>> don't > >>> have any information where the message is coming from, the only > >>> thing you can > >>> do is to call a higher layer (Help, I'm getting lot's of forged > >>> messages !). > >>> > >>> The only exception I see is if you receive a message with a bad > >>> signature but > >>> the package was signed correctly. In this case it's clear that the > >>> forwarding > >>> node is either a stupid attacker or malfunctioning, so you could > >>> remove it. > >> > >> Or, maybe, that the forwarding node was not equipped to validate the > >> signature. E.g. a protocol extension using a message type unknown to > >> the forwarder, and where the "key-space" is proper to the extension > >> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to > >> OLSRv1, though) where this is the case. > >> > >> I'd not even consider "good packet signature, bad message signature" > >> as a reason to remove the sender of the packet. > > I think this would depend on the policy of the network. > > > > Maybe you drop the node at once (because you have mandatory > > signature checking > > on all nodes), maybe you just drop the message and inform your IDS > > "got bad > > message signature from node X forwarded by node Y". > > > > Right, I agree. This is rather deployment/policy dependent. We just > need to make sure that we not enforce a behavior that excludes useful > behaviors. > > Thomas > > > Henning Rogge > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-263, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > > ------------------------------ > > Message: 6 > Date: Thu, 19 Nov 2009 11:18:01 +0100 > From: Thomas Heide Clausen > Subject: Re: [manet] Security drafts > To: "Dearlove, Christopher (UK)" > Cc: Rex Buddenberg , manet@ietf.org > Message-ID: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: > > >> I can think > >> of no situation where dropping a whole packet if a contained message > >> doesn't validate would make sense > > > > There are always two cases of "doesn't validate" to consider > > - Has signature, signature is bad. > > - Doesn't have signature. > > > > You can afford to be harsher in the former case than the latter. > > Whether that extends to dropping a whole packet is another matter. > > Actually, I made a comment to this effect to Henning and on the list > just now - not even in that case is it (always) reasonable to drop the > packet, as the forwarder might just be an innocent bystander not able > to validate the contained messages that it forwards. > > >> In terms of the way forward, it appears clear to me that discussing > >> things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier - > > > >> and allow us to extract the general/agnostic matters. > > > > Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific > > drafts > > that an aim is exactly that, given the RFC 5444 multiplexing > > framework. > > I could live with that, Ulrich? > > > > > ------------------------------ > > Message: 7 > Date: Thu, 19 Nov 2009 11:28:09 +0100 > From: Henning Rogge > Subject: Re: [manet] Security drafts > To: manet@ietf.org > Cc: Rex Buddenberg , "Dearlove, Christopher > \(UK\)" , Thomas Heide > Clausen > > Message-ID: <200911191128.20190.henning.rogge@fkie.fraunhofer.de> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu November 19 2009 11:18:01 Thomas Heide Clausen wrote: > > On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote: > > > You can afford to be harsher in the former case than the latter. > > > Whether that extends to dropping a whole packet is another matter. > > > > Actually, I made a comment to this effect to Henning and on the list > > just now - not even in that case is it (always) reasonable to drop the > > packet, as the forwarder might just be an innocent bystander not able > > to validate the contained messages that it forwards. > > I think the signatures will get even more important in combination with the > state-machine-drafts mentioned at IETF. Together they would allow to check > for > misbehaving nodes and trigger alerts to an IDS infrastructure (or a local > response daemon). > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 197 bytes > Desc: This is a digitally signed message part. > Url : < > http://www.ietf.org/mail-archive/web/manet/attachments/20091119/41534a0b/attachment.sig > > > > ------------------------------ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > End of manet Digest, Vol 67, Issue 22 > ************************************* > -- "Every one is the architect of his own fortune." Mathurin Regnier --00504502ce958590260478b6f3e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to put forth my view about the usage of signatures for cl= aiming security in MANET. Why should we look in to some other alternative i= nstead of signatures for claiming security in MANET as it consumes much ene= rgy?
=C2=A0
Regards
Kavitha Ammayappan

On Thu, Nov 19, 2009 at 3:58 PM, <manet-request@ietf.org= > wrote:
If you have received this digest= without all the individual message
attachments you will need to update = your digest options in your list
subscription. =C2=A0To do so, go to

https://www.ietf.org/mailman/list= info/manet

Click the 'Unsubscribe or edit options' butto= n, log in, and set "Get
MIME or Plain Text Digests?" to MIME. =C2=A0You can set this optionglobally for all the list digests you receive at this point.


Send manet mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0manet@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2= =A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/manet
or, via = email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0manet-= request@ietf.org

You can reach the person managing the list at=C2=A0 =C2=A0 =C2=A0 =C2=A0manet-= owner@ietf.org

When replying, please edit your Subject line so i= t is more specific
than "Re: Contents of manet digest..."


Today's Top= ics:

=C2=A0 1. Re: Security drafts (Henning Rogge)
=C2=A0 2. Re: = Security drafts (Thomas Heide Clausen)
=C2=A0 3. Re: Security drafts (De= arlove, Christopher (UK))
=C2=A0 4. Re: Security drafts (Henning Rogge)
=C2=A0 5. Re: Security dra= fts (Thomas Heide Clausen)
=C2=A0 6. Re: Security drafts (Thomas Heide C= lausen)
=C2=A0 7. Re: Security drafts (Henning Rogge)


-------= ---------------------------------------------------------------

Message: 1
Date: Thu, 19 Nov 2009 11:04:57 +0100
From: Henning Ro= gge <henning.rogge@f= kie.fraunhofer.de>
Subject: Re: [manet] Security drafts
To: manet@ietf.org
Cc: 'Rex Buddenberg' <bud= den@nps.navy.mil>, "'Dearlove, Christopher
=C2=A0 =C2=A0= =C2=A0 =C2=A0\(UK\)'" <Chris.Dearlove@baesystems.com>, =C2=A0 =C2=A0 =C2=A0 Thoma= s Heide Clausen
=C2=A0 =C2=A0 =C2=A0 =C2=A0<= thomas@thomasclausen.org>
Message-ID: <200911191104.57676.henning.= rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset=3D"iso-8859-1"

On Thu No= vember 19 2009 10:49:19 Thomas Heide Clausen wrote:
> All good commen= ts. I won't pretend to answer to your questions, as I
> don't= know that I know the ultimate answers ;) I'd just bounce a
> couple of thoughts out and off you for discussion
>
> I do= know that there are uses for situations where a given network may
> = maintain two topologies: one "secured" and one "not secured&= quot;. Thus,
> one topology may reject a given entry in the LSDB while another
>= ; topology in the same router may accept and use it, depending on the
&g= t; validation of signatures.
Yes, we could do this, as long as unsigned = messages cannot change the state
delivered by signed messages.

> A blanket "throw away a mess= age which doesn't validate, also without
> forwarding" would= , I think, disable this functioning.
Yes.

> Consequently,
> this holds also for "throw away a packet which contains a message=
> where the signature doesn't validate".
A packet should= be only thrown away completely if the packet signature is
wrong (if it = contains a packet signature).

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhof= er-Institut f?r
Kommunikation, Informationsverarbeitung und Ergonomie FK= IE
Kommunikationssysteme (KOM)
Neuenahrer Stra?e 20, 53343 Wachtberg,= Germany
Telefon +49 228 9435-263, =C2=A0 Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.= fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- ne= xt part --------------
A non-text attachment was scrubbed...
Name: no= t available
Type: application/pgp-signature
Size: 197 bytes
Desc: = This is a digitally signed message part.
Url : <http://www.ietf.org/ma= il-archive/web/manet/attachments/20091119/916c7e46/attachment.sig>
------------------------------

Message: 2
Date: Thu, 19 Nov 2= 009 11:07:42 +0100
From: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [man= et] Security drafts
To: Henning Rogge <h= enning.rogge@fkie.fraunhofer.de>
Cc: Rex Buddenberg <budden@nps.navy.mil>, "Dearlove= , =C2=A0 =C2=A0Christopher
=C2=A0 =C2=A0 =C2=A0 =C2=A0\(UK\)" <Chris.Dearlove@baesystems.com>, manet@ietf.org
Message-ID: <C680F494-46E3-43F5-899= 0-CCC0447B87E1@thomasclausen.org>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed; delsp=3Dye= s


On Nov 19, 2009, at 11:02 AM, Henning Rogge wrote:

>= On Thu November 19 2009 10:24:57 Ulrich Herberg wrote:
>> This is= an interesting point. I fear, however, that allowing to block
>> an originator forever leads to another attack. A malicious router<= br>>> simply sends a few unsigned (or badly signed) messages claiming= to
>> originate from another router.
> Unsigned or badly si= gned messages/packets should NEVER be used to
> block a node
> if the capability exists to forge your own MAC/So= urce-IP. You simply
> don't
> have any information where th= e message is coming from, the only
> thing you can
> do is to c= all a higher layer (Help, I'm getting lot's of forged
> messages !).
>
> The only exception I see is if you receiv= e a message with a bad
> signature but
> the package was signed= correctly. In this case it's clear that the
> forwarding
> node is either a stupid attacker or malfunctioning, so you could
&g= t; remove it.
>

Or, maybe, that the forwarding node was not eq= uipped to validate the
signature. E.g. a protocol extension using a mess= age type unknown to
the forwarder, and where the "key-space" is proper to the extensi= on
(i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (toOLSRv1, though) where this is the case.

I'd not even consider &= quot;good packet signature, bad message signature"
as a reason to remove the sender of the packet.

Thomas

> H= enning Rogge
>
> --
> Diplom-Informatiker Henning Rogge ,= Fraunhofer-Institut f?r
> Kommunikation, Informationsverarbeitung un= d Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Stra?e 20, 53343 Wachtb= erg, Germany
> Telefon +49 228 9435-263, =C2=A0 Fax +49 228 9435 685<= br>> mailto:henning.= rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> _______= ________________________________________
> manet mailing list
>= manet@ietf.org
> https://www.ie= tf.org/mailman/listinfo/manet



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

Message: 3
Date: Thu, = 19 Nov 2009 10:13:01 -0000
From: "Dearlove, Christopher (UK)" = <Chris.Dearlove@baesyst= ems.com>
Subject: Re: [manet] Security drafts
To: "Thomas Heide Clausen"= ; <thomas@thomasclausen.org<= /a>>
Cc: Rex Buddenberg <bu= dden@nps.navy.mil>, manet@ietf.org=
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0<ABE739C5ADAC9A41ACCC7= 2DF366B719D0275B53D@GLKMS2100.GREENLNK.NET>
Content-Type: text/pl= ain; charset=3Dus-ascii

> I can think
> of no situation where dropping a whole packet = if a contained message
> doesn't validate would make sense
There are always two cases of "doesn't validate" to consider=
- Has signature, signature is bad.
- Doesn't have signature.

= You can afford to be harsher in the former case than the latter.
Whether= that extends to dropping a whole packet is another matter.

> In = terms of the way forward, it appears clear to me that discussing
> things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier -<= br>
> and allow us to extract the general/agnostic matters.

Ag= reed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts
that an aim is exactly that, given the RFC 5444 multiplexing framework.
=

*******************************************************************= *
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipi= ent please delete it from your system and notify the sender.
You should = not copy it or use it for any purpose nor disclose or
distribute its con= tents to any other person.
********************************************************************


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

Message: 4
Date: Thu, 19 = Nov 2009 11:14:34 +0100
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Subject: Re: [manet] Security drafts
To: Thomas Heide Clausen <thomas@thomasclausen.org>
C= c: Rex Buddenberg <budden@nps.nav= y.mil>, "Dearlove, =C2=A0 =C2=A0Christopher
=C2=A0 =C2=A0 =C2=A0 =C2=A0\(UK\)" <Chris.Dearlove@baesystems.com>, manet@ietf.org
Message-ID: <200911191114.34159.hennin= g.rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset=3D"iso-8859-1"

On Thu No= vember 19 2009 11:07:42 Thomas Heide Clausen wrote:

> > Unsign= ed or badly signed messages/packets should NEVER be used to
> > bl= ock a node
> > if the capability exists to forge your own MAC/Source-IP. You sim= ply
> > don't
> > have any information where the mess= age is coming from, the only
> > thing you can
> > do is = to call a higher layer (Help, I'm getting lot's of forged
> > messages !).
> >
> > The only exception I see i= s if you receive a message with a bad
> > signature but
> &g= t; the package was signed correctly. In this case it's clear that the > > forwarding
> > node is either a stupid attacker or malfu= nctioning, so you could
> > remove it.
>
> Or, maybe, = that the forwarding node was not equipped to validate the
> signature= . E.g. a protocol extension using a message type unknown to
> the forwarder, and where the "key-space" is proper to the ex= tension
> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensi= ons (to
> OLSRv1, though) where this is the case.
>
> I&#= 39;d not even consider "good packet signature, bad message signature&q= uot;
> as a reason to remove the sender of the packet.
I think this would = depend on the policy of the network.

Maybe you drop the node at once= (because you have mandatory signature checking
on all nodes), maybe you= just drop the message and inform your IDS "got bad
message signature from node X forwarded by node Y".

Henning Rog= ge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r=
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunika= tionssysteme (KOM)
Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,= =C2=A0 Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- ne= xt part --------------
A non-text attachment was scrubbed...
Name: no= t available
Type: application/pgp-signature
Size: 197 bytes
Desc: = This is a digitally signed message part.
Url : <http://www.ietf.org/ma= il-archive/web/manet/attachments/20091119/d11ea6f3/attachment.sig>
------------------------------

Message: 5
Date: Thu, 19 Nov 2= 009 11:16:25 +0100
From: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [man= et] Security drafts
To: Henning Rogge <h= enning.rogge@fkie.fraunhofer.de>
Cc: Rex Buddenberg <budden@nps.navy.mil>, "Dearlove= , =C2=A0 =C2=A0Christopher
=C2=A0 =C2=A0 =C2=A0 =C2=A0\(UK\)" <Chris.Dearlove@baesystems.com>, manet@ietf.org
Message-ID: <CA9041AC-A550-4A53-A1A= 5-761F32D898BF@thomasclausen.org>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed; delsp=3Dye= s


On Nov 19, 2009, at 11:14 AM, Henning Rogge wrote:

>= On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote:
>
&g= t;>> Unsigned or badly signed messages/packets should NEVER be used t= o
>>> block a node
>>> if the capability exists to forge= your own MAC/Source-IP. You simply
>>> don't
>>&g= t; have any information where the message is coming from, the only
>&= gt;> thing you can
>>> do is to call a higher layer (Help, I'm getting lot's = of forged
>>> messages !).
>>>
>>> The = only exception I see is if you receive a message with a bad
>>>= signature but
>>> the package was signed correctly. In this case it's clear = that the
>>> forwarding
>>> node is either a stupid= attacker or malfunctioning, so you could
>>> remove it.
>>
>> Or, maybe, that the forwarding node was not equipped t= o validate the
>> signature. E.g. a protocol extension using a mes= sage type unknown to
>> the forwarder, and where the "key-spa= ce" is proper to the extension
>> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to=
>> OLSRv1, though) where this is the case.
>>
>>= ; I'd not even consider "good packet signature, bad message signat= ure"
>> as a reason to remove the sender of the packet.
> I think th= is would depend on the policy of the network.
>
> Maybe you dro= p the node at once (because you have mandatory
> signature checking > on all nodes), maybe you just drop the message and inform your IDS
= > "got bad
> message signature from node X forwarded by node = Y".
>

Right, I agree. This is rather deployment/policy de= pendent. We just
need to make sure that we not enforce a behavior that excludes useful
be= haviors.

Thomas

> Henning Rogge
>
> --
>= Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> Kommun= ikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Stra?e 20, 53343 Wachtb= erg, Germany
> Telefon +49 228 9435-263, =C2=A0 Fax +49 228 9435 685<= br>> mailto:henning.= rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0



= ------------------------------

Message: 6
Date: Thu, 19 Nov 2009 = 11:18:01 +0100
From: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] Security drafts
To: "Dearlove, Christopher (UK= )" <Chris.Dearlove= @baesystems.com>
Cc: Rex Buddenberg <budden@nps.navy.mil>, manet@ietf.org
Message-ID: <0BB64875-3DCD-4C80-A3E4-FF706F4DB86F@thomasclausen.org&g= t;
Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; delsp= =3Dyes


On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote:
=
>> I can think
>> of no situation where dropping a whole= packet if a contained message
>> doesn't validate would make = sense
>
> There are always two cases of "doesn't validate"= to consider
> - Has signature, signature is bad.
> - Doesn'= ;t have signature.
>
> You can afford to be harsher in the form= er case than the latter.
> Whether that extends to dropping a whole packet is another matter.
=
Actually, I made a comment to this effect to Henning and on the listjust now - not even in that case is it (always) reasonable to drop the
packet, as the forwarder might just be an innocent bystander not able
to= validate the contained messages that it forwards.

>> In terms= of the way forward, it appears clear to me that discussing
>> thi= ngs in the context of protocols (NHDP/OLSRv2/DYMO) may be easier -
>
>> and allow us to extract the general/agnostic matters.
&= gt;
> Agreed. In fact it may make sense to say in NHDP/OLSRv2 specifi= c
> drafts
> that an aim is exactly that, given the RFC 5444 mu= ltiplexing
> framework.

I could live with that, Ulrich?




-= -----------------------------

Message: 7
Date: Thu, 19 Nov 2009 1= 1:28:09 +0100
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Subject: Re: [manet] Security drafts
To: manet@ietf.org
Cc: Rex Buddenberg <budden@nps.navy.mil>, "Dearlove, =C2=A0 =C2=A0Chris= topher
=C2=A0 =C2=A0 =C2=A0 =C2=A0\(UK\)" <Chris.Dearlove@baesystems.com>, =C2=A0 =C2=A0 =C2= =A0 =C2=A0Thomas Heide Clausen
=C2=A0 =C2=A0 =C2=A0 =C2=A0<thomas@thomasclausen.org>
Message-ID: <200911191128.20190.henning.rogge@fkie.fraunhofer.de>
= Content-Type: text/plain; charset=3D"iso-8859-1"

On Thu No= vember 19 2009 11:18:01 Thomas Heide Clausen wrote:
> On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote:
>= ; > You can afford to be harsher in the former case than the latter.
= > > Whether that extends to dropping a whole packet is another matter= .
>
> Actually, I made a comment to this effect to Henning and on th= e list
> just now - not even in that case is it (always) reasonable t= o drop the
> packet, as the forwarder might just be an innocent bysta= nder not able
> to validate the contained messages that it forwards.

I think th= e signatures will get even more important in combination with the
state-= machine-drafts mentioned at IETF. Together they would allow to check for misbehaving nodes and trigger alerts to an IDS infrastructure (or a localresponse daemon).

Henning Rogge

--
Diplom-Informatiker H= enning Rogge , Fraunhofer-Institut f?r
Kommunikation, Informationsverarb= eitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra?e 20, 53343 Wachtberg, Germa= ny
Telefon +49 228 9435-263, =C2=A0 Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofe= r.de http:= //www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- ne= xt part --------------
A non-text attachment was scrubbed...
Name: no= t available
Type: application/pgp-signature
Size: 197 bytes
Desc: = This is a digitally signed message part.
Url : <http://www.ietf.org/ma= il-archive/web/manet/attachments/20091119/41534a0b/attachment.sig>
------------------------------

_________________________________= ______________
manet mailing list
m= anet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


End of manet Digest, Vol 67, Issue 22
**************************= ***********



--
"Ev= ery one is the architect of his own fortune." =C2=A0 Mathurin Regnier<= br> --00504502ce958590260478b6f3e8-- From j.schoenwaelder@jacobs-university.de Wed Nov 18 15:58:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2474D3A6B17; Wed, 18 Nov 2009 15:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4PDO+jXl2jA; Wed, 18 Nov 2009 15:58:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CCA773A69B8; Wed, 18 Nov 2009 15:58:27 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68044C0031; Thu, 19 Nov 2009 00:58:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JqwdzLmlVIDF; Thu, 19 Nov 2009 00:58:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26303C002B; Thu, 19 Nov 2009 00:58:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB5CDE2A42D; Thu, 19 Nov 2009 00:58:22 +0100 (CET) Date: Thu, 19 Nov 2009 00:58:22 +0100 From: Juergen Schoenwaelder To: Ulrich Herberg Message-ID: <20091118235822.GB7886@elstar.local> Mail-Followup-To: Ulrich Herberg , 6lowpan <6lowpan@ietf.org>, "manet@ietf.org" , "roll@ietf.org" References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 19 Nov 2009 08:10:09 -0800 Cc: "manet@ietf.org" , 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" Subject: Re: [manet] [6lowpan] SNMP optimizations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:58:29 -0000 On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote: [... we should restrict this to one mailing list...] > However, it is unclear whether the code footprint of SNMP > implementations can fit into the memory of small devices. From > discussions with several persons from the MANET WG, I conclude that > for MANET the same problem exists. (and I think for ROLL, too?) > > I have several questions that came to my mind about this topic: > > - First of all, to which WG does this issue belong to? Or is it -- as > I suppose -- a common problem for the three working groups addressed > in this mail? I don't know. > - Is this really an issue? Are there implementations of SNMP (maybe > not open-source) that can be run on very small devices such as > considered in 6lowpan/ROLL/MANET? Is there any experimental (or > theoretical) analysis whether SNMP (or any other standardized > management protocol) can run on these devices? The question is under specified. What is a "very small device" and how much can a "very small device" devote to SNMP? And what is SNMP? The SNMPv3 specs are pretty modular. One of the more important questions is how you deal with security - the security code has the potential to be bigger than the rest of the SNMP engine. And it boils down to the question of how many MIB objects you support and to what extend you hardwire things. Remember that SNMP is a child of the late 80s and early versions were sometimes embedded into devices that could not afford TCP. Of course, the 80s version of SNMP did not care much about security... > - If SNMP cannot be used for small devices, how can we manage and > monitor these devices then? (e.g. using proxies, different message > formats such as proposed in 6lowapp, etc.). Do we need a different > lightweight protocol for management? Again, the big question is how to deal with the security aspect. SNMP originally was lightweight because there was no security. It took the IETF many years to find a workable security solution and even today people are working on utilizing transport layer security protocols within SNMP (see ISMS working group). > - Can we provide SNMP not only on a single device, but for a whole > network? That might need an aggregator device that runs full SNMP and > collects the data from the low power devices. This would imply to > monitor statistics of a whole network (e.g. number of links, average > throughput, average path-length, etc.) Sure, there are ways of doing this. For read-only objects, this is relatively easy - it can get a bit messy if you have read-write objects. Whether this direction is worthwhile to explore depends on how you solve the security issues and whether a dependency on a "gateway" is desirable in the first place. > - What kind of objects should be provided in a MIB running on a > MANET/6lowpan/ROLL device? This might be specific to the routing > protocol, but there can be commonalities. In general, the IETF tends to break MIB modules down along protocol functions. Following this approach, a ROLL MIB module would report data about the ROLL routing protocol. A 6LoWPAN MIB would report data about the 6LoWPAN layer, that is for example the list of supported 6LoWPAN protocol features and counters for 6LoWPAN processing failures (e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues. I would hope that some IPv6 MIB objects apply as well and then there should ideally be an IEEE 802.15.4 MIB module for this particular radio technology. I do not think there is much overlap if things get structured well. This, however, might be difficult to achieve if work is spread over several WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hrogge@googlemail.com Thu Nov 19 08:16:56 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DB228C0E7 for ; Thu, 19 Nov 2009 08:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55hV6SnkCPdx for ; Thu, 19 Nov 2009 08:16:55 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id E13A728C0F4 for ; Thu, 19 Nov 2009 08:16:00 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so570460eya.51 for ; Thu, 19 Nov 2009 08:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=d1DRccw28NGAnzVF5QpHNgg6C2lxjwUnQ1IhxRSnq7s=; b=oLhqvJWex0EowJJbTk1czkTNP6V6vl48TrdEXCjiYLGAPkVnfHywDedyPv9aCRH/vV 2gj7QO6lWhqHJCdF/PGrIVHuBOe1ALhqKRFORMnKomP71HAxyGfRyU5Blq/uD/rYta6w MP2gNPI355JG+0zkYg2s1n9Ppp0bZplBnCe6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=u3I3Op1jsXR58zyDMPGXTHunywxdoKzg/DXm7kiG9e7foSYwpG/exiz/u9+Tvz3VPl kcCbqKh+cvJtl7Ka5eop1bT/WaCzyVXl6VkrqvXEwH4hSjnCfFDC4T4bCpKvbADUw8q7 d4frPl8AEAOIWWtTQJHYGQyG7dsDQWKon4C1s= Received: by 10.213.24.22 with SMTP id t22mr1647958ebb.59.1258647353689; Thu, 19 Nov 2009 08:15:53 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 24sm173625eyx.14.2009.11.19.08.15.52 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 08:15:53 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 17:15:47 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <87772ea0911190237t45ce9bd9oda65d89c33bbb7c1@mail.gmail.com> In-Reply-To: <87772ea0911190237t45ce9bd9oda65d89c33bbb7c1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1390490.vp2AlUc5cD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911191715.52317.hrogge@googlemail.com> Cc: Kavitha Ammayappan Subject: Re: [manet] manet Digest, Vol 67, Issue 22 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:16:56 -0000 --nextPart1390490.vp2AlUc5cD Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Donnerstag 19 November 2009 11:37:51 schrieb Kavitha Ammayappan: > I would like to put forth my view about the usage of signatures for > claiming security in MANET. Why should we look in to some other > alternative instead of signatures for claiming security in MANET as it > consumes much energy? =46irst not all attacks on a MANET can be contained with signatures. Second signatures open an attack vector itself on the CPU consumption of th= e=20 protocoll. Third embedded nodes might be not equipped to run signatures on their messa= ges=20 including signatures to prove their links. Henning Rogge --nextPart1390490.vp2AlUc5cD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksFbzgACgkQcenvcwAcHWdn+ACeItBoT3mIqetFlSlwzzFedqkL PL4An3VJ3c2rSSogiCkXSG3ncpM8ae6p =Q32h -----END PGP SIGNATURE----- --nextPart1390490.vp2AlUc5cD-- From Chris.Dearlove@baesystems.com Thu Nov 19 09:14:34 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15A33A6849 for ; Thu, 19 Nov 2009 09:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ij9Ft1fo16s for ; Thu, 19 Nov 2009 09:14:33 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 8CCA03A68D9 for ; Thu, 19 Nov 2009 09:14:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,772,1249254000"; d="scan'208";a="33974180" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 17:14:28 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJHEauD015431; Thu, 19 Nov 2009 17:14:36 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 17:14:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 17:14:25 -0000 Message-ID: In-Reply-To: <87772ea0911190237t45ce9bd9oda65d89c33bbb7c1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] manet Digest, Vol 67, Issue 22 Thread-Index: AcppMr5c1M1M8Z9sQEKdZuQdHPuBMgACOGXw References: <87772ea0911190237t45ce9bd9oda65d89c33bbb7c1@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Kavitha Ammayappan" , X-OriginalArrivalTime: 19 Nov 2009 17:14:27.0747 (UTC) FILETIME=[BFED5730:01CA693B] Subject: Re: [manet] manet Digest, Vol 67, Issue 22 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:14:35 -0000 > I would like to put forth my view about the usage of signatures > for claiming security in MANET. Why should we look in to some > other alternative instead of signatures for claiming security > in MANET as it consumes much energy? If you've got a solution that's lower energy, I'm sure we'd like to hear it. But as this is the IETF not the IRTF I think we're limited to the art of the currently possible, not an open-ended look for something else. Here's the basic problem. I want to form an ad hoc network. How do I allow A and B (who are "good guys") to join with me to start that network, but not allow X (who is a "bad guy") to join. That's not to say that any solution to that problem is acceptable. It might be too expensive (as you note). But it also might not solve the problem, it might have too much pre-configuration needed, it might introduce new problems, to name but three. But something that solves that is a minimal starting point. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From gumstix@scatechnica.com Thu Nov 19 11:06:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD4128C0CF for ; Thu, 19 Nov 2009 11:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U92E4ZksbVXp for ; Thu, 19 Nov 2009 11:06:16 -0800 (PST) Received: from defend3.alphahosting.com (defend3.alphahosting.com [206.126.97.8]) by core3.amsl.com (Postfix) with ESMTP id CE37E3A6974 for ; Thu, 19 Nov 2009 11:06:15 -0800 (PST) X-Envelope-From: gumstix@scatechnica.com X-Envelope-To: Chris.Dearlove@baesystems.com Received: From web.server.MX.relay.75.127.110.13-static.reverse.yourdnshost.com (75.127.110.13) by defend3.alphahosting.com (MAILFOUNDRY) id mrHmGtU+Ed6FfAAw; Thu, 19 Nov 2009 19:06:12 -0000 (GMT) Received: from static-64-222-191-96.man.east.myfairpoint.net ([64.222.191.96]:6290 helo=[192.168.2.103]) by www13.yourdnshost.com with esmtpa (Exim 4.67) (envelope-from ) id 1NBCKa-0006aA-Ay; Thu, 19 Nov 2009 14:06:12 -0500 Message-ID: <4B059808.5070000@scatechnica.com> Date: Thu, 19 Nov 2009 14:10:00 -0500 From: Tony User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:06:17 -0000 Hello, I would like to add a few points for consideration to the security discussion First, when ever you add new behavior to a system, you bring in new security concerns. I always like to think of Manet as an addition to an existing wireless system’s communication stack. A wireless communication system can still work without Manet (or Mesh, etc); the communication node will not have the multi hop, discovery, etc capabilities. Thus, Manet’s scope should be limited to only the new functionality added to the system. Is there a definition of Manet that defines its domain/scope within a system? I know there is an RFP at the OMG for a platform independent model for Manet providing such a description (I was part of the group who submitted it). If the domain/scope is not clear, then you cannot understand the assets that are specific to Manet (as apposed to a point to point communication network). If you cannot understand what the assets are then you cannot understand what vulnerabilities and threats are specific to Manet and what what vulnerabilities and threat are against other communication mechanisms and services within a system. Example, jamming is not an attack against Manet but is an attack on a nodes RF broadcast. While it affects Manet and multi hop networking can be used to route around it ultimately does not stop the jamming’s effect if the end node is the target. Manet cannot provide any mitigation against such an attack. A jamming attack can still take place and the mitigation against such an attack must come from layer 1. End to End security is not a concern for Manet because it is outside of scope. I can provide end to end security with or without Manet because such security services are outside of Manet’s scope. For example: IPSec does not care if a system is Manet enabled or not. While this does help enhance the security of a system, it does not address the security concerns that are specific to Manet. End to end security is address at layer 3 or higher in the network stack. (be it IP end to end communication or application to application). Unless manet replaces one or more of these layers, then end to end security should not be a concern for manet security and should be handled by other security mechanisms and services. Point to Point security may even be in Manet scope because there are many examples of point to point security without Manet. So the question is, is p2p within the domain / scope of what Manet brings to a system. Point to point security is address at layer 2 in the network stack. Unless manet replaces layer 2, then point to point security should not be a concern for manet security and should be handled by other security mechanisms and services at layer 2. If a manet design implementation replaces either point to point or end to end communication in existing network stacks, then it must address the security concerns for each. The multi hop route security concerns are clearly within the scope/domain of Manet because this is what is it brings to a system. Multihop is neither point to point nor end to end communication but exists someplace in between. Security engineering requires a series of steps to be able to more accurately identify the needed security architecture, mechanisms and services. The assets that are specific to the components (Manet) need to be identified, then identify the vulnerabilities for these assets and then find the attacks and their associated threats which leverage the various vulnerabilities. Once this is done, one can properly begin to identify the needed security architecture, design, services and mechanisms to mitigate the threats and attacks. If this is not done, your security requirements/recommendations will not be traceable, incomplete or improperly over reaching. Tony Martin From teco@inf-net.nl Thu Nov 19 12:04:43 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84263A67DD for ; Thu, 19 Nov 2009 12:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+hmhi4nOrKg for ; Thu, 19 Nov 2009 12:04:43 -0800 (PST) Received: from CPSMTPM-EML105.kpnxchange.com (cpsmtpm-eml105.kpnxchange.com [195.121.3.9]) by core3.amsl.com (Postfix) with ESMTP id D59D43A6405 for ; Thu, 19 Nov 2009 12:04:42 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 19 Nov 2009 21:04:39 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Date: Thu, 19 Nov 2009 21:04:38 +0100 Message-ID: <00c201ca6953$86618320$93248960$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppESA9rbCb+qvJSK6CD0TQ5m8y2wAACnvQABBc6jA= Content-Language: nl x-cr-hashedpuzzle: BelG EfaT E59W Jw9W O6oQ SmI1 Y2BK dJRN lR+l ojRA oqsP pRDg vHTd vTDi xLei y6SF; 5; YwBoAHIAaQBzAC4AZABlAGEAcgBsAG8AdgBlAEAAYgBhAGUAcwB5AHMAdABlAG0AcwAuAGMAbwBtADsAaABlAG4AbgBpAG4AZwAuAHIAbwBnAGcAZQBAAGYAawBpAGUALgBmAHIAYQB1AG4AaABvAGYAZQByAC4AZABlADsAbQBhAG4AZQB0AEAAaQBlAHQAZgAuAG8AcgBnADsAdABoAG8AbQBhAHMAQAB0AGgAbwBtAGEAcwBjAGwAYQB1AHMAZQBuAC4AbwByAGcAOwB1AGwAcgBpAGMAaABAAGgAZQByAGIAZQByAGcALgBuAGEAbQBlAA==; Sosha1_v1; 7; {12E694FD-515C-4A7B-80EA-D96BD74477B9}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Thu, 19 Nov 2009 20:04:13 GMT; UgBFADoAIABbAG0AYQBuAGUAdABdACAAUwBlAGMAdQByAGkAdAB5ACAAZAByAGEAZgB0AHMA x-cr-puzzleid: {12E694FD-515C-4A7B-80EA-D96BD74477B9} X-OriginalArrivalTime: 19 Nov 2009 20:04:39.0203 (UTC) FILETIME=[866DDF30:01CA6953] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:04:44 -0000 I don't get why we sign nhdp msgs and not the packets. This would protect for all protocols. I think Chris and Henning said this before. Can [ Thomas | Ulrich ] explain? Teco. From thomas@thomasclausen.org Thu Nov 19 12:06:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F22C3A687B for ; Thu, 19 Nov 2009 12:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03fYXQ5wTYNV for ; Thu, 19 Nov 2009 12:06:30 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7A2913A6860 for ; Thu, 19 Nov 2009 12:06:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9976A43025B; Thu, 19 Nov 2009 12:06:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 499BE430257; Thu, 19 Nov 2009 12:06:27 -0800 (PST) Message-Id: <37D22D02-6548-4437-BC33-11C755B2E1F2@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <00c201ca6953$86618320$93248960$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 21:06:24 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> <00c201ca6953$86618320$93248960$@nl> X-Mailer: Apple Mail (2.936) Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:06:31 -0000 On Nov 19, 2009, at 9:04 PM, Teco Boot wrote: > I don't get why we sign nhdp msgs and not the packets. This would > protect for all protocols. I think Chris and Henning said this before. > Can [ Thomas | Ulrich ] explain? It would not solve the problem for TC messages, or any other messages that are relayed beyond 1 hop - so it wouldn't protect for all protocols. Thomas From hrogge@googlemail.com Thu Nov 19 12:09:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA6A3A6828 for ; Thu, 19 Nov 2009 12:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yhw6-vzihX6 for ; Thu, 19 Nov 2009 12:09:31 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id AF0E53A67AF for ; Thu, 19 Nov 2009 12:09:30 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id d26so120105eyd.5 for ; Thu, 19 Nov 2009 12:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=8dv+3SFu0KP1ktvt7V/83JknRu1+3CuTaUkheCvpHwc=; b=VAi/yav4XOnPpXkQrpjIdI7KDWLKchNbYTmhQ1STgDK+6KHeVFC+KUT6xcb3y/ORJE /YLJnU/PHb0kJX3uYL5F3T1kQnpy/BuUZ/3LoUpYCAHJwnxw7hlnW9lAMfAy/u6RxiyZ oONENdOANxlxThVOZcW7GFHkS3YY01CT9yfQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=FXOGMkIamjRh1smQM2PLUZpMxrsnCESRb59CrY7TDEn68R6h1N2/K7l3N4G3gqH2i4 iqKEwzI8KD5F4r3EW4lA8JYFKUrY6agMTRY3BisvOUhavL8+0ufvGQECKZv10koEZbVx ZIajsEfXWtksNWhHI76R3j/Kl/BVjmpSRbUJc= Received: by 10.213.102.66 with SMTP id f2mr455759ebo.12.1258661363134; Thu, 19 Nov 2009 12:09:23 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm220324eyg.33.2009.11.19.12.09.21 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:09:21 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Thu, 19 Nov 2009 21:09:16 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <00c201ca6953$86618320$93248960$@nl> In-Reply-To: <00c201ca6953$86618320$93248960$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2850520.EGSNBXUpFo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911192109.20790.hrogge@googlemail.com> Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:09:32 -0000 --nextPart2850520.EGSNBXUpFo Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 19 November 2009 21:04:38 schrieb Teco Boot: > I don't get why we sign nhdp msgs and not the packets. This would > protect for all protocols. I think Chris and Henning said this before. > Can [ Thomas | Ulrich ] explain? Signing packets ist to protect the link, signing messages the end-2-end dat= a=20 transfer. for NHDP signing packets could be enough, but signing messages would do the= =20 job too. Henning Rogge --nextPart2850520.EGSNBXUpFo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksFpfAACgkQcenvcwAcHWcItACeOIueFOf19YwhaScU3MVR3+38 jioAn2QpTSeAicCSlr9lvMQx0y+8Tgf9 =f7YN -----END PGP SIGNATURE----- --nextPart2850520.EGSNBXUpFo-- From thomas@thomasclausen.org Thu Nov 19 12:17:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5C23A67EA for ; Thu, 19 Nov 2009 12:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9+wv4SBaoWF for ; Thu, 19 Nov 2009 12:17:10 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 94C393A67AF for ; Thu, 19 Nov 2009 12:17:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A9E714302A9; Thu, 19 Nov 2009 12:17:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-106-212.w92-140.abo.wanadoo.fr [92.140.113.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 50AC843028A; Thu, 19 Nov 2009 12:17:07 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Henning Rogge In-Reply-To: <200911192109.20790.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 21:17:05 +0100 References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <00c201ca6953$86618320$93248960$@nl> <200911192109.20790.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:17:11 -0000 On Nov 19, 2009, at 9:09 PM, Henning Rogge wrote: > Am Donnerstag 19 November 2009 21:04:38 schrieb Teco Boot: >> I don't get why we sign nhdp msgs and not the packets. This would >> protect for all protocols. I think Chris and Henning said this >> before. >> Can [ Thomas | Ulrich ] explain? > Signing packets ist to protect the link, signing messages the end-2- > end data > transfer. > Agree. > for NHDP signing packets could be enough, but signing messages would > do the > job too. > Actually, one might want to have a link advertised in a HELLO message with "both ends of the link signing for its existence", and so I would say that even NHDP would not (universally) be sufficiently supported by "just packet signatures". Besides, each protocol with messages carried inside the same RFC5444 packet might just use very different keys, signing processes, ..... Thomas From hrogge@googlemail.com Thu Nov 19 12:25:59 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBC43A69CA for ; Thu, 19 Nov 2009 12:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGLmcHUr6ehG for ; Thu, 19 Nov 2009 12:25:58 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id B4A8B3A6851 for ; Thu, 19 Nov 2009 12:25:57 -0800 (PST) Received: by fxm7 with SMTP id 7so2901797fxm.29 for ; Thu, 19 Nov 2009 12:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=23KpeQAuqnhmzk/7oer0j6h1n7JsnMXikfq7wQfV1Ak=; b=U1whQXJwndyFalwOsstetVDQ41qmgXihAUKJJQmrAenwltcPTKdsqlgv06iWiMiiuP NypZ2aJp20oNqQKS/IJlo+Yu3OUOgSvaSU4NuKs+8fqoZE3hRKA5Nn4I/Pv/nlKA3H8p xFrPVHcZNBcTmdtDgftsXmfS19iZomIv6oB2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=LeLAbUCKsbFePL0j3WRxslwA+dFD1F28n9TMzVLkF9t5Um9A/efI7FNLPAVV1S8ZrD eHNOoM6BRP7gxQRe52BLn3xcbBp2Tv01UoOPrsE4fX0gzQzVIwx0QAD9OBdaoBT/4WgX LqbvleToWoDwppDTgM0AgFT8aIN/xPQpDq6Ew= Received: by 10.216.86.139 with SMTP id w11mr149761wee.10.1258662352064; Thu, 19 Nov 2009 12:25:52 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm207832eye.3.2009.11.19.12.25.51 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:25:51 -0800 (PST) From: Henning Rogge To: Thomas Heide Clausen Date: Thu, 19 Nov 2009 21:25:46 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911192109.20790.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1610357.CdEn3KRt21"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911192125.50489.hrogge@googlemail.com> Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:25:59 -0000 --nextPart1610357.CdEn3KRt21 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 19 November 2009 21:17:05 schrieb Thomas Heide Clausen: > On Nov 19, 2009, at 9:09 PM, Henning Rogge wrote: > > Signing packets ist to protect the link, signing messages the end-2- > > end data transfer. >=20 > Agree. >=20 > > for NHDP signing packets could be enough, but signing messages would > > do the > > job too. >=20 > Actually, one might want to have a link advertised in a HELLO message > with "both ends of the link signing for its existence", and so I would > say that even NHDP would not (universally) be sufficiently supported > by "just packet signatures". This "co-signing" of links would be a very expensive operation, especially = in=20 dense networks. Both expensive in terms of network load and cpu-power. =20 > Besides, each protocol with messages carried inside the same RFC5444 > packet might just use very different keys, signing processes, ..... Yes. Henning Rogge --nextPart1610357.CdEn3KRt21 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksFqc4ACgkQcenvcwAcHWfjJwCffq9J8k18/t+rIaKDKUwke5Nd zlUAnRQ4OcyL/5M0ptwrf1MU4ZLJHkk1 =DHLH -----END PGP SIGNATURE----- --nextPart1610357.CdEn3KRt21-- From jdean@itd.nrl.navy.mil Thu Nov 19 12:26:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906E33A6828 for ; Thu, 19 Nov 2009 12:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7nyq5TQ2qos for ; Thu, 19 Nov 2009 12:26:27 -0800 (PST) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 9921B3A69CA for ; Thu, 19 Nov 2009 12:26:27 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id nAJKQ3DU009401; Thu, 19 Nov 2009 15:26:03 -0500 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009111915260317429 ; Thu, 19 Nov 2009 15:26:03 -0500 From: "Justin Dean" To: "'Henning Rogge'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <00c201ca6953$86618320$93248960$@nl> <200911192109.20790.hrogge@googlemail.com> In-Reply-To: <200911192109.20790.hrogge@googlemail.com> Date: Thu, 19 Nov 2009 15:25:53 -0500 Message-ID: <004101ca6956$7dc3ac40$794b04c0$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppVD+t7sFkFfcVRYup3VCxn/IUqwAAVhvA Content-Language: en-us Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:26:28 -0000 It also has to do with the way RFC5444 delegates protocols to message types. Having it at the packet level is okay but limited as it would have to work correctly for all protocols. A simple drop it if it doesn't have a (correct) key works and is what I believe either Chris or Thomas mentioned they might have a draft or are working on. It doesn't however support multiple hop signing to take advantage of possible heterogeneous situations where not all routers (for whatever reason) understand signatures. To me there is value in having both. Justin > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Henning Rogge > Sent: Thursday, November 19, 2009 3:09 PM > To: manet@ietf.org > Cc: 'Dearlove, Christopher (UK)'; 'Thomas Heide Clausen' > Subject: Re: [manet] Security drafts > > Am Donnerstag 19 November 2009 21:04:38 schrieb Teco Boot: > > I don't get why we sign nhdp msgs and not the packets. This would > > protect for all protocols. I think Chris and Henning said this > before. > > Can [ Thomas | Ulrich ] explain? > Signing packets ist to protect the link, signing messages the end-2-end > data transfer. > > for NHDP signing packets could be enough, but signing messages would do > the job too. > > Henning Rogge From ulrich@herberg.name Thu Nov 19 12:32:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A223A6952 for ; Thu, 19 Nov 2009 12:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZbU1JLdzdgO for ; Thu, 19 Nov 2009 12:32:41 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id B6DC23A696F for ; Thu, 19 Nov 2009 12:32:40 -0800 (PST) Received: by bwz23 with SMTP id 23so2909108bwz.29 for ; Thu, 19 Nov 2009 12:32:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.143.153 with SMTP id v25mr464037bku.116.1258662754463; Thu, 19 Nov 2009 12:32:34 -0800 (PST) In-Reply-To: <200911192125.50489.hrogge@googlemail.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911192109.20790.hrogge@googlemail.com> <200911192125.50489.hrogge@googlemail.com> Date: Thu, 19 Nov 2009 21:32:34 +0100 Message-ID: <25c114b90911191232s1b6c917fic0fd9417a89fe2d1@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:32:41 -0000 Henning On Thu, Nov 19, 2009 at 9:25 PM, Henning Rogge wrote: > Am Donnerstag 19 November 2009 21:17:05 schrieb Thomas Heide Clausen: >> On Nov 19, 2009, at 9:09 PM, Henning Rogge wrote: >> > Signing packets ist to protect the link, signing messages the end-2- >> > end data transfer. >> >> Agree. >> >> > for NHDP signing packets could be enough, but signing messages would >> > do the >> > job too. >> >> Actually, one might want to have a link advertised in a HELLO message >> with "both ends of the link signing for its existence", and so I would >> say that even NHDP would not (universally) be sufficiently supported >> by "just packet signatures". > This "co-signing" of links would be a very expensive operation, especially in > dense networks. Both expensive in terms of network load and cpu-power. Yes, and as such it should not be mandatory. But for some deployments that can be okay, so I think we should consider it as an additional means of protection. > >> Besides, each protocol with messages carried inside the same RFC5444 >> packet might just use very different keys, signing processes, ..... > Yes. I second that. We definitely need signatures of messages in the NHDP/OLSR-sec drafts. The question is, do we additionally allow to sign packets? Ulrich From jasteven@rockwellcollins.com Thu Nov 19 14:21:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6C33A6AC5 for ; Thu, 19 Nov 2009 14:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgJjqtDnPc6g for ; Thu, 19 Nov 2009 14:21:38 -0800 (PST) Received: from secvs01.rockwellcollins.com (secvs01.rockwellcollins.com [205.175.225.240]) by core3.amsl.com (Postfix) with ESMTP id 54B4A3A68BF for ; Thu, 19 Nov 2009 14:20:45 -0800 (PST) Received: from secvs01.rockwellcollins.com (secvs01.rockwellcollins.com [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CC9088F72B for ; Thu, 19 Nov 2009 16:20:38 -0600 (CST) Received: from collinscrsmtp02.rockwellcollins.com (collinscrsmtp02.rockwellcollins.com [131.198.63.133]) by secvs01.rockwellcollins.com (Postfix) with ESMTP id B691F8F712 for ; Thu, 19 Nov 2009 16:20:38 -0600 (CST) In-Reply-To: To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF1303 November 21, 2007 From: jasteven@rockwellcollins.com Message-ID: Date: Thu, 19 Nov 2009 16:20:23 -0600 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5 HF411|May 07, 2009) at 11/19/2009 04:20:38 PM, Serialize complete at 11/19/2009 04:20:38 PM Content-Type: multipart/alternative; boundary="=_alternative 007AB41486257673_=" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:21:39 -0000 This is a multipart message in MIME format. --=_alternative 007AB41486257673_= Content-Type: text/plain; charset="US-ASCII" Christopher Dearlove wrote on Thur, 19 Nov 2009 that >> I can think >> of no situation where dropping a whole packet if a contained message >> doesn't validate would make sense > >There are always two cases of "doesn't validate" to consider >- Has signature, signature is bad. >- Doesn't have signature. Even if packet/messages have valid signature, should also consider protecting against someone recording a valid transmission/message and then replaying it from a different part of the network as if the packet/message originated from there. --=_alternative 007AB41486257673_= Content-Type: text/html; charset="US-ASCII"
Christopher Dearlove wrote on Thur, 19 Nov 2009 that

>> I can think  
>> of no situation where dropping a whole packet if a contained message  
>> doesn't validate would make sense
>
>There are always two cases of "doesn't validate" to consider
>- Has signature, signature is bad.
>- Doesn't have signature.

Even if packet/messages have valid signature, should also consider protecting against someone recording a valid transmission/message and then replaying it from a different part of the network as if the packet/message originated from there.
--=_alternative 007AB41486257673_=-- From ulrich@herberg.name Thu Nov 19 14:28:27 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84853A6984 for ; Thu, 19 Nov 2009 14:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbBEYT0-jup5 for ; Thu, 19 Nov 2009 14:28:27 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 08AA93A68E1 for ; Thu, 19 Nov 2009 14:28:26 -0800 (PST) Received: by bwz23 with SMTP id 23so3029828bwz.29 for ; Thu, 19 Nov 2009 14:28:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.25.82 with SMTP id y18mr582560bkb.137.1258669701411; Thu, 19 Nov 2009 14:28:21 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2009 23:28:21 +0100 Message-ID: <25c114b90911191428t23b2bf6ejba735c1867870402@mail.gmail.com> From: Ulrich Herberg To: jasteven@rockwellcollins.com Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:28:28 -0000 Hi, On Thu, Nov 19, 2009 at 11:20 PM, wrote: > > Christopher Dearlove wrote on Thur, 19 Nov 2009 that > >>> I can think >>> of no situation where dropping a whole packet if a contained message >>> doesn't validate would make sense >> >>There are always two cases of "doesn't validate" to consider >>- Has signature, signature is bad. >>- Doesn't have signature. > > Even if packet/messages have valid signature, should also consider > protecting against someone recording a valid transmission/message and then > replaying it from a different part of the network as if the packet/message > originated from there. Yes, this is an optional part of the NHDP-sec draft (and will be in the OLSRv2-sec draft as well). The draft allows to include a timestamp TLV in messages and to reject messages that are "too old". The reason why this is optional is that it has some additional assumptions (such as synchronized clocks). In the current revision of the draft, only the unix timestamp is used for the timestamp TLV. As Henning pointed out, the others uses of the timestamp TLV as described in the packetbb-sec draft (e.g. using NTP time format, or a sequence number) could be allowed as well for protection against replay attacks. Ulrich From teco@inf-net.nl Thu Nov 19 23:17:57 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A173A6A5B for ; Thu, 19 Nov 2009 23:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoeveIOvc4Io for ; Thu, 19 Nov 2009 23:17:56 -0800 (PST) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id F08D53A69A7 for ; Thu, 19 Nov 2009 23:17:55 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 20 Nov 2009 08:17:47 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Henning Rogge'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <00c201ca6953$86618320$93248960$@nl> <200911192109.20790.hrogge@googlemail.com> In-Reply-To: Date: Fri, 20 Nov 2009 08:17:47 +0100 Message-ID: <011c01ca69b1$92536ff0$b6fa4fd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppVUXwpADD3WWlQSuu3YGrY/n84AAW3Msg Content-Language: nl X-OriginalArrivalTime: 20 Nov 2009 07:17:52.0055 (UTC) FILETIME=[9271F470:01CA69B1] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:17:57 -0000 Thanks for the replies on signing NHDP msgs or packets. However, I did not see an answer. The replies were for other protocols, or IMHO special cases. I'm getting worried on having std track mechanism for MANET protocol security. I think we should define the basics first, that MUST be supported. After that we could define other mechanisms, but as I see it now this is experimental. Teco. >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: donderdag 19 november 2009 21:17 >Aan: Henning Rogge >CC: manet@ietf.org; Teco Boot; 'Ulrich Herberg'; 'Dearlove, Christopher >(UK)' >Onderwerp: Re: [manet] Security drafts > > >On Nov 19, 2009, at 9:09 PM, Henning Rogge wrote: > >> Am Donnerstag 19 November 2009 21:04:38 schrieb Teco Boot: >>> I don't get why we sign nhdp msgs and not the packets. This would >>> protect for all protocols. I think Chris and Henning said this >>> before. >>> Can [ Thomas | Ulrich ] explain? >> Signing packets ist to protect the link, signing messages the end-2- >> end data >> transfer. >> > >Agree. > >> for NHDP signing packets could be enough, but signing messages would >> do the >> job too. >> > >Actually, one might want to have a link advertised in a HELLO message >with "both ends of the link signing for its existence", and so I would >say that even NHDP would not (universally) be sufficiently supported >by "just packet signatures". > >Besides, each protocol with messages carried inside the same RFC5444 >packet might just use very different keys, signing processes, ..... > >Thomas From henning.rogge@fkie.fraunhofer.de Fri Nov 20 01:13:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5C33A67FB for ; Fri, 20 Nov 2009 01:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktWm3ITTlIje for ; Fri, 20 Nov 2009 01:13:15 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 119693A6899 for ; Fri, 20 Nov 2009 01:13:14 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NBPY8-0004rw-Gr; Fri, 20 Nov 2009 10:13:04 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NBPY8-0006Lt-7G; Fri, 20 Nov 2009 10:13:04 +0100 From: Henning Rogge To: manet@ietf.org Date: Fri, 20 Nov 2009 10:12:56 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> In-Reply-To: <011c01ca69b1$92536ff0$b6fa4fd0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1841926.eOIsoIDuRy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911201013.01023.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10051/Fri Nov 20 04:48:11 2009) by mailguard.fgan.de X-Scan-Signature: 2577de289e0484eccb48b316b05ab48b Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:13:16 -0000 --nextPart1841926.eOIsoIDuRy Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Fri November 20 2009 08:17:47 Teco Boot wrote: > Thanks for the replies on signing NHDP msgs or packets. > However, I did not see an answer. The replies were for > other protocols, or IMHO special cases. > I'm getting worried on having std track mechanism for > MANET protocol security. I think we should define > the basics first, that MUST be supported. After that > we could define other mechanisms, but as I see it now > this is experimental. Signing packets helps to achive link-layer security for packetbb. If you ha= ve=20 signed packets and don't want to sign the neighbor entries in the HELLOs, y= ou=20 might just skip signing NHDP messages. But I think the NHDP security draft should only work on signatures/encrypti= on=20 of the NHDP messages. Packet signatures can be handled in a packetbb securi= ty=20 draft. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1841926.eOIsoIDuRy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksGXZgACgkQRIfGfFXsz+AdKQCdHI0QWB9wynm2Olekq8dyXG/3 xAYAn0lskJGk2Am9sGCX2V3qk0gujR4L =VweC -----END PGP SIGNATURE----- --nextPart1841926.eOIsoIDuRy-- From Chris.Dearlove@baesystems.com Fri Nov 20 01:19:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65633A67BD for ; Fri, 20 Nov 2009 01:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pinlNNIxaSSw for ; Fri, 20 Nov 2009 01:19:52 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id A539B3A63EB for ; Fri, 20 Nov 2009 01:19:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34061882" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:19:38 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9JjXw002985; Fri, 20 Nov 2009 09:19:46 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:19:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:19:33 -0000 Message-ID: In-Reply-To: <00c201ca6953$86618320$93248960$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppESA9rbCb+qvJSK6CD0TQ5m8y2wAACnvQABBc6jAAG+gsIA== References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> <00c201ca6953$86618320$93248960$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Heide Clausen" , "Ulrich Herberg" X-OriginalArrivalTime: 20 Nov 2009 09:19:37.0227 (UTC) FILETIME=[94AABDB0:01CA69C2] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:19:54 -0000 > I don't get why we sign nhdp msgs and not the packets. Without looking at the draft, I see no reason why a particular deployment can't choose one, and another deployment the other. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Fri Nov 20 01:22:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64E13A6A31 for ; Fri, 20 Nov 2009 01:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rofYhwCIf6S0 for ; Fri, 20 Nov 2009 01:22:39 -0800 (PST) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id E6EE43A6910 for ; Fri, 20 Nov 2009 01:22:38 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 20 Nov 2009 10:22:26 +0100 From: "Teco Boot" To: "'Henning Rogge'" , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> <200911201013.01023.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911201013.01023.henning.rogge@fkie.fraunhofer.de> Date: Fri, 20 Nov 2009 10:22:26 +0100 Message-ID: <013301ca69c2$f97fbab0$ec7f3010$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acppwa8NeVJs5FslT1GWZhrtGgirrAAAL2sw Content-Language: nl X-OriginalArrivalTime: 20 Nov 2009 09:22:26.0079 (UTC) FILETIME=[F94F82F0:01CA69C2] Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:22:39 -0000 >But I think the NHDP security draft should only work on >signatures/encryption >of the NHDP messages. Packet signatures can be handled in a packetbb >security >draft. This is what I don't get. Having packetbb-sec in std track, we don't need something for 1-hop messages. Securing packets will do. Teco. From Chris.Dearlove@baesystems.com Fri Nov 20 01:24:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184533A6A5C for ; Fri, 20 Nov 2009 01:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHeWnYkrPuBm for ; Fri, 20 Nov 2009 01:24:27 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 1F3D63A68BA for ; Fri, 20 Nov 2009 01:24:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34063380" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:24:24 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9OWYc006563; Fri, 20 Nov 2009 09:24:32 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:24:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:24:22 -0000 Message-ID: In-Reply-To: <25c114b90911191232s1b6c917fic0fd9417a89fe2d1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppV24vJuu/4V0NTU+ijzIpiZaVaAAa0kLA References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911192109.20790.hrogge@googlemail.com> <200911192125.50489.hrogge@googlemail.com> <25c114b90911191232s1b6c917fic0fd9417a89fe2d1@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , "Henning Rogge" X-OriginalArrivalTime: 20 Nov 2009 09:24:23.0788 (UTC) FILETIME=[3F787AC0:01CA69C3] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:24:28 -0000 > I second that. We definitely need signatures of messages in the > NHDP/OLSR-sec drafts. The question is, do we additionally allow to > sign packets? Yes. While message signatures offer advantages, packet signatures also have their uses. For example if you are prepared to assume that no node is ever compromised, and the signature process is flawless (I'm not, but a system offering a basic level of security might) then packet signatures might suffice. Packet signatures used in addition to message signatures might also offer some advantages in some cases. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Fri Nov 20 01:26:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EDF3A6A66 for ; Fri, 20 Nov 2009 01:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmIWL02LEPFx for ; Fri, 20 Nov 2009 01:26:19 -0800 (PST) Received: from CPSMTPM-EML110.kpnxchange.com (cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 252383A68BA for ; Fri, 20 Nov 2009 01:26:18 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 20 Nov 2009 10:26:14 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Thomas Heide Clausen'" , "'Ulrich Herberg'" References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> <00c201ca6953$86618320$93248960$@nl> In-Reply-To: Date: Fri, 20 Nov 2009 10:26:14 +0100 Message-ID: <013401ca69c3$81dcc970$85965c50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppESA9rbCb+qvJSK6CD0TQ5m8y2wAACnvQABBc6jAAG+gsIAAAKUgA Content-Language: nl X-OriginalArrivalTime: 20 Nov 2009 09:26:14.0928 (UTC) FILETIME=[81B71900:01CA69C3] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:26:20 -0000 >> I don't get why we sign nhdp msgs and not the packets. > >Without looking at the draft, I see no reason why a >particular deployment can't choose one, and another >deployment the other. Unless our goal is publishing lots of RFCs, I don't see the benefit. Remember, we want to define some standards. Having multiple options is contra-productive. Teco. From ulrich@herberg.name Fri Nov 20 01:29:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB753A68BA for ; Fri, 20 Nov 2009 01:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG8K50mPM4+T for ; Fri, 20 Nov 2009 01:29:17 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 18E9D3A6858 for ; Fri, 20 Nov 2009 01:29:16 -0800 (PST) Received: by bwz23 with SMTP id 23so3279595bwz.29 for ; Fri, 20 Nov 2009 01:29:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.21.4 with SMTP id h4mr1137722bkb.58.1258709350395; Fri, 20 Nov 2009 01:29:10 -0800 (PST) In-Reply-To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911192109.20790.hrogge@googlemail.com> <200911192125.50489.hrogge@googlemail.com> <25c114b90911191232s1b6c917fic0fd9417a89fe2d1@mail.gmail.com> Date: Fri, 20 Nov 2009 10:29:10 +0100 Message-ID: <25c114b90911200129k56542e70mf75e513147e1e7da@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:29:18 -0000 On Fri, Nov 20, 2009 at 10:24 AM, Dearlove, Christopher (UK) wrote: >> I second that. We definitely need signatures of messages in the >> NHDP/OLSR-sec drafts. The question is, do we additionally allow to >> sign packets? > > Yes. While message signatures offer advantages, packet signatures > also have their uses. For example if you are prepared to assume > that no node is ever compromised, and the signature process is > flawless (I'm not, but a system offering a basic level of security > might) then packet signatures might suffice. Packet signatures > used in addition to message signatures might also offer some > advantages in some cases. Okay, I think that we can indeed suggest a packet signature mechanism. But as Henning pointed out before, I do not think that this would be part of the NHDP-sec draft, since it is a lower layer mechanism. I suggest that we include it in the packetbb-sec draft. If in a deployment of NHDP/OLSRv2 no message signatures are required, the NHDP-/OLSRv2-sec drafts can be ignored then. Rejected packets would simply be never delivered to the NHDP/OLSRv2/otherprotocol instances. Ulrich From Chris.Dearlove@baesystems.com Fri Nov 20 01:30:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C6128C11B for ; Fri, 20 Nov 2009 01:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4lY4ldk2Az6 for ; Fri, 20 Nov 2009 01:30:14 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 921BF3A6A8B for ; Fri, 20 Nov 2009 01:30:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34065337" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:30:11 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9UJQv010714; Fri, 20 Nov 2009 09:30:19 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:30:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:30:10 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppZtIOInRRp/QhRZylyNBzRFnmJQAXHb3A References: From: "Dearlove, Christopher (UK)" To: , X-OriginalArrivalTime: 20 Nov 2009 09:30:11.0343 (UTC) FILETIME=[0EA129F0:01CA69C4] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:30:16 -0000 > Even if packet/messages have valid signature, should > also consider protecting against someone recording > a valid transmission/message and then replaying it > from a different part of the network as if the > packet/message originated from there. The delayed in time replay attack has some protection offered in the general draft by means of a timestamp. If you can ship a message across a network quickly (cooperating attackers, or one fast attacker) so that the timestamp doesn't protect you, then you need something more. What you can do, I'm not sure. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Fri Nov 20 01:32:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFB53A6A42 for ; Fri, 20 Nov 2009 01:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqOl-NjAUT9r for ; Fri, 20 Nov 2009 01:32:26 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id DD9893A68B5 for ; Fri, 20 Nov 2009 01:32:25 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NBPqn-0002Ba-CY; Fri, 20 Nov 2009 10:32:21 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NBPqn-0006X4-30; Fri, 20 Nov 2009 10:32:21 +0100 From: Henning Rogge To: manet@ietf.org Date: Fri, 20 Nov 2009 10:32:06 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <013401ca69c3$81dcc970$85965c50$@nl> In-Reply-To: <013401ca69c3$81dcc970$85965c50$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3117327.zrVgYtzjd3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911201032.11053.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10051/Fri Nov 20 04:48:11 2009) by mailguard.fgan.de X-Scan-Signature: 9bea0208ff5bf14e461e230ff4736cfe Cc: "'Dearlove, Christopher \(UK\)'" , 'Thomas Heide Clausen' Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:32:27 -0000 --nextPart3117327.zrVgYtzjd3 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Fri November 20 2009 10:26:14 Teco Boot wrote: > >> I don't get why we sign nhdp msgs and not the packets. > > > >Without looking at the draft, I see no reason why a > >particular deployment can't choose one, and another > >deployment the other. >=20 > Unless our goal is publishing lots of RFCs, I don't see > the benefit. Remember, we want to define some standards. > Having multiple options is contra-productive. Signing all packets have a huge overhead compared to signing only your own= =20 messages, because you have to sign packages that only contain forwarded=20 messages. So signing NHDP messages, even if you don't sign the links of NHDP, have it= 's=20 use cases. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3117327.zrVgYtzjd3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksGYhYACgkQRIfGfFXsz+BCGgCgpANiHMlHCv944U6VakeD7Vht wDQAnjpH3JHg09dFJasXf6a0/UDKbtm5 =JTad -----END PGP SIGNATURE----- --nextPart3117327.zrVgYtzjd3-- From ulrich@herberg.name Fri Nov 20 01:33:55 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31153A6A7F for ; Fri, 20 Nov 2009 01:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X4+69K43Gq3 for ; Fri, 20 Nov 2009 01:33:55 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id C51463A6925 for ; Fri, 20 Nov 2009 01:33:54 -0800 (PST) Received: by bwz23 with SMTP id 23so3282307bwz.29 for ; Fri, 20 Nov 2009 01:33:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.36.197 with SMTP id u5mr1149246bkd.81.1258709628554; Fri, 20 Nov 2009 01:33:48 -0800 (PST) In-Reply-To: <013401ca69c3$81dcc970$85965c50$@nl> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> <00c201ca6953$86618320$93248960$@nl> <013401ca69c3$81dcc970$85965c50$@nl> Date: Fri, 20 Nov 2009 10:33:47 +0100 Message-ID: <25c114b90911200133l68e684b9k988cf453510ba908@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:33:55 -0000 On Fri, Nov 20, 2009 at 10:26 AM, Teco Boot wrote: >>> I don't get why we sign nhdp msgs and not the packets. >> >>Without looking at the draft, I see no reason why a >>particular deployment can't choose one, and another >>deployment the other. > > Unless our goal is publishing lots of RFCs, I don't see > the benefit. Remember, we want to define some standards. > Having multiple options is contra-productive. No, I don't think so. A major principle of this security work bases on the principle no "one-size-fits-all". As Chris and Thomas pointed out, there are many cases where message signatures are required. However, I also understand that in some cases, packet signatures are sufficient. For the latter, a modification of the packetbb-sec draft (or a new draft for packet based signatures?) can be provided. Ulrich From Chris.Dearlove@baesystems.com Fri Nov 20 01:38:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BA33A6814 for ; Fri, 20 Nov 2009 01:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8doRLAMmMS-Q for ; Fri, 20 Nov 2009 01:38:31 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 61C6E3A67B8 for ; Fri, 20 Nov 2009 01:38:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34067941" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:38:28 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9caXu016492; Fri, 20 Nov 2009 09:38:36 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:38:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:38:27 -0000 Message-ID: In-Reply-To: <011c01ca69b1$92536ff0$b6fa4fd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppVUXwpADD3WWlQSuu3YGrY/n84AAW3MsgAATbZ2A= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><00c201ca6953$86618320$93248960$@nl><200911192109.20790.hrogge@googlemail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Heide Clausen" , "Henning Rogge" X-OriginalArrivalTime: 20 Nov 2009 09:38:28.0064 (UTC) FILETIME=[36B2C600:01CA69C5] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:38:32 -0000 > I'm getting worried on having std track mechanism for > MANET protocol security. Has anyone suggested standards track now? > I think we should define > the basics first, that MUST be supported. I don't believe we can actually define what must be supported. If someone is working in an environment requiring high grade military security, and someone else is working in an environment where authentication is basically there to prevent accidental network joining, they aren't going to have much in common in their implementations, beyond working in the same framework. > After that > we could define other mechanisms, I'm not sure what you are considering now and later. I would consider all of the framework proposed (message and packet, timestamps and signatures, a space for a range of algorithms, a few basic ones defined now) as for now. > but as I see it now > this is experimental. I would have to be persuaded that was not the case if that is proposed. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Fri Nov 20 01:39:37 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6CA3A6931 for ; Fri, 20 Nov 2009 01:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1orYW17cDgMb for ; Fri, 20 Nov 2009 01:39:36 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id EEAD828C119 for ; Fri, 20 Nov 2009 01:39:34 -0800 (PST) Received: by bwz23 with SMTP id 23so3285738bwz.29 for ; Fri, 20 Nov 2009 01:39:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.154.69 with SMTP id n5mr1164933bkw.43.1258709969298; Fri, 20 Nov 2009 01:39:29 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Nov 2009 10:39:29 +0100 Message-ID: <25c114b90911200139v32bca001g70b1cb1300b96bcc@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, jasteven@rockwellcollins.com Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:39:37 -0000 On Fri, Nov 20, 2009 at 10:30 AM, Dearlove, Christopher (UK) wrote: >> Even if packet/messages have valid signature, should >> also consider protecting against someone recording >> a valid transmission/message and then replaying it >> from a different part of the network as if the >> packet/message originated from there. > > The delayed in time replay attack has some protection > offered in the general draft by means of a timestamp. > If you can ship a message across a network quickly > (cooperating attackers, or one fast attacker) so that > the timestamp doesn't protect you, then you need > something more. What you can do, I'm not sure. Yes, this is an accurate description. I am not sure we can do anything against this attack. In research, there are heuristics against these attacks, based on additional information such as positions of routers, radio range of the wireless interfaces, etc. But without such information, I am not aware how such attacks can be counteracted. Ulrich From Chris.Dearlove@baesystems.com Fri Nov 20 01:41:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178A33A6A50 for ; Fri, 20 Nov 2009 01:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNxMYL8sPL0n for ; Fri, 20 Nov 2009 01:41:15 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2587B3A68B8 for ; Fri, 20 Nov 2009 01:41:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34068704" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:41:12 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9fJlF018279; Fri, 20 Nov 2009 09:41:20 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:41:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:41:11 -0000 Message-ID: In-Reply-To: <200911201013.01023.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppwbGBU8PbCks2RBSuvY/rD+HR+wAA5PmQ References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> <200911201013.01023.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 20 Nov 2009 09:41:11.0797 (UTC) FILETIME=[984A7250:01CA69C5] Cc: Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:41:16 -0000 > But I think the NHDP security draft should only work on signatures/encryption > of the NHDP messages. Packet signatures can be handled in a packetbb security > draft. The NHDP draft should refer to the RFC 5444 security draft and note that packet signatures may be appropriate, especially if not also running any other protocol that requires more than one hop messages. But the details can be left in the general RFC 5444 security draft, I agree. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Fri Nov 20 01:43:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EDF3A67EF for ; Fri, 20 Nov 2009 01:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvi91lvaP8xC for ; Fri, 20 Nov 2009 01:43:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id C22AE3A6932 for ; Fri, 20 Nov 2009 01:43:27 -0800 (PST) Received: by bwz23 with SMTP id 23so3288040bwz.29 for ; Fri, 20 Nov 2009 01:43:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.154.135 with SMTP id o7mr1051628bkw.201.1258710201246; Fri, 20 Nov 2009 01:43:21 -0800 (PST) In-Reply-To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <00c201ca6953$86618320$93248960$@nl> <200911192109.20790.hrogge@googlemail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> Date: Fri, 20 Nov 2009 10:43:21 +0100 Message-ID: <25c114b90911200143k445927fmbd5118fa9a7330cb@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:43:28 -0000 Teco, On Fri, Nov 20, 2009 at 10:38 AM, Dearlove, Christopher (UK) wrote: >> I'm getting worried on having std track mechanism for >> MANET protocol security. > > Has anyone suggested standards track now? The intended status is Experimental. >> I think we should define >> the basics first, that MUST be supported. > > I don't believe we can actually define what must be > supported. If someone is working in an environment > requiring high grade military security, and someone > else is working in an environment where authentication > is basically there to prevent accidental network > joining, they aren't going to have much in common in > their implementations, beyond working in the same > framework. Yes, again: no "one-size-fits-all". >> After that >> we could define other mechanisms, > > I'm not sure what you are considering now and later. > I would consider all of the framework proposed (message > and packet, timestamps and signatures, a space for a > range of algorithms, a few basic ones defined now) as > for now. > >> but as I see it now >> this is experimental. > > I would have to be persuaded that was not the case if > that is proposed. Ulrich From Chris.Dearlove@baesystems.com Fri Nov 20 01:44:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639533A6A66 for ; Fri, 20 Nov 2009 01:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD2Lpe+ZeWk8 for ; Fri, 20 Nov 2009 01:44:01 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 57D853A6932 for ; Fri, 20 Nov 2009 01:44:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,776,1249254000"; d="scan'208";a="34069597" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Nov 2009 09:43:58 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAK9i69x020162; Fri, 20 Nov 2009 09:44:06 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 09:43:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Nov 2009 09:43:57 -0000 Message-ID: In-Reply-To: <013401ca69c3$81dcc970$85965c50$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcppESA9rbCb+qvJSK6CD0TQ5m8y2wAACnvQABBc6jAAG+gsIAAAKUgAAACr+TA= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <200911191248.19893.henning.rogge@fkie.fraunhofer.de> <200911191309.14315.henning.rogge@fkie.fraunhofer.de> <00c201ca6953$86618320$93248960$@nl> <013401ca69c3$81dcc970$85965c50$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Heide Clausen" , "Ulrich Herberg" X-OriginalArrivalTime: 20 Nov 2009 09:43:58.0208 (UTC) FILETIME=[FB7AC000:01CA69C5] Cc: manet@ietf.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:44:02 -0000 > Unless our goal is publishing lots of RFCs, I don't see > the benefit. Remember, we want to define some standards. > Having multiple options is contra-productive. Different people have seriously different security requirements. You only need to look at the affiliations of some people in this WG, from one of the chairs on down, to consider why. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Fri Nov 20 01:44:24 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9189A3A690D for ; Fri, 20 Nov 2009 01:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+cOE4nHl+Op for ; Fri, 20 Nov 2009 01:44:24 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9BFBB3A6AB4 for ; Fri, 20 Nov 2009 01:44:23 -0800 (PST) Received: by bwz23 with SMTP id 23so3288630bwz.29 for ; Fri, 20 Nov 2009 01:44:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.21.4 with SMTP id h4mr1155849bkb.58.1258710260776; Fri, 20 Nov 2009 01:44:20 -0800 (PST) In-Reply-To: References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <011c01ca69b1$92536ff0$b6fa4fd0$@nl> <200911201013.01023.henning.rogge@fkie.fraunhofer.de> Date: Fri, 20 Nov 2009 10:44:20 +0100 Message-ID: <25c114b90911200144m6ca50876h5c42b14d46844a8c@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 09:44:24 -0000 On Fri, Nov 20, 2009 at 10:41 AM, Dearlove, Christopher (UK) wrote: >> But I think the NHDP security draft should only work on > signatures/encryption >> of the NHDP messages. Packet signatures can be handled in a packetbb > security >> draft. > > The NHDP draft should refer to the RFC 5444 security > draft and note that packet signatures may be appropriate, > especially if not also running any other protocol that > requires more than one hop messages. But the details can > be left in the general RFC 5444 security draft, I agree. Yes, I agree with that. Ulrich From paul@marvell.com Wed Nov 25 16:10:17 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EF23A6819 for ; Wed, 25 Nov 2009 16:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-jl7wgWT6su for ; Wed, 25 Nov 2009 16:10:15 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id C4DEE3A67E3 for ; Wed, 25 Nov 2009 16:10:15 -0800 (PST) X-ASG-Debug-ID: 1259194210-692000d40000-Rp4q3q X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id 7C0661CDCA3; Wed, 25 Nov 2009 16:10:10 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id uoFaWrtK2Fft6iPv; Wed, 25 Nov 2009 16:10:10 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 65CBB80863; Wed, 25 Nov 2009 16:10:10 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 16:10:10 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Wed, 25 Nov 2009 16:10:09 -0800 From: Paul Lambert To: 'Ulrich Herberg' , "manet@ietf.org" , "T.Clausen@computer.org" Date: Wed, 25 Nov 2009 16:10:08 -0800 X-ASG-Orig-Subj: RE: [manet] Security drafts Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9A= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> In-Reply-To: <008a01ca66f9$e61c3aa0$b254afe0$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 00:10:10.0137 (UTC) FILETIME=[D13A8490:01CA6E2C] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1259194210 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:10:17 -0000 Please excuss the out-of sync comments on the security drafts ... I'm an in= frequent lurket on this list .... =20 On draft-herberg-manet-packetbb-sec-02 The Hash functions can be usefully truncated to smaller sizes than the bloc= k size. Are all 256 bits of SHA256 intended to be used (table 3)? If not = - Ids should be made for each size to prevent a hash truncation attack. | 3 | SHA256 | The hash function as specified in | | | | [SHA256] | On=20 9.2.3. Cryptographic Algorithm Registry Please remove 3DES it's a deprecated algorithm and should not be used. AES is not fully defined - are you intending to use a AES-CBC MIC? | 4 | 3DES | 3DES as specified in [3DES] | | 5 | AES | AES as specified in [AES] | It's also odd having the mix of public and symmetric key algorithms in the = same table. The properties are different. Not indicating the key distribu= tion methods leaves a big hole wrt PK usage. =20 Event the symmetric algorithm typically could use a "security association i= dentifier". If there is no identifier, the mapping of keys to addresses sh= ould be better defined. =20 Paul Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Teco Boot > Sent: Monday, November 16, 2009 12:18 PM > To: 'Ulrich Herberg'; manet@ietf.org > Subject: Re: [manet] Security drafts >=20 > Hi Ulrich, >=20 > I'll comment on sec-threats first. This would line out what needs > to be done. >=20 > At first, I would like to distinguish networks that have L2 protection > and those who have not. For the firsts, we could skip the whole thing. >=20 > Then, we want to know what to protect, and against who. Let's say we > have the good guys and the bad guys. The question is, do the bad guys > think the good guys are the bad guys? In other words, are there > multiple groups on the same medium? Do we want to separate those > with crypto? Or use some kind of identifier? >=20 > After more analysis of threats, I expect a demand for protecting packets, > not messages. Messages are updated along the path, only by the good guys. > For OLSR, there is only the hop-count and hop-limit being updated. For > DYMO, there is a lot more. Who knows what future brings. >=20 > Regards, Teco. >=20 >=20 > >-----Oorspronkelijk bericht----- > >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens > >Ulrich Herberg > >Verzonden: donderdag 12 november 2009 6:44 > >Aan: manet@ietf.org > >Onderwerp: [manet] Security drafts > > > >Hi, > > > >as mentioned during my presentation of security extensions to packetbb > >and NHDP, here are my drafts: > > > >http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02 > >http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt > >http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 > > > > > >Feel free to read them and give me comments. > > > >Thanks > >Ulrich > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Wed Nov 25 22:26:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A903A69E8 for ; Wed, 25 Nov 2009 22:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQv0IPGR2VA6 for ; Wed, 25 Nov 2009 22:26:12 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 546DD3A68E0 for ; Wed, 25 Nov 2009 22:26:12 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDXnn-0005qO-H1; Thu, 26 Nov 2009 07:26:03 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDXnm-0000OH-Px; Thu, 26 Nov 2009 07:26:03 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 26 Nov 2009 07:25:49 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2400245.IbCaDgzjcl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911260725.54631.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10078/Thu Nov 26 05:46:53 2009) by mailguard.fgan.de X-Scan-Signature: 4b38097bf486f81358d7b7391bab2582 Cc: "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:26:14 -0000 --nextPart2400245.IbCaDgzjcl Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 26 2009 01:10:08 Paul Lambert wrote: > Please excuss the out-of sync comments on the security drafts ... I'm an > infrequent lurket on this list .... On draft-herberg-manet-packetbb-sec-= 02 >=20 > The Hash functions can be usefully truncated to smaller sizes than the > block size. Are all 256 bits of SHA256 intended to be used (table 3)? = If > not - Ids should be made for each size to prevent a hash truncation > attack. >=20 > | 3 | SHA256 | The hash function as specified in | > | > | | | [SHA256] | I agree to this, the length of the truncated string would be in the length= =20 field of the TLV anyways. We only have to define that we store a prefix of = the=20 hash. > On > 9.2.3. Cryptographic Algorithm Registry >=20 > Please remove 3DES it's a deprecated algorithm and should not be used. 3DES should be nearly useless today, SHA1 should be faster. > AES is not fully defined - are you intending to use a AES-CBC MIC? > | 4 | 3DES | 3DES as specified in [3DES] | > | 5 | AES | AES as specified in [AES] | >=20 > It's also odd having the mix of public and symmetric key algorithms in the > same table. The properties are different. Not indicating the key > distribution methods leaves a big hole wrt PK usage. Key distribution is out of scope for the MANET WG I think. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart2400245.IbCaDgzjcl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksOH20ACgkQRIfGfFXsz+Bm8ACeOxmGuyKylrtl0gAZAPSwsQdy SdIAn2EW864p0t6TZUq72vk242HFsqTO =rxQK -----END PGP SIGNATURE----- --nextPart2400245.IbCaDgzjcl-- From Chris.Dearlove@baesystems.com Thu Nov 26 01:43:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F503A691D for ; Thu, 26 Nov 2009 01:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olT7s7mXlAfj for ; Thu, 26 Nov 2009 01:43:18 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 697933A685B for ; Thu, 26 Nov 2009 01:43:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,292,1257120000"; d="scan'208";a="35121222" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Nov 2009 09:43:08 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAQ9hGFT019385; Thu, 26 Nov 2009 09:43:16 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:43:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Nov 2009 09:43:02 -0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUA== References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> From: "Dearlove, Christopher (UK)" To: "Paul Lambert" , "Ulrich Herberg" , , X-OriginalArrivalTime: 26 Nov 2009 09:43:07.0836 (UTC) FILETIME=[DBEF17C0:01CA6E7C] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:43:19 -0000 > The Hash functions can be usefully truncated > to smaller sizes than the block size. If there's a well-defined way to truncate, then this could be done with no additional overhead if the type extension fully defines the untruncated size. Then the TLV length (of value) field could define the truncated size. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Nov 26 04:17:49 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8321C3A6964 for ; Thu, 26 Nov 2009 04:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MfUig5S8Qy9 for ; Thu, 26 Nov 2009 04:17:48 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 695D23A68FF for ; Thu, 26 Nov 2009 04:17:48 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDdI2-0004kL-KQ; Thu, 26 Nov 2009 13:17:38 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDdI2-00027w-BA; Thu, 26 Nov 2009 13:17:38 +0100 From: Henning Rogge To: manet@ietf.org Date: Thu, 26 Nov 2009 13:17:27 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1696539.o9ri59VM1C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911261317.32595.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10079/Thu Nov 26 06:55:07 2009) by mailguard.fgan.de X-Scan-Signature: 9cb3f381a8845856dbdf3f2e90234067 Cc: "Dearlove, Christopher \(UK\)" , T.Clausen@computer.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 12:17:49 -0000 --nextPart1696539.o9ri59VM1C Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu November 26 2009 10:43:02 Dearlove, Christopher (UK) wrote: > > The Hash functions can be usefully truncated > > to smaller sizes than the block size. >=20 > If there's a well-defined way to truncate, then this could > be done with no additional overhead if the type extension > fully defines the untruncated size. Then the TLV length > (of value) field could define the truncated size. In a good hash every byte should contain the same amount of information. So= =20 just using the prefix should be okay. It does not change the strength of th= e=20 hash function but increase the chance of random collisions. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1696539.o9ri59VM1C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksOcdcACgkQRIfGfFXsz+DMcgCfQosGujNEB4jEbLe5AaD4B6V7 FlYAn0Os0Xlxm+P9cUSdycf5j+Xrly9G =wWzU -----END PGP SIGNATURE----- --nextPart1696539.o9ri59VM1C-- From gumstix@scatechnica.com Sun Nov 29 19:13:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A550A3A6819 for ; Sun, 29 Nov 2009 19:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvyTjWWOLsns for ; Sun, 29 Nov 2009 19:13:40 -0800 (PST) Received: from defend3.alphahosting.com (defend3.alphahosting.com [206.126.97.8]) by core3.amsl.com (Postfix) with ESMTP id 8CDCA3A67B1 for ; Sun, 29 Nov 2009 19:13:40 -0800 (PST) X-Envelope-From: gumstix@scatechnica.com X-Envelope-To: henning.rogge@fkie.fraunhofer.de Received: From web.server.MX.relay.75.127.110.13-static.reverse.yourdnshost.com (75.127.110.13) by defend3.alphahosting.com (MAILFOUNDRY) id V0Uy4t1eEd6oXAAw; Mon, 30 Nov 2009 03:13:32 -0000 (GMT) Received: from c-66-31-66-176.hsd1.nh.comcast.net ([66.31.66.176]:38351 helo=gandalf.com) by www13.yourdnshost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NEwhg-00017Z-Js; Sun, 29 Nov 2009 22:13:32 -0500 Message-ID: <4B13385D.7070501@scatechnica.com> Date: Sun, 29 Nov 2009 22:13:33 -0500 From: Tony User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Henning Rogge References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <200911260725.54631.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911260725.54631.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: manet@ietf.org, "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 03:13:41 -0000 Henning Rogge wrote: > On Thu November 26 2009 01:10:08 Paul Lambert wrote: > >> On >> 9.2.3. Cryptographic Algorithm Registry >> >> Please remove 3DES it's a deprecated algorithm and should not be used. >> > 3DES should be nearly useless today, SHA1 should be faster. > SHA1, as of 2010, is no longer recommended by NIST; collisions were found reducing complexity. Md5 is no longer secure either. Tony Martin From ulrich@herberg.name Mon Nov 30 01:15:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6AB3A6824 for ; Mon, 30 Nov 2009 01:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oALmhDkYh1x0 for ; Mon, 30 Nov 2009 01:15:46 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 4F9553A63D3 for ; Mon, 30 Nov 2009 01:15:46 -0800 (PST) Received: by bwz23 with SMTP id 23so2405023bwz.29 for ; Mon, 30 Nov 2009 01:15:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.7.87 with SMTP id c23mr4243276bkc.97.1259572536334; Mon, 30 Nov 2009 01:15:36 -0800 (PST) In-Reply-To: <4B13385D.7070501@scatechnica.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <200911260725.54631.henning.rogge@fkie.fraunhofer.de> <4B13385D.7070501@scatechnica.com> Date: Mon, 30 Nov 2009 10:15:35 +0100 Message-ID: <25c114b90911300115x66a36affj2aac31b7d36d22e2@mail.gmail.com> From: Ulrich Herberg To: Tony Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 09:15:47 -0000 That's the advantage of the code point in the draft: signature algorithms can be easily removed or added. Thanks Tony for that information, we will consider that when updating the draft. Ulrich On Mon, Nov 30, 2009 at 4:13 AM, Tony wrote: > Henning Rogge wrote: >> On Thu November 26 2009 01:10:08 Paul Lambert wrote: >> >>> On >>> =A0 =A0 =A0 =A09.2.3. Cryptographic Algorithm Registry >>> >>> Please remove 3DES it's a deprecated algorithm and should not be used. >>> >> 3DES should be nearly useless today, SHA1 should be faster. >> > SHA1, as of 2010, is no longer recommended by NIST; collisions were > found reducing complexity. Md5 is no longer secure either. > > Tony Martin > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From paul@marvell.com Mon Nov 30 09:40:50 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794743A6967 for ; Mon, 30 Nov 2009 09:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU-BeUhqv+fo for ; Mon, 30 Nov 2009 09:40:49 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id BDD4E3A6959 for ; Mon, 30 Nov 2009 09:40:49 -0800 (PST) X-ASG-Debug-ID: 1259602842-1cc901790000-Rp4q3q X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id CAEF11E8C39; Mon, 30 Nov 2009 09:40:42 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id Yei0MhFqvecYUX0r; Mon, 30 Nov 2009 09:40:42 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id B455E808F8; Mon, 30 Nov 2009 09:40:42 -0800 (PST) Received: from sc-owa02.marvell.com ([10.93.76.22]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 09:40:42 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 30 Nov 2009 09:40:41 -0800 From: Paul Lambert To: "Dearlove, Christopher (UK)" , Ulrich Herberg , "manet@ietf.org" , "T.Clausen@computer.org" Date: Mon, 30 Nov 2009 09:40:39 -0800 X-ASG-Orig-Subj: RE: [manet] Security drafts Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 17:40:42.0348 (UTC) FILETIME=[3D01A2C0:01CA71E4] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1259602842 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:40:50 -0000 So, imagine a message is sent with a hash of length 256. It could be inter= cepted, and easily truncated to a length of 8. Both the hash and the lengt= h value could be changed. Hash truncation is not so much the issue as the = reduction in size - which would greatly reduce the search space for valid h= ash values. The definition requires at least a notion of the enforcement of a minimum a= cceptable hash size.=20 Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: Thursday, November 26, 2009 1:43 AM > To: Paul Lambert; Ulrich Herberg; manet@ietf.org; T.Clausen@computer.org > Subject: RE: [manet] Security drafts >=20 > > The Hash functions can be usefully truncated > > to smaller sizes than the block size. >=20 > If there's a well-defined way to truncate, then this could > be done with no additional overhead if the type extension > fully defines the untruncated size. Then the TLV length > (of value) field could define the truncated size. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** From teco@inf-net.nl Mon Nov 30 09:58:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C702D28C134 for ; Mon, 30 Nov 2009 09:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnN6WRYBtGlj for ; Mon, 30 Nov 2009 09:58:39 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9C92428C12C for ; Mon, 30 Nov 2009 09:58:37 -0800 (PST) Received: (qmail 8819 invoked from network); 30 Nov 2009 18:57:04 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 30 Nov 2009 18:57:04 +0100 From: "Teco Boot" To: "'Paul Lambert'" , "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" , , References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> Date: Mon, 30 Nov 2009 18:57:57 +0100 Message-ID: <004f01ca71e6$b805e010$2811a030$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAADIakA= Content-Language: nl Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:58:39 -0000 I had similar thoughts. Add type and length in hashed text? Teco. >-----Oorspronkelijk bericht----- >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Paul >Lambert >Verzonden: maandag 30 november 2009 18:41 >Aan: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; >T.Clausen@computer.org >Onderwerp: Re: [manet] Security drafts > > >So, imagine a message is sent with a hash of length 256. It could be >intercepted, and easily truncated to a length of 8. Both the hash and >the length value could be changed. Hash truncation is not so much the >issue as the reduction in size - which would greatly reduce the search >space for valid hash values. > >The definition requires at least a notion of the enforcement of a >minimum acceptable hash size. > >Paul > >Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 > >> -----Original Message----- >> From: Dearlove, Christopher (UK) >[mailto:Chris.Dearlove@baesystems.com] >> Sent: Thursday, November 26, 2009 1:43 AM >> To: Paul Lambert; Ulrich Herberg; manet@ietf.org; >T.Clausen@computer.org >> Subject: RE: [manet] Security drafts >> >> > The Hash functions can be usefully truncated >> > to smaller sizes than the block size. >> >> If there's a well-defined way to truncate, then this could >> be done with no additional overhead if the type extension >> fully defines the untruncated size. Then the TLV length >> (of value) field could define the truncated size. >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Nov 30 10:00:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4D53A692F for ; Mon, 30 Nov 2009 10:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+QSuEaU0HWE for ; Mon, 30 Nov 2009 10:00:13 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 23E3B3A690B for ; Mon, 30 Nov 2009 10:00:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,315,1257120000"; d="scan'208";a="35813399" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Nov 2009 18:00:02 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAUI093Z009611; Mon, 30 Nov 2009 18:00:10 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 18:00:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 17:59:00 -0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAABsnnA= References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> From: "Dearlove, Christopher (UK)" To: "Paul Lambert" , "Ulrich Herberg" , , X-OriginalArrivalTime: 30 Nov 2009 18:00:00.0839 (UTC) FILETIME=[EF855570:01CA71E6] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:00:14 -0000 There's a key issue here of how much is agreed between sender and recipient (and more widely, all the nodes in the MANET). In the applications I'm thinking of, which are about signing, not simply attaching a hash, the nodes will have pre-arranged some things (how is an issue I'm not getting into now) and that will actually probably make the specification of which algorithm, and what length, redundant in that it's pre-agreed. That's not to say those things shouldn't be included - but see my next paragraph - and the TLV value length is mandatory (RFC 5444, needed to parse). But there's no issue in those cases of the attacker doing what you suggest as that would fail the pre-arrangement, and hence be a (cheap) authentication failure. But other systems may be different (that's the whole point here) and so this might be an issue. But is the solution in this draft to specify limitations, or to specify that limitations will be needed, but those are administrative? A thought that arose typing the above. I think (meaning I don't have time to check right now) that type extension zero (which is the most efficient type) is allocated to "none". The above suggests to me that a possible type extension might be for "if this is for you, you know what it is". Should that have type extension 0? Or does type extension 255 (private use) allow this? --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com]=20 Sent: 30 November 2009 17:41 To: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; T.Clausen@computer.org Subject: RE: [manet] Security drafts *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. So, imagine a message is sent with a hash of length 256. It could be intercepted, and easily truncated to a length of 8. Both the hash and the length value could be changed. Hash truncation is not so much the issue as the reduction in size - which would greatly reduce the search space for valid hash values. The definition requires at least a notion of the enforcement of a minimum acceptable hash size.=20 Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: Thursday, November 26, 2009 1:43 AM > To: Paul Lambert; Ulrich Herberg; manet@ietf.org; T.Clausen@computer.org > Subject: RE: [manet] Security drafts >=20 > > The Hash functions can be usefully truncated > > to smaller sizes than the block size. >=20 > If there's a well-defined way to truncate, then this could > be done with no additional overhead if the type extension > fully defines the untruncated size. Then the TLV length > (of value) field could define the truncated size. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 30 10:04:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8153A63C9 for ; Mon, 30 Nov 2009 10:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiagSqbShsZX for ; Mon, 30 Nov 2009 10:04:11 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0EDF13A6916 for ; Mon, 30 Nov 2009 10:04:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,315,1257120000"; d="scan'208";a="35814426" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Nov 2009 18:04:04 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAUI4BWW011837; Mon, 30 Nov 2009 18:04:12 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 18:04:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 18:03:47 -0000 Message-ID: In-Reply-To: <004f01ca71e6$b805e010$2811a030$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAADIakAAABelIA== References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> <004f01ca71e6$b805e010$2811a030$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Paul Lambert" , "Ulrich Herberg" , , X-OriginalArrivalTime: 30 Nov 2009 18:04:03.0143 (UTC) FILETIME=[7FF1FD70:01CA71E7] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:04:12 -0000 Adding type and length in hashed text doesn't work. Or rather it does, but only if you add them in a separate TLV just for this purpose, and that's getting horrible,=20 or if you do some sort of really nasty process that involves something like a TLV that you add with a length field, duplicating that in the TLV value length, and otherwise zeros in the value field, then you hash etc., then you modify the TLV in situ. Reception is the opposite and even uglier. This is not the model in RFC 5444, or this draft. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot Sent: 30 November 2009 17:58 To: 'Paul Lambert'; Dearlove, Christopher (UK); 'Ulrich Herberg'; manet@ietf.org; T.Clausen@computer.org Subject: Re: [manet] Security drafts *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. I had similar thoughts. Add type and length in hashed text? Teco. >-----Oorspronkelijk bericht----- >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Paul >Lambert >Verzonden: maandag 30 november 2009 18:41 >Aan: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; >T.Clausen@computer.org >Onderwerp: Re: [manet] Security drafts > > >So, imagine a message is sent with a hash of length 256. It could be >intercepted, and easily truncated to a length of 8. Both the hash and >the length value could be changed. Hash truncation is not so much the >issue as the reduction in size - which would greatly reduce the search >space for valid hash values. > >The definition requires at least a notion of the enforcement of a >minimum acceptable hash size. > >Paul > >Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 > >> -----Original Message----- >> From: Dearlove, Christopher (UK) >[mailto:Chris.Dearlove@baesystems.com] >> Sent: Thursday, November 26, 2009 1:43 AM >> To: Paul Lambert; Ulrich Herberg; manet@ietf.org; >T.Clausen@computer.org >> Subject: RE: [manet] Security drafts >> >> > The Hash functions can be usefully truncated >> > to smaller sizes than the block size. >> >> If there's a well-defined way to truncate, then this could >> be done with no additional overhead if the type extension >> fully defines the untruncated size. Then the TLV length >> (of value) field could define the truncated size. >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From paul@marvell.com Mon Nov 30 10:04:58 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCF028C12C for ; Mon, 30 Nov 2009 10:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR1PabXQfEd6 for ; Mon, 30 Nov 2009 10:04:57 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id 867913A67D4 for ; Mon, 30 Nov 2009 10:04:57 -0800 (PST) X-ASG-Debug-ID: 1259604289-1cc902010000-Rp4q3q X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id B8BF51E5399; Mon, 30 Nov 2009 10:04:49 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id y7SnXf12Xh26DQBe; Mon, 30 Nov 2009 10:04:49 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id A64FD80925; Mon, 30 Nov 2009 10:04:49 -0800 (PST) Received: from sc-owa02.marvell.com ([10.93.76.22]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 10:04:49 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 30 Nov 2009 10:04:49 -0800 From: Paul Lambert To: Teco Boot , "'Dearlove, Christopher (UK)'" , 'Ulrich Herberg' , "manet@ietf.org" , "T.Clausen@computer.org" Date: Mon, 30 Nov 2009 10:04:47 -0800 X-ASG-Orig-Subj: RE: [manet] Security drafts Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAADIakAAAB/yIA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> <004f01ca71e6$b805e010$2811a030$@nl> In-Reply-To: <004f01ca71e6$b805e010$2811a030$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 18:04:49.0289 (UTC) FILETIME=[9B734F90:01CA71E7] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1259604289 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:04:58 -0000 I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64 bits) w= ould solve the problem. There is no need to have variable hash sizes. Add= ing the type and length into the has does not help if the length is reduce= d to 8. =20 There's a issue here also that some notion of the acceptable cipher suite i= s needed. It's normally part of the key management or "security associatio= n" setup. There's some type of negotiation that determines what algorithms= are acceptable. If the negotiation selects SHA-256 ... it should be of a = known hash size and not subject to variations. So, pinning down the hash l= enth as part of the "type" would hopefully eliminate this issue. Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Monday, November 30, 2009 9:58 AM > To: Paul Lambert; 'Dearlove, Christopher (UK)'; 'Ulrich Herberg'; > manet@ietf.org; T.Clausen@computer.org > Subject: RE: [manet] Security drafts >=20 > I had similar thoughts. Add type and length in hashed text? > Teco. >=20 > >-----Oorspronkelijk bericht----- > >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Paul > >Lambert > >Verzonden: maandag 30 november 2009 18:41 > >Aan: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; > >T.Clausen@computer.org > >Onderwerp: Re: [manet] Security drafts > > > > > >So, imagine a message is sent with a hash of length 256. It could be > >intercepted, and easily truncated to a length of 8. Both the hash and > >the length value could be changed. Hash truncation is not so much the > >issue as the reduction in size - which would greatly reduce the search > >space for valid hash values. > > > >The definition requires at least a notion of the enforcement of a > >minimum acceptable hash size. > > > >Paul > > > >Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 > > > >> -----Original Message----- > >> From: Dearlove, Christopher (UK) > >[mailto:Chris.Dearlove@baesystems.com] > >> Sent: Thursday, November 26, 2009 1:43 AM > >> To: Paul Lambert; Ulrich Herberg; manet@ietf.org; > >T.Clausen@computer.org > >> Subject: RE: [manet] Security drafts > >> > >> > The Hash functions can be usefully truncated > >> > to smaller sizes than the block size. > >> > >> If there's a well-defined way to truncate, then this could > >> be done with no additional overhead if the type extension > >> fully defines the untruncated size. Then the TLV length > >> (of value) field could define the truncated size. > >> > >> ******************************************************************** > >> This email and any attachments are confidential to the intended > >> recipient and may also be privileged. If you are not the intended > >> recipient please delete it from your system and notify the sender. > >> You should not copy it or use it for any purpose nor disclose or > >> distribute its contents to any other person. > >> ******************************************************************** > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www.ietf.org/mailman/listinfo/manet From paul@marvell.com Mon Nov 30 10:10:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861EF3A696E for ; Mon, 30 Nov 2009 10:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y4MKf+Jjc8g for ; Mon, 30 Nov 2009 10:10:13 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id 9978E28C11F for ; Mon, 30 Nov 2009 10:10:13 -0800 (PST) X-ASG-Debug-ID: 1259604606-1cc9021a0000-Rp4q3q X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id A06331CBBE0; Mon, 30 Nov 2009 10:10:06 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id MxY04iRAZDnR9bag; Mon, 30 Nov 2009 10:10:06 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 8726980925; Mon, 30 Nov 2009 10:10:06 -0800 (PST) Received: from sc-owa02.marvell.com ([10.93.76.22]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 10:10:06 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 30 Nov 2009 10:10:06 -0800 From: Paul Lambert To: "Dearlove, Christopher (UK)" , Ulrich Herberg , "manet@ietf.org" , "T.Clausen@computer.org" Date: Mon, 30 Nov 2009 10:10:04 -0800 X-ASG-Orig-Subj: RE: [manet] Security drafts Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAABsnnAAALgd8A== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3D@SC-VEXCH2.marvell.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 18:10:06.0142 (UTC) FILETIME=[584F3DE0:01CA71E8] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1259604606 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:10:14 -0000 =20 > A thought that arose typing the above. I think (meaning I don't > have time to check right now) that type extension zero (which > is the most efficient type) is allocated to "none". The above > suggests to me that a possible type extension might be for > "if this is for you, you know what it is". Should that have > type extension 0? Or does type extension 255 (private use) > allow this? > Hummm ... this is actually a better process than having an explicit algorit= hm. It's a little confusing in this specification - but it better represen= ts how this would interact with any form of key management. Basically - th= e signatures, hashes and all algorithms are determine before hand ... and e= ach side should know what is expected. Ideally there would only be a ident= ifier providing the context of this pre-agreement (akin to the an SAID or S= PI in IPsec). Paul > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: Paul Lambert [mailto:paul@marvell.com] > Sent: 30 November 2009 17:41 > To: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; > T.Clausen@computer.org > Subject: RE: [manet] Security drafts >=20 >=20 > *** WARNING *** >=20 > This message has originated outside your organisation, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. >=20 >=20 > So, imagine a message is sent with a hash of length 256. It could be > intercepted, and easily truncated to a length of 8. Both the hash and > the length value could be changed. Hash truncation is not so much the > issue as the reduction in size - which would greatly reduce the search > space for valid hash values. >=20 > The definition requires at least a notion of the enforcement of a > minimum acceptable hash size. >=20 > Paul >=20 > Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 >=20 > > -----Original Message----- > > From: Dearlove, Christopher (UK) > [mailto:Chris.Dearlove@baesystems.com] > > Sent: Thursday, November 26, 2009 1:43 AM > > To: Paul Lambert; Ulrich Herberg; manet@ietf.org; > T.Clausen@computer.org > > Subject: RE: [manet] Security drafts > > > > > The Hash functions can be usefully truncated > > > to smaller sizes than the block size. > > > > If there's a well-defined way to truncate, then this could > > be done with no additional overhead if the type extension > > fully defines the untruncated size. Then the TLV length > > (of value) field could define the truncated size. > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** >=20 From hrogge@googlemail.com Mon Nov 30 10:11:24 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFEB28C177 for ; Mon, 30 Nov 2009 10:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXNjTBoFLOIl for ; Mon, 30 Nov 2009 10:11:23 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id DE96828C17F for ; Mon, 30 Nov 2009 10:11:22 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so944669eyf.51 for ; Mon, 30 Nov 2009 10:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=7CHX+42erbar8ipUrNVxGCjmfzpZqqPh58mrtnGzysw=; b=NdSGTEi54T6m/Iw9fa02ZUEWrfmFEEpLczdz1cNRf0vi2HrNSOCQwjIGbhmYm8NtX5 EqtlVhrpkc7fb59Qiu64b7V+QxqXvfin70bt9IJ7pAXz8brWn1Y0bD0QI02XMIzc8Z2w yBcPivBV1fRfpyOFO3S83zNxex1N4dH82IwxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=a+J0cAivV37BJUHTzTZY4zY6QICo1Mo686gWYqdmNIEQSAsNZ21pqt7AuT1kQWL+4w 1MpnZ0KWg0oYcWFKrjLfMZowEBBmtz786W9EooeEKl/Djp8dzB8HVxQMc2qFq1JiGOXP RAMNqnP/Q3PfUdnr4dy5gexAjiPJMOd4Grc+8= Received: by 10.213.24.24 with SMTP id t24mr4949537ebb.16.1259604672664; Mon, 30 Nov 2009 10:11:12 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 16sm2648657ewy.2.2009.11.30.10.11.10 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 10:11:10 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Mon, 30 Nov 2009 19:10:59 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <004f01ca71e6$b805e010$2811a030$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3511416.xineDCq6lJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911301911.04812.hrogge@googlemail.com> Cc: "'Dearlove, Christopher \(UK\)'" , "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:11:25 -0000 --nextPart3511416.xineDCq6lJ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 30 November 2009 19:04:47 schrieb Paul Lambert: > I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64 bits) > would solve the problem. There is no need to have variable hash sizes.= =20 > Adding the type and length into the has does not help if the length is > reduced to 8. Yes, there is a reason. Sometimes it can be better to have a short has if you need lot's of them.=20 Taking the first FOUR bytes from a SHA-256 will protect you against all=20 attacks better than guessing (1 to 2^32), so it could be more than enough f= or=20 shortlived routing packages. =20 > There's a issue here also that some notion of the acceptable cipher suite > is needed. It's normally part of the key management or "security > association" setup. There's some type of negotiation that determines wh= at > algorithms are acceptable. If the negotiation selects SHA-256 ... it > should be of a known hash size and not subject to variations. So, pinni= ng > down the hash lenth as part of the "type" would hopefully eliminate this > issue. I think what algorithm you use and what length of it you use it in the scop= e=20 of the protocol... if we define that we always take the has prefix, even=20 different implementations can talk with each other. And you can always add = a=20 "check if hash is long enough for my security policy" if you need it. Henning --nextPart3511416.xineDCq6lJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksUCrgACgkQcenvcwAcHWc0VgCeKh3E1o9jMs2kwW8z8C6tE8n9 nYcAn30a9G1bymteAkFTMLcoajyfN5ta =0nkJ -----END PGP SIGNATURE----- --nextPart3511416.xineDCq6lJ-- From Chris.Dearlove@baesystems.com Mon Nov 30 10:12:36 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED5B28C170 for ; Mon, 30 Nov 2009 10:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKIp0+Vas8OE for ; Mon, 30 Nov 2009 10:12:26 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id A6C9628C177 for ; Mon, 30 Nov 2009 10:12:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,315,1257120000"; d="scan'208";a="35815569" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Nov 2009 18:12:06 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAUICEuV015852; Mon, 30 Nov 2009 18:12:15 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 18:12:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 18:11:46 -0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpjWx8xHDtiv0n7R0+LxIhMc/6AXQDm3aawAc1Ee9AAFCfhUADZwyPgAADIakAAAB/yIAAARU1w References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl><7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> <004f01ca71e6$b805e010$2811a030$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> From: "Dearlove, Christopher (UK)" To: "Paul Lambert" , "Teco Boot" , "Ulrich Herberg" , , X-OriginalArrivalTime: 30 Nov 2009 18:12:05.0803 (UTC) FILETIME=[9FA20FB0:01CA71E8] Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:12:37 -0000 Actually there's another issue, to do with that the TLV=20 value length isn't the hash length, it's the signature length, and the hash length and signature length don't have to be equal. So - possibly in contradiction to an earlier email of mine - you need to include the hash length, probably in the type extension specifying the hash. It is clear that a proper specification of a good set of algorithms, pinning down their options, is needed. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com]=20 Sent: 30 November 2009 18:05 To: Teco Boot; Dearlove, Christopher (UK); 'Ulrich Herberg'; manet@ietf.org; T.Clausen@computer.org Subject: RE: [manet] Security drafts *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64 bits) would solve the problem. There is no need to have variable hash sizes. Adding the type and length into the has does not help if the length is reduced to 8. =20 There's a issue here also that some notion of the acceptable cipher suite is needed. It's normally part of the key management or "security association" setup. There's some type of negotiation that determines what algorithms are acceptable. If the negotiation selects SHA-256 ... it should be of a known hash size and not subject to variations. So, pinning down the hash lenth as part of the "type" would hopefully eliminate this issue. Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Monday, November 30, 2009 9:58 AM > To: Paul Lambert; 'Dearlove, Christopher (UK)'; 'Ulrich Herberg'; > manet@ietf.org; T.Clausen@computer.org > Subject: RE: [manet] Security drafts >=20 > I had similar thoughts. Add type and length in hashed text? > Teco. >=20 > >-----Oorspronkelijk bericht----- > >Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Paul > >Lambert > >Verzonden: maandag 30 november 2009 18:41 > >Aan: Dearlove, Christopher (UK); Ulrich Herberg; manet@ietf.org; > >T.Clausen@computer.org > >Onderwerp: Re: [manet] Security drafts > > > > > >So, imagine a message is sent with a hash of length 256. It could be > >intercepted, and easily truncated to a length of 8. Both the hash and > >the length value could be changed. Hash truncation is not so much the > >issue as the reduction in size - which would greatly reduce the search > >space for valid hash values. > > > >The definition requires at least a notion of the enforcement of a > >minimum acceptable hash size. > > > >Paul > > > >Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 > > > >> -----Original Message----- > >> From: Dearlove, Christopher (UK) > >[mailto:Chris.Dearlove@baesystems.com] > >> Sent: Thursday, November 26, 2009 1:43 AM > >> To: Paul Lambert; Ulrich Herberg; manet@ietf.org; > >T.Clausen@computer.org > >> Subject: RE: [manet] Security drafts > >> > >> > The Hash functions can be usefully truncated > >> > to smaller sizes than the block size. > >> > >> If there's a well-defined way to truncate, then this could > >> be done with no additional overhead if the type extension > >> fully defines the untruncated size. Then the TLV length > >> (of value) field could define the truncated size. > >> > >> ******************************************************************** > >> This email and any attachments are confidential to the intended > >> recipient and may also be privileged. If you are not the intended > >> recipient please delete it from your system and notify the sender. > >> You should not copy it or use it for any purpose nor disclose or > >> distribute its contents to any other person. > >> ******************************************************************** > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Nov 30 10:14:51 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B39A28C139 for ; Mon, 30 Nov 2009 10:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efz2nf2FMY-0 for ; Mon, 30 Nov 2009 10:14:50 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id CC50E3A696E for ; Mon, 30 Nov 2009 10:14:49 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so945419eyf.51 for ; Mon, 30 Nov 2009 10:14:38 -0800 (PST) Received: by 10.213.2.70 with SMTP id 6mr5201349ebi.30.1259604875844; Mon, 30 Nov 2009 10:14:35 -0800 (PST) Received: from phoenix-mac.local (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id 15sm2654641ewy.4.2009.11.30.10.14.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 10:14:31 -0800 (PST) Message-ID: <4B140B84.2050506@herberg.name> Date: Mon, 30 Nov 2009 19:14:28 +0100 From: Ulrich Herberg User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Lambert References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com><008a01ca66f9$e61c3aa0$b254afe0$@nl> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBA87E@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB1F@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3D@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3D@SC-VEXCH2.marvell.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/alternative; boundary="------------080707080100060401070208" Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:14:51 -0000 This is a multi-part message in MIME format. --------------080707080100060401070208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul Lambert wrote: > > >> A thought that arose typing the above. I think (meaning I don't >> have time to check right now) that type extension zero (which >> is the most efficient type) is allocated to "none". The above >> suggests to me that a possible type extension might be for >> "if this is for you, you know what it is". Should that have >> type extension 0? Or does type extension 255 (private use) >> allow this? >> >> > > Hummm ... this is actually a better process than having an explicit algorithm. It's a little confusing in this specification - but it better represents how this would interact with any form of key management. Basically - the signatures, hashes and all algorithms are determine before hand ... and each side should know what is expected. > [...] > Yes, exactly. All parameters have to be exchanged or set before (e.g. hash length, keys, etc.). We will work on the text of the draft to make that clearer. Ulrich --------------080707080100060401070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Paul Lambert wrote: 
 
  
A thought that arose typing the above. I think (meaning I don't
have time to check right now) that type extension zero (which
is the most efficient type) is allocated to "none". The above
suggests to me that a possible type extension might be for
"if this is for you, you know what it is". Should that have
type extension 0? Or does type extension 255 (private use)
allow this?

    

Hummm ... this is actually a better process than having an explicit algorithm.  It's a little confusing in this specification - but it better represents how this would interact with any form of key management.  Basically - the signatures, hashes and all algorithms are determine before hand ... and each side should know what is expected. 
[...]

Yes, exactly. All parameters have to be exchanged or set before (e.g. hash length, keys, etc.). We will work on the text of the draft to make that clearer.

Ulrich


--------------080707080100060401070208-- From henning.rogge@fkie.fraunhofer.de Mon Nov 30 22:26:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135B63A6AF8 for ; Mon, 30 Nov 2009 22:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce4EmnWLBa12 for ; Mon, 30 Nov 2009 22:26:46 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id CE6013A6834 for ; Mon, 30 Nov 2009 22:26:45 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NFMBz-0000bZ-FG; Tue, 01 Dec 2009 07:26:31 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NFMBz-0004sf-5z; Tue, 01 Dec 2009 07:26:31 +0100 From: Henning Rogge To: manet@ietf.org Date: Tue, 1 Dec 2009 07:26:18 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6299959.gENWv2n9xR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912010726.28014.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10098/Tue Dec 1 04:06:27 2009) by mailguard.fgan.de X-Scan-Signature: 0f287e88b12fb29766ba98e7b870a51f Cc: "Dearlove, Christopher \(UK\)" , T.Clausen@computer.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 06:26:47 -0000 --nextPart6299959.gENWv2n9xR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 30 2009 19:11:46 Dearlove, Christopher (UK) wrote: > Actually there's another issue, to do with that the TLV > value length isn't the hash length, it's the signature > length, and the hash length and signature length don't > have to be equal. So - possibly in contradiction to an > earlier email of mine - you need to include the hash > length, probably in the type extension specifying the > hash. >=20 > It is clear that a proper specification of a good set > of algorithms, pinning down their options, is needed. So maybe a TLV extension type should specify a hash algorithm and the hash= =20 output length ? It can be even worse, because we combine a hash function and an encryption= =20 function. So we need to know the length of the hash output, must define if = it's=20 padded or shortened before it's pushed into the encryption function, then w= e=20 have to know the output size of the encryption function and again do have t= o=20 decide if we shorten or pad the final TLV data. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart6299959.gENWv2n9xR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksUtwoACgkQRIfGfFXsz+Bs0wCdHKsTqpieGrguOTNFzrfthOal GU4An1WqPBGIq/zqdoidVuYJUTYV+IyF =t3Zo -----END PGP SIGNATURE----- --nextPart6299959.gENWv2n9xR--