From abdussalambaryun@gmail.com Thu Feb 28 23:24:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CB021F87EE for ; Thu, 28 Feb 2013 23:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPNWC7nNX-HI for ; Thu, 28 Feb 2013 23:24:04 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 894DE11E80A2 for ; Thu, 28 Feb 2013 23:24:04 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id ro8so1589187pbb.4 for ; Thu, 28 Feb 2013 23:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HynCEE9uPKy3TlY0TkDRXqDQlWxzo/51w+1REtlNxdY=; b=RQ8T1YGcHDHiCpq3f3eiBAE1GfXZyKKZo+TOpAKKT70s33bT8NkpGJbtLhFLQYsZya fOxEkvGDcisd8muDzbuihhE9qcBERNwLAu3v8TXTQhOobn8UKOHpKvuXCEawhzNB6uSD 7e6Qj6KrLQg26qI4KtLy6WiLjzoIzsY3Kl48kCT9o5FONDuV8G2yJjKbg/uyZI56Ix4s yRPdJAF+BI2L/rhi5cKjs9GgvkiyOr66Cosxk8mPZXLIqRemScY2cLV1lRYuyMHTzdYk tVJnS/SvD9JdWK50AHgr0Cz1I6fHZlw7BFeU6g6TSPj08FAiLgQCv6hYxv+HuaBlse/r I6nQ== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr13134251pbc.163.1362122641666; Thu, 28 Feb 2013 23:24:01 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 23:24:01 -0800 (PST) In-Reply-To: <20130225151705.EB129B1E008@rfc-editor.org> References: <20130225151705.EB129B1E008@rfc-editor.org> Date: Fri, 1 Mar 2013 08:24:01 +0100 Message-ID: From: Abdussalam Baryun To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 01 Mar 2013 00:06:57 -0800 Cc: macker@itd.nrl.navy.mil, T.Clausen@computer.org, chris.dearlove@baesystems.com, manet@ietf.org, Cedric.Adjih@inria.fr, sratliff@cisco.com, jdean@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:24:05 -0000 I *reject* the proposal (but agree with change needed for update), because I read the way of errata-review as mentioned in IETF guide, Rejected - The erratum is in error, or proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list. Please in future guide participants of the special way of review/respond/judge, because it is first time for me, I was not familiar to this, AB On 2/25/13, RFC Errata System wrote: > > The following errata report has been submitted for RFC5444, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: Appendix A > > Original Text > ------------- > 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. > > > Corrected Text > -------------- > o The field, if present, contains a sequence number > that SHOULD be maintained for each participating interface and > incremented by 1 for each packet generated by a node for that > interface. The sequence number after 65535 is 0. In other words, > the sequence number "wraps" in the usual way. > > > Notes > ----- > Packet sequence number should be per interface, not per node. Uses that > recognise missing packet sequence numbers only work in the corrected > (intended) case. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) > Packet/Message Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From hrogge@googlemail.com Fri Mar 1 00:13:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4AC21F8984 for ; Fri, 1 Mar 2013 00:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlnGV76F8kOE for ; Fri, 1 Mar 2013 00:13:27 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1692821F8964 for ; Fri, 1 Mar 2013 00:13:26 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so2067450lbj.31 for ; Fri, 01 Mar 2013 00:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0c1EBFcRVRWtFBlYSWHsyVFGa327AUEUEmF91f3ZcXg=; b=uVu1Z9vConK3HU1dP7+og5cArA/xybNI+LgLYVyBgWaA4yUBpVF7RhzmbsS63WEixj yiczRs3Wd5A1Y+DykVYRnuIyjm69GJxv884hmJSsb3CILuuSCwYueOwkVYfZWRlFRiop J1+1qdnzfhJhaTwumGmSXF/pGVVTHlhzwpQjptBh+BfdnwLgk2EamQmiSTVZxp/JgB7q MPeKkx5yolupGJxQ491FK1PJJljBlSOHOfxuZk1s2axFcBRDp5RbeEUXu9Bg3IAdh5KC 6RA9NtWZN1nIqvpC42CGwFPBMup7VrzLC91mbzOdjZTSarH6qoNxrxqmScDmIJOQP7qd KMMw== X-Received: by 10.112.51.44 with SMTP id h12mr378957lbo.111.1362125606020; Fri, 01 Mar 2013 00:13:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Fri, 1 Mar 2013 00:13:05 -0800 (PST) In-Reply-To: References: <20130225151705.EB129B1E008@rfc-editor.org> From: Henning Rogge Date: Fri, 1 Mar 2013 09:13:05 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: T.Clausen@computer.org, chris.dearlove@baesystems.com, manet@ietf.org, Cedric.Adjih@inria.fr, sratliff@cisco.com, macker@itd.nrl.navy.mil, jdean@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:13:28 -0000 Luckily I think you are pretty alone with this opinion. The way the packet sequence numbers were described was definitely a mistake. I don't think anyone who USED packet sequence numbers with RFC5444 has used them in this way. In addition to this there was no protocol which included usage of the packet sequence number... except maybe RFC 6130, but the usage described in the RFC would NOT work unless we include this errata. Henning Rogge On Fri, Mar 1, 2013 at 8:24 AM, Abdussalam Baryun wrote: > I *reject* the proposal (but agree with change needed for update), > because I read the way of errata-review as mentioned in IETF guide, > > Rejected - The erratum is in error, or proposes a change to the RFC > that should be done by publishing a new RFC that replaces the current > RFC. In the latter case, if the change is to be considered for future > updates of the document, it should be proposed using channels other > than the errata process, such as a WG mailing list. > > Please in future guide participants of the special way of > review/respond/judge, because it is first time for me, I was not > familiar to this, > > AB > > On 2/25/13, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC5444, >> "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 >> >> -------------------------------------- >> Type: Technical >> Reported by: Christopher Dearlove >> >> Section: Appendix A >> >> Original Text >> ------------- >> 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. >> >> >> Corrected Text >> -------------- >> o The field, if present, contains a sequence number >> that SHOULD be maintained for each participating interface and >> incremented by 1 for each packet generated by a node for that >> interface. The sequence number after 65535 is 0. In other words, >> the sequence number "wraps" in the usual way. >> >> >> Notes >> ----- >> Packet sequence number should be per interface, not per node. Uses that >> recognise missing packet sequence numbers only work in the corrected >> (intended) case. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5444 (draft-ietf-manet-packetbb-17) >> -------------------------------------- >> Title : Generalized Mobile Ad Hoc Network (MANET) >> Packet/Message Format >> Publication Date : February 2009 >> Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih >> Category : PROPOSED STANDARD >> Source : Mobile Ad-hoc Networks >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hrogge@googlemail.com Fri Mar 1 00:14:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5521F8988 for ; Fri, 1 Mar 2013 00:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I42B-RlS6Geg for ; Fri, 1 Mar 2013 00:14:23 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3824921F8964 for ; Fri, 1 Mar 2013 00:14:19 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so2620069lab.25 for ; Fri, 01 Mar 2013 00:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tHKcqWXq5VTeYK2iG6/NQ8aQwSrgb+PYzZmHVVMV22w=; b=r7Y+oUUAur9LXyggDCCW5aWSE6xIDfmpPEZylwPCaH9wJj9xMZeKUQ5nUTR7bEOu2M 7l786KFW4GuF+8+PKROa6L4Zlcmd1FWscKyRTJFd26yyheMJRl3nEZNRkF8mWROp5ZPj 4MxRXB3zkvDJyTZ/20Dg0P7mDJOF//83IvphjePLhknkvPXh7QqtQuSPTbG+GVVdd8Z7 HFH1YKjn39UQOZc+sC4jpM1JK/DsSSJDdQg8iMizavvGWV1USxhtc7OEs7VHItR0WR0e /iQZWZapsQ5jzahXDalIp1GYgp+N5iIrUfwZ5BaKNPNH14p4Fi+AI+5A3gZ8Rm30EFih jCOA== X-Received: by 10.112.88.9 with SMTP id bc9mr424196lbb.22.1362125658173; Fri, 01 Mar 2013 00:14:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Fri, 1 Mar 2013 00:13:58 -0800 (PST) In-Reply-To: References: <066.1f1dc1e7a958c726a83d410656ac5449@trac.tools.ietf.org> From: Henning Rogge Date: Fri, 1 Mar 2013 09:13:58 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] #18: NHDP Sequence Number Threat X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:14:24 -0000 No, we don't. Because the usage hinted in RFC6130 depends on the errata, it will not work right without it. Henning Rogge On Fri, Mar 1, 2013 at 7:51 AM, Abdussalam Baryun wrote: > I think as related to this ticket about NHDP-interface sequence > number, three errata (two technical and one editorials) were posted > later [1] [2] [3]. If we change RFC5444 related to interfaces info, > then we will need to change RFC6130. Why it was it not mentioned the > packet sequence number maintained in RFC6130-NHDP and how, or why not > as NHDP sequence number? I may need to prapare an update about NHDP > information which is different from threats of NHDP. > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg15025.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg15026.html > [3] http://www.ietf.org/mail-archive/web/manet/current/msg15058.html > > AB > > On Mon, Feb 25, 2013 at 7:40 AM, manet issue tracker < > trac+manet@trac.tools.ietf.org> wrote: > >> #18: NHDP Sequence Number Threat >> >> I don't know how the sequence number section was ignored/deleted in the >> updated draft but would like to advise to include as per the below input >> discussions. >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13286.html >> >> http://www.ietf.org/mail-archive/web/manet/current/msg15004.html >> >> http://www.ietf.org/mail-archive/web/manet/current/msg15006.html >> >> The attack to sequence number of packets/messages may make changes into >> NHDP and routing. If you disagree please discuss, >> >> Regards >> AB >> >> -- >> ----------------------------------------+------------------------------- >> Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun >> Type: enhancement | Status: new >> Priority: major | Milestone: milestone1 >> Component: nhdp-sec-threats | Version: 1.0 >> Severity: In WG Last Call | Keywords: NHDP >> ----------------------------------------+------------------------------- >> >> Ticket URL: >> manet >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From adrian@olddog.co.uk Fri Mar 1 03:31:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE221F8726 for ; Fri, 1 Mar 2013 03:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHKiKeAdnzbE for ; Fri, 1 Mar 2013 03:31:08 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id DE54121F86D5 for ; Fri, 1 Mar 2013 03:31:07 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BV1ZO004337; Fri, 1 Mar 2013 11:31:01 GMT Received: from 950129200 (089144192049.atnat0001.highway.a1.net [89.144.192.49]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BUv3U004309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 11:31:00 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'manet'" References: <20130225151705.EB129B1E008@rfc-editor.org> In-Reply-To: Date: Fri, 1 Mar 2013 11:30:59 -0000 Message-ID: <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWyZ6xa8bXu4rMTag2AY499DrM3wE1cC9gmHWe4IA= Content-Language: en-gb Cc: chris.dearlove@baesystems.com Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:31:08 -0000 > > Corrected Text > > -------------- > > o The field, if present, contains a sequence number > > that SHOULD be maintained for each participating interface and > > incremented by 1 for each packet generated by a node for that > > interface. The sequence number after 65535 is 0. In other words, > > the sequence number "wraps" in the usual way. > > > > what you mean by *participating interface* do you mean NHDP-RFC6130, > how does the interface maintain such number? is there an answer in any > MANET doc? Erm, a "participating interface" is one that is participating in this RFC. How does an interface maintain a sequence number? That is an implementation detail. We don't write implementation specs. Most people use registers, variables, or other forms of storage. I knew a vendor that tired to use pixie dust, but they went Chapter 11. > Why you say SHOULD not MUST, or RECOMMENDED, please advise, RECOMMENDED would equate to SHOULD so there is no question there. I admit I shuffled my feet over the inclusion of a new 2119 word through this Errata Report. My thinking was that this is what everyone is doing in their implementations and it is clearly what was intended. It is not mandatory to maintain the counter in this way and there may be implementation reasons for doing something different. However, doing it different will reduce the functionality achieved through the use of the sequence number. Adrian From adrian@olddog.co.uk Fri Mar 1 03:31:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460A021F86D5 for ; Fri, 1 Mar 2013 03:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg9cc8l59+Se for ; Fri, 1 Mar 2013 03:31:08 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8251F21F8700 for ; Fri, 1 Mar 2013 03:31:08 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BV3AS004343; Fri, 1 Mar 2013 11:31:03 GMT Received: from 950129200 (089144192049.atnat0001.highway.a1.net [89.144.192.49]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BUv3V004309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 11:31:01 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , References: <20130226132309.97678B1E006@rfc-editor.org> In-Reply-To: Date: Fri, 1 Mar 2013 11:30:59 -0000 Message-ID: <008501ce1670$429df740$c7d9e5c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEkYAddi4PNnYjAc25anqyC5AbmgJAoYTjmJG1XcA= Content-Language: en-gb Cc: elloyd@udel.edu, 'RFC Errata System' , macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:31:09 -0000 "any" is correct English and appears in the text that has been approved in the Errata Report > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 01 March 2013 04:43 > To: manet@ietf.org > Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; > sratliff@cisco.com; elloyd@udel.edu; RFC Errata System > Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) > > > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > > "x", > > select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > AB>edit> > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > "n", select "n" as an MPR: > > A. Add "n" to the set "MPR" and remove "n" from "N1". > > B. For each interface "z" in "N2(w)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove all interfaces in > "N2(w)" from "N2(y)". > > In your errata proposal for the point 7-C please advise do you mean > *any* or *ALL*, because any may mean one only but all is a must for > all that are in N2(w) to be removed. I think you mean all, > > Please discuss, or advise, > > AB From adrian@olddog.co.uk Fri Mar 1 03:31:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140D21F89B2 for ; Fri, 1 Mar 2013 03:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSQOnT3aE+Sk for ; Fri, 1 Mar 2013 03:31:09 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7925C21F86D5 for ; Fri, 1 Mar 2013 03:31:09 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BV4X8004355; Fri, 1 Mar 2013 11:31:04 GMT Received: from 950129200 (089144192049.atnat0001.highway.a1.net [89.144.192.49]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BUv3W004309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 11:31:03 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'manet'" References: <20130226132309.97678B1E006@rfc-editor.org> In-Reply-To: Date: Fri, 1 Mar 2013 11:30:59 -0000 Message-ID: <008601ce1670$436a9610$ca3fc230$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEkYAddi4PNnYjAc25anqyC5AbmgGPV2H1mJc+5+A= Content-Language: en-gb Cc: elloyd@udel.edu, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:31:10 -0000 In my view the new text in 7 is clear on the meaning of x. No further change is needed. I have already approved the Errata Report. Adrian > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 01 March 2013 03:19 > To: manet > Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; > sratliff@cisco.com; elloyd@udel.edu > Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) > > The *x* in the line 7 is different to others, it was interface, then > became memebr of an interface, > > AB>edit> replace *x* in 7 to *n* > > (still not complete the review check of RFC6621, this thread does not > include a last date for review) > AB > > On 2/26/13, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC6621, > > "Simplified Multicast Forwarding". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3499 > > > > -------------------------------------- > > Type: Technical > > Reported by: Errol Lloyd > > > > Section: B.4. > > > > Original Text > > ------------- > > 1. Initialize the set "MPR" to empty. > > > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > > "n0" and any routers in "N1". Nodes that are only reachable via > > "N1" routers with router priority values of NEVER are also > > excluded. > > > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > > include any interfaces in "N2" that are 1-hop neighbors of "y". > > > > 5. For each interface "x" in "N1" with a router priority value of > > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > > include any interfaces in "N1" that are 1-hop neighbors of "z". > > > > 7. For each interface "x" in "N2" where "N1(x)" has only one member, > > select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2" and > > delete "N1(z)". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 8. While "N2" is not empty, select the interface "x" in "N1" with > > the largest router priority that has the number of members in > > "N_2(x)" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > > > > > > > > > Corrected Text > > -------------- > > 1. Initialize the set "MPR" to empty. > > > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > > "n0" and any routers in "N1". Nodes that are only reachable via > > "N1" routers with router priority values of NEVER are also > > excluded. > > > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > > include any interfaces in "N2" that are 1-hop neighbors of "y". > > > > 5. For each interface "x" in "N1" with a router priority value of > > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > > include any interfaces in "N1" that are 1-hop neighbors of "z". > > > > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > > "x", > > select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 8. While "N2" is not empty, select the interface "x" in "N1" with > > the highest router priority [break ties in favor of the node with the > > > > largest number of members in "N_2(x)"] as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > > > > > > > > > Notes > > ----- > > There are three changes: > > > > On line 7, the first and second occurrences of x are replaced by w, and then > > x is given as the name of the sole member of N1(w). > > > > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with the > > rest of the algorithm. > > > > On line 8 some rewording is done for clarification. > > > > This errata prepared in consultation with Justin Dean and Gus Macker. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6621 (draft-ietf-manet-smf-14) > > -------------------------------------- > > Title : Simplified Multicast Forwarding > > Publication Date : May 2012 > > Author(s) : J. Macker, Ed. > > Category : EXPERIMENTAL > > Source : Mobile Ad-hoc Networks > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > From adrian@olddog.co.uk Fri Mar 1 03:35:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7021F84B2 for ; Fri, 1 Mar 2013 03:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDk03EhaJZfv for ; Fri, 1 Mar 2013 03:35:21 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 028D121F84AB for ; Fri, 1 Mar 2013 03:35:20 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BZJBb008755 for ; Fri, 1 Mar 2013 11:35:19 GMT Received: from 950129200 (089144192049.atnat0001.highway.a1.net [89.144.192.49]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r21BZGd1008668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Mar 2013 11:35:19 GMT From: "Adrian Farrel" To: References: <20130225151705.EB129B1E008@rfc-editor.org> In-Reply-To: Date: Fri, 1 Mar 2013 11:35:18 -0000 Message-ID: <009b01ce1670$db9d4b30$92d7e190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWyZ6xa8bXu4rMTag2AY499DrM3wHzNwznmG+x95CAAAKf4A== Content-Language: en-gb Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:35:21 -0000 Resend just to the mailing list > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 01 March 2013 11:31 > To: 'Abdussalam Baryun'; 'RFC Errata System' > Cc: 'T.Clausen@computer.org'; 'chris.dearlove@baesystems.com'; > 'jdean@itd.nrl.navy.mil'; 'Cedric.Adjih@inria.fr'; 'stbryant@cisco.com'; > 'sratliff@cisco.com'; 'macker@itd.nrl.navy.mil'; 'manet@ietf.org' > Subject: RE: [manet] [Technical Errata Reported] RFC5444 (3496) > > Hi, > > > I *reject* the proposal (but agree with change needed for update), > > Thanks, but you are not in a position to reject or approve anything here. > Even Thomas may agree that sometimes the AD is empowered to make > decisions. > The rejection or approval of errata sits with the AD. > > > because I read the way of errata-review as mentioned in IETF guide, > > > > Rejected - The erratum is in error, or proposes a change to the RFC > > that should be done by publishing a new RFC that replaces the current > > RFC. In the latter case, if the change is to be considered for future > > updates of the document, it should be proposed using channels other > > than the errata process, such as a WG mailing list. > > Thanks for your opinion. > I did consider this text when I approved the errata. > I do not believe that this is a change that "should be done by publishing a new > RFC" > > > Please in future guide participants of the special way of > > review/respond/judge, because it is first time for me, I was not > > familiar to this, > > I have sent AB a private email on how the errata process works. Am willing to > share it with others on request. > > Adrian From yi.jiazi@gmail.com Fri Mar 1 06:38:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46AF21E80E5 for ; Fri, 1 Mar 2013 06:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=3.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efo9lcDzBHg3 for ; Fri, 1 Mar 2013 06:38:57 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id AF83121E80C1 for ; Fri, 1 Mar 2013 06:38:56 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so3539645wib.10 for ; Fri, 01 Mar 2013 06:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=9qDdfLOzzYBqIBHrj+casZZ337SPoCZbXNKVVDXKED0=; b=x1lhSBPlzZZW9FFuUI4sMEL64pHkCIa9swXYaC8iDtYmaw3TeUa8HK4fsstGdKmuE2 cRmogV+8egtQgTxJlT6JYsMu6USfKY6AOpBJnIg+MckPxJDKti5F1D470iJqMYQAT28U zXuzO7PHxEk7GwgqTd3SvYTGdfNNx5lFzzdyNpC/21Steb/YqrtNHdqvvgT+xTempEdx UK8wM0mwRN2ihz0uNcvbRILsLinH7x9Lw/NxCa8osTBOaYPBKWoL9L/bG5ynDAmPv4ZJ Zg1U+AViDRFrEklKXJYu8XqlLxvEEmOZW1RX8x6yuJTbp83+b3B+QIYUWsR/w48zYl8L Dlyg== X-Received: by 10.194.157.42 with SMTP id wj10mr18079638wjb.12.1362148734307; Fri, 01 Mar 2013 06:38:54 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id du2sm39866228wib.0.2013.03.01.06.38.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 06:38:53 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> Date: Fri, 1 Mar 2013 15:38:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130225151705.EB129B1E008@rfc-editor.org> <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1499) Cc: chris.dearlove@baesystems.com, manet Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:38:58 -0000 I think it's OK to have SHOULD here.=20 But isn't it better to have a few words to explain why not MUST, or = what's the consequence of not doing that in the corrected text? In that = case, the implementors would know that if they are trying to tracing = missing pack using packet sequence number, this must be done.=20 best Jiazi On Mar 1, 2013, at 12:30 PM, Adrian Farrel wrote: >>> Corrected Text >>> -------------- >>> o The field, if present, contains a sequence number >>> that SHOULD be maintained for each participating interface and >>> incremented by 1 for each packet generated by a node for that >>> interface. The sequence number after 65535 is 0. In other = words, >>> the sequence number "wraps" in the usual way. >>>=20 >>=20 >> what you mean by *participating interface* do you mean NHDP-RFC6130, >> how does the interface maintain such number? is there an answer in = any >> MANET doc? >=20 > Erm, a "participating interface" is one that is participating in this = RFC. >=20 > How does an interface maintain a sequence number? > That is an implementation detail. We don't write implementation specs. > Most people use registers, variables, or other forms of storage. I = knew a vendor > that tired to use pixie dust, but they went Chapter 11. >=20 >> Why you say SHOULD not MUST, or RECOMMENDED, please advise, >=20 > RECOMMENDED would equate to SHOULD so there is no question there. > I admit I shuffled my feet over the inclusion of a new 2119 word = through this > Errata Report. > My thinking was that this is what everyone is doing in their = implementations and > it is clearly what was intended. > It is not mandatory to maintain the counter in this way and there may = be > implementation reasons for doing something different. However, doing = it > different will reduce the functionality achieved through the use of = the sequence > number. >=20 > Adrian >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Mar 2 00:46:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7521F9044 for ; Sat, 2 Mar 2013 00:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTFAIMj-fchM for ; Sat, 2 Mar 2013 00:46:52 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id B650621F9042 for ; Sat, 2 Mar 2013 00:46:51 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so1752320daj.22 for ; Sat, 02 Mar 2013 00:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Q2NDQ2R93R78NGHY8Klgs+78sZGlW8iV3qOGY9R+dos=; b=WZ8ltIoRxgebwRT+ViEPSenLzDREJvJQSPykERb/zQCccUq1qbERYLw9M1R2l6Y4ij 0KDUoT0zabmi/l1jAAmMRKOSmCKuHtOYxfLAXgbs0tZ6Jd966k61gEhGntokS/ADXMnf 3u86dhJK4jXkNtbSy66aFHWloNhU1QvBbX/h4f0BISuVNopX7Oxt8H64KaGV9KmWSEko 9Ua6A/ZdRbogjGySvR3CEIDNP23RHODuGeDFXrIxgQDa3zX6l/01RtLTja8m/G6hvOdX ianMb5I3jr2RPs7YJGrbmS3CZydglZHmFukS/qJRcDplr66sW30+EKC3qG8lCS/atGlA 4ygg== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr18650032pbc.6.1362214011512; Sat, 02 Mar 2013 00:46:51 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 2 Mar 2013 00:46:51 -0800 (PST) In-Reply-To: <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> References: <20130225151705.EB129B1E008@rfc-editor.org> <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> Date: Sat, 2 Mar 2013 09:46:51 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: chris.dearlove@baesystems.com, manet Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 08:46:52 -0000 On 3/1/13, Adrian Farrel wrote: >> > Corrected Text >> > -------------- >> > o The field, if present, contains a sequence number >> > that SHOULD be maintained for each participating interface and >> > incremented by 1 for each packet generated by a node for that >> > interface. The sequence number after 65535 is 0. In other >> > words, >> > the sequence number "wraps" in the usual way. >> > >> >> what you mean by *participating interface* do you mean NHDP-RFC6130, >> how does the interface maintain such number? is there an answer in any >> MANET doc? > > Erm, a "participating interface" is one that is participating in this RFC. > > How does an interface maintain a sequence number? > That is an implementation detail. We don't write implementation specs. > Most people use registers, variables, or other forms of storage. I knew a > vendor > that tired to use pixie dust, but they went Chapter 11. The interface participating in this RFC is will usually RFC6130 (only one using RFC5444 so far). Regarding the sequence number maintained in MANET interfaces, I don't think it is only an implementation parameter but also sepecification parameter. Why not add sequence number as a new interface parameter in RFC6130-section-5.3? for not updating the question still stands, how does RFC6130 maintain such parameter which is assigned in RFC5444 packets? As long as this errata mentions the interface's number, Is it a must parameter maintain for interface that uses RFC5444? I think so yes, AB From adrian@olddog.co.uk Sat Mar 2 03:01:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E182F21F910A for ; Sat, 2 Mar 2013 03:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EH7GYDAehO8 for ; Sat, 2 Mar 2013 03:01:30 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9A21F8CD4 for ; Sat, 2 Mar 2013 03:01:25 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r22B1LNG019587; Sat, 2 Mar 2013 11:01:21 GMT Received: from 950129200 (089144192008.atnat0001.highway.a1.net [89.144.192.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r22B1JSR019570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Mar 2013 11:01:20 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <20130225151705.EB129B1E008@rfc-editor.org> <008401ce1670$416cca40$c4465ec0$@olddog.co.uk> In-Reply-To: Date: Sat, 2 Mar 2013 11:01:21 -0000 Message-ID: <01f601ce1735$477bbc00$d6733400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWyZ6xa8bXu4rMTag2AY499DrM3wE1cC9gAnNUmd8BhoVQeZhXWngQ Content-Language: en-gb Cc: chris.dearlove@baesystems.com, 'manet' Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 11:01:31 -0000 Hi, Wrt end of discussion date for this errata... Gone. Done. Ended. Errata has been verified. Move along now please, there is nothing to see. > >> > Corrected Text > >> > -------------- > >> > o The field, if present, contains a sequence number > >> > that SHOULD be maintained for each participating interface and > >> > incremented by 1 for each packet generated by a node for that > >> > interface. The sequence number after 65535 is 0. In other > >> > words, the sequence number "wraps" in the usual way. > >> > >> what you mean by *participating interface* do you mean NHDP-RFC6130, > >> how does the interface maintain such number? is there an answer in any > >> MANET doc? > > > > Erm, a "participating interface" is one that is participating in this RFC. > > > > How does an interface maintain a sequence number? > > That is an implementation detail. We don't write implementation specs. > > Most people use registers, variables, or other forms of storage. I knew a > > vendor that tried to use pixie dust, but they went Chapter 11. > > The interface participating in this RFC is will usually RFC6130 (only > one using RFC5444 so far). Regarding the sequence number maintained in > MANET interfaces, I don't think it is only an implementation parameter > but also sepecification parameter. Why not add sequence number as a > new interface parameter in RFC6130-section-5.3? for not updating the > question still stands, how does RFC6130 maintain such parameter which > is assigned in RFC5444 packets? I am probably having trouble parsing what you wrote. Let me reiterate that we do not write implementation specifications. You asked *how* an interface maintains a sequence number, and the answer to that is quite clearly out of scope. You say "I don't think it is only an implementation parameter but also sepecification parameter". That is a thought, not an argument. Your thoughts are very interesting to us, but only those supported with reasoning are likely to gather support. Can you explain why it is necessary for two interoperable implementations to know how the other stores or maintains a sequence number? Now you reference 5.3 of 6130. This is a list of parameters that affect the on-the-wire performance of the protocol. Several are configurable, and several are qualities of the interface. > As long as this errata mentions the interface's number, Is it a must > parameter maintain for interface that uses RFC5444? I think so yes, You are now talking about interface number? That is a change of track, but anyway, this errata report does not mention interface number. Thanks, Adrian > received end of discussion/date related to this errata.> > > AB From abdussalambaryun@gmail.com Sat Mar 2 04:54:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0021F90FC for ; Sat, 2 Mar 2013 04:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhzYgZnAPyyw for ; Sat, 2 Mar 2013 04:54:18 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id EC25421F90E7 for ; Sat, 2 Mar 2013 04:54:17 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id fa11so2295048pad.23 for ; Sat, 02 Mar 2013 04:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=vIvXR7QWJMQVSce1l3lZlTzKu3Fvqws18SNEZBpugNc=; b=LGzTbWo4HhMOt4ZvMqKLIaLA0kB+aoLbPAeBuI2D94ttFdRCc8WY1FhOPHOcrjcZmY /Q8mewHgJ3o6hHs0FzdHOTCU7ci1EXLkKX67RZuYUpT80KW+eKffJ9fUw7InzgrOScE9 pGoGTHUAgv6hm5ot+kOToorXaUw9tWyFZKEjg9jPGrJOl5IzxncEoFZQYPbVlUkmOcTh Q17n4xEPykIm2PvBsFetyaQ3pRmSTMcM09hEcoWIlPHib3bV8rj+2mBoXo5mrndx2y7E r+O9ikssvZluSYmCDtyKAIahAiDJzhTpB9FWhq44Tc+pzAkjygaOeLqFSQg92AsOUC5n U92Q== MIME-Version: 1.0 X-Received: by 10.68.231.135 with SMTP id tg7mr8597497pbc.113.1362228857541; Sat, 02 Mar 2013 04:54:17 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 2 Mar 2013 04:54:17 -0800 (PST) Date: Sat, 2 Mar 2013 13:54:17 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] MANET interface Sequence Number incremented by MANET router (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 12:54:19 -0000 Ok now the errata is done let me discuss the manet interface issue, On 3/2/13, Adrian Farrel wrote: >> The interface participating in this RFC is will usually RFC6130 (only >> one using RFC5444 so far). Regarding the sequence number maintained in >> MANET interfaces, I don't think it is only an implementation parameter >> but also sepecification parameter. Why not add sequence number as a >> new interface parameter in RFC6130-section-5.3? for not updating the >> question still stands, how does RFC6130 maintain such parameter which >> is assigned in RFC5444 packets? > > I am probably having trouble parsing what you wrote. > Let me reiterate that we do not write implementation specifications. I think we write manet protocol specification as RFC6130, and sequence number can be related as a one interface protocol parameter (i.e. which is incremented by router) mentioned by that approved and done errata 3496, > > You asked *how* an interface maintains a sequence number, and the answer to > that > is quite clearly out of scope. For the approved errata reason, I think it is in scope for RFC5444 and RFC6130. I will change my question by; how does MANET router increment the sequence number in the interface (mentioned who increments and where in errata 3496) if the interface protocol does not specify any sequence number in its info who will specify for it. > > You say "I don't think it is only an implementation parameter but also > sepecification parameter". That is a thought, not an argument. Your > thoughts > are very interesting to us, but only those supported with reasoning are > likely > to gather support. I agree but even the participant thought-comment is part of any I-D/RFC discussion, and because volunteering in my work process I sometimes note my thoughts and then reasons which maybe posted in different time, that such process has a reason also which depends on the subject, document and WG reputations. > Can you explain why it is necessary for two > interoperable > implementations to know how the other stores or maintains a sequence > number? Realy your question depends on the approved errata 3496 or RFC5444-designer reason, why does the errata mention that the sequence number of the interface is change/incremented by the router. In the particular argument, the rounting operation to be successful in manet, there are two WG protocols; the router, and the router-interface (this is when both using the RFC5444 packet related to the errata 3496). I requested to specify the parameter in the manet interface protocol, because the errata is specifying the incrementation inside the interface protocol by another protocol which is the router. Also, regarding to all routers' implementations (using RFC5444 specification), they need to know how sequence number was incremented or maintained in the interface specification that they use, otherwise how can router use such number in packet chack algorithms or other concerning the RFC5444 sequence number. > > Now you reference 5.3 of 6130. This is a list of parameters that affect the > on-the-wire performance of the protocol. Several are configurable, and > several > are qualities of the interface. > Yes the interface RFC6130 performance is a general purpose performance which is flexible to all routers that use RFC5444/RFC5498 not only IETF-MANET WG productions. Is this right thought or assumption by me? >> As long as this errata mentions the interface's number, Is it a must >> parameter maintain for interface that uses RFC5444? I think so yes, > > You are now talking about interface number? > That is a change of track, but anyway, this errata report does not mention > interface number. > I think it mentioned a number related to each interface generating-packet incremented by the router (i.e packet sequence number). AB From adrian@olddog.co.uk Sat Mar 2 13:41:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B039321F8598 for ; Sat, 2 Mar 2013 13:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[AWL=-2.428, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR9d9i1OQjTs for ; Sat, 2 Mar 2013 13:41:50 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CF2CE21F855A for ; Sat, 2 Mar 2013 13:41:49 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r22Lfl0j008150; Sat, 2 Mar 2013 21:41:47 GMT Received: from 950129200 (089144192008.atnat0001.highway.a1.net [89.144.192.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r22LfkWK008131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Mar 2013 21:41:47 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" Date: Sat, 2 Mar 2013 21:41:49 -0000 Message-ID: <025001ce178e$bf8cbe70$3ea63b50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Xjq8CxgkVYt5gT6WK/bFNEXzFYA== Content-Language: en-gb Cc: 'manet' Subject: Re: [manet] MANET interface Sequence Number incremented by MANET router (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 21:41:50 -0000 I'm afraid that I am starting to find this discussion burdensome and I apologise to the WG for clogging the list. I really thought I could move things along, but apparently not. This will be my last engagement on this topic on this list. > > I am probably having trouble parsing what you wrote. > > Let me reiterate that we do not write implementation specifications. > > I think we write manet protocol specification as RFC6130, and sequence > number can be related as a one interface protocol parameter (i.e. > which is incremented by router) mentioned by that approved and done > errata 3496, No-one doubts this, I think. > > You asked *how* an interface maintains a sequence number, and the answer > > to that is quite clearly out of scope. > > For the approved errata reason, I think it is in scope for RFC5444 and > RFC6130. I will change my question by; how does MANET router increment > the sequence number in the interface (mentioned who increments and > where in errata 3496) if the interface protocol does not specify any > sequence number in its info who will specify for it. You have exactly not changed your question! You still as "how?" Here is a suggestion: if (sending_packet == 1) { packet_sequence_number [interface_ID]++; } Please understand that the sequence number is a local value held in the implementation and incremented by the implementation when it sends a packet. This is not rocket science - you will find sequence numbers in very many protocols. > > You say "I don't think it is only an implementation parameter but also > > sepecification parameter". That is a thought, not an argument. Your > > thoughts are very interesting to us, but only those supported with > > reasoning are likely to gather support. > > I agree but even the participant thought-comment is part of any > I-D/RFC discussion, and because volunteering in my work process I > sometimes note my thoughts and then reasons which maybe posted in > different time Well, please don't. It is disruptive to the WG to cause people to attempt to guess your reasoning, and it clogs the list unnecessarily to have emails that have to be open and read, but which do not add to the sum of received wisdom. > > Can you explain why it is necessary for two > > interoperable implementations to know how the > > other stores or maintains a sequence number? > > Realy your question depends on the approved errata 3496 or > RFC5444-designer reason, why does the errata mention that the sequence > number of the interface is change/incremented by the router. In the > particular argument, the rounting operation to be successful in manet, > there are two WG protocols; the router, and the router-interface (this > is when both using the RFC5444 packet related to the errata 3496). As neither a router nor an interface is "a protocol" I cannot extract any meaning from this text. But it sounds like you are asking me how to implement a counter in software for a router that may have many interfaces. My answer is "work it out for yourself because my ability to work it out is how I sell my software!" > I > requested to specify the parameter in the manet interface protocol, > because the errata is specifying the incrementation inside the > interface protocol by another protocol which is the router. Que? > > Now you reference 5.3 of 6130. This is a list of parameters that affect the > > on-the-wire performance of the protocol. Several are configurable, and > > several are qualities of the interface. > > Yes the interface RFC6130 performance is a general purpose performance > which is flexible to all routers that use RFC5444/RFC5498 not only > IETF-MANET WG productions. Is this right thought or assumption by me? I cannot parse your text. You introduced NHDP to this discussion so I presume you know what you mean. > >> As long as this errata mentions the interface's number, Is it a must > >> parameter maintain for interface that uses RFC5444? I think so yes, > > > > You are now talking about interface number? > > That is a change of track, but anyway, this errata report does not mention > > interface number. > > I think it mentioned a number related to each interface > generating-packet incremented by the router (i.e packet sequence > number). The packet sequence number is not the "interface's number." I quoted your email, so please don't "think" what you mentioned; please read it. The fact that an interface needs to maintain a sequence number does not make the sequence number a qualitative parameter of that interface. So it does not belong in the list in 6130. I'm out of here. I really did try. Adrian From sratliff@cisco.com Sun Mar 3 15:43:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA421F884C; Sun, 3 Mar 2013 15:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAq4ntJktph4; Sun, 3 Mar 2013 15:43:22 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD721F8825; Sun, 3 Mar 2013 15:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13888; q=dns/txt; s=iport; t=1362354183; x=1363563783; h=from:to:cc:subject:date:message-id:mime-version; bh=qyzEbf70PD4oLgfqT9js4p8SglL5cMic9xGlfJPRYSU=; b=fn3Rn2f3PUCgTsFmtKtwX3OuZS1iymasslsFZNhvcYBHD/fA77gO65eZ 4locFFfnANo9uvxBaUqHuJbNzLzvFGmncQsO/7B0N60yOhaPEULLH9/af 3BDKY4zJTJ8MhT7RVf/+VvKfixhgUOQEKAC45bb/QPUMcaJHlxQUXJ1sx k=; X-Files: OLSRv2-Metrics-Rationale.rtf : 9514 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE7eM1GtJXHA/2dsb2JhbAA7CsJKfBZzgiEBBEUmBwcSASomMCcEDg0BBYgFDMcgjUwGgRoxgmZhA48pg1qUL4MIgWsHFwYY X-IronPort-AV: E=Sophos;i="4.84,776,1355097600"; d="rtf'212?scan'212,208,212";a="180232773" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 03 Mar 2013 23:43:02 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r23Nh2DH003036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Mar 2013 23:43:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 17:42:55 -0600 From: "Stan Ratliff (sratliff)" To: "ietf-secretary@ietf.org" Thread-Topic: Please publish draft-ietf-manet-olsrv2-metrics-rationale-02 Thread-Index: AQHOGGjTSX0kTayFyUCbh262WY2IzA== Date: Sun, 3 Mar 2013 23:42:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1003C214@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.213] Content-Type: multipart/mixed; boundary="_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C214xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "" , "manet@ietf.org List" Subject: [manet] Please publish draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:43:24 -0000 --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C214xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: <3B5EAD08DCB45A448833980026B64B35@cisco.com> Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-manet-foo as an Informational RFC. The shepherd w= rite-up is attached. Regards, Stan --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C214xmbalnx03ciscoc_ Content-Type: text/rtf; name="OLSRv2-Metrics-Rationale.rtf" Content-Description: OLSRv2-Metrics-Rationale.rtf Content-Disposition: attachment; filename="OLSRv2-Metrics-Rationale.rtf"; size=9514; creation-date="Sun, 03 Mar 2013 23:42:54 GMT"; modification-date="Sun, 03 Mar 2013 23:42:54 GMT" Content-ID: <21601B3086C44245815141B530320F0C@cisco.com> Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMTM4XGNvY29hc3VicnRmNTEwDQp7XGZv bnR0YmxcZjBcZnN3aXNzXGZjaGFyc2V0MCBIZWx2ZXRpY2E7fQ0Ke1xjb2xvcnRibDtccmVkMjU1 XGdyZWVuMjU1XGJsdWUyNTU7fQ0KXG1hcmdsMTQ0MFxtYXJncjE0NDBcdmlld3cxMDgwMFx2aWV3 aDg0MDBcdmlld2tpbmQwDQpccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2MDBc dHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRpcm5h dHVyYWwNCg0KXGYwXGZzMjQgXGNmMCBcDQo+ICgxKSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5n IHJlcXVlc3RlZCAoQkNQLCBQcm9wb3NlZCBTdGFuZGFyZCxcDQo+IEludGVybmV0IFN0YW5kYXJk LCBJbmZvcm1hdGlvbmFsLCBFeHBlcmltZW50YWwsIG9yIEhpc3RvcmljKT8gV2h5XA0KPiBpcyB0 aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/IElzIHRoaXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVk IGluIHRoZVwNCj4gdGl0bGUgcGFnZSBoZWFkZXI/XA0KXA0KVGhpcyBkb2N1bWVudCBpcyByZXF1 ZXN0ZWQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLlwNClwNCk9MU1J2 MiByZWZsZWN0cyB+OCB5ZWFycyBvZiBleHBlcmllbmNlcyB3aXRoIE9MU1IsIHB1Ymxpc2hlZCBh cyBSRkMzNjI2XA0KKEV4cGVyaW1lbnRhbCksIGFuZCBtdWx0aXBsZSBpbmRlcGVuZGVudCBpbXBs ZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1lbnRzXA0KZXhpc3QsIGFuZCB0aGlzIHByb3RvY29sIGlz IGluIGZpbmFsIHJldmlldyBieSB0aGUgSUVTRyBmb3IgcHVibGljYXRpb25cDQphcyBhIFByb3Bv c2VkIFN0YW5kYXJkLiAoVGhlIHNpbmdsZSBESVNDVVNTIG91dHN0YW5kaW5nIGlzIG5vdCByZWxh dGVkXA0KdG8gdGhlIHN1YmplY3QgbWF0dGVyIG9mIHRoaXMgZG9jdW1lbnQuKVwNClwNClRoaXMg ZG9jdW1lbnQgcHJlc2VudHMgdGhlIGRlc2lnbiByYXRpb25hbGUgYmVoaW5kIHRoZSB3YXkgaW4g d2hpY2hcDQpPTFNSdjIgaW5jb3Jwb3JhdGVkIG1ldHJpY3MuIEl0IGRvZXMgbm90IG1hbmRhdGUg YW55IHByb3RvY29sIGJlaGF2aW9ycy5cDQpcDQo+ICgyKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5v dW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCBBbm5vdW5jZW1lbnRcDQo+IFdyaXRlLVVwLiBQ bGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNl bnRcDQo+IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUgIkFjdGlvbiIgYW5ub3VuY2VtZW50 cyBmb3IgYXBwcm92ZWRcDQo+IGRvY3VtZW50cy4gVGhlIGFwcHJvdmFsIGFubm91bmNlbWVudCBj b250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOlwNClwNCj4gVGVjaG5pY2FsIFN1bW1hcnlc DQo+XA0KPiAgUmVsZXZhbnQgY29udGVudCBjYW4gZnJlcXVlbnRseSBiZSBmb3VuZCBpbiB0aGUg YWJzdHJhY3QgXA0KPiAgYW5kL29yIGludHJvZHVjdGlvbiBvZiB0aGUgZG9jdW1lbnQuIElmIG5v dCwgdGhpcyBtYXkgYmUgXA0KPiAgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZXJlIGFyZSBkZWZpY2ll bmNpZXMgaW4gdGhlIGFic3RyYWN0IFwNCj4gIG9yIGludHJvZHVjdGlvbi5cDQpcDQpUaGUgYWJz dHJhY3Qgb2YgdGhpcyBkb2N1bWVudCBpcyBpbmNsdWRlZCBiZWxvdy5cDQpcDQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgcmF0aW9uYWxlIGZvciBhbmQgZGVzaWduIGNvbnNpZGVyYXRp b25zXA0KICAgYmVoaW5kIGhvdyBsaW5rIG1ldHJpY3MgYXJlIGluY2x1ZGVkIGluIE9MU1J2Miwg aW4gb3JkZXIgdG8gYWxsb3dcDQogICByb3V0aW5nIGJ5IG90aGVyIHRoYW4gbWluaW11bSBob3Ag Y291bnQgcm91dGVzLlwNCiAgIFwNCj4gV29ya2luZyBHcm91cCBTdW1tYXJ5XA0KPlwNCj4gIFdh cyB0aGVyZSBhbnl0aGluZyBpbiBXRyBwcm9jZXNzIHRoYXQgaXMgd29ydGggbm90aW5nPyBGb3Ig XA0KPiAgZXhhbXBsZSwgd2FzIHRoZXJlIGNvbnRyb3ZlcnN5IGFib3V0IHBhcnRpY3VsYXIgcG9p bnRzIG9yIFwNCj4gIHdlcmUgdGhlcmUgZGVjaXNpb25zIHdoZXJlIHRoZSBjb25zZW5zdXMgd2Fz IHBhcnRpY3VsYXJseSBcDQo+ICByb3VnaD9cDQoJCVwNCglvCU9MU1J2MiB3YXMgZmlyc3Qgc3Vi bWl0dGVkIGFzIGFuIGluZGl2aWR1YWwgZHJhZnQgaW4gSnVseSAyMDA1XA0KCQkoZHJhZnQtY2xh dXNlbi1tYW5ldC1vbHNydjItMDApLCBhbmQgYWNjZXB0ZWQgYXMgYSBXb3JraW5nIEdyb3VwXA0K CQlkb2N1bWVudCBpbiBBdWd1c3QgMjAwNS5cDQpcDQoJbwlPTFNSdjIgaXMgY2xvc2UgdG8gYXBw cm92YWwgYXMgYSBQcm9wb3NlIFN0YW5kYXJkIGJ5IHRoZSBJRVNHXA0KICAgICAgICAgICAgICAg KG9uZSBESVNDVVNTIHRvIHJlc29sdmUpLlwNCgkJXA0KCW8JQSBrZXkgZGlmZmVyZW5jZSBiZXR3 ZWVuIFJGQzM2MjYgYW5kIE9MU1J2MiBpcyB0aGUgaW50cm9kdWN0aW9uIG9mXA0KCQlzdXBwb3J0 IGZvciBsaW5rIG1ldHJpY3MuIEFuIGluZGl2aWR1YWwgZHJhZnRcDQoJCShkcmFmdC1kZWFybG92 ZS1vbHNydjItbWV0cmljcy0wMCkgd2FzIHN1Ym1pdHRlZCBpbiAyMDA3LCBkaXNjdXNzaW5nXA0K CQl0aGUgZGVzaWduIG9wdGlvbnMsIGN1bG1pbmF0aW5nIGluIDIwMTAgd2l0aFwNCgkJZHJhZnQt ZGVhcmxvdmUtb2xzcnYyLW1ldHJpY3MtMDUgZG9jdW1lbnRpbmcgV29ya2luZyBHcm91cCBjb25z ZW5zdXNcDQoJCW9uIHRoaXMgbWF0dGVyLiBNZXRyaWNzIHN1cHBvcnQgd2FzLCB0aGVuLCBmb2xk ZWQgaW50byBPTFNSdjIuXA0KXA0KCW8JVGhpcyBkb2N1bWVudCByZXRhaW5zIGFuZCBkb2N1bWVu dHMgdGhlIGRlc2lnbiByYXRpb25hbGUsIGFuZCBpbXBvcnRhbnRcDQoJCWRlY2lzaW9ucyBmb3Ig aG93IG1ldHJpY3Mgd2VyZSBpbnRlZ3JhdGVkIGludG8gT0xTUnYyLlwNClwNCj4gRG9jdW1lbnQg UXVhbGl0eVwNCj5cDQo+ICBBcmUgdGhlcmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRo ZSBwcm90b2NvbD8gSGF2ZSBhIFwNCj4gIHNpZ25pZmljYW50IG51bWJlciBvZiB2ZW5kb3JzIGlu ZGljYXRlZCB0aGVpciBwbGFuIHRvIFwNCj4gIGltcGxlbWVudCB0aGUgc3BlY2lmaWNhdGlvbj8g QXJlIHRoZXJlIGFueSByZXZpZXdlcnMgdGhhdCBcDQo+ICBtZXJpdCBzcGVjaWFsIG1lbnRpb24g YXMgaGF2aW5nIGRvbmUgYSB0aG9yb3VnaCByZXZpZXcsIFwNCj4gIGUuZy4sIG9uZSB0aGF0IHJl c3VsdGVkIGluIGltcG9ydGFudCBjaGFuZ2VzIG9yIGEgXA0KPiAgY29uY2x1c2lvbiB0aGF0IHRo ZSBkb2N1bWVudCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiBcDQo+ICB0aGVyZSB3YXMg YSBNSUIgRG9jdG9yLCBNZWRpYSBUeXBlIG9yIG90aGVyIGV4cGVydCByZXZpZXcsIFwNCj4gIHdo YXQgd2FzIGl0cyBjb3Vyc2UgKGJyaWVmbHkpPyBJbiB0aGUgY2FzZSBvZiBhIE1lZGlhIFR5cGUg XA0KPiAgcmV2aWV3LCBvbiB3aGF0IGRhdGUgd2FzIHRoZSByZXF1ZXN0IHBvc3RlZD9cDQpcDQoJ VGhlcmUgaXMgYSBudW1iZXIgb2YgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIG9mIE9MU1J2 MiwgYXMgd2FzXA0KCWluZGljYXRlZCBpbiB0aGUgd3JpdGUtdXAgZm9yIHRoYXQgT0xTUnYyLlwN CglcDQoJVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9wb3NlIGEgcHJvdG9jb2wsIG9yIG1hbmRh dGUgcHJvdG9jb2wgYmVoYXZpb3IsXA0KCWJ1dCByYXRoZXIgcHJlc2VudHMgcGFydCBvZiB0aGUg ZGVzaWduIHJhdGlvbmFsZSBmb3IgT0xTUnYyLlwNCglcDQo+IFBlcnNvbm5lbFwNCj5cDQo+ICBX aG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkPyBXaG8gaXMgdGhlIFJlc3BvbnNpYmxlIEFyZWFc DQo+ICBEaXJlY3Rvcj9cDQpcDQpBZHJpYW4gRmFycmVsIGlzICJSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yIlwNCj8/PyA/Pz8gaXMgIkRvY3VtZW50IFNoZXBoZXJkIi5cDQpcDQo+ICgzKSBCcmll Zmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB0aGF0IHdhcyBwZXJmb3Jt ZWQgYnlcDQo+IHRoZSBEb2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBk b2N1bWVudCBpcyBub3QgcmVhZHlcDQo+IGZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4cGxhaW4g d2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG9cDQo+IHRoZSBJRVNHLlwNClwN Cj8/PyA/Pz9cDQpcDQo+ICg0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBj b25jZXJucyBhYm91dCB0aGUgZGVwdGggb3JcDQo+IGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhh dCBoYXZlIGJlZW4gcGVyZm9ybWVkPyBcDQpcDQo/Pz8gPz8/XA0KXA0KPiAoNSkgRG8gcG9ydGlv bnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb21c DQo+IGJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21w bGV4aXR5LCBBQUEsIEROUyxcDQo+IERIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/ IElmIHNvLCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXRcDQo+IHRvb2sgcGxhY2UuXA0KXA0KVGhl IGF1dGhvcnMgZG8gbm90IGJlbGlldmUgdGhhdCAtIG91dHNpZGUgdGhlIHVzdWFsIGRpcmVjdG9y YXRlIHJldmlld3NcDQpkdXJpbmcgIElFVEYgTGFzdCBDYWxsIC0gYWRkaXRpb25hbCByZXZpZXdz IGFyZSByZXF1aXJlZC5cDQpcDQo+ICg2KSBEZXNjcmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMg b3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNoZXBoZXJkXA0KPiBoYXMgd2l0aCB0aGlzIGRv Y3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgYW5kL29yIHRoZVwNCj4g SUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNoZSBp cyB1bmNvbWZvcnRhYmxlXA0KPiB3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50LCBv ciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHlcDQo+IGlzIGEgbmVlZCBmb3IgaXQu IEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZFwN Cj4gaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1 bWVudCwgZGV0YWlsIHRob3NlXA0KPiBjb25jZXJucyBoZXJlLlwNClwNCj8/PyA/Pz9cDQpcDQo+ ICg3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlh dGUgSVBSXA0KPiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRo IHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OFwNCj4gYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVl biBmaWxlZC4gSWYgbm90LCBleHBsYWluIHdoeS5cDQpcDQpBbGwgYXV0aG9ycyBoYXZlIGNvbmZp cm1lZCB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55IElQUiBuZWVkaW5nIGRpc2Nsb3N1cmUs XA0KaW5kZWVkIHRoYXQgdGhlcmUgYXJlIG5vIGtub3duIElQUiBjbGFpbXMgcmVsYXRlZCB0byB0 aGlzIGRvY3VtZW50LlwNClwNCj4gKDgpIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVk IHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50P1wNCj4gSWYgc28sIHN1bW1hcml6ZSBhbnkg V0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIElQUlwNCj4gZGlzY2xv c3VyZXMuXA0KXA0KTm8gSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVlbiBmaWxlZC5cDQpcDQo+ICg5 KSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9l cyBpdCBcDQo+IHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2 aWR1YWxzLCB3aXRoIG90aGVyc1wNCj4gYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBh IHdob2xlIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/IFwNClwNCj4gKDEwKSBIYXMgYW55 b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSBc DQo+IGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25m bGljdCBpbiBzZXBhcmF0ZVwNCj4gZW1haWwgbWVzc2FnZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFy ZWEgRGlyZWN0b3IuIChJdCBzaG91bGQgYmUgaW4gYVwNCj4gc2VwYXJhdGUgZW1haWwgYmVjYXVz ZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxlLikgXA0KXA0KPiAoMTEp IElkZW50aWZ5IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgZm91bmQgaW4g dGhpc1wNCj4gZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMv IFteXSBhbmQgdGhlIEludGVybmV0LURyYWZ0c1wNCj4gQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUg Y2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlXA0KPiB0aG9yb3Vn aC5cDQpcDQpJRG5pdHMgcmV0dXJucyBubyBlcnJvcnMgb3Igd2FybmluZ3NcDQpcDQo+ICgxMikg RGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmll d1wNCj4gY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBV UkkgdHlwZSByZXZpZXdzLlwNClwNClRoaXMgZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBhIHBy b3RvY29sLCBhIGZvcm1hdCwgYSBtZWRpYSB0eXBlIG9yIHJlc2VydmVcDQphbnkgY29kZS1wb2lu dHMuIFRodXMsIHN1Y2ggcmV2aWV3cyBhcmUgbm90IG5lZWRlZC5cDQpcDQo+ICgxMykgSGF2ZSBh bGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXNcDQo+ IGVpdGhlciBub3JtYXRpdmUgb3IgaW5mb3JtYXRpdmU/XA0KXA0KWWVzLlwNClwNCj4gKDE0KSBB cmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBy ZWFkeSBmb3JcDQo+IGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBz dGF0ZT8gSWYgc3VjaCBub3JtYXRpdmVcDQo+IHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhl IHBsYW4gZm9yIHRoZWlyIGNvbXBsZXRpb24/XA0KXA0KTm8uIFRoZXJlIGFyZSBubyBub3JtYXRp dmUgcmVmZXJlbmNlcyBpbiB0aGlzIGRvY3VtZW50LlwNClwNCj4gKDE1KSBBcmUgdGhlcmUgZG93 bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT9cDQo+ IElmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydCB0aGUgQXJl YSBEaXJlY3RvciBpbiB0aGVcDQo+IExhc3QgQ2FsbCBwcm9jZWR1cmUuIFwNClwNCk5vLiBUaGVy ZSBhcmUgbm8gbm9ybWF0aXZlIHJlZmVyZW5jZXMuIFwNClwNCkFsbCBpbmZvcm1hdGl2ZSByZWZl cmVuY2VzIGFyZSwgZnVydGhlcm1vcmUsIHRvIGFscmVhZHkgcHVibGlzaGVkIFJGQ3Mgb3JcDQpz b29uLXRvLWJlLVJGQ3MgKE9MU1J2MiBjdXJyZW50bHkgaW4gSUVTRyByZXZpZXcpXA0KXA0KPiAo MTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBv ZiBhbnlcDQo+IGV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0 bGUgcGFnZSBoZWFkZXIsIGxpc3RlZFwNCj4gaW4gdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2Vk IGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3RcDQo+IGxpc3RlZCBpbiB0 aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0 aGVcDQo+IHBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhp cyBkb2N1bWVudCB0byB0aGVcDQo+IG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGlu Zm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsXA0KPiBleHBsYWluIHdoeSB0aGUgV0cg Y29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5LlwNClwNClB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1l bnQgd2lsbCBub3QgY2hhbmdlIHRoZSBzdGF0dXMgb2YgYW55IGV4aXN0aW5nIFJGQ3MuXA0KXA0K PiAoMTcpIERlc2NyaWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFO QSBjb25zaWRlcmF0aW9uc1wNCj4gc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBp dHMgY29uc2lzdGVuY3kgd2l0aCB0aGUgYm9keSBvZiB0aGVcDQo+IGRvY3VtZW50LiBDb25maXJt IHRoYXQgYWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1lbnQgbWFrZXNcDQo+ IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcHJvcHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5B IHJlZ2lzdHJpZXMuXA0KPiBDb25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3Ry aWVzIGhhdmUgYmVlbiBjbGVhcmx5XA0KPiBpZGVudGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkg Y3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhXA0KPiBkZXRhaWxlZCBzcGVjaWZpY2F0 aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUgcmVnaXN0cnksIHRoYXRcDQo+IGFs bG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFyZSBkZWZpbmVk LCBhbmQgYVwNCj4gcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVu IHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS5cDQpcDQpUaGlzIGRvY3VtZW50IGhhcyBubyBhY3Rp b25zIGZvciBJQU5BLlwNClwNCj4gKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRo YXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvciBmdXR1cmVcDQo+IGFsbG9jYXRpb25zLiBQcm92 aWRlIGFueSBwdWJsaWMgZ3VpZGFuY2UgdGhhdCB0aGUgSUVTRyB3b3VsZCBmaW5kXA0KPiB1c2Vm dWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVz LlwNClwNClRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuXA0KICAgXA0KPiAo MTkpIERlc2NyaWJlIHJldmlld3MgYW5kIGF1dG9tYXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRo ZSBEb2N1bWVudFwNCj4gU2hlcGhlcmQgdG8gdmFsaWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3Vt ZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWxcDQo+IGxhbmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBC TkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLlwNClwNCk5vIGF1dG9tYXRlZCBjaGVja3Ms IG90aGVyIHRoYW4gSURuaXRzLCBwZXJmb3JtZWQ7IHRoZSBkb2N1bWVudCBkb2VzIG5vdFwNCnNw ZWNpZnkgYSBwcm90b2NvbCwgYnV0IGRvY3VtZW50cyBhIGRlc2lnbiByYXRpb25hbGUufQ== --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C214xmbalnx03ciscoc_-- From sratliff@cisco.com Sun Mar 3 15:47:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D021F88B0; Sun, 3 Mar 2013 15:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCKO4IKSo5Ue; Sun, 3 Mar 2013 15:47:38 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B2AFD21F889C; Sun, 3 Mar 2013 15:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15479; q=dns/txt; s=iport; t=1362354458; x=1363564058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IyFSuPGQCw/DjZK0XWK4ROCUGh73GBBsnTaBeCFcTx4=; b=h5kMf+EfAR5KeO0x3wrnf5heccbGzS9Yun4TKkZ0y07PCfRZ/iDxBKT0 vHyM/IOa8Or+ptm+5TPOdADhbe6yE7ZxEqxLH86u7HPZQrR1inRLR202w p8xROKk4ne2zAYQpXqmYE6mvXSZhriyuOSPjaNMnLA6gXMFdGtw0/aP6R s=; X-Files: OLSRv2-Metrics-Rationale.rtf : 9514 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIrgM1GtJV2c/2dsb2JhbAA7CoJDwAd8FnOCFgkBAQEDAUUmBwcFCwIBCAMBHiQCMCUCBA4NAQWHfwYMxyaNTAaBGjEHAgKCW2EDjymDWpQvgwiBawcXBhg X-IronPort-AV: E=Sophos;i="4.84,776,1355097600"; d="rtf'212?scan'212,208,217,212";a="183224473" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 03 Mar 2013 23:47:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r23NlaJN014263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Mar 2013 23:47:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 17:47:36 -0600 From: "Stan Ratliff (sratliff)" To: "" Thread-Topic: Please publish draft-ietf-manet-olsrv2-metrics-rationale-02 Thread-Index: AQHOGGl7SX0kTayFyUCbh262WY2IzA== Date: Sun, 3 Mar 2013 23:47:36 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.213] Content-Type: multipart/mixed; boundary="_004_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "" , "manet@ietf.org List" Subject: Re: [manet] Please publish draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:47:41 -0000 --_004_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_ Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_" --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. Cut and paste error. Please publish draft-ietf-manet-olsrv2-metrics-= rationale-02 as an informational RFC. Shepherd's write-up is attached. Regards, Stan On Mar 3, 2013, at 6:42 PM, Stan Ratliff wrote: > Please publish draft-ietf-manet-foo as an Informational RFC. The shepherd= write-up is attached. > > Regards, > Stan > > --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry. Cut and paste error. Please publish draft-i= etf-manet-olsrv2-metrics-rationale-02 as an informational RFC. Shepherd's w= rite-up is attached.

Regards,
Stan






On Mar 3, 2013, at 6:42 PM, Stan Ratliff wrote:

> Please publish draft-ietf-manet-foo as an Informational RFC. The sheph= erd write-up is attached.
>
> Regards,
> Stan
>
> <OLSRv2-Metrics-Rationale.rtf>

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_-- --_004_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_ Content-Type: text/rtf; name="OLSRv2-Metrics-Rationale.rtf" Content-Description: OLSRv2-Metrics-Rationale.rtf Content-Disposition: attachment; filename="OLSRv2-Metrics-Rationale.rtf"; size=9514; creation-date="Sun, 03 Mar 2013 23:47:36 GMT"; modification-date="Sun, 03 Mar 2013 23:47:36 GMT" Content-ID: Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMTM4XGNvY29hc3VicnRmNTEwDQp7XGZv bnR0YmxcZjBcZnN3aXNzXGZjaGFyc2V0MCBIZWx2ZXRpY2E7fQ0Ke1xjb2xvcnRibDtccmVkMjU1 XGdyZWVuMjU1XGJsdWUyNTU7fQ0KXG1hcmdsMTQ0MFxtYXJncjE0NDBcdmlld3cxMDgwMFx2aWV3 aDg0MDBcdmlld2tpbmQwDQpccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2MDBc dHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRpcm5h dHVyYWwNCg0KXGYwXGZzMjQgXGNmMCBcDQo+ICgxKSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5n IHJlcXVlc3RlZCAoQkNQLCBQcm9wb3NlZCBTdGFuZGFyZCxcDQo+IEludGVybmV0IFN0YW5kYXJk LCBJbmZvcm1hdGlvbmFsLCBFeHBlcmltZW50YWwsIG9yIEhpc3RvcmljKT8gV2h5XA0KPiBpcyB0 aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/IElzIHRoaXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVk IGluIHRoZVwNCj4gdGl0bGUgcGFnZSBoZWFkZXI/XA0KXA0KVGhpcyBkb2N1bWVudCBpcyByZXF1 ZXN0ZWQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLlwNClwNCk9MU1J2 MiByZWZsZWN0cyB+OCB5ZWFycyBvZiBleHBlcmllbmNlcyB3aXRoIE9MU1IsIHB1Ymxpc2hlZCBh cyBSRkMzNjI2XA0KKEV4cGVyaW1lbnRhbCksIGFuZCBtdWx0aXBsZSBpbmRlcGVuZGVudCBpbXBs ZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1lbnRzXA0KZXhpc3QsIGFuZCB0aGlzIHByb3RvY29sIGlz IGluIGZpbmFsIHJldmlldyBieSB0aGUgSUVTRyBmb3IgcHVibGljYXRpb25cDQphcyBhIFByb3Bv c2VkIFN0YW5kYXJkLiAoVGhlIHNpbmdsZSBESVNDVVNTIG91dHN0YW5kaW5nIGlzIG5vdCByZWxh dGVkXA0KdG8gdGhlIHN1YmplY3QgbWF0dGVyIG9mIHRoaXMgZG9jdW1lbnQuKVwNClwNClRoaXMg ZG9jdW1lbnQgcHJlc2VudHMgdGhlIGRlc2lnbiByYXRpb25hbGUgYmVoaW5kIHRoZSB3YXkgaW4g d2hpY2hcDQpPTFNSdjIgaW5jb3Jwb3JhdGVkIG1ldHJpY3MuIEl0IGRvZXMgbm90IG1hbmRhdGUg YW55IHByb3RvY29sIGJlaGF2aW9ycy5cDQpcDQo+ICgyKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5v dW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCBBbm5vdW5jZW1lbnRcDQo+IFdyaXRlLVVwLiBQ bGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNl bnRcDQo+IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUgIkFjdGlvbiIgYW5ub3VuY2VtZW50 cyBmb3IgYXBwcm92ZWRcDQo+IGRvY3VtZW50cy4gVGhlIGFwcHJvdmFsIGFubm91bmNlbWVudCBj b250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOlwNClwNCj4gVGVjaG5pY2FsIFN1bW1hcnlc DQo+XA0KPiAgUmVsZXZhbnQgY29udGVudCBjYW4gZnJlcXVlbnRseSBiZSBmb3VuZCBpbiB0aGUg YWJzdHJhY3QgXA0KPiAgYW5kL29yIGludHJvZHVjdGlvbiBvZiB0aGUgZG9jdW1lbnQuIElmIG5v dCwgdGhpcyBtYXkgYmUgXA0KPiAgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZXJlIGFyZSBkZWZpY2ll bmNpZXMgaW4gdGhlIGFic3RyYWN0IFwNCj4gIG9yIGludHJvZHVjdGlvbi5cDQpcDQpUaGUgYWJz dHJhY3Qgb2YgdGhpcyBkb2N1bWVudCBpcyBpbmNsdWRlZCBiZWxvdy5cDQpcDQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgcmF0aW9uYWxlIGZvciBhbmQgZGVzaWduIGNvbnNpZGVyYXRp b25zXA0KICAgYmVoaW5kIGhvdyBsaW5rIG1ldHJpY3MgYXJlIGluY2x1ZGVkIGluIE9MU1J2Miwg aW4gb3JkZXIgdG8gYWxsb3dcDQogICByb3V0aW5nIGJ5IG90aGVyIHRoYW4gbWluaW11bSBob3Ag Y291bnQgcm91dGVzLlwNCiAgIFwNCj4gV29ya2luZyBHcm91cCBTdW1tYXJ5XA0KPlwNCj4gIFdh cyB0aGVyZSBhbnl0aGluZyBpbiBXRyBwcm9jZXNzIHRoYXQgaXMgd29ydGggbm90aW5nPyBGb3Ig XA0KPiAgZXhhbXBsZSwgd2FzIHRoZXJlIGNvbnRyb3ZlcnN5IGFib3V0IHBhcnRpY3VsYXIgcG9p bnRzIG9yIFwNCj4gIHdlcmUgdGhlcmUgZGVjaXNpb25zIHdoZXJlIHRoZSBjb25zZW5zdXMgd2Fz IHBhcnRpY3VsYXJseSBcDQo+ICByb3VnaD9cDQoJCVwNCglvCU9MU1J2MiB3YXMgZmlyc3Qgc3Vi bWl0dGVkIGFzIGFuIGluZGl2aWR1YWwgZHJhZnQgaW4gSnVseSAyMDA1XA0KCQkoZHJhZnQtY2xh dXNlbi1tYW5ldC1vbHNydjItMDApLCBhbmQgYWNjZXB0ZWQgYXMgYSBXb3JraW5nIEdyb3VwXA0K CQlkb2N1bWVudCBpbiBBdWd1c3QgMjAwNS5cDQpcDQoJbwlPTFNSdjIgaXMgY2xvc2UgdG8gYXBw cm92YWwgYXMgYSBQcm9wb3NlIFN0YW5kYXJkIGJ5IHRoZSBJRVNHXA0KICAgICAgICAgICAgICAg KG9uZSBESVNDVVNTIHRvIHJlc29sdmUpLlwNCgkJXA0KCW8JQSBrZXkgZGlmZmVyZW5jZSBiZXR3 ZWVuIFJGQzM2MjYgYW5kIE9MU1J2MiBpcyB0aGUgaW50cm9kdWN0aW9uIG9mXA0KCQlzdXBwb3J0 IGZvciBsaW5rIG1ldHJpY3MuIEFuIGluZGl2aWR1YWwgZHJhZnRcDQoJCShkcmFmdC1kZWFybG92 ZS1vbHNydjItbWV0cmljcy0wMCkgd2FzIHN1Ym1pdHRlZCBpbiAyMDA3LCBkaXNjdXNzaW5nXA0K CQl0aGUgZGVzaWduIG9wdGlvbnMsIGN1bG1pbmF0aW5nIGluIDIwMTAgd2l0aFwNCgkJZHJhZnQt ZGVhcmxvdmUtb2xzcnYyLW1ldHJpY3MtMDUgZG9jdW1lbnRpbmcgV29ya2luZyBHcm91cCBjb25z ZW5zdXNcDQoJCW9uIHRoaXMgbWF0dGVyLiBNZXRyaWNzIHN1cHBvcnQgd2FzLCB0aGVuLCBmb2xk ZWQgaW50byBPTFNSdjIuXA0KXA0KCW8JVGhpcyBkb2N1bWVudCByZXRhaW5zIGFuZCBkb2N1bWVu dHMgdGhlIGRlc2lnbiByYXRpb25hbGUsIGFuZCBpbXBvcnRhbnRcDQoJCWRlY2lzaW9ucyBmb3Ig aG93IG1ldHJpY3Mgd2VyZSBpbnRlZ3JhdGVkIGludG8gT0xTUnYyLlwNClwNCj4gRG9jdW1lbnQg UXVhbGl0eVwNCj5cDQo+ICBBcmUgdGhlcmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRo ZSBwcm90b2NvbD8gSGF2ZSBhIFwNCj4gIHNpZ25pZmljYW50IG51bWJlciBvZiB2ZW5kb3JzIGlu ZGljYXRlZCB0aGVpciBwbGFuIHRvIFwNCj4gIGltcGxlbWVudCB0aGUgc3BlY2lmaWNhdGlvbj8g QXJlIHRoZXJlIGFueSByZXZpZXdlcnMgdGhhdCBcDQo+ICBtZXJpdCBzcGVjaWFsIG1lbnRpb24g YXMgaGF2aW5nIGRvbmUgYSB0aG9yb3VnaCByZXZpZXcsIFwNCj4gIGUuZy4sIG9uZSB0aGF0IHJl c3VsdGVkIGluIGltcG9ydGFudCBjaGFuZ2VzIG9yIGEgXA0KPiAgY29uY2x1c2lvbiB0aGF0IHRo ZSBkb2N1bWVudCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiBcDQo+ICB0aGVyZSB3YXMg YSBNSUIgRG9jdG9yLCBNZWRpYSBUeXBlIG9yIG90aGVyIGV4cGVydCByZXZpZXcsIFwNCj4gIHdo YXQgd2FzIGl0cyBjb3Vyc2UgKGJyaWVmbHkpPyBJbiB0aGUgY2FzZSBvZiBhIE1lZGlhIFR5cGUg XA0KPiAgcmV2aWV3LCBvbiB3aGF0IGRhdGUgd2FzIHRoZSByZXF1ZXN0IHBvc3RlZD9cDQpcDQoJ VGhlcmUgaXMgYSBudW1iZXIgb2YgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIG9mIE9MU1J2 MiwgYXMgd2FzXA0KCWluZGljYXRlZCBpbiB0aGUgd3JpdGUtdXAgZm9yIHRoYXQgT0xTUnYyLlwN CglcDQoJVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9wb3NlIGEgcHJvdG9jb2wsIG9yIG1hbmRh dGUgcHJvdG9jb2wgYmVoYXZpb3IsXA0KCWJ1dCByYXRoZXIgcHJlc2VudHMgcGFydCBvZiB0aGUg ZGVzaWduIHJhdGlvbmFsZSBmb3IgT0xTUnYyLlwNCglcDQo+IFBlcnNvbm5lbFwNCj5cDQo+ICBX aG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkPyBXaG8gaXMgdGhlIFJlc3BvbnNpYmxlIEFyZWFc DQo+ICBEaXJlY3Rvcj9cDQpcDQpBZHJpYW4gRmFycmVsIGlzICJSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yIlwNCj8/PyA/Pz8gaXMgIkRvY3VtZW50IFNoZXBoZXJkIi5cDQpcDQo+ICgzKSBCcmll Zmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB0aGF0IHdhcyBwZXJmb3Jt ZWQgYnlcDQo+IHRoZSBEb2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBk b2N1bWVudCBpcyBub3QgcmVhZHlcDQo+IGZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4cGxhaW4g d2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG9cDQo+IHRoZSBJRVNHLlwNClwN Cj8/PyA/Pz9cDQpcDQo+ICg0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBj b25jZXJucyBhYm91dCB0aGUgZGVwdGggb3JcDQo+IGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhh dCBoYXZlIGJlZW4gcGVyZm9ybWVkPyBcDQpcDQo/Pz8gPz8/XA0KXA0KPiAoNSkgRG8gcG9ydGlv bnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb21c DQo+IGJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21w bGV4aXR5LCBBQUEsIEROUyxcDQo+IERIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/ IElmIHNvLCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXRcDQo+IHRvb2sgcGxhY2UuXA0KXA0KVGhl IGF1dGhvcnMgZG8gbm90IGJlbGlldmUgdGhhdCAtIG91dHNpZGUgdGhlIHVzdWFsIGRpcmVjdG9y YXRlIHJldmlld3NcDQpkdXJpbmcgIElFVEYgTGFzdCBDYWxsIC0gYWRkaXRpb25hbCByZXZpZXdz IGFyZSByZXF1aXJlZC5cDQpcDQo+ICg2KSBEZXNjcmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMg b3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNoZXBoZXJkXA0KPiBoYXMgd2l0aCB0aGlzIGRv Y3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgYW5kL29yIHRoZVwNCj4g SUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNoZSBp cyB1bmNvbWZvcnRhYmxlXA0KPiB3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50LCBv ciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHlcDQo+IGlzIGEgbmVlZCBmb3IgaXQu IEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZFwN Cj4gaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1 bWVudCwgZGV0YWlsIHRob3NlXA0KPiBjb25jZXJucyBoZXJlLlwNClwNCj8/PyA/Pz9cDQpcDQo+ ICg3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlh dGUgSVBSXA0KPiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRo IHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OFwNCj4gYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVl biBmaWxlZC4gSWYgbm90LCBleHBsYWluIHdoeS5cDQpcDQpBbGwgYXV0aG9ycyBoYXZlIGNvbmZp cm1lZCB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55IElQUiBuZWVkaW5nIGRpc2Nsb3N1cmUs XA0KaW5kZWVkIHRoYXQgdGhlcmUgYXJlIG5vIGtub3duIElQUiBjbGFpbXMgcmVsYXRlZCB0byB0 aGlzIGRvY3VtZW50LlwNClwNCj4gKDgpIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVk IHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50P1wNCj4gSWYgc28sIHN1bW1hcml6ZSBhbnkg V0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIElQUlwNCj4gZGlzY2xv c3VyZXMuXA0KXA0KTm8gSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVlbiBmaWxlZC5cDQpcDQo+ICg5 KSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9l cyBpdCBcDQo+IHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2 aWR1YWxzLCB3aXRoIG90aGVyc1wNCj4gYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBh IHdob2xlIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/IFwNClwNCj4gKDEwKSBIYXMgYW55 b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSBc DQo+IGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25m bGljdCBpbiBzZXBhcmF0ZVwNCj4gZW1haWwgbWVzc2FnZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFy ZWEgRGlyZWN0b3IuIChJdCBzaG91bGQgYmUgaW4gYVwNCj4gc2VwYXJhdGUgZW1haWwgYmVjYXVz ZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxlLikgXA0KXA0KPiAoMTEp IElkZW50aWZ5IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgZm91bmQgaW4g dGhpc1wNCj4gZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMv IFteXSBhbmQgdGhlIEludGVybmV0LURyYWZ0c1wNCj4gQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUg Y2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlXA0KPiB0aG9yb3Vn aC5cDQpcDQpJRG5pdHMgcmV0dXJucyBubyBlcnJvcnMgb3Igd2FybmluZ3NcDQpcDQo+ICgxMikg RGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmll d1wNCj4gY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBV UkkgdHlwZSByZXZpZXdzLlwNClwNClRoaXMgZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBhIHBy b3RvY29sLCBhIGZvcm1hdCwgYSBtZWRpYSB0eXBlIG9yIHJlc2VydmVcDQphbnkgY29kZS1wb2lu dHMuIFRodXMsIHN1Y2ggcmV2aWV3cyBhcmUgbm90IG5lZWRlZC5cDQpcDQo+ICgxMykgSGF2ZSBh bGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXNcDQo+ IGVpdGhlciBub3JtYXRpdmUgb3IgaW5mb3JtYXRpdmU/XA0KXA0KWWVzLlwNClwNCj4gKDE0KSBB cmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBy ZWFkeSBmb3JcDQo+IGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBz dGF0ZT8gSWYgc3VjaCBub3JtYXRpdmVcDQo+IHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhl IHBsYW4gZm9yIHRoZWlyIGNvbXBsZXRpb24/XA0KXA0KTm8uIFRoZXJlIGFyZSBubyBub3JtYXRp dmUgcmVmZXJlbmNlcyBpbiB0aGlzIGRvY3VtZW50LlwNClwNCj4gKDE1KSBBcmUgdGhlcmUgZG93 bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT9cDQo+ IElmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydCB0aGUgQXJl YSBEaXJlY3RvciBpbiB0aGVcDQo+IExhc3QgQ2FsbCBwcm9jZWR1cmUuIFwNClwNCk5vLiBUaGVy ZSBhcmUgbm8gbm9ybWF0aXZlIHJlZmVyZW5jZXMuIFwNClwNCkFsbCBpbmZvcm1hdGl2ZSByZWZl cmVuY2VzIGFyZSwgZnVydGhlcm1vcmUsIHRvIGFscmVhZHkgcHVibGlzaGVkIFJGQ3Mgb3JcDQpz b29uLXRvLWJlLVJGQ3MgKE9MU1J2MiBjdXJyZW50bHkgaW4gSUVTRyByZXZpZXcpXA0KXA0KPiAo MTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBv ZiBhbnlcDQo+IGV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0 bGUgcGFnZSBoZWFkZXIsIGxpc3RlZFwNCj4gaW4gdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2Vk IGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3RcDQo+IGxpc3RlZCBpbiB0 aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0 aGVcDQo+IHBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhp cyBkb2N1bWVudCB0byB0aGVcDQo+IG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGlu Zm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsXA0KPiBleHBsYWluIHdoeSB0aGUgV0cg Y29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5LlwNClwNClB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1l bnQgd2lsbCBub3QgY2hhbmdlIHRoZSBzdGF0dXMgb2YgYW55IGV4aXN0aW5nIFJGQ3MuXA0KXA0K PiAoMTcpIERlc2NyaWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFO QSBjb25zaWRlcmF0aW9uc1wNCj4gc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBp dHMgY29uc2lzdGVuY3kgd2l0aCB0aGUgYm9keSBvZiB0aGVcDQo+IGRvY3VtZW50LiBDb25maXJt IHRoYXQgYWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1lbnQgbWFrZXNcDQo+ IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcHJvcHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5B IHJlZ2lzdHJpZXMuXA0KPiBDb25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3Ry aWVzIGhhdmUgYmVlbiBjbGVhcmx5XA0KPiBpZGVudGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkg Y3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhXA0KPiBkZXRhaWxlZCBzcGVjaWZpY2F0 aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUgcmVnaXN0cnksIHRoYXRcDQo+IGFs bG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFyZSBkZWZpbmVk LCBhbmQgYVwNCj4gcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVu IHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS5cDQpcDQpUaGlzIGRvY3VtZW50IGhhcyBubyBhY3Rp b25zIGZvciBJQU5BLlwNClwNCj4gKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRo YXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvciBmdXR1cmVcDQo+IGFsbG9jYXRpb25zLiBQcm92 aWRlIGFueSBwdWJsaWMgZ3VpZGFuY2UgdGhhdCB0aGUgSUVTRyB3b3VsZCBmaW5kXA0KPiB1c2Vm dWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVz LlwNClwNClRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuXA0KICAgXA0KPiAo MTkpIERlc2NyaWJlIHJldmlld3MgYW5kIGF1dG9tYXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRo ZSBEb2N1bWVudFwNCj4gU2hlcGhlcmQgdG8gdmFsaWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3Vt ZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWxcDQo+IGxhbmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBC TkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLlwNClwNCk5vIGF1dG9tYXRlZCBjaGVja3Ms IG90aGVyIHRoYW4gSURuaXRzLCBwZXJmb3JtZWQ7IHRoZSBkb2N1bWVudCBkb2VzIG5vdFwNCnNw ZWNpZnkgYSBwcm90b2NvbCwgYnV0IGRvY3VtZW50cyBhIGRlc2lnbiByYXRpb25hbGUufQ== --_004_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2A8xmbalnx03ciscoc_-- From sratliff@cisco.com Sun Mar 3 15:50:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D27C21F88E1; Sun, 3 Mar 2013 15:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.75 X-Spam-Level: X-Spam-Status: No, score=-7.75 tagged_above=-999 required=5 tests=[AWL=-0.250, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPwzxh7qI8N2; Sun, 3 Mar 2013 15:50:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6986D21F88C4; Sun, 3 Mar 2013 15:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5313; q=dns/txt; s=iport; t=1362354633; x=1363564233; h=from:to:cc:subject:date:message-id:mime-version; bh=AvVJDyTPpnicviFLzARrbM0arMJqKgh51fVR06kEXio=; b=O4L5YpFh252Flnx6JuwnsLKlnrNbzV0JkmE2VbCshzybNX84IzwSHL3d SqsaznfSDFcYPH8evDK5kczEZNTHkJd25WNCaeNa7CwJQKcl1dT9BXi4l J23JkdtSSKSVizFWy7AzBrk10Pbr3M9mNpDdmlja+tv5s0u9tDhTQOm5M 8=; X-Files: OLSRv2-MIB-shepherd-doc copy.txt : 3231 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEXhM1GtJV2a/2dsb2JhbABFwkp8FnOCIQEEaw4SASomMCcEDgUIBogFxzKObDGCZmEDjymYCYMIgic X-IronPort-AV: E=Sophos;i="4.84,776,1355097600"; d="txt'?scan'208";a="183013121" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 03 Mar 2013 23:50:15 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r23NoFGO002146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Mar 2013 23:50:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 17:50:14 -0600 From: "Stan Ratliff (sratliff)" To: "ietf-secretary@ietf.org" Thread-Topic: Please publish draft-ietf-manet-olsrv2-mib-05 Thread-Index: AQHOGGnZl+YUkuyOa0+tnmzv/4NoIw== Date: Sun, 3 Mar 2013 23:50:14 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2CB@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.213] Content-Type: multipart/mixed; boundary="_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2CBxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "" , "manet@ietf.org List" Subject: [manet] Please publish draft-ietf-manet-olsrv2-mib-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:50:37 -0000 --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2CBxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: <4D33270FB5834E45A10C302F5178EF58@cisco.com> Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-olsrv2-mib-05 as an Informational RFC. The Shephe= rd's write-up is attached.=20 Regards, Stan --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2CBxmbalnx03ciscoc_ Content-Type: text/plain; name="OLSRv2-MIB-shepherd-doc copy.txt" Content-Description: OLSRv2-MIB-shepherd-doc copy.txt Content-Disposition: attachment; filename="OLSRv2-MIB-shepherd-doc copy.txt"; size=3231; creation-date="Sun, 03 Mar 2013 23:50:14 GMT"; modification-date="Sun, 03 Mar 2013 23:50:14 GMT" Content-ID: Content-Transfer-Encoding: base64 Q2hhbmdlcyBhcmUgZXhwZWN0ZWQgb3ZlciB0aW1lLiBUaGlzIHZlcnNpb24gaXMgZGF0ZWQgSmFu dWFyeSA5LCAyMDEzLg0gKDEuYSkgU3RhbiBSYXRsaWZmIChzcmF0bGlmZkBjaXNjby5jb20pIGlz IHRoZSBkb2N1bWVudCBzaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudC4gVGhlIHNoZXBoZXJkIGhh cyBwZXJzb25hbGx5IHJldmlld2VkIHRoZSBkb2N1bWVudCwgYW5kIGJlbGlldmVzIGl0IGlzIHJl YWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4NICgxLmIpIFRo ZSBkb2N1bWVudCBoYXMgaGFkIGFkZXF1YXRlIHJldmlldyBmcm9tIGJvdGgga2V5IHdvcmtpbmcg Z3JvdXAgbWVtYmVycyBhbmQgZnJvbSBrZXkgbm9uLVdHIG1lbWJlcnMuIFRoZSBzaGVwaGVyZCBk b2VzIG5vdCBoYXZlIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZiB0 aGUgcmV2aWV3cyB0aGF0IGhhdmUgYmVlbiBwZXJmb3JtZWQuDSAoMS5jKSBUaGUgc2hlcGhlcmQg ZG9lcyBub3QgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50IG5lZWRpbmcgYWRk aXRpb25hbCByZXZpZXcuIA0gKDEuZCkgVGhlIHNoZXBoZXJkIGRvZXMgbm90IGhhdmUgYW55IGNv bmNlcm5zIG9yIGlzc3VlcyB3aXRoIHRoZSBkb2N1bWVudCB0aGF0IHRoZSByZXNwb25zaWJsZSBB cmVhIERpcmVjdG9yIG9yIHRoZSBJRVNHIG5lZWQgdG8gYmUgYXdhcmUgb2YuIElQUiBkaXNjbG9z dXJlcyB3ZXJlIG5vdCBuZWNlc3NhcnksIHRoZXJlZm9yZSwgbm9uZSBoYXZlIGJlZW4gZmlsZWQu IA0gKDEuZSkgV29ya2luZyBncm91cCBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQgaXMg c29saWQuIFRoZSBkb2N1bWVudCByZXByZXNlbnRzIHN0cm9uZyBjb25jdXJyZW5jZSBvZiB0aGUg d29ya2luZyBncm91cCBhcyBhIHdob2xlLCB0aGUgdGhlIFdHIHVuZGVyc3RhbmRzIGFuZCBhZ3Jl ZXMgd2l0aCB0aGUgZG9jdW1lbnQuDSAoMS5mKSBObyBvbmUgaGFzIHRocmVhdGVuZWQgYXBwZWFs IG9yIGhhcyBpbmRpY2F0ZWQgZGlzY29udGVudCB3aXRoIHRoZSBkb2N1bWVudC4gDSAoMS5nKSBU aGUgZG9jdW1lbnQgc2hlcGhlcmQgaGFzIHJ1biB0aGUgImlkbml0cyIgdG9vbCBhZ2FpbnN0IHRo ZSBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGhhcyBtZXQgYWxsIHJlcXVpcmVkIGZvcm1hbCByZXZp ZXcgY3JpdGVyaWEuIA0gKDEuaCkgVGhlIGRvY3VtZW50IGhhcyBzcGxpdCBpdHMgcmVmZXJlbmNl cyBpbnRvIG5vcm1hdGl2ZSBhbmQgaW5mb3JtYXRpdmUuIFRoZXJlIGlzIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSB0byBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi0xNywgd2hpY2ggaXMgY3VycmVudGx5 IGluIElFU0cgZXZhbHVhdGlvbiwgd2l0aCAgb25lIERJU0NVU1MgYnV0IGVub3VnaCB2b3RlcyB0 byBwYXNzLCBvbmNlIHRoZSBESVNDVVNTIGlzIHJlc29sdmVkLiBUaGUgc2hlcGFyZCBpcyBjb25m aWRlbnQgdGhhdCBPTFNSdjIgd2lsbCBiZSBwdWJsaXNoZWQgc29vbi4gT3RoZXIgdGhhbiB0aGF0 LCB0byB0aGUgc2hlcGhlcmQncyBrbm93bGVkZ2UsIHRoZXJlIGFyZSBubyBub3JtYXRpdmUgcmVm ZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCBhcmUgbm90IHJlYWR5IGZvciBhZHZhbmNlbWVudCBv ciBhcmUgaW4gYW4gdW5jbGVhciBzdGF0ZS4gVGhlcmUgYXJlIG5vIGRvd253YXJkIHJlZmVyZW5j ZXMuIA0gKDEuaSkgVGhlIHNoZXBoZXJkIGhhcyB2ZXJpZmllZCB0aGF0IGRvY3VtZW50IElBTkEg Y29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cywgYW5kIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUg Ym9keSBvZiB0aGUgZG9jdW1lbnQuIE5vIHByb3RvY29sIGV4dGVuc2lvbnMgYXJlIHJlcXVlc3Rl ZC4gVGhlIG5lY2Vzc2FyeSBJQU5BIHJlZ2lzdHJpZXMgYXJlIGNsZWFybHkgZGVmaW5lZC4gTm8g bmV3IHJlZ2lzdHJpZXMgYXJlIHJlcXVlc3RlZC4gTm8gZXhwZXJ0IHJldmlldyBoYXMgYmVlbiBy ZXF1ZXN0ZWQuIA0gKDEuaikgVGhlIGRvY3VtZW50IGhhcyBiZWVuIHJ1biB0aHJvdWdoIHRoZSAi c21pbGludCIgY2hlY2tlci4gV2FybmluZ3MgZXhpc3QgZHVlIHRvIHJlZmVyZW5jZXMgdG8gIkZM T0FULVRDLU1JQiIsIGhvd2V2ZXIsIHRob3NlIHJlZmVyZW5jZXMgYXBwZWFyIHRvIGJlIGR1ZSB0 byBhIGRlZmljaWVuY3kgb2YgdGhlIHRvb2wgKGUuZy4sIFJGQzYzNDAgaXMgJ3RvbyBuZXcnIHRv IGJlIGluIHZpZXcgYnkgdGhlIHRvb2wpLiANICgxLmspIFRoZSBJRVNHIGFwcHJvdmFsIGFubm91 bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4gUGxlYXNl IHByb3ZpZGUgc3VjaCBhIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50IGV4 YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBw cm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBm b2xsb3dpbmcgc2VjdGlvbnM6IA0gICBUZWNobmljYWwgU3VtbWFyeSBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBwb3J0aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikg Zm9yIHVzZSB3aXRoIHRoZSBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nIFByb3RvY29sIHZl cnNpb24gMiBkZXZlbG9wZWQgaW4gdGhlIE1BTkVUIHdvcmtpbmcgZ3JvdXAuDSAgIFdvcmtpbmcg R3JvdXAgU3VtbWFyeSBUaGUgcHJvY2VzcyBmb3IgcmVhY2hpbmcgd29ya2luZyBncm91cCBjb25z ZW5zdXMgb24gdGhpcyB3YXMgc21vb3RoOyBubyBjb250cm92ZXJzeSBleGlzdGVkLiBXb3JraW5n IGdyb3VwIGNvbnNlbnN1cyBiZWhpbmQgdGhlIGRvY3VtZW50IGlzIHNvbGlkLiANICAgRG9jdW1l bnQgUXVhbGl0eSBUaGlzIGRvY3VtZW50IHNoZXBoZXJkIGlzIG5vdCBhd2FyZSBvZiBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBNSUIuIFJldmlldyBieSBNSUIgZG9jdG9yIHdhcyBk aXNjdXNzZWQgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwLCBob3dldmVyLCB0aGUgV0cgY29uc2Vu c3VzIHdhcyB0aGF0IHRoaXMgcmV2aWV3IHdhcyB1bm5lY2Vzc2FyeSwgYXMgdGhlIFdHIGNvbnRh aW5zIHN1ZmZpY2llbnQgZXhwZXJ0aXNlIHRvIGRldGVybWluZSBhcHBsaWNhYmlsaXR5IG9mIGFs bCBvYmplY3RzLCBhbmQgY29ycmVjdG5lc3Mgb2YgdGhlIE1JQi4N --_002_2ED1D3801ACAAB459FDB4EAC9EAD090C1003C2CBxmbalnx03ciscoc_-- From yuanpingzhu0101@gmail.com Mon Mar 4 00:26:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0812621F8916 for ; Mon, 4 Mar 2013 00:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH8cVltsCpRr for ; Mon, 4 Mar 2013 00:26:55 -0800 (PST) Received: from mail-vc0-f196.google.com (mail-vc0-f196.google.com [209.85.220.196]) by ietfa.amsl.com (Postfix) with ESMTP id 856BE21F8910 for ; Mon, 4 Mar 2013 00:26:55 -0800 (PST) Received: by mail-vc0-f196.google.com with SMTP id fy7so685487vcb.7 for ; Mon, 04 Mar 2013 00:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=bNP2xVtw5K4C1FiWNLjm/g53b0QTINUb/9Fu8w0T8jw=; b=jr8InBMJx/6NXMmjkW9zIVAW1HVn8JoZUd+QdUcMzA/gkl5mQ8pU+AfNlYBV0/Pjmz X0wpqBSfGaqPR1HTND2r++Lpz2evVh3KsORYzdjNcHX81b3WZ2Yx3r7EuueicaPr5CWi ksV5mNqtJ2cWVIHgT3VYzs9SyizexWaLY0CxSRDCRdqSMTGtYsbLWx6R+bDyVYLq2x/k 0k7PvA99rPqpVYdGKLd7O2Ml2QnRzObwFgSWZf/HLUXmnMfotwJebf/TuRgWcpOA88p1 +uAwOJ8GffP0rKMP7nlOkZLsp/qHZxzz3j9hqhEGiANRnn4F/g5NP/7KYokZSPrWsko0 usQQ== MIME-Version: 1.0 X-Received: by 10.52.24.229 with SMTP id x5mr6458592vdf.84.1362385614959; Mon, 04 Mar 2013 00:26:54 -0800 (PST) Received: by 10.58.232.202 with HTTP; Mon, 4 Mar 2013 00:26:54 -0800 (PST) Date: Mon, 4 Mar 2013 16:26:54 +0800 Message-ID: From: Yuanping Zhu To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3810a0776704d7151e70 Subject: [manet] IEEE GreenCom 2013 Call for Workshop Proposals X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:26:57 -0000 --20cf307f3810a0776704d7151e70 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable *IEEE GreenCom **2013 Call for Workshop Proposals*** *Deadline: April 5, 2013* * * [My apologies if you have received multiple copies of this message] The 2013 IEEE International Conference on Green Computing and Communications (GreenCom 2013) will be held in Beijing, China, during August 20-23, 2013 (http://www.china-iot.net/GreenCom2013.htm). In addition to technical sessions, the program will also include a set of workshops. The goal of the workshops is to explore emerging research topics, and to provide a forum for authors to present early research results on those topics. Workshop papers are expected to focus on more specific research areas than those in the main conference. GreenCom welcomes returning workshops which have successfully appeared in previous conferences, as well as workshop proposals on non-green topics. Workshops can be full-day or half-day, with 4 or 2 sessions, respectively. The dates for paper submissio= n, notification and camera-ready paper submission should be stated in the proposal; note that camera-ready papers must be received no later than July 10, 2013. All GreenCom 2013 workshop papers will appear in IEEE Xplore database and will be EI indexed. Web pages of the accepted workshops will reside on the official IEEE GreenCom 2013 website ( http://www.china-iot.net/GreenCom2013.htm). -------------------------------------- Workshop papers are to be submitted through the EDAS (http://edas.info/) Submission Format Instructions: Paper length: Up to 6 pages without overlength charges, a maximum of 2 extra pages will be allowed with an overlength charge of US$30.00 per page. Paper format: Papers should be written in English following the IEEE CS format. Formatting instructions and templates: http://www.computer.org/portal/web/cscps/formatting -------------------------------------- A workshop proposal, in plain text or PDF, should provide the following information: 1. Title, scope and topics of the workshop 2. Names, addresses, and affiliation of workshop organizers 3. Tentative committee lists 4. Workshop format planned (papers, demos, panels, etc.) 5. Past history of the workshop if any (where held, number of papers, number of participants) 6. Rationale - why is the topic relevant of current interest; why is the workshop expected to attract a significant number of submissions of good quality. 7. Please also include a draft call for paper. Workshop organizers should send their workshop proposals to Workshop Co-Chairs by email by April 5, 2013. Please include in the email subject = =93 GreenCom 2013 Workshop Proposals=94. Notification of acceptance for worksho= p proposals will be on April 10, 2013. Workshop Co-Chairs: Dr. Xiaoli Chu, The University of Sheffield, UK, Email: x.chu@sheffield.ac.uk Dr. Guoqiang Mao, The University of Sydney, Australia, Email: guoqiang.mao@sydney.edu.au Dr. Yang Yang, Shanghai Research Center for Wireless Communications, China, Email: yangyang@ieee.org --20cf307f3810a0776704d7151e70 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

IEEE Green= Com 2013 Call for Workshop Proposals

Deadline: April 5, 2013

=A0

[My apologies if you have receiv= ed multiple copies of this message]

=A0

The 2013 IEEE International Conf= erence on Green Computing and Communications (GreenCom 2013) will be held in Beijing, China, during Augus= t 20-23, 2013 (http://w= ww.china-iot.net/GreenCom2013.htm). In addition to technical sessions, the program will also include a set of workshops. The g= oal of the workshops is to explore emerging research topics, and to provide a forum for authors to present early research results on those topics. Workshop pape= rs are expected to focus on more specific research areas than those in the main conference. GreenCom welcomes returning workshops which have success= fully appeared in previous conferences, as well as workshop proposals on non-gree= n topics. Workshops can be full-day or half-day, with 4 or 2 sessions, respectively. The dates for paper submission= , notification and camera-ready paper submission should be stated in the proposal; note that camera-ready papers must be received no l= ater than July 10, 2013. All GreenCom 2013 workshop papers will appear in IEEE Xplore database and will be EI indexed. Web pages of the accepted work= shops will reside on the official IEEE GreenCom 2013 website (http://www.china-iot.net/GreenCom2013.htm).= =

=A0

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

Workshop papers are to be submit= ted through the EDAS (http://edas.info/)<= /span>

=A0

Submission Format Instructions:<= /span>

Paper length: Up to 6 pages with= out overlength charges, a maximum of 2 extra pages will be allowed with an overlength charge of US$30.00 per page.=

=A0

Paper format:=A0 Papers should b= e written in English following the IEEE CS format. Formatting instructions an= d templates: = http://www.computer.org/portal/web/cscps/formatting

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

=A0

A works= hop proposal, in plain text or PDF, should provide the following information:

1.=A0=A0=A0=A0=A0=A0= =A0 Title, scope and topics of the workshop

2.=A0=A0=A0=A0=A0=A0= =A0 Names, addresses, and affiliation of workshop organizers

3.=A0=A0=A0=A0=A0=A0= =A0 Tentative committee lists

4.=A0=A0=A0=A0=A0=A0= =A0 Workshop format planned (papers, demos, panels, etc.)

5.=A0=A0=A0=A0=A0=A0= =A0 Past history of the workshop if any (where held, number of papers, number of participant= s)

6.=A0=A0=A0=A0=A0=A0= =A0 Rationale - why is the topic relevant of current interest; why is the workshop expected= to attract a significant number of submissions of good quality. =

7.=A0=A0=A0=A0=A0= =A0=A0 Please also include a draft call for paper.

=A0

Workshop orga= nizers should send their workshop proposals to Workshop Co-Chairs by email by April 5, 2013. Please include in the email subject =93GreenCom 2013 Wo= rkshop Proposals=94. Notification of acceptance for workshop proposals will be on April 10, 201= 3.

Workshop Co-C= hairs:

Dr. Xiaoli<= span lang=3D"EN-US" style=3D"font-family:'Times New Roman',serif"> = Chu, The University of Sheffield, UK, Email: =A0x.chu@sheffield.ac.uk

Dr. Guoqiang Mao, The University of Sydney, Australia, Email: guoqiang.mao@sydney.edu.au

Dr. Yang Yang, Shanghai Research Center for Wireless Communications, China, Email: <= a href=3D"mailto:yangyang@ieee.org">yangyang@ieee.org

--20cf307f3810a0776704d7151e70-- From sratliff@cisco.com Tue Mar 5 07:11:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E121F89D3 for ; Tue, 5 Mar 2013 07:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM+6PV6hAYhe for ; Tue, 5 Mar 2013 07:11:04 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BA55F21F8904 for ; Tue, 5 Mar 2013 07:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5315; q=dns/txt; s=iport; t=1362496263; x=1363705863; h=from:to:subject:date:message-id:references:mime-version; bh=hmJU/+/QcvrmCeC8+2J1I0g99ss5lUphm7EB8d6K6W4=; b=DsidwzHJwDkrRbvjiCGPcZYeKtDWoL8vP7ZGIWGxDH2ELCu75eoj7UoN WMD341NjT/e+MUB4cyWmq9BNtlqefgP55S2Wz/EUweMfZCnKTtbsfunj6 TqiUgJWaW0vjZf1na2mC+Jk2hvaEFuclJe/8GZPk8gAI9nGGmVEDAWDq/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANsJNlGtJV2Y/2dsb2JhbABEwlOBAhZzgh8BAQEEbgUWAgEZAwECCx0HIREUBwIIAgQTCId5Aw+tUoZODYlajESBB4EQIBcHgllhA5RqjTaFGIMIgWkJFwMb X-IronPort-AV: E=Sophos;i="4.84,787,1355097600"; d="scan'208,217";a="183944294" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2013 15:11:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r25FB35f021667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Mar 2013 15:11:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 09:11:02 -0600 From: "Stan Ratliff (sratliff)" To: "manet@ietf.org List" Thread-Topic: Public Warning under RFC 3934 Thread-Index: AQHOGbOmThHH/H/ACU2+ZD44FnIUGg== Date: Tue, 5 Mar 2013 15:11:02 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76F@xmb-aln-x03.cisco.com> References: <5FE80271-96B9-4D46-B2DC-47331C10CACD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.124] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76Fxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [manet] Fwd: Public Warning under RFC 3934 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:11:11 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76Fxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: From: Stan Ratliff > Subject: Public Warning under RFC 3934 Date: March 5, 2013 10:05:03 AM EST To: Abdussalam Baryun > Cc: >, "> Adrian" >, "Stewart Bryant (stbryant)" > Abdussalam, There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your pos= ts typically do not contain sufficient content to advance the discussion. Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by r= easoned technical arguments. If you are unable to do this or continue to po= st in the same volume and/or style, the chairs will follow with a suspensio= n of your posting privileges. Sincerely, Stan --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76Fxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3932581A0FE2524EA364BC6029077452@cisco.com> Content-Transfer-Encoding: quoted-printable

Begin forwarded message:

From: Stan = Ratliff <sratliff@cisco.com>= ;
Subject: Pu= blic Warning under RFC 3934
Date: March= 5, 2013 10:05:03 AM EST
To: Abdus= salam Baryun <abdussalamba= ryun@gmail.com>
Cc: <<= a href=3D"mailto:manet-chairs@tools.ietf.org">manet-chairs@tools.ietf.org>, "<adrian@olddog.co.u= k> Adrian" <adrian@ol= ddog.co.uk>, "Stewart Bryant (stbryant)" <stbryant@cisco.com>

Abdussalam,

There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your posts typically do not contain suffi= cient content to advance the discussion.

Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by reasoned technical arguments. If you= are unable to do this or continue to post in the same volume and/or style,= the chairs will follow with a suspension of your posting privileges.

Sincerely,
Stan

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76Fxmbalnx03ciscoc_-- From henning.rogge@fkie.fraunhofer.de Tue Mar 5 22:39:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47F221F85BC for ; Tue, 5 Mar 2013 22:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytnArStYqY5B for ; Tue, 5 Mar 2013 22:39:10 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C621F85BB for ; Tue, 5 Mar 2013 22:39:09 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UD80I-0005Aw-Jj; Wed, 06 Mar 2013 07:39:06 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UD80I-0007l6-H4; Wed, 06 Mar 2013 07:39:06 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 6 Mar 2013 07:39:06 +0100 Message-ID: <5136E488.9040104@fkie.fraunhofer.de> Date: Wed, 6 Mar 2013 07:39:04 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010007050800000202070100" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16790/Wed Mar 6 04:50:05 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: fb1b735a18614dc364f28f1a7f4db999 Cc: Stan Ratliff Subject: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 06:39:11 -0000 --------------ms010007050800000202070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Stan, could you maybe say something about the status of DLEP-04 before the=20 IETF starts in Orlando? I fear that our time will be (again) spent with=20 different things and I was/am looking forward to the draft. DLEP is really important to our current project. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010007050800000202070100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAzMDYwNjM5MDRaMCMGCSqGSIb3DQEJBDEWBBScEN3SBD+o5aTtRuE6URy8NH1ZGTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAcGgtzM1ChsIhE/UqQoKnDHNP0+g4PpPPOJ7aqMdkRULU ehOLnKsA1uUB9tYczwpqj01Fpnb/HDPxlJdhxsVDRcDj3AzFw9NH2twilao7ZzBChXFZRKj2 kuGpX2pQDbhwuj0oWvZKxOs/AXeY0zuMt78H9+kLFonQDDkdcV/SCwX982+W8fdDVKcT3eoP sjz+BktVxfDE4dYo6XJpBTP4JZp/Aj0HOrhie8jCbk5B/K+lCUr+ZhO/n0+NyxDccpPcLvoM dwUTQqZeybUdl3hp5JEUO85pVZtDU+GkWO5Qw3YSxmwQL2EL0zSOrjr0eUhipQaUOfMi4GGQ XCDosGbu2QAAAAAAAA== --------------ms010007050800000202070100-- From abdussalambaryun@gmail.com Wed Mar 6 01:01:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C453121F8617 for ; Wed, 6 Mar 2013 01:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQCrrinv7gmp for ; Wed, 6 Mar 2013 01:01:39 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id CD58921F8615 for ; Wed, 6 Mar 2013 01:01:38 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so5704762pbc.38 for ; Wed, 06 Mar 2013 01:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uq/fpq3IJAC6qOFe3ZF7HADy41W0yt1qfv14SIJp8Dg=; b=XcEFXtYQlxEEloTd1LVL4ZhhL+4Rk5UqetOy3nGUADLJXfqWu+q1lX9FehBt1w0Fdx DsBthkGVVEegZNDQD2z7Xfahh7kgZav9qK3Ndx0LRA3vZAODjXTpN8M4NZcVO1FQ3rb8 +4Vyt0OblXhIITjNk5jyqvwl4Dm/6QJ0zOsk8vychUds7M1ZhvWPm6gUNyeJ+ynBr4Nw ER5l+fdU3jL1Op1FXBmZZ7YSoFIOxF3q8b6P7fn1wkHSLUhBY5eY4zkhQ4o5uYXyG1q4 l0lEdmPOWixCVJiZ0gHtDHaVzYdpE1BGJdXIOXuEJKBwGba0XzcxV1F5JoJdPBbSRTyl UdrQ== MIME-Version: 1.0 X-Received: by 10.68.196.1 with SMTP id ii1mr35856962pbc.93.1362560498574; Wed, 06 Mar 2013 01:01:38 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 6 Mar 2013 01:01:38 -0800 (PST) In-Reply-To: <5136E488.9040104@fkie.fraunhofer.de> References: <5136E488.9040104@fkie.fraunhofer.de> Date: Wed, 6 Mar 2013 09:01:38 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bd6c73e81617904d73dd677 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 09:01:39 -0000 --047d7bd6c73e81617904d73dd677 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ***Comment*** I agree with Henning, ***Reason**** There was no reply to some input; http://www.ietf.org/mail-archive/web/manet/current/msg14733.html ******* AB On Wed, Mar 6, 2013 at 6:39 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi Stan, > > could you maybe say something about the status of DLEP-04 before the IETF > starts in Orlando? I fear that our time will be (again) spent with > different things and I was/am looking forward to the draft. > > DLEP is really important to our current project. > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7bd6c73e81617904d73dd677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
***Comment***
I agree with Henning,
=A0
= ***Reason****
There was no reply to some input;
=A0
*******
AB

On Wed, Mar 6, 2013 at 6:39 AM, Henning Rogge <henning= .rogge@fkie.fraunhofer.de> wrote:
Hi Stan,

could you maybe say something about the status of DLEP-04 before the IETF s= tarts in Orlando? I fear that our time will be (again) spent with different= things and I was/am looking forward to the draft.

DLEP is really important to our current project.

Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7bd6c73e81617904d73dd677-- From sratliff@cisco.com Wed Mar 6 06:57:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11221F8934 for ; Wed, 6 Mar 2013 06:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCo+oO1psoFy for ; Wed, 6 Mar 2013 06:57:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5557B21F8922 for ; Wed, 6 Mar 2013 06:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1284; q=dns/txt; s=iport; t=1362581841; x=1363791441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tFzPSZ+tqGjnua/j8lyiTvqXcT0MFSm5eE+/Do1mX50=; b=AWXgGRxQi6sSNj+sxFq2wmQpvb3h7jDcIhyz10/2u//tjBvU5i+MYaVR vtGF5EG4trmpusSuS8aNm+TbZZEjv+kZhRnHqW0mBoqcTaihLBtQ/anjS r7DAYat/g54n/4xvqL4cgLuPI93OkXZF8TpvrSd7PKnz0fuVlG49a9vWi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPlYN1GtJXHA/2dsb2JhbABExEOBWBZzgioBAQEDAXkFCwIBCCIdBzIUEQIEDgUIiAUGvHiOWQIxB4JfYQOINp8FgwiCJw X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184404881" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 06 Mar 2013 14:57:00 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r26EuxTG019807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 14:57:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 08:56:59 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: Status of DLEP draft 04? Thread-Index: AQHOGjVRLERmjuwL0EKU1z9/q/ypFpiZJeAA Date: Wed, 6 Mar 2013 14:56:58 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> References: <5136E488.9040104@fkie.fraunhofer.de> In-Reply-To: <5136E488.9040104@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.124] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:57:22 -0000 Henning,=20 I believe the cutoff for submitting new drafts for this IETF has already pa= ssed. So no, there won't be a DLEP-04 before Orlando.=20 I apologize to the working group for this; it's just a simple matter of tim= e. I've been pressed on several other issues, including the reactive protoc= ol draft, and just haven't got to it. However, i promise we (the co-authors= ) will get on it, and produce a draft when the website opens up after ORL.= =20 And Henning, if you are going to be in ORL, perhaps we could chat about DLE= P. Regards, Stan On Mar 6, 2013, at 1:39 AM, Henning Rogge wrote: > Hi Stan, >=20 > could you maybe say something about the status of DLEP-04 before the IETF= starts in Orlando? I fear that our time will be (again) spent with differe= nt things and I was/am looking forward to the draft. >=20 > DLEP is really important to our current project. >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From hrogge@googlemail.com Wed Mar 6 06:59:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8F21F8739 for ; Wed, 6 Mar 2013 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6mKgvUjVZyF for ; Wed, 6 Mar 2013 06:59:44 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEFAE21F85FE for ; Wed, 6 Mar 2013 06:59:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so5773331lbj.3 for ; Wed, 06 Mar 2013 06:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=ytzr6GhS4JDkGe085A4B7rGROie8u/VTPAD3NwUXpI4=; b=0L1oDa/FE0tsaw7GVCz7xyOfnGFHFYo26tsh8c5TFRRDiAjkhEVgd6xegGxhD7pHhA zNToVe959TwxRmrIosnOtw5cZV06jtKYBSgOlLNtvNn858RYAeA9SewX6ZVL5IaAXdys jgzhQXce7dn8F0Vnw8G7qNczEDdzSliCqo5Vd24owFKVzPAM66EKsYztQowotFqMaVjF V+d8JkxBy24dyR7Q4zeS4kw8iC7rYU/q7Ua4gw8vwkBogwxLo+1O6Zx2in/sEaTzn4+I Ewn9tvIyaNWmsFDmzBvMVaPWDbwjYSLWRTiVKd+M0Fz5ZRH1wO+aVA2Rt9I+F0yAJ3r+ gg5w== X-Received: by 10.152.148.133 with SMTP id ts5mr2162931lab.2.1362581980787; Wed, 06 Mar 2013 06:59:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Wed, 6 Mar 2013 06:59:19 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> References: <5136E488.9040104@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Wed, 6 Mar 2013 15:59:19 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:59:45 -0000 On Wed, Mar 6, 2013 at 3:56 PM, Stan Ratliff (sratliff) wrote: > Henning, > > I believe the cutoff for submitting new drafts for this IETF has already = passed. So no, there won't be a DLEP-04 before Orlando. I am not asking for DLEP-04... just a statement when we might get it would be fine. > I apologize to the working group for this; it's just a simple matter of t= ime. I've been pressed on several other issues, including the reactive prot= ocol draft, and just haven't got to it. However, i promise we (the co-autho= rs) will get on it, and produce a draft when the website opens up after ORL= . Okay... I am looking forward to it. > And Henning, if you are going to be in ORL, perhaps we could chat about D= LEP. Unfortunately not. The next IETF I will be able to attend will be the one in Berlin this year. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From sratliff@cisco.com Wed Mar 6 07:19:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981621F85D4 for ; Wed, 6 Mar 2013 07:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZm5bl93y-r2 for ; Wed, 6 Mar 2013 07:19:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5F21F8573 for ; Wed, 6 Mar 2013 07:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1362583175; x=1363792775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=l6kd2y0M/9S+UAVyEJLaSMTUQ/T7NkOZGgZf2H8o8PU=; b=awbkD47cXPxUZJEbWc0/jSLCcwfwbGq4W3TSkqZ4viQn5snVzxiEkxGS TeP0z0vGVBptBvouUs9A3Q8E81SJjLH1II7vWo2CHL+BPPhsyUiqL2hU5 EvpPIqCtCByA8vfFIVt3gdQ/nA+9CGV+KzIBHa8TzjSzlfl/pPv0cSzSD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALpdN1GtJV2Y/2dsb2JhbABExEOBWBZzgioBAQEDAXkFCwIBCA4KCiQyJQIEDgUIiAUGvQCOWQIxB4JfYQOINp8FgwiCJw X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184416322" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 06 Mar 2013 15:19:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r26FJYQr010315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 15:19:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 09:19:34 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP draft 04? Thread-Index: AQHOGjVRLERmjuwL0EKU1z9/q/ypFpiZJeAAgAAApYCAAAWpAA== Date: Wed, 6 Mar 2013 15:19:34 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1004139B@xmb-aln-x03.cisco.com> References: <5136E488.9040104@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.124] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <383BE57213C033498DA6362E364D4CE4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:19:41 -0000 On Mar 6, 2013, at 9:59 AM, Henning Rogge wrote: > On Wed, Mar 6, 2013 at 3:56 PM, Stan Ratliff (sratliff) > wrote: >> Henning, >>=20 >> I believe the cutoff for submitting new drafts for this IETF has already= passed. So no, there won't be a DLEP-04 before Orlando. >=20 > I am not asking for DLEP-04... just a statement when we might get it > would be fine. I've got some time to work on it this week; that plus next week (out of the= office, focused on IETF stuff anyway, you know the drill) means I'm shooti= ng for somewhere around Mar. 22.=20 Hope that works.=20 Regards, Stan >=20 >> I apologize to the working group for this; it's just a simple matter of = time. I've been pressed on several other issues, including the reactive pro= tocol draft, and just haven't got to it. However, i promise we (the co-auth= ors) will get on it, and produce a draft when the website opens up after OR= L. >=20 > Okay... I am looking forward to it. >=20 >> And Henning, if you are going to be in ORL, perhaps we could chat about = DLEP. >=20 > Unfortunately not. >=20 > The next IETF I will be able to attend will be the one in Berlin this yea= r. >=20 > Henning Rogge >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan From prvs=6777784c97=bcheng@ll.mit.edu Wed Mar 6 07:24:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96321F8A7E for ; Wed, 6 Mar 2013 07:24:09 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-M5P6sf2Uqy for ; Wed, 6 Mar 2013 07:24:08 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75121F8A5A for ; Wed, 6 Mar 2013 07:24:07 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r26FO4JE032567; Wed, 6 Mar 2013 10:24:05 -0500 From: "Cheng, Bow-Nan - 0665 - MITLL" To: "Stan Ratliff (sratliff)" , Henning Rogge Date: Wed, 6 Mar 2013 10:24:00 -0500 Thread-Topic: [manet] Status of DLEP draft 04? Thread-Index: Ac4afqKc8FgWqmsiQJOvzT+T/D8X6g== Message-ID: In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1004139B@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3445410240_66102282" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-03-06_05:2013-03-06, 2013-03-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1303060113 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:24:11 -0000 --B_3445410240_66102282 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Stan, Also, a quick thought, if you have a bulletized list of things you're thinking of changing in the draft, it would also be helpful to have that prior to the 22nd.. Thanks!! -Bow-Nan On 3/6/13 10:19 AM, "Stan Ratliff (sratliff)" wrote: > >On Mar 6, 2013, at 9:59 AM, Henning Rogge wrote: > >> On Wed, Mar 6, 2013 at 3:56 PM, Stan Ratliff (sratliff) >> wrote: >>> Henning, >>> >>> I believe the cutoff for submitting new drafts for this IETF has >>>already passed. So no, there won't be a DLEP-04 before Orlando. >> >> I am not asking for DLEP-04... just a statement when we might get it >> would be fine. > >I've got some time to work on it this week; that plus next week (out of >the office, focused on IETF stuff anyway, you know the drill) means I'm >shooting for somewhere around Mar. 22. >Hope that works. > >Regards, >Stan > > >> >>> I apologize to the working group for this; it's just a simple matter >>>of time. I've been pressed on several other issues, including the >>>reactive protocol draft, and just haven't got to it. However, i promise >>>we (the co-authors) will get on it, and produce a draft when the >>>website opens up after ORL. >> >> Okay... I am looking forward to it. >> >>> And Henning, if you are going to be in ORL, perhaps we could chat >>>about DLEP. >> >> Unfortunately not. >> >> The next IETF I will be able to attend will be the one in Berlin this >>year. >> >> Henning Rogge >> >> -- >> We began as wanderers, and we are wanderers still. We have lingured >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet --B_3445410240_66102282 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUBAYJKoZIhvcNAQcCoIIT9TCCE/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EecwggTNMIIDtaADAgECAgpmR0phAAAAAFLvMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTIwOTI2MTgwODE3WhcNMTMwOTI2MTgwODE3WjBgMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMR8wHQYDVQQDExZDaGVuZy5Cb3ctTmFuLjUwMDEwNzM5MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA0LdTMTV8InyZdZ0vdcELnmJ9TDZExAe1BZ/RUnaOUocBklSr 2GNhq10z3FCDuPU5MSLRPplWU2kVe4iZMTPizeGTbUaKk5lXH7ebZMOiuM4Nj/zUz+rg4S6A 4YwvTnNZwjtUfyxHap7khBmmVruX7YPk+XKaJg8QQuCoGp7uNWmVPR1a4rnusVop05BuMJMX xvfLgH1+5/LiSxSse67srzOyYijiTwOqC41t5yCvDJ80DxlXbSsGnqGIp6FyRcMv9Bdgtrrm nH24z+TcQYixSBfgRmIwMJ8Y9l950RYytXIJxYsxMefM2I2WeAm5ii0bpdXLQaoZ+fgg6H/O QnGy7QIDAQABo4IBljCCAZIwHQYDVR0OBBYEFCdenk/MFEee1t9lrnD2yvkq0o8sMA4GA1Ud DwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3JkVeGYp+JDAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EyMGIGCCsGAQUFBwEB BFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EyMCMG CCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8EAjAAMD0GCSsG AQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFk AgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwHAYDVR0RBBUwE4ERYmNoZW5nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEL BQADggEBAJBwHIp50DE1iqaCZCM//pYWNGyrh+qv83P+GBKHeJMMROD1bTxXDrQF3qr1+ZNm 378Oz31rEo6l154BbgjdvMVocYqPP8x+Cr+CsAHFvTNAvPDCF1UmgWmMP6pWO4+wGX+k2MBI TxSrJDaSxX0SI4cdNLwJLO63D4JdcvJeqVNNoOCIZYMoieQVP4r3hHmki/zJP73wl77uK/LW Ff0rC2s3kkZ769SPG4ul6LTYSIRSMnliKpFy5Ay+A9Wx+EgUeIGzIwDPhirP1jO+OZFij7RL DcgODGSZoN2NkeXkM8iGVFEBfVKdDauU+6oGYx1A5mo2I5hde8IMpO0LcWLgYCMwggS3MIID n6ADAgECAgEUMA0GCSqGSIb3DQEBCwUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwHhcNMDkxMjE0MTIwMDAwWhcNMTUxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpN SVRMTCBDQS0yMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApwTLI2FIh+w3oDMH BWFmTOjpJ2M0YBDuYDYDxPSSZ0IHwwfqNaNVUzAVnCWD1yCOAsoS4Q70o3wr0zyOB5kQyiKe VF+TdgQs8LuwSSTMFCRxWkuETAAu572IejCBIsaZdmlgqZGF++G9gngw0K4hpalwr8ZoNkIT 5TZpODjaS//NCsfcCioVfzU4XueLBc2dqc/WFBF+QxNGudoRbwNfRMxob+31HLnFIystM1z0 O9C2MDlly5acQKJSnIMEVbEuv3LHvGB/X8vCALFygF4pIEGhbORCYoCyAyj0yrUWn+ecirDk UqaA6ztXL7p7QOT5yB/6gBXwArxkUxCtUTS4fQIDAQABo4IBlTCCAZEwEgYDVR0TAQH/BAgw BgEB/wIBADAdBgNVHQ4EFgQUjkp9iaFjFxyBiDRXNyZFXhmKfiQwHwYDVR0jBBgwFoAUZ6p6 z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/BAQDAgGGMGEGCCsGAQUFBwEBBFUwUzAtBggr BgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5sbC5taXQuZWR1MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu bGwubWl0LmVkdS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjAN BgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xIC AQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsq hkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAiHcGodD9cfwLoMIv54Qaug7PEFwKpM0i 2ay/gwA1o5Oh2BTaOuMdwaNeXOqGlvxnE6WQArd0rT2tzr7IAJygrZPNW0NFldjGi/9KplGM jd259TYlq0A/GiwLLL/Wi2OXVMpRjjta9+3fW91/mLRcrYNBUQn5eWq2AGIVNUgwh8EnA9qO uyLP6mAURjCGHAnG+zx+VKLQUsITvtVgsSKg/mHEbrMg95BHHOHVuiBt+mFYce2iJMOQFJnh R+8ZdBNV/tCOEPnJjDXTIgK2Mea2Bt+AGQfn++9H3Y1j1FKU0/NmqYYoiJrrVskKZqBFgbJ7 F951U0XRwlYvgn9wseGA1jCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5 NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/V UkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012E CHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4Yq SevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02R XDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqD AgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDD Q+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX 9Nqg1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mL WbZ4G+g4HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z 4zbj3YCXzt3dVqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6Mq lhZx9ipDcUZ/ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0 ADCCBNAwggO4oAMCAQICCh/XPXQAAAAALD0wDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEG A1UEAxMKTUlUTEwgQ0EtMjAeFw0xMTExMzAxOTI1MjJaFw0xMjExMjkxOTI1MjJaMGAxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxHzAdBgNVBAMTFkNoZW5nLkJvdy1OYW4uNTAwMTA3MzkwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDdxmrHWxnUaFSfiNUM8BV5wFyFsFt1SiKmvJN0Ui77veb97y2D ffUdKIOZYmIvZ2g9saQBXkwUxPYDqh8FzEw3QNIOVcLuDytMVKMyS1BGSOSTw/daRiL9ZMT0 ZMz3+adWtG8LHWb0vZcbXI8R2/nBZfiBWd+0cKj9RKjBuRfYxr/DL4kn2r2d1EsrGqR7CM5o SeUAduukVNgoCb4G3XDS37MnkSMSB1OWgMLFGn9oShzAxHTyZmdhAfCdafUgwLzjjE6usPQr 5zOuoegdUw7gALD/XbXn9pKFfT12p4YgKFrfCBt0CkMTOzG7GQkgn/Xcl+aYvzb53bG6IdZ3 /8HvAgMBAAGjggGZMIIBlTAdBgNVHQ4EFgQUFrle2xdmVOWJjyy2lmom3/rMKeIwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYI KwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQC AQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzAN BgsqhkiG9xICAQMBCDAcBgNVHREEFTATgRFiY2hlbmdAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAdnUkMV+GYalb1DvK3d1sLeQB2adomR3BR+A+f+1S22CoOZwaIyxDa48zf5id xCVfnKWY6fn/AuB4oGEW7qndwwEQe9tL5jUky4EMWLsw3HRLtt0Jj/dz6p0rQN0THwNcPgI7 TCU97INZW1TVNmYhAbAcWZpskNXS8IKdkD9wvombF0VI8gXZqrXuQkrI2bXe0ojDZrdGgfbt /TO/nxz5awxR4EoECQD6uYCtxngx26DkvLoVUab5dYqlAxirJdC0gpvSbRVBNuv+FgU6xQsN eLknKxcNyOZ9f3if4u04b4B/0k9qZjmvBKtYT6PIyN+iiotFcmvOJhbQcViYND+lQzGCAeUw ggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZkdKYQAAAABS7zAJBgUr DgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFE/orDtjjXL0dY4rZHfSbX57z6TLMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwNjE1MjQwMFowDQYJKoZI hvcNAQEBBQAEggEAdIOpCl/Lz45eE6uhFFehqz91Gxpkw5rt0n5l/hiE0Q63jDUj0VwJHK87 iF2BpwcIEWvzI5ma3c8eEOd31LQg2+MDaz4nOOpqK4OzyAixNS/gxzrDuIsxIMYMYBUeHXNz QsdMsu0ZcBPUd6yVkmmQRNnbwBv4vPnP4doZhBHqAOr16w006XeEg1fdDP6UVTbwLEdIkCuh y5NyXc3rtiGlRYbGPk70yAKGsTQxAH/6UC/Mg0hZU+EgYlG9CDVogU+7DlawYncdyV1BGMZI kOyDm7Sr0DWmgBw5aOCE6DRw87aa8X6Dg7o0ns94SQEAhR4rfvvg6rDnpr4oSJrtHvBgJQ== --B_3445410240_66102282-- From ulrich@herberg.name Wed Mar 6 08:59:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14F421F89D8 for ; Wed, 6 Mar 2013 08:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4qlY62MGKDM for ; Wed, 6 Mar 2013 08:59:28 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55921F8614 for ; Wed, 6 Mar 2013 08:59:28 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id m8so4997867vcd.9 for ; Wed, 06 Mar 2013 08:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EWEcNPfdAeSmLHfgW5+0Dt72/4tB5xwSKTCtbq8NwDY=; b=yQcEkqKX6FmUBpeSbB1YimIkq7iZyJ8vv8ZDX7nwCdHVIw0oQ26VntfeLL0NJpx4BM 7KTOtOgwjcWrE5pMDSFYCHzpJWMJ93e066PFICdUhcWgm3uBxfDS5ux/w66msupMj62B 6sHwkBRG1Cij1kv1bZrW5o8lBBn489CGgFZ24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EWEcNPfdAeSmLHfgW5+0Dt72/4tB5xwSKTCtbq8NwDY=; b=Trf64+02x60agBX9D8qnvL/jPAW9uQCtJd+aXOY/9FueCdELHBk4WAfNyRcmRlnE7C Mos1aLhuq4IQD0IkNVc/SvZqN0QHgdBjfEdNHi9RTzcV8VRpJaxEJ4APGBuEGzrNEqDl LfQnwsVvDbhKpl5pHopqTtXHqyJozwE68guvuJ8RvuvQPqXTY+WYXGORU1pDsRJKpPMO Sn2ph6KJbXQHe8JI/nP2EdDnZ3tr8sZ8BRoxg/PrWv7pZ1Ial+7eW9x42RwcJ6helgv8 JcYTJOvzEgWPHAslFgWsgq6Y/HPbwp+VHNV2tNmPL/3R2JvJVgspbCS6FfEUezzcSAuq i7cg== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr10103600vde.100.1362589167665; Wed, 06 Mar 2013 08:59:27 -0800 (PST) Received: by 10.220.203.130 with HTTP; Wed, 6 Mar 2013 08:59:27 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> References: <5136E488.9040104@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C100411D6@xmb-aln-x03.cisco.com> Date: Wed, 6 Mar 2013 08:59:27 -0800 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf307c9bba50994c04d744839f X-Gm-Message-State: ALoCoQn/fGQvZ3QeUdHwBoIfcF2okZm7hIPNg3mNFoDp2amn3SAH8LAxZ1NvbuYemRcl85Mo8GQM Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP draft 04? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:59:33 -0000 --20cf307c9bba50994c04d744839f Content-Type: text/plain; charset=ISO-8859-1 Stan, On Wed, Mar 6, 2013 at 6:56 AM, Stan Ratliff (sratliff) wrote: > [...]However, i promise we (the co-authors) will get on it, and produce a > draft when the website opens up after ORL. > I thought the submission web site opens up on Monday 11? The "important dates" web site does not mention anything, but for previous IETFs that was the case. Best regards Ulrich --20cf307c9bba50994c04d744839f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stan,

On Wed, Mar 6, 2013 at 6:56 AM, Sta= n Ratliff (sratliff) <sratliff@cisco.com> wrote:
[...]However, i promise we (the co-authors) will get on it, and produce a d= raft when the website opens up after ORL.

I though= t the submission web site opens up on Monday 11? The "important dates&= quot; web site does not mention anything, but for previous IETFs that was t= he case.


Best regards
Ulrich

--20cf307c9bba50994c04d744839f-- From adrian@olddog.co.uk Mon Mar 11 11:05:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058611E81AD for ; Mon, 11 Mar 2013 11:05:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPgpUj6FFCpe for ; Mon, 11 Mar 2013 11:05:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id EEED011E8128 for ; Mon, 11 Mar 2013 11:05:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2BI5Kus014348; Mon, 11 Mar 2013 18:05:20 GMT Received: from 950129200 (dhcp-1045.meeting.ietf.org [130.129.16.69]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2BI5HCQ014280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Mar 2013 18:05:19 GMT From: "Adrian Farrel" To: Date: Mon, 11 Mar 2013 18:05:15 -0000 Message-ID: <00da01ce1e82$fde18480$f9a48d80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4egstmzX8SHbyOT7qPom9ATtck2A== Content-Language: en-gb Cc: manet@ietf.org Subject: [manet] Mail regarding draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:05:23 -0000 Hi, This I-D just completed IETF last call. The only discussion was around the Security Directorate review by Steve Kent. After some debate it became clear that Steve had misconstrued the scope of the document and, with explanation, he reduced his concern to: I think the easiest/best fix is for the authors to not use the (almost outlawed) phrase "This document does not specify any security considerations." While I don't believe this is a show-stopper, it does tie with one of the questions I raised in my review and I suspect that the issue will continue to be raised (e.g. by the Sec ADs). Furthermore, we can do a little better for posterity. So I suggest that the entirety of Section 8 be replaced as: Security issues arising from the inclusion of metrics in OLSRv2 did not get any specific discussion. Since OLSRv2 has its own security considerations to cover the whole protocol, there is nothing further to say in this document. [Or please propose alternative text]. --- Additionally, in his email of 2/26 Chris noted: > We had intended to put in a comment that if you want a node metric, > add it to incoming link metrics. I think from the author team I dropped > the ball on that one. So there is a small amount of text needed there. --- I would be happy to do this as an RFC editor note or for you to post a new I-D. If the former, please send me text. If the latter please post a new version. Thanks, Adrian From abdussalambaryun@gmail.com Tue Mar 12 03:29:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957321F88C0 for ; Tue, 12 Mar 2013 03:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyI6kfUmbkCh for ; Tue, 12 Mar 2013 03:29:59 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4272021F881B for ; Tue, 12 Mar 2013 03:29:59 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4846400pbb.32 for ; Tue, 12 Mar 2013 03:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L02c96aUulu7cYEfK6Gd/5ZSES3BmoJhwnpVv3YrMSk=; b=iEKRM0hnhWHTCP3S2kj5ATJthO8T5E/7SIeqMf0yqGwjAiWgsH7Mey9zRsWT84Mrr2 kplCzPxdvwn7ZmBYVafRul4FmNn0iNabLpLWdVdx7KXiT2XQGM607XThLG3H6by9MbZJ KkYmiwTQzCP9eJ8b+G7VG1O3PjXjoTByUmZhop1i+m7mtfIDgUiKPq08CfBvdBv7oWgK y265txuuU8c9CqgzVyrJLV7ikZSZ0g3t5cM+YBfIYZt+lraxGAsf/ec3aCdHcyIcy0ou +0jW/vuDaC3odrXq+/kAeJ0Vv9E+4yBU2hg++MLsSygyov0smcZcXmoukAa8p2ytpKSK ZzZA== MIME-Version: 1.0 X-Received: by 10.68.196.1 with SMTP id ii1mr35501074pbc.93.1363084198966; Tue, 12 Mar 2013 03:29:58 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Tue, 12 Mar 2013 03:29:58 -0700 (PDT) In-Reply-To: <00da01ce1e82$fde18480$f9a48d80$@olddog.co.uk> References: <00da01ce1e82$fde18480$f9a48d80$@olddog.co.uk> Date: Tue, 12 Mar 2013 11:29:58 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org Subject: Re: [manet] Mail regarding draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 10:29:59 -0000 I recommend to post new version with advised changes, AB On 3/11/13, Adrian Farrel wrote: > Hi, > > This I-D just completed IETF last call. > The only discussion was around the Security Directorate review by Steve > Kent. > After some debate it became clear that Steve had misconstrued the scope of > the > document and, with explanation, he reduced his concern to: > > I think the easiest/best fix is for the authors to not use the (almost > outlawed) > phrase "This document does not specify any security considerations." > > While I don't believe this is a show-stopper, it does tie with one of the > questions I raised in my review and I suspect that the issue will continue > to be > raised (e.g. by the Sec ADs). Furthermore, we can do a little better for > posterity. > > So I suggest that the entirety of Section 8 be replaced as: > > Security issues arising from the inclusion of metrics in OLSRv2 did not get > any > specific discussion. Since OLSRv2 has its own security considerations to > cover > the whole protocol, there is nothing further to say in this document. > > [Or please propose alternative text]. > > --- > > Additionally, in his email of 2/26 Chris noted: > >> We had intended to put in a comment that if you want a node metric, >> add it to incoming link metrics. I think from the author team I dropped >> the ball on that one. > > So there is a small amount of text needed there. > > --- > > I would be happy to do this as an RFC editor note or for you to post a new > I-D. > > If the former, please send me text. If the latter please post a new > version. > > Thanks, > Adrian > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From internet-drafts@ietf.org Tue Mar 12 05:51:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F92C21F8A98; Tue, 12 Mar 2013 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Loq-a1UjLKuz; Tue, 12 Mar 2013 05:51:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF84421F8A6F; Tue, 12 Mar 2013 05:51:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130312125139.8418.20659.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 05:51:39 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:51:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-aodvv2-00.txt Pages : 60 Date : 2013-03-11 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ulrich@herberg.name Wed Mar 13 12:17:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D414711E8107 for ; Wed, 13 Mar 2013 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zoHOf48ugGn for ; Wed, 13 Mar 2013 12:17:33 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8674011E8160 for ; Wed, 13 Mar 2013 12:17:32 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id fa15so687589vbb.25 for ; Wed, 13 Mar 2013 12:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=JUcaVdHoqI5aQQBXLLBPKMtjVxjIGtcynvj35ldK1V0=; b=vHOl88bqpBw3hu1vreDeZLnyDSo1JSEPOcxJPoEJmAg4V68xuQVhvV27SLqVWJodvj 61UYAHZN811Az6d0yOFqa3+tmeBBDC/FvIPSfTkpTR031MhNzzY6pqy57S2wxLgl5Vx+ 3x47X9bv5cXINA/J21FXLH9MHDhzscp3nfcxk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=JUcaVdHoqI5aQQBXLLBPKMtjVxjIGtcynvj35ldK1V0=; b=Hr5U7M8DcZWrpVDVCVoB7Wn8LzNilg38xzfkAvAeOQlYdfa4QEqSXnF57IQNynhveJ wVKhcerPLJV04JpA6lrUxsUT0SdubKzL5BYHleI6xCwP0H3umLpNfTMNMF42KB4ZFfP/ f7M/IGHH1fUhKY8ZEWLjBMOA+gu7mVeBsBy/XzC/vKimpSQs70l+g6ZOsU+yTCm0gNUg mnH+y+cjmGhDO9+zH5MkqCLt9ZT15q6oW//ypZfdNKfmf82+iCvBxjQW01i9E+KcV7l9 5PBvqjxElO9TW8zYQxyvZvphZHJHiEzfLOAYC8EC/11/EEhNSdPW2NAXkhfE+lEBnXIK /uFg== MIME-Version: 1.0 X-Received: by 10.58.0.230 with SMTP id 6mr1961650veh.21.1363202251936; Wed, 13 Mar 2013 12:17:31 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Wed, 13 Mar 2013 12:17:31 -0700 (PDT) Date: Wed, 13 Mar 2013 15:17:31 -0400 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnsuuIIX+7AxOal1hT4hstiGSfq/UugN6fu4cmXFfsMfrdIurQX65lpAIMOd3BbZxpdjsTI Subject: [manet] Volunteers for scribe / minute taker? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:17:34 -0000 Hi, how would like to volunteer for either scribe or minute taker? That would be much appreciated! Best Ulrich From brian.adamson@nrl.navy.mil Wed Mar 13 16:09:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771D211E80DC for ; Wed, 13 Mar 2013 16:09:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnOXtxBeGFOs for ; Wed, 13 Mar 2013 16:09:27 -0700 (PDT) Received: from mail3.nrl.navy.mil (mail3.nrl.navy.mil [IPv6:2001:480:20:404::465:27]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79D11E80D5 for ; Wed, 13 Mar 2013 16:09:27 -0700 (PDT) Received: from map-experiment-1289b.meeting.ietf.org (map-experiment-1289b.meeting.ietf.org [130.129.128.155] (may be forged)) (authenticated bits=0) by mail3.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id r2DN9NXT030542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Mar 2013 19:09:24 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Adamson In-Reply-To: Date: Wed, 13 Mar 2013 19:09:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1499) X-Scanned-By: MIMEDefang 2.72 Cc: manet@ietf.org Subject: Re: [manet] Volunteers for scribe / minute taker? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:09:28 -0000 Hi Ulrich, I can take minutes, but can scribe if needed. Brian On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: > Hi, > > how would like to volunteer for either scribe or minute taker? > > That would be much appreciated! > > Best > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From james.h.nguyen4.civ@mail.mil Thu Mar 14 06:38:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8855A21F8CF7 for ; Thu, 14 Mar 2013 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwX6fJPmsKkG for ; Thu, 14 Mar 2013 06:38:50 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 11FA521F8CEA for ; Thu, 14 Mar 2013 06:38:49 -0700 (PDT) Received: from UCOLHP3O.easf.csd.disa.mil (131.64.100.154) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 14 Mar 2013 13:38:32 +0000 Received: from UCOLHP9K.easf.csd.disa.mil ([169.254.3.38]) by UCOLHP3O.easf.csd.disa.mil ([131.64.100.154]) with mapi id 14.02.0309.003; Thu, 14 Mar 2013 13:38:32 +0000 From: "Nguyen, James H CIV USARMY CERDEC (US)" To: "manet@ietf.org" Thread-Topic: Audiocast (UNCLASSIFIED) Thread-Index: AQHOID/b5xcRbUKfx06imQl8EWOWWpilMUtA Date: Thu, 14 Mar 2013 13:38:32 +0000 Message-ID: <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> In-Reply-To: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03B3_01CE2097.AF271E10" MIME-Version: 1.0 Subject: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:38:51 -0000 ------=_NextPart_000_03B3_01CE2097.AF271E10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Hi, I'd like to dial in to listen to the meeting from remote site, but I couldn't find the phone number on the agenda. Can someone help me out? Thanks, James Nguyen US Army CERDEC S&TCD Email: james.h.nguyen4.civ@mail.mil Phone: 443-395-5628 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Brian Adamson Sent: Wednesday, March 13, 2013 7:09 PM To: Ulrich Herberg Cc: manet@ietf.org Subject: Re: [manet] Volunteers for scribe / minute taker? Hi Ulrich, I can take minutes, but can scribe if needed. Brian On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: > Hi, > > how would like to volunteer for either scribe or minute taker? > > That would be much appreciated! > > Best > 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 Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_03B3_01CE2097.AF271E10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISwjCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtDCCA5ygAwIBAgIDIzkxMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTEwNjIyMDAwMDAwWhcN MTQwNjIxMjM1OTU5WjB2MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSMwIQYDVQQDExpOR1VZRU4u SkFNRVMuSE4uMTM5Mzc2NTEzMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWhoyiY EPfriy4L2fQOjm3IZ1zyTlBQ7KG5tbv9PYyw7H4DGI2jvSenfw4WGhNl1l/gsrqnSVuWBGmNbJWp WAvtsgvzhm5Xssi36/tDkXmAr7sIXelFVKoWC5Q0aTFIWe0OltDtByPYQhBGLQAd/g2zCXPLsvq2 R/Q+FgjXSr6p9jPOShN39wZe+OKAC+NLTvZUuuPqNYp38jn+AJw3USuXJweSl44LopnEWRZhQYpg U5Jf999pp6oS8gR0zNXZTbtrKuRa+nzfjSuQtble4w1Rc/GRuTVBk0mwUTyl6nnUDtTY1ML6jVNE iFdcGEpcoyxLW+u6xskftsDtxoYEBXMCAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFFSqcyrHs3fq zSJAeUh7EfunmSKCMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3JsL0RP REVNQUlMQ0FfMjQuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgELCTAL BglghkgBZQIBCxMwHQYDVR0OBBYEFJTCtL8IRNk2WQhIiUibdHr3anu6MGgGCCsGAQUFBwEBBFww WjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjQuY2Vy MCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlKQU1FUy5OR1VZ RU41QFVTLkFSTVkuTUlMMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcNAQEF BQADggEBAJp3KkGZpjT8RbG4Cfsik5H/uQWn+WS5IrN/JhXrsPFhS1Jlp//eTHg9PrWDV4y6WCB2 dnMLMh1mOjeJnuz6KE2BjInpOj4NWtwoww2H/ppq8bgrmW86KFMhteEL2kj5gSkuvhVNHNVj8ov/ yGyBJ13cHSdMU21oO5sSq15cEoJ8fbYTUmt34+Toh4q8vRO2oVpdZXx5fJd3ub/VolGY7WESSdDV 3B06OKs1q5SA5buVV743xnJjfnwOgEk2rC4GN/jV2p7IbEJw7OwQrFACVjdTSbotWNKt23JOzVJu mY01lE+Zcx6IGSmjpiiFNTg6kOoBykys1s5eHhO3deu/6EkwggT/MIID56ADAgECAgMjOS8wDQYJ KoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoG A1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yNDAeFw0xMTA2 MjIwMDAwMDBaFw0xNDA2MjEyMzU5NTlaMHYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExIzAhBgNV BAMTGk5HVVlFTi5KQU1FUy5ITi4xMzkzNzY1MTMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAw/R86/FEH3wIY0h6S/bm/Fe2XN6jUlH7egpWKA2+tHg22hPTEBJ8WgZEitsW1I+nnXgL GgNBPvuHlfsbhftkP7iSYW0as7rWAZC/Xmke+bGNE9EHswsx6yg0vDs1aJr6G+A6OSMxSNzOGn8O fuUvHVYClOJ9YVzozPvTGZ+0F3qWjJ8inmLGWJVE48fjlIlcuAsJVNsXf4jKtcWEvvrWDTIgwJG3 tDdwv571QHhc4yfWycaZccL+Ibrfm5T0pZyZZAu+1UCUmVHKg7T/RTgeYinnuHMtx9jnM+bLUKWU SAq65ZQS+TwHJI5Bpi516uTv2CZOlKxzommXiOYnlkjmxwIDAQABo4IBrTCCAakwHwYDVR0jBBgw FoAUVKpzKsezd+rNIkB5SHsR+6eZIoIwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2NybC5kaXNh Lm1pbC9jcmwvRE9ERU1BSUxDQV8yNC5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQcMBowCwYJ YIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUkYJ8+Iomb2hK5Y3iFTFxrccz2IEwaAYI KwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24vRE9ERU1B SUxDQV8yNC5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1UdEQQ9MDuB GUpBTUVTLk5HVVlFTjVAVVMuQVJNWS5NSUygHgYKKwYBBAGCNxQCA6AQDA4xMzkzNzY1MTMxQG1p bDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAKWeFP2mWVzpu7FPybJ3r0d3Ip2fX LINLeWbVhK68c8BNzBGeh3XCl3DmvcHGA74eNFiPBTeGVbgDhDoivNil+PU5Mh8zL+3AotG4Pf26 c10Fou4wMD++QBno8XdFf+fNEoklSBcy0B+/1FUx1yWlaQIE2kAlXdRk6vmYycRl8IfDseVgdtGA TXmy4l8fE7q5w+vKp03Ajkkup/8c3ESMzyXQmL13DnWh9k3U+nevr0PyD7QJ4RDaTR0bfwqdPYbQ iXKZRB7gTsG1vDfxD96SSrgFDrJ3Dy+WcHkDg37ephEyOH61FPmRwBc6oqviSgoU/qDIGuRWk1Jn 0Jshd+8HlzCCBY8wggR3oAMCAQICAUUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAW BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDURvRCBSb290IENBIDIwHhcNMDkwMTI2MjAyNjE1WhcNMTUwMTI1MjAyNjE1WjBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEApS5YeqHe5ppb9gLx1dTcNSOae24oZHQacDyWHczCn3QEPAw5kiEIDRJOoNc3qNLJxied KPpV17IXBBnOMrzweZ71aKsuzM83BLL4CmWaSSAUJcG8EmqgQm0bCLSHoUIiqxOZ2gIBOR9eCFdr YN4TfmhqfkH1iYA4ev2XstLilks2gGK27CW70A+no81RqPfSeVWQNCaj5FzNu2gmdAk3oeavzeQ+ mUf/f8JHvGWEujIpow7wwqJbeuqySn0LxsNurL0Qf0+pdjo9AgEsKjC098ig0pg6fAjQWokPtYqC +g0wHn7W0ce2QyexKKkM47MHeN9iZJpFjE7Nrw6unFg23wIDAQABo4ICWjCCAlYwDgYDVR0PAQH/ BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBRUqnMqx7N3 6s0iQHlIexH7p5kigjAMBgNVHSQEBTADgAEAMBIGA1UdEwEB/wQIMAYBAf8CAQAwgZ8GA1UdIASB lzCBlDALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELCjALBglghkgBZQIBCxIw CwYJYIZIAWUCAQsTMAsGCWCGSAFlAgELFDAMBgpghkgBZQMCAQMGMAwGCmCGSAFlAwIBAwcwDAYK YIZIAWUDAgEDCDAMBgpghkgBZQMCAQMNMAwGCmCGSAFlAwIBAxEwPwYDVR0fBDgwNjA0oDKgMIYu aHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYBBQUH AQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/RG9E JTIwUm9vdCUyMENBJTIwMjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgGCCsG AQUFBzAChnxsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIl MmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQByFtw5c2NNk+k3HM+y7ZzYTfcM MkqJnrPKuvMErHFmMaYqvbp9VNgvCWNKiAjobBOh7F57VhcwLcjS7deNR0RpzxFvy9jnUnW1Uciq HWnwGR8w8AfHNr3ODN47dv0Kzsu2E7rWhYvxXBKRyq/ofxKorC2L1nZQlOw2+qMP38Yy6sdzRvyE GpovxOgnHEjCRjb2F+ztZzIPuKLgt9JekAYTlCFhQ2x98ztrZe3j26j/xZuykufrX+7vv/M5jLP1 F9KG1cNsSjpsP56v6FsdNlumJhVGC0Zrx9SAqueuHLgrTvohcp9fn4GvtO5byZcpiXzp3HjiTuB0 n9KGeGaix5ioMYIDMjCCAy4CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zl cm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENB LTI0AgMjOS8wCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTMwMzE0MTMzODI5WjAjBgkqhkiG9w0BCQQxFgQUiCrkageWK3zGX/NmRi7YrqET e6AwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQsw CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI0AgMjOTEwdQYLKoZIhvcNAQkQAgsxZqBk MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAyM5MTANBgkqhkiG9w0BAQEF AASCAQBZR4MunBTsoilXoIx+3ByrYr+JomZVUA0m7I5oZnuDpEmpOFCNsoU7dHt1DiteAiU1owJ+ oJmsmHjhwt04mtn9VDgpQoHoe3BZUwFjyWruWxN8+kJcsiOx43LIWCYI5G3vq5h0QUhp2rm3jA1O CZKxCQQoTCMiga9Uec84sCAPkIWbB47A1W540MPofEeW2Xa0HxvxBk0Ut10NF7Rn7iBakuN5ngNR GQTXZdBqwXhtXcmIVdMrf7+aC96DQfKCI1/kumKLCoihcYPAZTWcnOrP7NdExsU5gYw/0oSlq8Tc oGMG1OM2efMciiVrcG4KL0YYNZBTkUyrqmq+qioZTCwoAAAAAAAA ------=_NextPart_000_03B3_01CE2097.AF271E10-- From ulrich@herberg.name Thu Mar 14 06:44:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC411E8123 for ; Thu, 14 Mar 2013 06:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzQ5MhWjyJw6 for ; Thu, 14 Mar 2013 06:44:51 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E837711E80FC for ; Thu, 14 Mar 2013 06:44:36 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id l1so1200100vba.27 for ; Thu, 14 Mar 2013 06:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CA5FujZ4qkY6XP0P9WCrN8JLkP8HoYN1mnqK18vtNVc=; b=Lu2BtjPt3/e+/D5U6oWQxo8wB6EUmtoTOJGpW5heAuBJk7SPZC0FBXgYmn7VP07Qvs NTS263RrQALIHVL0pvDMvyX0qeCVQTm3ie5jSn23b3k7MIn9H6wfBkABvohdfzCq3Wqo Dzb7X0M1FMv2e27W2M/Monimb0V5/vrMZmmXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=CA5FujZ4qkY6XP0P9WCrN8JLkP8HoYN1mnqK18vtNVc=; b=QWc9524+h+mVQI5Kf8ekgmi5hQD9Q3groW5yQpu3VSn2pVnuNj/vDKCAlGLjJPkmw8 sW4KUgw3bHkLOeLuHgXcM2lTz6tf0ry3RVbkrvFvEMurUl8dIRJpYqw27LxXCjH09Bf6 fa6gOh9MKnKhA2bZKeePKpsR3y3e1rb9sVngwzwxVxsSd5lFPb6fckHQ7TLemmLB7CKn JfwnWeQ9MKZGj4zLvWZqX6KFHUJe7g6ycHdG3Zi7vH1ZAvtHqluj9qEo8D6sQoFFs31F Ap4bCd04tYJlKeZPpgfKE8P3Ev1Bxr1X6A7bnLWAzxZsdJqF+KTbWZXR24ESwEBGTYWk A+SQ== MIME-Version: 1.0 X-Received: by 10.52.100.163 with SMTP id ez3mr1423900vdb.6.1363268676223; Thu, 14 Mar 2013 06:44:36 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Thu, 14 Mar 2013 06:44:36 -0700 (PDT) In-Reply-To: <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> Date: Thu, 14 Mar 2013 09:44:36 -0400 Message-ID: From: Ulrich Herberg To: "Nguyen, James H CIV USARMY CERDEC (US)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm3hKpoq5HSay4ZBFSsSaWer4aegj/x/gJB1gAc5aiANDHBr+jfsVyJ9iwQ3BwWmX9smQen Cc: "manet@ietf.org" Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:44:55 -0000 James, you can listen to the live-stream at: http://ietf86streaming.dnsalias.net/ietf/ietf862.m3u (this is the stream for the Boca 2 room). You can also join Jabber if you want to ask questions during the meeting: https://www.ietf.org/jabber General information about remote participation can be found at: https://www.ietf.org/meeting/86/remote-participation.html Best regards Ulrich On Thu, Mar 14, 2013 at 9:38 AM, Nguyen, James H CIV USARMY CERDEC (US) wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, > > I'd like to dial in to listen to the meeting from remote site, but I > couldn't find the phone number on the agenda. Can someone help me out? > > Thanks, > > James Nguyen > US Army CERDEC S&TCD > Email: james.h.nguyen4.civ@mail.mil > Phone: 443-395-5628 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Brian Adamson > Sent: Wednesday, March 13, 2013 7:09 PM > To: Ulrich Herberg > Cc: manet@ietf.org > Subject: Re: [manet] Volunteers for scribe / minute taker? > > Hi Ulrich, > > I can take minutes, but can scribe if needed. > > Brian > > On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: > >> Hi, >> >> how would like to volunteer for either scribe or minute taker? >> >> That would be much appreciated! >> >> Best >> 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 > > Classification: UNCLASSIFIED > Caveats: NONE > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From jpmacker@gmail.com Thu Mar 14 07:40:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83DA11E8112 for ; Thu, 14 Mar 2013 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-SoIZF02usm for ; Thu, 14 Mar 2013 07:40:49 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D511E8153 for ; Thu, 14 Mar 2013 07:40:48 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so2561186lab.30 for ; Thu, 14 Mar 2013 07:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eALQ2fCMFna4ZJiSjw9/RhmFdwl00Qx7JOCdcO65aYA=; b=hQVkEUKzSePNpLmB6NWjrhB1d7O+KGPcTXZBUe5myAOK8vovpUCeCOgdyfdSel0Zot bP5O9LCHbaVc2sphcGnmZrcSLxh1OFcZw9dwUjQ2RdhTol6a4zDZlymSsI2xxQH1Se0n Ws0GNhv8jIowvzdP9sifMGRD9wbGaa10JTyZnWzud7FxhGC7xQN0wIAYsYCKUAd1ILNt g3RgjYLkn24NkCrb1MaIOLo9KMoNvRk+bxq9tw16u+ZRz2EGr3jaRrJTrgzNb+K0sBc8 nVfLfQhP71PUfSelGskaJTF2h5BS49GAiOhooactD/DmjwGxobsQqXj8WYX5oobY6M+i ZyhA== MIME-Version: 1.0 X-Received: by 10.112.25.40 with SMTP id z8mr1251326lbf.20.1363272047117; Thu, 14 Mar 2013 07:40:47 -0700 (PDT) Received: by 10.112.46.197 with HTTP; Thu, 14 Mar 2013 07:40:46 -0700 (PDT) In-Reply-To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> Date: Thu, 14 Mar 2013 10:40:46 -0400 Message-ID: From: Joseph Macker To: Ulrich Herberg Content-Type: multipart/alternative; boundary=f46d040122a319d71a04d7e382c1 Cc: "manet@ietf.org" Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:40:50 -0000 --f46d040122a319d71a04d7e382c1 Content-Type: text/plain; charset=ISO-8859-1 The web based agenda tools also provide links for audiostreams, jabber sessions,etc You can get to that here. http://tools.ietf.org/agenda/86 On Thu, Mar 14, 2013 at 9:44 AM, Ulrich Herberg wrote: > James, > > you can listen to the live-stream at: > http://ietf86streaming.dnsalias.net/ietf/ietf862.m3u > (this is the stream for the Boca 2 room). > > You can also join Jabber if you want to ask questions during the meeting: > https://www.ietf.org/jabber > > General information about remote participation can be found at: > https://www.ietf.org/meeting/86/remote-participation.html > > Best regards > Ulrich > > > On Thu, Mar 14, 2013 at 9:38 AM, Nguyen, James H CIV USARMY CERDEC > (US) wrote: > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > Hi, > > > > I'd like to dial in to listen to the meeting from remote site, but I > > couldn't find the phone number on the agenda. Can someone help me out? > > > > Thanks, > > > > James Nguyen > > US Army CERDEC S&TCD > > Email: james.h.nguyen4.civ@mail.mil > > Phone: 443-395-5628 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of > > Brian Adamson > > Sent: Wednesday, March 13, 2013 7:09 PM > > To: Ulrich Herberg > > Cc: manet@ietf.org > > Subject: Re: [manet] Volunteers for scribe / minute taker? > > > > Hi Ulrich, > > > > I can take minutes, but can scribe if needed. > > > > Brian > > > > On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: > > > >> Hi, > >> > >> how would like to volunteer for either scribe or minute taker? > >> > >> That would be much appreciated! > >> > >> Best > >> 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 > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > > > > > _______________________________________________ > > 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 > --f46d040122a319d71a04d7e382c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The web based agenda tools also provide links for aud= iostreams, jabber sessions,etc
You can get to that here.


On Thu, Mar 14, 2013 at 9:44 AM, Ulrich Herberg = <ulrich@herberg= .name> wrote:
James,

you can listen to the live-stream at:
http://ietf86streaming.dnsalias.net/ietf/ietf862.m3u
(this is the stream for the Boca 2 room).

You can also join Jabber if you want to ask questions during the meeting: https://www.ietf.= org/jabber

General information about remote participation can be found at:
https://www.ietf.org/meeting/86/remote-participation.html<= br>
Best regards
Ulrich


On Thu, Mar 14, 2013 at 9:38 AM, Nguyen, James H CIV USARMY CERDEC
(US) <james.h.nguyen4.ci= v@mail.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Hi,
>
> I'd like to dial in to listen to the meeting from remote site, but= I
> couldn't find the phone number on the agenda. =A0Can someone help = me out?
>
> Thanks,
>
> James Nguyen
> US Army CERDEC S&TCD
> Email: james.h.nguyen4= .civ@mail.mil
> Phone: =A0443-395-= 5628
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org= [mailto:manet-bounces@ietf.o= rg] On Behalf Of
> Brian Adamson
> Sent: Wednesday, March 13, 2013 7:09 PM
> To: Ulrich Herberg
> Cc: manet@ietf.org
> Subject: Re: [manet] Volunteers for scribe / minute taker?
>
> Hi Ulrich,
>
> I can take minutes, but can scribe if needed.
>
> Brian
>
> On Mar 13, 2013, at 3:17 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
>
>> Hi,
>>
>> how would like to volunteer for either scribe or minute taker?
>>
>> That would be much appreciated!
>>
>> Best
>> 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
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d040122a319d71a04d7e382c1-- From ulrich@herberg.name Thu Mar 14 14:54:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7611E814D for ; Thu, 14 Mar 2013 14:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i02uunzRY5D1 for ; Thu, 14 Mar 2013 14:54:54 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 496F311E80E9 for ; Thu, 14 Mar 2013 14:54:54 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id d10so2139789vea.12 for ; Thu, 14 Mar 2013 14:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=65H7/PKr+VgqIWLhVnZcfLoLYT7art021Suvyvazj4g=; b=eeSWJTja5WOHlAirRyt4H8BHCTKcwblqOZUEjyu15wf8hYpKzpbKwTFXaQpDkjQhiE cqRlwo3xeR12ZMPSrEgQxrwCbv9+IFiHKFNZGNdpkG2gHWxRXpvUeWU0ekdpP+uhEKo/ TSrLQqs9xchCKbuJ5fukTTcgqAwHz1PeiQxAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=65H7/PKr+VgqIWLhVnZcfLoLYT7art021Suvyvazj4g=; b=asxgOu/5DN0WDnSqyLWKAQuYc/aPhgASKt/uS/zrX3om3p9aAMtCdoVJ+dGZxU3ss2 i850alZA2HIYJI7b8EPuHK2fffguwH96qfKpC0usE2BTC8cBaODNHnTpeF4q1zB6Nih7 9LFKqBqtcqcIOQlSHQ5dXLyVQdwMcWEz80koulKNMXkeLNfIB7Ht27Ov2j9QS7D50IE5 XzZ8KJqmKX8LBZu3w6TI4WzYefES5jKgEG7KlnyyuVy3yevQwcqGHuzzDHN0vI7TvujX QEmbpNLMqRnuJVkVoqO7mW64nNANrgSGnUM+x5XbGa4A6MNmCznGijAQq6aaWkTEyfD/ UhpA== MIME-Version: 1.0 X-Received: by 10.52.163.33 with SMTP id yf1mr2865606vdb.11.1363298093704; Thu, 14 Mar 2013 14:54:53 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Thu, 14 Mar 2013 14:54:53 -0700 (PDT) In-Reply-To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> Date: Thu, 14 Mar 2013 17:54:53 -0400 Message-ID: From: Ulrich Herberg To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnL9dzBGYg82VUQMjd4N/PeLOafGomajt6JxnF+ei5BymFBSQE3U/lIo+uEWky769oYDPAt Cc: "manet@ietf.org" Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:54:55 -0000 Unfortunately, for some participants the audio did not work. I will upload the meeting minutes soon and will also post the link to the audio archives, once they are available. Best regards Ulrich On Thu, Mar 14, 2013 at 10:40 AM, Joseph Macker wrote: > The web based agenda tools also provide links for audiostreams, jabber > sessions,etc > You can get to that here. > > http://tools.ietf.org/agenda/86 > > > > On Thu, Mar 14, 2013 at 9:44 AM, Ulrich Herberg wrote: >> >> James, >> >> you can listen to the live-stream at: >> http://ietf86streaming.dnsalias.net/ietf/ietf862.m3u >> (this is the stream for the Boca 2 room). >> >> You can also join Jabber if you want to ask questions during the meeting: >> https://www.ietf.org/jabber >> >> General information about remote participation can be found at: >> https://www.ietf.org/meeting/86/remote-participation.html >> >> Best regards >> Ulrich >> >> >> On Thu, Mar 14, 2013 at 9:38 AM, Nguyen, James H CIV USARMY CERDEC >> (US) wrote: >> > Classification: UNCLASSIFIED >> > Caveats: NONE >> > >> > Hi, >> > >> > I'd like to dial in to listen to the meeting from remote site, but I >> > couldn't find the phone number on the agenda. Can someone help me out? >> > >> > Thanks, >> > >> > James Nguyen >> > US Army CERDEC S&TCD >> > Email: james.h.nguyen4.civ@mail.mil >> > Phone: 443-395-5628 >> > >> > >> > -----Original Message----- >> > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> > Of >> > Brian Adamson >> > Sent: Wednesday, March 13, 2013 7:09 PM >> > To: Ulrich Herberg >> > Cc: manet@ietf.org >> > Subject: Re: [manet] Volunteers for scribe / minute taker? >> > >> > Hi Ulrich, >> > >> > I can take minutes, but can scribe if needed. >> > >> > Brian >> > >> > On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: >> > >> >> Hi, >> >> >> >> how would like to volunteer for either scribe or minute taker? >> >> >> >> That would be much appreciated! >> >> >> >> Best >> >> 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 >> > >> > Classification: UNCLASSIFIED >> > Caveats: NONE >> > >> > >> > >> > _______________________________________________ >> > 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 Fri Mar 15 10:17:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37E21F8916 for ; Fri, 15 Mar 2013 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFqvgWsTvRgn for ; Fri, 15 Mar 2013 10:17:46 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id E854521F8896 for ; Fri, 15 Mar 2013 10:17:45 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id gf12so1416663vcb.38 for ; Fri, 15 Mar 2013 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P39siqvaFJ5uroxQG4bIr+3kS2rtq3Ef5TB+EFdSR9w=; b=th3KgV6jEKFHajBpT1+K4kwjZGGdC3ovRyTAl4JgM6hjk6GJEpJwmmwtS+3zSemJfD 7Gg2L34/fXJhImIdj5eXwZ4YNEc7dRIxNZi5vo9VkU1Jce9hOYkkzPUxguIp9/rW8VLg PH+/I2NmXOgfXpDrLgWE/GY11Tz5m2ddqzq60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=P39siqvaFJ5uroxQG4bIr+3kS2rtq3Ef5TB+EFdSR9w=; b=CVH5C7EL9w9I7gbdq5sBpOrHvxWM0sEetOeA2J8jYXiXq/RouAGreRW+Iht9ww29KG p4qEY/UA6+I+FaY79py4KzQF35ULoTfMjvR0X8OQm1f1y5t4NPD2htR5WPi1SiS8rLjf 12rg3zydoEQFMnihLpFa6EzqWx4ObJXz1MAzs/9PAtvmILaU4fksb+TjSopJhnzNAqx2 3uww/VD9j+qTHxQoICq3Mb86TbOVrg2GbS3b6Fzl3+jxMt4YbLRHC8uSjzcSkMuKf3he FIhDftGXjGhWfNNwXk5AbUobT9czBVIXqMMySsjv59o10eNqBp71ibnyo1EtlN9qEpZW M0bQ== MIME-Version: 1.0 X-Received: by 10.52.24.66 with SMTP id s2mr21833vdf.40.1363367865363; Fri, 15 Mar 2013 10:17:45 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Fri, 15 Mar 2013 10:17:45 -0700 (PDT) In-Reply-To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> Date: Fri, 15 Mar 2013 13:17:45 -0400 Message-ID: From: Ulrich Herberg To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkNoV83xSUDNjoO7/x6N3Q3OYlugdpE5aN9DSWMBQhZPerATND+ruI5kTONcRhULRGGefbS Cc: "manet@ietf.org" Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:17:47 -0000 The audio files are now uploaded: https://www.ietf.org/audio/ietf86/ietf86-boca2-20130314-1520-pm2.mp3 I haven't checked the file yet, but looking at the file name, it's possible that the first 10 minutes are missing. Ulrich On Thu, Mar 14, 2013 at 5:54 PM, Ulrich Herberg wrote: > Unfortunately, for some participants the audio did not work. > > I will upload the meeting minutes soon and will also post the link to > the audio archives, once they are available. > > Best regards > Ulrich > > > On Thu, Mar 14, 2013 at 10:40 AM, Joseph Macker wrote: >> The web based agenda tools also provide links for audiostreams, jabber >> sessions,etc >> You can get to that here. >> >> http://tools.ietf.org/agenda/86 >> >> >> >> On Thu, Mar 14, 2013 at 9:44 AM, Ulrich Herberg wrote: >>> >>> James, >>> >>> you can listen to the live-stream at: >>> http://ietf86streaming.dnsalias.net/ietf/ietf862.m3u >>> (this is the stream for the Boca 2 room). >>> >>> You can also join Jabber if you want to ask questions during the meeting: >>> https://www.ietf.org/jabber >>> >>> General information about remote participation can be found at: >>> https://www.ietf.org/meeting/86/remote-participation.html >>> >>> Best regards >>> Ulrich >>> >>> >>> On Thu, Mar 14, 2013 at 9:38 AM, Nguyen, James H CIV USARMY CERDEC >>> (US) wrote: >>> > Classification: UNCLASSIFIED >>> > Caveats: NONE >>> > >>> > Hi, >>> > >>> > I'd like to dial in to listen to the meeting from remote site, but I >>> > couldn't find the phone number on the agenda. Can someone help me out? >>> > >>> > Thanks, >>> > >>> > James Nguyen >>> > US Army CERDEC S&TCD >>> > Email: james.h.nguyen4.civ@mail.mil >>> > Phone: 443-395-5628 >>> > >>> > >>> > -----Original Message----- >>> > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>> > Of >>> > Brian Adamson >>> > Sent: Wednesday, March 13, 2013 7:09 PM >>> > To: Ulrich Herberg >>> > Cc: manet@ietf.org >>> > Subject: Re: [manet] Volunteers for scribe / minute taker? >>> > >>> > Hi Ulrich, >>> > >>> > I can take minutes, but can scribe if needed. >>> > >>> > Brian >>> > >>> > On Mar 13, 2013, at 3:17 PM, Ulrich Herberg wrote: >>> > >>> >> Hi, >>> >> >>> >> how would like to volunteer for either scribe or minute taker? >>> >> >>> >> That would be much appreciated! >>> >> >>> >> Best >>> >> 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 >>> > >>> > Classification: UNCLASSIFIED >>> > Caveats: NONE >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 Fri Mar 15 10:51:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC8A21F8921 for ; Fri, 15 Mar 2013 10:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEEhuSkdL9Fd for ; Fri, 15 Mar 2013 10:51:12 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAD21F84F3 for ; Fri, 15 Mar 2013 10:51:12 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id fs19so2020783vbb.16 for ; Fri, 15 Mar 2013 10:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=WZZKI+51e0OIkcAOHzPBzJjiPMaheFkNWYgA2yMBuHg=; b=EadsP6sIAZRRv6xwgy12dJriZ7z9BTph1WSLP6SpiL9nSZ8V8QsnWH8qGaDG7Nl1ZE 4Lm7qqSwObakLvrzGVsrQaD/ilGoqaI1v+xG2KaUEICg3OPmJdvUGnEM+HGK34XQdSDJ zaLfbnoTNLox52so0wFGmZK60LXic65E/gci4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=WZZKI+51e0OIkcAOHzPBzJjiPMaheFkNWYgA2yMBuHg=; b=KiZ/lnKel2kZ3VpvvhsQx3VLa0ks/CuUaRxom/Gw9fR6hc9b6QCH0hM4DvJFQfTbse MIBBGA631Hc7LacYfCtWXCZGIVcaa7NtLfch4fF3ImglfOX+jQSkzYLPp9rvL0ASjvFA ECzYIL1jdQom55Sk2HIZPN0eHaVisqFQM2/KspppY/AAKcGfJgzcbkmhDLT0Ak5phQbO DgKYR+KRGs1cGKv5V/ZkOxIPRguiKYL+rcizIUoZ0X/RaKTi2BagFKmQa/l6e7EdJw36 UkYtB13FsW8yGbEzAHfepZ7H6ODgsCFbNjY2l2wSMothE8dIDR5jAdaPPvG3xXQyeo/P 4PfA== MIME-Version: 1.0 X-Received: by 10.52.163.33 with SMTP id yf1mr6511277vdb.11.1363369871744; Fri, 15 Mar 2013 10:51:11 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Fri, 15 Mar 2013 10:51:11 -0700 (PDT) Date: Fri, 15 Mar 2013 13:51:11 -0400 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl1kESQRhM5yLoqpTmSCTRVZ1TS9Z5QavhWEpOzi4cVK54+hwcVfsslzeFoWx6aYU7x6r3l Cc: Christopher Dearlove , Thomas Clausen Subject: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:51:13 -0000 Dear all, The OLSRv2 authors have had a discussion with Stephen Farrell (Security AD) and Adrian about how to resolve the remaining security related DISCUSS on OLSRv2, and we agreed on a way forward that involves the following steps: 1) Publication of: http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 This document mandates (at least) implementation of HMAC/SHA2 integrity protection of OLSRv2 messages. Deployments of OLSRv2 should use that mechanism unless they have a more appropriate solution (e.g., different cipher) for that particular deployment. This document also updates NHDP and mandates to implement the same HMAC/SHA2 protection for HELLO messages. 2) Publication of: http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 This document obsoletes RFC6622bis by fixing an oversight in RFC6622. The differences are minor to RFC6622 and can be seen here: http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis Essentially, RFC6622 does not protect the IP source address of the interface over which the control message is sent. Since that address is used to establish neighbors in NHDP (and therefore must be protected), a new type extension 3 of the ICV TLV has been added to the registry. 3) Publication of an update to OLSRv2, referencing the use of the defined security mechanism, and resolving other smaller issues from Stephen's DISCUSS. In order to not hold up OLSRv2 further, and upon discussions with Stan and Adrian, we would like to request WG adoption of these two new documents - asking that the chairs will officially poll the WG on this matter shortly. The documents are brief, and addresses issues requested by the ADs, so we hope that processing them should also be a brief affair. Best regards Ulrich From sratliff@cisco.com Fri Mar 15 12:04:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8539121F8477 for ; Fri, 15 Mar 2013 12:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIr0BpIZjglG for ; Fri, 15 Mar 2013 12:04:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 41CE521F8689 for ; Fri, 15 Mar 2013 12:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2430; q=dns/txt; s=iport; t=1363374266; x=1364583866; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8RT6+yP8RJbr/dgBuxsg+MgFuccGwYMxefz/sYzbsxw=; b=kf9gwtfEa3CGvjFKwzAWuNBNMDG9zlCFeTa7mp1jIQoGXZzIesHS/iYU l8XgEhWFsvIczluuehlxQF0tKmz0T8BixvGdV5x/3FnlrhzxIqGeaXYuW j3t3fPVLvUP7ruiG/aVPtSNDRAsda/S2Tig4Db0bSBf8RBYIj/+eqZG+r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFRwQ1GtJV2c/2dsb2JhbABDxSKBZxZ0gioBAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQgTh3MGDMMxjVWBDQIxB4JfYQOTFoRkj2ODCoFzNQ X-IronPort-AV: E=Sophos;i="4.84,853,1355097600"; d="scan'208";a="188043989" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 15 Mar 2013 19:04:26 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2FJ4P0V023637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 19:04:25 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 14:04:15 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Security documents for OLSRv2/NHDP Thread-Index: AQHOIaWznpJD/yD5G0K5xcEOhuWrxJincEmA Date: Fri, 15 Mar 2013 19:04:14 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <87379D9AC2E7034B8DEA93E1D02CF556@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Dearlove , "" , Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 19:04:28 -0000 Ulrich,=20 Thanks for this email. OK, Working Group participants: Consider this a 1-we= ek poll for adoption of these docs as WG documents. Polling period ends Mar= ch 22. And, silence will be deemed to be agreement that the documents *shou= ld be* accepted as WG docs.=20 Regards, Stan On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: > Dear all, >=20 > The OLSRv2 authors have had a discussion with Stephen Farrell (Security A= D) > and Adrian about how to resolve the remaining security related DISCUSS > on OLSRv2, and we agreed on a way forward that involves the following > steps: >=20 > 1) Publication of: > http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >=20 > This document mandates (at least) implementation of HMAC/SHA2 > integrity protection of OLSRv2 messages. Deployments of OLSRv2 should > use that mechanism unless they have a more appropriate solution (e.g., > different cipher) for that particular deployment. This document also > updates NHDP and mandates to implement the same HMAC/SHA2 protection > for HELLO messages. >=20 > 2) Publication of: > http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >=20 > This document obsoletes RFC6622bis by fixing an oversight in RFC6622. > The differences are minor to RFC6622 and can be seen here: > http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-manet-r= fc6622-bis > Essentially, RFC6622 does not protect the IP source address of the > interface over which the control message is sent. Since that address > is used to establish neighbors in NHDP (and therefore must be > protected), a new type extension 3 of the ICV TLV has been added to > the registry. >=20 > 3) Publication of an update to OLSRv2, referencing the use of the > defined security mechanism, and resolving other smaller issues from > Stephen's DISCUSS. >=20 > In order to not hold up OLSRv2 further, and upon discussions with Stan > and Adrian, we would like to request WG adoption of these two new > documents - asking that the chairs will officially poll the WG on this > matter shortly. The documents are brief, and addresses issues > requested by the ADs, so we hope that processing them should also be a > brief affair. >=20 > Best regards > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Mar 15 14:09:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB921F848B for ; Fri, 15 Mar 2013 14:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjR51EDoCMKT for ; Fri, 15 Mar 2013 14:09:04 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C18621F848D for ; Fri, 15 Mar 2013 14:09:04 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id 4so305143pdd.1 for ; Fri, 15 Mar 2013 14:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WteUudopbzxK9FXi3spxVemsMjk1X3XamHEwDqGQsvw=; b=SngFluZg7CPAi27oM3nhy9j3DkOZ/Pu99m/y6yM8PgssUIqjNsgj8e+hfIpVxa+smR 35ZnIadbO/yMtO3maKIIOyGhNlX9YSruXZxBn6bMwzf0XN7mJEqnL0In0jD+d7S3vc1V 7S7Us3QsS0LbW0heflQHtJBoMWvZUQxoK4lTgUj+Ps8dlXEsKhclCBAqFndUYjqXPhJQ VUfzhy5cAyHKoAL8W7h98r6OkB4yNy4JoRvarVUj184Dj+niaprm6tYijBYcXRGPr+sh GAByXH3r1S1nkRf83wfAEdv2pA53dAZETRFPHw/FIpwxk1iz8Pbsj4/LG+LfY1KJYxRq n+bQ== MIME-Version: 1.0 X-Received: by 10.68.25.42 with SMTP id z10mr19414545pbf.113.1363381743629; Fri, 15 Mar 2013 14:09:03 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Fri, 15 Mar 2013 14:09:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 22:09:03 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: Christopher Dearlove , manet@ietf.org, Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:09:04 -0000 Hi Ulrich, Do I understand that publication 1 updates both RFC6130 and OLSRv2, or do you mean only updates RFC6130, AB On 3/15/13, Ulrich Herberg wrote: > Dear all, > > The OLSRv2 authors have had a discussion with Stephen Farrell (Security AD) > and Adrian about how to resolve the remaining security related DISCUSS > on OLSRv2, and we agreed on a way forward that involves the following > steps: > > 1) Publication of: > http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 > > This document mandates (at least) implementation of HMAC/SHA2 > integrity protection of OLSRv2 messages. Deployments of OLSRv2 should > use that mechanism unless they have a more appropriate solution (e.g., > different cipher) for that particular deployment. This document also > updates NHDP and mandates to implement the same HMAC/SHA2 protection > for HELLO messages. > > 2) Publication of: > http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 > > This document obsoletes RFC6622bis by fixing an oversight in RFC6622. > The differences are minor to RFC6622 and can be seen here: > http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis > Essentially, RFC6622 does not protect the IP source address of the > interface over which the control message is sent. Since that address > is used to establish neighbors in NHDP (and therefore must be > protected), a new type extension 3 of the ICV TLV has been added to > the registry. > > 3) Publication of an update to OLSRv2, referencing the use of the > defined security mechanism, and resolving other smaller issues from > Stephen's DISCUSS. > > In order to not hold up OLSRv2 further, and upon discussions with Stan > and Adrian, we would like to request WG adoption of these two new > documents - asking that the chairs will officially poll the WG on this > matter shortly. The documents are brief, and addresses issues > requested by the ADs, so we hope that processing them should also be a > brief affair. > > Best regards > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From christopher.dearlove@googlemail.com Fri Mar 15 14:19:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D4121F8A04 for ; Fri, 15 Mar 2013 14:19:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4ZHF5oX1418 for ; Fri, 15 Mar 2013 14:19:49 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7221F89B5 for ; Fri, 15 Mar 2013 14:19:49 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hq4so942461wib.11 for ; Fri, 15 Mar 2013 14:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ioundPCbPmjpzL3+9STGQXOXG/yBxkeNJDVae04wdFw=; b=dIV8o+R7nHtBfqp5wN1h56GUgignTASL/sk3k2kyVJBHuPuooHoqlxBkRCP9aLg3vj QIe7fXrDXjOB7ooUbmY7qEkWAiZtpztu6DCANMAdj8uu2rxl/leQhP+33W8amywVJClS 3xCz6pGasLdFpZQB4M7KcWuQ3tD35pD2Y+yorclmHOFVyqWwuDwgmPDiW6mTpQmJzaBb n0DvGVFugnqWSuekyx6M44GXNHxjJ3PVTZ3SbxGaGfoWwUMFxAj7gVb3pHldTYQxmq86 vixUBQgCF1o0ATq5UCmTyHv7mV2lm39JmBVyI6FMfaETZqAnWpb3Eri3a2AYSih6iSvo AuNQ== X-Received: by 10.180.85.97 with SMTP id g1mr5566416wiz.29.1363382388591; Fri, 15 Mar 2013 14:19:48 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPS id j4sm181319wiz.10.2013.03.15.14.19.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 14:19:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Fri, 15 Mar 2013 21:19:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Cc: Christopher Dearlove , manet@ietf.org, Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:19:50 -0000 OLSRv2 will reference this draft, and therefore it's not an update in = the technical sense in which the term is being used here, as a formal = update to RFC 6130. On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: > Hi Ulrich, >=20 > Do I understand that publication 1 updates both RFC6130 and OLSRv2, or > do you mean only updates RFC6130, >=20 > AB > On 3/15/13, Ulrich Herberg wrote: >> Dear all, >>=20 >> The OLSRv2 authors have had a discussion with Stephen Farrell = (Security AD) >> and Adrian about how to resolve the remaining security related = DISCUSS >> on OLSRv2, and we agreed on a way forward that involves the following >> steps: >>=20 >> 1) Publication of: >> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>=20 >> This document mandates (at least) implementation of HMAC/SHA2 >> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >> use that mechanism unless they have a more appropriate solution = (e.g., >> different cipher) for that particular deployment. This document also >> updates NHDP and mandates to implement the same HMAC/SHA2 protection >> for HELLO messages. >>=20 >> 2) Publication of: >> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>=20 >> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >> The differences are minor to RFC6622 and can be seen here: >> = http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-manet-rf= c6622-bis >> Essentially, RFC6622 does not protect the IP source address of the >> interface over which the control message is sent. Since that address >> is used to establish neighbors in NHDP (and therefore must be >> protected), a new type extension 3 of the ICV TLV has been added to >> the registry. >>=20 >> 3) Publication of an update to OLSRv2, referencing the use of the >> defined security mechanism, and resolving other smaller issues from >> Stephen's DISCUSS. >>=20 >> In order to not hold up OLSRv2 further, and upon discussions with = Stan >> and Adrian, we would like to request WG adoption of these two new >> documents - asking that the chairs will officially poll the WG on = this >> matter shortly. The documents are brief, and addresses issues >> requested by the ADs, so we hope that processing them should also be = a >> brief affair. >>=20 >> Best regards >> 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 c.peoples@ulster.ac.uk Sat Mar 16 03:52:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45EB21F890F for ; Sat, 16 Mar 2013 03:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RD_TO_BAD_TLD=2.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNYr9Ob8t8Cf for ; Sat, 16 Mar 2013 03:52:34 -0700 (PDT) Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2A21F88ED for ; Sat, 16 Mar 2013 03:52:34 -0700 (PDT) Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id r2GAqXQ2022014 for ; Sat, 16 Mar 2013 10:52:33 GMT Received: from UUJCAS01.ad.ulster.ac.uk (uujcas01.ad.ulster.ac.uk [193.61.128.42]) by m0.ulster.ac.uk (UU/BC) with ESMTP id r2GAqXLu019235 for ; Sat, 16 Mar 2013 10:52:33 GMT (envelope-from c.peoples@ulster.ac.uk) Received: from UUJ-MBOX-02.ad.ulster.ac.uk ([fe80::b918:3bff:4f5:b9f0]) by UUJCAS01.ad.ulster.ac.uk ([::1]) with mapi id 14.02.0318.001; Sat, 16 Mar 2013 10:52:33 +0000 From: "Peoples, Cathryn" To: "manet@ietf.org" Thread-Topic: Deadline Extension: IEEE GLOBECOM 2013 Green Track Thread-Index: Ac4iNFvxanUigDdfR5u2HpUs7r++eg== Date: Sat, 16 Mar 2013 10:52:31 +0000 Message-ID: <4FBB08E32C10024FA495B2B6B329034E0AEDC283@uuj-mbox-02.ad.ulster.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.61.128.240] Content-Type: multipart/alternative; boundary="_000_4FBB08E32C10024FA495B2B6B329034E0AEDC283uujmbox02adulst_" MIME-Version: 1.0 Subject: [manet] Deadline Extension: IEEE GLOBECOM 2013 Green Track X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 10:52:36 -0000 --_000_4FBB08E32C10024FA495B2B6B329034E0AEDC283uujmbox02adulst_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS IEEE GLOBECOM (Global Communications Conference) 2013 Symposium on Selected Areas in Communications Green Communication Systems and Networks Track EXTENDED Submission deadline: 29 March 2013 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Track Chair Stefano Bregni, Politecnico di Milano, Italy, bregni@elet.polimi.it Neelesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.ii= sc.ernet.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D EDAS Submission Link: https://www.edas.info/newPaper.php?c=3D13183&track=3D= 24871 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Submission Guidelines Prospective authors are invited to submit original technical papers. For fu= ll details, please visit the following website: http://www.ieee-globecom.org/2013/submguide.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Scope and Topics of Interest Green communications and computing has been increasingly emphasized in rece= nt years, on the grounds not only of ecological concerns but also of signif= icant economic drivers (cost saving). The current explosive growth in the n= umber of devices connected to the Internet and in transmission capacity cal= ls for "green solutions" to address the challenges in energy efficient and/= or resource-efficient and/or environmentally-friendly communications and co= mputing systems. This track solicits contributions describing current trends and cutting-edg= e research in communication and computing systems and networks that incorpo= rate "green" constraints in their design and operation. It covers a wide ra= nge of green communications topics, including not only green-enabled commun= ications and computing networks, but also communication and computing techn= ologies enabling other green solutions such as smart grids, green buildings= and green logistics. -------------------------------------------------- Topics of interest include (but are not limited to): - Energy-efficient protocols and networking - Non-energy based green issues and approaches - Green transmission technologies and network protocols - Novel network concepts and architectures lowering the overall footprint o= f ICT - Self-organizing green wireless networks - Green traffic shaping and policy implementation - Green optical communications, switching and networking - Use of cognitive principles to reduce energy and/or resource consumption = in wireline and/or wireless networks - Power-efficient cooling and air-conditioning systems for communications a= nd computing - Physical layer approaches for green communications and computing - Low cost, energy-efficient antenna and RF designs - Green management of communication networks - Context-based green management & green awareness - Economy and pricing for green communication and services - Green network monitoring - Green sustainable storage and cloud computing - Measurement and profiling of energy consumption - Green scheduling for communications and computing - Power consumption trends and reduction in communications - Modeling and analysis for green communications and computing - Security in green communication networks - Standardization, policy and regulation for green communications and compu= ting - Mitigation of electromagnetic pollution - Experimental test-beds and results for green communications and computing - Communication technologies for transport and logistics efficiency, e.g., = applications to road traffic optimization and supply chain management - Communication technologies for industrial processes - Communication technologies for green buildings - Communication technologies for energy harvesting - Architectures and models for Smart Grid communications - Communications networks for the Smart Grid - Quality of service in smart grids - Information security in the Smart Grid - Sensor and actuator networks for smart grid - Advanced metering infrastructure and smart meter technologies - Field trials and deployment experiences ________________________________ This email and any attachments are confidential and intended solely for the= use of the addressee and may contain information which is covered by legal= , professional or other privilege. If you have received this email in error= please notify the system manager at postmaster@ulster.ac.uk and delete thi= s email immediately. Any views or opinions expressed are solely those of th= e author and do not necessarily represent those of the University of Ulster= . The University's computer systems may be monitored and communications car= ried out on them may be recorded to secure the effective operation of the s= ystem and for other lawful purposes. The University of Ulster does not guar= antee that this email or any attachments are free from viruses or 100% secu= re. Unless expressly stated in the body of a separate attachment, the text = of email is not intended to form a binding contract. Correspondence to and = from the University may be subject to requests for disclosure by 3rd partie= s under relevant legislation. The University of Ulster was founded by Royal= Charter in 1984 and is registered with company number RC000726 and VAT reg= istered number GB672390524.The primary contact address for the University o= f Ulster in Northern Ireland is,Cromore Road, Coleraine, Co. Londonderry BT= 52 1SA --_000_4FBB08E32C10024FA495B2B6B329034E0AEDC283uujmbox02adulst_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
CALL FOR PAPERS

IEEE GLOBECOM (Global Communications Conference) 2013

Symposium on Selected Areas in Communications
Green Communication Systems and Networks Track
 
EXTENDED Submission deadline: 29 March 2013

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Track Chair

Stefano Bregni, Politecnico di Milano, Italy, bregni@elet.polimi.it<= /font>

Neelesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.ii= sc.ernet.in

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
EDAS Submission Link: <= font color=3D"#006699" size=3D"2" face=3D"Arial">https://www.edas.info/newPaper.php?c=3D13183&track= =3D24871

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Submission Guidelines

Prospective authors are invited to submit original technical papers. For fu= ll details, please visit the following website:
http://www.ie= ee-globecom.org/2013/submguide.html

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Scope and Topics of Interest<= span lang=3D"en-US">

Green communications and computing has been increasingly emphasized in rece= nt years, on the grounds not only of ecological concerns but also of signif= icant economic drivers (cost saving). The current explosive growth in the n= umber of devices connected to the Internet and in transmission capacity calls for "green solutions"= ; to address the challenges in energy efficient and/or resource-efficient a= nd/or environmentally-friendly communications and computing systems.=

This track solicits contributions describing current trends and cutting-edg= e research in communication and computing systems and networks that incorpo= rate "green" constraints in their design and operation. It covers= a wide range of green communications topics, including not only green-enabled communications and computing networks, bu= t also communication and computing technologies enabling other green soluti= ons such as smart grids, green buildings and green logistics.=

--------------------------------------------------
Topics of interest include (but are not limited to):

- Energy-efficient protocols and networking
- Non-energy based green issues and approaches
- Green transmission technologies and network protocols
- Novel network concepts and architectures lowering the overall footprint o= f ICT - Self-organizing green wireless networks
- Green traffic shaping and policy implementation
- Green optical communications, switching and networking
- Use of cognitive principles to reduce energy and/or resource consumption = in wireline and/or wireless networks
- Power-efficient cooling and air-conditioning systems for communicati= ons and computing
- Physical layer approaches for green communications and computing
- Low cost, energy-efficient antenna and RF designs
- Green management of communication networks
- Context-based green management & green awareness
- Economy and pricing for green communication and services
- Green network monitoring
- Green sustainable storage and cloud computing
- Measurement and profiling of energy consumption
- Green scheduling for communications and computing
- Power consumption trends and reduction in communications
- Modeling and analysis for green communications and computing
- Security in green communication networks
- Standardization, policy and regulation for green communications and compu= ting
- Mitigation of electromagnetic pollution
- Experimental test-beds and results for green communications and computing=
- Communication technologies for transport and logistics efficiency, e.g., = applications to road traffic optimization and supply chain management
- Communication technologies for industrial processes
- Communication technologies for green buildings
- Communication technologies for energy harvesting
- Architectures and models for Smart Grid communications
- Communications networks for the Smart Grid
- Quality of service in smart grids
- Information security in the Smart Grid
- Sensor and actuator networks for smart grid
- Advanced metering infrastructure and smart meter te= chnologies
- Field trials and deployment experiences


This email and any attachments are confidential and intend= ed solely for the use of the addressee and may contain information which is= covered by legal, professional or other privilege. If you have received th= is email in error please notify the system manager at postmaster@ulster.ac.uk and delete this email immediatel= y. Any views or opinions expressed are solely those of the author and do no= t necessarily represent those of the University of Ulster. The University's= computer systems may be monitored and communications carried out on them may be recorded to secure the effec= tive operation of the system and for other lawful purposes. The University = of Ulster does not guarantee that this email or any attachments are free fr= om viruses or 100% secure. Unless expressly stated in the body of a separate attachment, the text of email i= s not intended to form a binding contract. Correspondence to and from the U= niversity may be subject to requests for disclosure by 3rd parties under re= levant legislation. The University of Ulster was founded by Royal Charter in 1984 and is registered with comp= any number RC000726 and VAT registered number GB672390524.The primary conta= ct address for the University of Ulster in Northern Ireland is,Cromore Road= , Coleraine, Co. Londonderry BT52 1SA --_000_4FBB08E32C10024FA495B2B6B329034E0AEDC283uujmbox02adulst_-- From bkantarc@uottawa.ca Sat Mar 16 08:34:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91E21F886B for ; Sat, 16 Mar 2013 08:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.64 X-Spam-Level: * X-Spam-Status: No, score=1.64 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_20=-0.74, HELO_EQ_TR=0.935, HTML_MESSAGE=0.001, SARE_RD_TO_BAD_TLD=2.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR90Pjdv0fGI for ; Sat, 16 Mar 2013 08:34:19 -0700 (PDT) Received: from smtp1.itu.edu.tr (smtp1.itu.edu.tr [160.75.2.3]) by ietfa.amsl.com (Postfix) with ESMTP id 919BA21F851E for ; Sat, 16 Mar 2013 08:34:18 -0700 (PDT) Received: from moufcpc101 ([137.122.91.232]) (authenticated aid=ITUec8aa06da52a8f1ebd017cfae50385f2 bits=0) by smtp1.itu.edu.tr with ESMTP id r2GFY3bj006361 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 16 Mar 2013 17:34:11 +0200 From: "Burak Kantarci" To: Date: Sat, 16 Mar 2013 11:34:03 -0400 Message-ID: <01c401ce225b$b52a2710$1f7e7530$@ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01CE223A.2E188710" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4iVZOtIUZfop5dT+KDpAP2VLbsjAABgkSQ Content-Language: en-ca X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp1.itu.edu.tr [160.75.2.3]); Sat, 16 Mar 2013 17:34:12 +0200 (EET) X-ITU-MailScanner-Information: Please contact with ITU BIDB for more information X-ITU-MailScanner-ID: r2GFY3bj006361 X-ITU-MailScanner: Found to be clean X-ITU-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=4.061, required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00, ITU_FORGED_FROM_AUTH_MAIL 5.50) X-ITU-MailScanner-SpamScore: ssss X-ITU-MailScanner-From: bkantarc@uottawa.ca X-ITU-MailScanner-To: manet@ietf.org X-ITU-MailScanner-Watermark: 1364052852.26431@tYf07gabfmmCB2CG2W2cCQ Subject: [manet] {Disarmed} New deadline: Mar 29, IEEE GLOBECOM 2013 Green Track X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 15:34:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C5_01CE223A.2E188710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies for possible multiple copies. CALL FOR PAPERS IEEE GLOBECOM (Global Communications Conference) 2013 Symposium on Selected Areas in Communications Green Communication Systems and Networks Track Submission deadline: March 29, 2013 23:59:00 EDT ====================================== Track Chair Stefano Bregni, Politecnico di Milano, Italy, bregni@elet.polimi.it Neelesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.iisc.ernet.in ====================================== EDAS Submission Link: https://www.edas.info/newPaper.php?c=13183&track=24871 ====================================== Submission Guidelines Prospective authors are invited to submit original technical papers. For full details, please visit the following website: http://www.ieee-globecom.org/2013/submguide.html ============================== Scope and Topics of Interest Green communications and computing has been increasingly emphasized in recent years, on the grounds not only of ecological concerns but also of significant economic drivers (cost saving). The current explosive growth in the number of devices connected to the Internet and in transmission capacity calls for "green solutions" to address the challenges in energy efficient and/or resource-efficient and/or environmentally-friendly communications and computing systems. This track solicits contributions describing current trends and cutting-edge research in communication and computing systems and networks that incorporate "green" constraints in their design and operation. It covers a wide range of green communications topics, including not only green-enabled communications and computing networks, but also communication and computing technologies enabling other green solutions such as smart grids, green buildings and green logistics. -------------------------------------------------- Topics of interest include (but are not limited to): -Energy-efficient protocols and networking -Non-energy based green issues and approaches -Green transmission technologies and network protocols -Novel network concepts and architectures lowering the overall footprint of ICT -Self-organizing green wireless networks -Green traffic shaping and policy implementation -Green optical communications, switching and networking -Use of cognitive principles to reduce energy and/or resource consumption in wireline and/or wireless networks - Power-efficient cooling and air-conditioning systems for communications and computing -Physical layer approaches for green communicommunications and computing -Low cost, energy-efficient antenna and RF designs -Green management of communication networks -Context-based green management & green awareness -Economy and pricing for green communication and services -Green network monitoring -Green sustainable storage and cloud computing -Measurement and profiling of energy consumption -Green scheduling for communications and computing -Power consumption trends and reduction in communications -Modeling and analysis for green communications and computing -Security in green communication networks -Standardization, policy and regulation for green communications and computing -Mitigation of electromagnetic pollution -Experimental test-beds and results for green communications and computing -Communication technologies for transport and logistics efficiency, e.g., applications to road traffic optimization and supply chain management -Communication technologies for industrial processes -Communication technologies for green buildings -Communication technologies for energy harvesting -Architectures and models for Smart Grid communications -Communications networks for the Smart Grid -Quality of service in smart grids -Information security in the Smart Grid -Sensor and actuator networks for smart grid -Advanced metering infrastructure and smart meter technologies -Field trials and deployment experiences ------=_NextPart_000_01C5_01CE223A.2E188710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Apolog= ies for possible multiple copies.

 

CALL FOR PAPERS
IEEE GLOBECOM (Global Communications Conference) = 2013
Symposium on Selected Areas in Communications
Green Communicatio= n Systems and Networks Track

= Submission deadline: March 29, 2013 23:59:00 EDT
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Track Chair
Stefano Bregni, Politecnico di Milano,= Italy, bregni@elet.polimi.it<= br>
Neelesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.iisc.ernet.in

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
EDAS Submission Link: DİKKAT: İTÜ = E-posta Güvenlik Sistemi tarafından "www.linkedin.com" adresine b= ir yönlendirme bulundu. Bu bir sahte yönlendirme (PHISHING) giri&= #351;imi olabilir. İçerikte görünen adres: = https://www.= edas.info/newPaper.php?c=3D13183&track=3D24871

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Submission Guidelines

Prospecti= ve authors are invited to submit original technical papers. For full detail= s, please visit the following website:
DİKKAT: İTÜ E-posta Güvenlik Sistemi taraf= ından "www.linkedin.com" adresine bir yönlendirme bulundu. Bu bir= sahte yönlendirme (PHISHING) girişimi olabilir. İçerik= te görünen adres: http://www.ieee-globecom.org/2013/submguide.htm= l

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scope and Topics of Interest
Green communications and computing has been increasingly emphasized in rec= ent years, on the grounds not only of ecological concerns but also of signi= ficant economic drivers (cost saving). The current explosive growth in the = number of devices connected to the Internet and in transmission capacity ca= lls for "green solutions" to address the challenges in energy eff= icient and/or resource-efficient and/or environmentally-friendly communicat= ions and computing systems.

This track solicits contributions descri= bing current trends and cutting-edge research in communication and computin= g systems and networks that incorporate "green" constraints in th= eir design and operation. It covers a wide range of green communications to= pics, including not only green-enabled communications and computing network= s, but also communication and computing technologies enabling other green s= olutions such as smart grids, green buildings and green logistics.

-= -------------------------------------------------
Topics of interest inc= lude (but are not limited to):

-Energy-efficient protocols and netwo= rking
-Non-energy based green issues and approaches
-Green transmissi= on technologies and network protocols
-Novel network concepts and archit= ectures lowering the overall footprint of ICT
-Self-organizing green wir= eless networks
-Green traffic shaping and policy implementation
-Gree= n optical communications, switching and networking
-Use of cognitive pri= nciples to reduce energy and/or resource consumption in wireline and/or wir= eless networks
- Power-efficient cooling and air-conditioning systems fo= r communications and computing
-Physical layer approaches for green comm= unicommunications and computing
-Low cost, energy-efficient antenna and = RF designs
-Green management of communication networks
-Context-based= green management & green awareness
-Economy and pricing for green c= ommunication and services
-Green network monitoring
-Green sustainabl= e storage and cloud computing
-Measurement and profiling of energy consu= mption
-Green scheduling for communications and computing
-Power cons= umption trends and reduction in communications
-Modeling and analysis fo= r green communications and computing
-Security in green communication ne= tworks
-Standardization, policy and regulation for green communications = and computing
-Mitigation of electromagnetic pollution
-Experimental = test-beds and results for green communications and computing
-Communicat= ion technologies for transport and logistics efficiency, e.g., applications= to road traffic optimization and supply chain management
-Communication= technologies for industrial processes
-Communication technologies for g= reen buildings
-Communication technologies for energy harvesting
-Arc= hitectures and models for Smart Grid communications
-Communications netw= orks for the Smart Grid
-Quality of service in smart grids
-Informati= on security in the Smart Grid
-Sensor and actuator networks for smart gr= id
-Advanced metering infrastructure and smart meter technologies
-Fi= eld trials and deployment experiences

 

 

= ------=_NextPart_000_01C5_01CE223A.2E188710-- From abdussalambaryun@gmail.com Sat Mar 16 13:53:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E921F8457 for ; Sat, 16 Mar 2013 13:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-fzUGzp9+RF for ; Sat, 16 Mar 2013 13:53:53 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id AE01821F8454 for ; Sat, 16 Mar 2013 13:53:53 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so5263827pbc.19 for ; Sat, 16 Mar 2013 13:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Qa0+lpigxHVZwVM3R4lFgtqk5T/lC/ldSMs3LaOq4Bk=; b=n6WFEWgrsdUPIZIW6kSPsZ556NsG6YZHDypsi7X7W487z0XwK9CaWXBzAdUDMG7omb 1j4wi3zfrMy1Uqt7SRNFgnAvKyFkOTOhCi+MEnP519n6nL+I+2wjYtJUVdj4fNuSeqeh Vn1KUsX5YAAugfYeyCKETSL7J+Gq5plhPSZMsYZXmB1uP18yjRWStVcJTq5DqdajUJpz ePP2adSTJJdaKBhZKq9R8RzYl6m5n6pNfo2AqV2ON5rHYYyV8ZZ8E6Eru9tljVlh5Hw3 k7JtDWPhFU6gs64sQAvTIeBc2ThsDlDW2ncwWfsweOFA3QNJbF/S8qKIrAErSYuJT35f K97g== MIME-Version: 1.0 X-Received: by 10.68.237.100 with SMTP id vb4mr25684659pbc.202.1363467233466; Sat, 16 Mar 2013 13:53:53 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sat, 16 Mar 2013 13:53:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Mar 2013 21:53:53 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:53:54 -0000 I agreed to update of RFC6130 and have no objection of others, but want to discuss/ask. If IESG-DISCUSS was about OLSRv2 document why the process was to update RFC6130 only? and if publication 1 mandates OLSRv2 messages, then IMO it needs to update OLSRv2 document as well, or do you mean the publication-3 is a new version -18 that includes the security of OLSRv2 messaging and refers to publication-1. AB ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This message is owned by the author and sent to IETF MANET address and not sent to private mail-boxes. This message is an IETF input not private input. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 3/15/13, Christopher Dearlove wrote: > OLSRv2 will reference this draft, and therefore it's not an update in the > technical sense in which the term is being used here, as a formal update to > RFC 6130. > > On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: > >> Hi Ulrich, >> >> Do I understand that publication 1 updates both RFC6130 and OLSRv2, or >> do you mean only updates RFC6130, >> >> AB >> On 3/15/13, Ulrich Herberg wrote: >>> Dear all, >>> >>> The OLSRv2 authors have had a discussion with Stephen Farrell (Security >>> AD) >>> and Adrian about how to resolve the remaining security related DISCUSS >>> on OLSRv2, and we agreed on a way forward that involves the following >>> steps: >>> >>> 1) Publication of: >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>> >>> This document mandates (at least) implementation of HMAC/SHA2 >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >>> use that mechanism unless they have a more appropriate solution (e.g., >>> different cipher) for that particular deployment. This document also >>> updates NHDP and mandates to implement the same HMAC/SHA2 protection >>> for HELLO messages. >>> >>> 2) Publication of: >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>> >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >>> The differences are minor to RFC6622 and can be seen here: >>> http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis >>> Essentially, RFC6622 does not protect the IP source address of the >>> interface over which the control message is sent. Since that address >>> is used to establish neighbors in NHDP (and therefore must be >>> protected), a new type extension 3 of the ICV TLV has been added to >>> the registry. >>> >>> 3) Publication of an update to OLSRv2, referencing the use of the >>> defined security mechanism, and resolving other smaller issues from >>> Stephen's DISCUSS. >>> >>> In order to not hold up OLSRv2 further, and upon discussions with Stan >>> and Adrian, we would like to request WG adoption of these two new >>> documents - asking that the chairs will officially poll the WG on this >>> matter shortly. The documents are brief, and addresses issues >>> requested by the ADs, so we hope that processing them should also be a >>> brief affair. >>> >>> Best regards >>> 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 adrian@olddog.co.uk Sat Mar 16 15:42:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC5121F86CD for ; Sat, 16 Mar 2013 15:42:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL5pigzbnL6T for ; Sat, 16 Mar 2013 15:42:54 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 54FCC21F86C2 for ; Sat, 16 Mar 2013 15:42:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2GMgpa0013750; Sat, 16 Mar 2013 22:42:51 GMT Received: from 950129200 (dhcp-4061.meeting.ietf.org [130.129.64.97]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2GMgngn013729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 22:42:51 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'manet'" References: In-Reply-To: Date: Sat, 16 Mar 2013 22:42:49 -0000 Message-ID: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWzvssfdepCa1Xv6pKjVcSghf1xgEGH5LeAYEv6bYBE8sVapf6t4cQ Content-Language: en-gb Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 22:42:55 -0000 Yes, I believe the plan is to add more security text to the OLSRv2 draft. The choice of words is confusing :-) "Update" has a general meaning: to update a draft means to make some revisions. "Update" has a specific meaning: to update an RFC means to add a meta-data tag formally noting that one RFC updates another. Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 16 March 2013 20:54 > To: manet > Subject: Re: [manet] Security documents for OLSRv2/NHDP > > I agreed to update of RFC6130 and have no objection of others, but > want to discuss/ask. > > If IESG-DISCUSS was about OLSRv2 document why the process was to > update RFC6130 only? and if publication 1 mandates OLSRv2 messages, > then IMO it needs to update OLSRv2 document as well, or do you mean > the publication-3 is a new version -18 that includes the security of > OLSRv2 messaging and refers to publication-1. > > AB > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > This message is owned by the author and sent to IETF MANET address and > not sent to private mail-boxes. This message is an IETF input not > private input. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > On 3/15/13, Christopher Dearlove > wrote: > > OLSRv2 will reference this draft, and therefore it's not an update in the > > technical sense in which the term is being used here, as a formal update to > > RFC 6130. > > > > On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: > > > >> Hi Ulrich, > >> > >> Do I understand that publication 1 updates both RFC6130 and OLSRv2, or > >> do you mean only updates RFC6130, > >> > >> AB > >> On 3/15/13, Ulrich Herberg wrote: > >>> Dear all, > >>> > >>> The OLSRv2 authors have had a discussion with Stephen Farrell (Security > >>> AD) > >>> and Adrian about how to resolve the remaining security related DISCUSS > >>> on OLSRv2, and we agreed on a way forward that involves the following > >>> steps: > >>> > >>> 1) Publication of: > >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 > >>> > >>> This document mandates (at least) implementation of HMAC/SHA2 > >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should > >>> use that mechanism unless they have a more appropriate solution (e.g., > >>> different cipher) for that particular deployment. This document also > >>> updates NHDP and mandates to implement the same HMAC/SHA2 > protection > >>> for HELLO messages. > >>> > >>> 2) Publication of: > >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 > >>> > >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. > >>> The differences are minor to RFC6622 and can be seen here: > >>> http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet- > rfc6622-bis > >>> Essentially, RFC6622 does not protect the IP source address of the > >>> interface over which the control message is sent. Since that address > >>> is used to establish neighbors in NHDP (and therefore must be > >>> protected), a new type extension 3 of the ICV TLV has been added to > >>> the registry. > >>> > >>> 3) Publication of an update to OLSRv2, referencing the use of the > >>> defined security mechanism, and resolving other smaller issues from > >>> Stephen's DISCUSS. > >>> > >>> In order to not hold up OLSRv2 further, and upon discussions with Stan > >>> and Adrian, we would like to request WG adoption of these two new > >>> documents - asking that the chairs will officially poll the WG on this > >>> matter shortly. The documents are brief, and addresses issues > >>> requested by the ADs, so we hope that processing them should also be a > >>> brief affair. > >>> > >>> Best regards > >>> 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 > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Sat Mar 16 16:46:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189C321F866F for ; Sat, 16 Mar 2013 16:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3XeiHS27HZ7 for ; Sat, 16 Mar 2013 16:46:46 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C215521F8526 for ; Sat, 16 Mar 2013 16:46:45 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id b13so2645916vby.33 for ; Sat, 16 Mar 2013 16:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ma8nEK0L5OeRG7mBvatgeaJTxnzBLfun9ydb9EBf5DE=; b=OPy2CbrGrx8odh+r7M6Mtcta/UWehA6tXxzN4aH0G2e0F5Z9S1OkAD6s6gRTKr0HO/ uCl7h3Bchb/D/wfvLTLnbsC2ZM17NU1Dc4Ww+KRbdEIlPQsfTnr2Dhh2BrfATZU1XEuj tmaHuynp8d159ty3u+AbdXk7MN3BVVA+uEWhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ma8nEK0L5OeRG7mBvatgeaJTxnzBLfun9ydb9EBf5DE=; b=IMOaqWXRP9M54b0LKeLHaLZDXfv4hFWDf10mf8PNGPkyUjAyj0iO8rJGPzRxErWFuy TnegxckLEitSTEIEJmxXIbdw4/HLqGjrOUKS3Rx4mqkofhQDmtkg08YVut5cieqcM8YU /CNkVQ5SMxJstZmTi0qY+WG+J6VefLmfn2aVbPMWpijrKRIvi4nl1ugC/71U/YC5IGpd rtCc6RiB0gr4PkIzBWXdTAV2VX0Oyf1eKfCWXAR4JwRdNutz66SjIAsY3YSBp+eNfXXE BreAzVFOzH78afcIuTOQy2vvchO1O1JSw0h+8hhi9jLQjDbE7euoIXXBXhqSUqcoWXIL xoNg== MIME-Version: 1.0 X-Received: by 10.220.215.73 with SMTP id hd9mr13364876vcb.19.1363477604950; Sat, 16 Mar 2013 16:46:44 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Sat, 16 Mar 2013 16:46:44 -0700 (PDT) In-Reply-To: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> References: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> Date: Sat, 16 Mar 2013 19:46:44 -0400 Message-ID: From: Ulrich Herberg To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkwcaYV58Uz1M6pXHthjCpP3SeX40YupW8yuhest8Sc0bwKfvVuF0yHcahfnxCkRhO6BgO+ Cc: manet Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 23:46:47 -0000 AB, we specified a integrity and replay security protection for OLSRv2, as requested by Stephen. We could have added that directly in OLSRv2, but since NHDP uses the same security mechanism, that would have been a copy of the same text. So we decided to specify the mechanism in a new draft, which is normatively referenced by OLSRv2, e.g.: "A conformant implementation of OLSRv2 MUST, at minimum, implement the security mechanisms specified in [draft-herberg-manet-nhdp-olsrv2-sec] ..." At the same time this new draft "updates" (in the IETF sense) NHDP by mandating to implement the security mechanism. The new OLSRv2 revision (as well as new revisions of the two security drafts) will be submitted in the next few days, we are just doing final reviews amongst the authors. Best regards Ulrich On Sat, Mar 16, 2013 at 6:42 PM, Adrian Farrel wrote: > Yes, I believe the plan is to add more security text to the OLSRv2 draft. The > choice of words is confusing :-) > "Update" has a general meaning: to update a draft means to make some revisions. > "Update" has a specific meaning: to update an RFC means to add a meta-data tag > formally noting that one RFC updates another. > > Adrian > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Abdussalam Baryun >> Sent: 16 March 2013 20:54 >> To: manet >> Subject: Re: [manet] Security documents for OLSRv2/NHDP >> >> I agreed to update of RFC6130 and have no objection of others, but >> want to discuss/ask. >> >> If IESG-DISCUSS was about OLSRv2 document why the process was to >> update RFC6130 only? and if publication 1 mandates OLSRv2 messages, >> then IMO it needs to update OLSRv2 document as well, or do you mean >> the publication-3 is a new version -18 that includes the security of >> OLSRv2 messaging and refers to publication-1. >> >> AB >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> This message is owned by the author and sent to IETF MANET address and >> not sent to private mail-boxes. This message is an IETF input not >> private input. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> On 3/15/13, Christopher Dearlove >> wrote: >> > OLSRv2 will reference this draft, and therefore it's not an update in the >> > technical sense in which the term is being used here, as a formal update to >> > RFC 6130. >> > >> > On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: >> > >> >> Hi Ulrich, >> >> >> >> Do I understand that publication 1 updates both RFC6130 and OLSRv2, or >> >> do you mean only updates RFC6130, >> >> >> >> AB >> >> On 3/15/13, Ulrich Herberg wrote: >> >>> Dear all, >> >>> >> >>> The OLSRv2 authors have had a discussion with Stephen Farrell (Security >> >>> AD) >> >>> and Adrian about how to resolve the remaining security related DISCUSS >> >>> on OLSRv2, and we agreed on a way forward that involves the following >> >>> steps: >> >>> >> >>> 1) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >> >>> >> >>> This document mandates (at least) implementation of HMAC/SHA2 >> >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >> >>> use that mechanism unless they have a more appropriate solution (e.g., >> >>> different cipher) for that particular deployment. This document also >> >>> updates NHDP and mandates to implement the same HMAC/SHA2 >> protection >> >>> for HELLO messages. >> >>> >> >>> 2) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >> >>> >> >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >> >>> The differences are minor to RFC6622 and can be seen here: >> >>> http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet- >> rfc6622-bis >> >>> Essentially, RFC6622 does not protect the IP source address of the >> >>> interface over which the control message is sent. Since that address >> >>> is used to establish neighbors in NHDP (and therefore must be >> >>> protected), a new type extension 3 of the ICV TLV has been added to >> >>> the registry. >> >>> >> >>> 3) Publication of an update to OLSRv2, referencing the use of the >> >>> defined security mechanism, and resolving other smaller issues from >> >>> Stephen's DISCUSS. >> >>> >> >>> In order to not hold up OLSRv2 further, and upon discussions with Stan >> >>> and Adrian, we would like to request WG adoption of these two new >> >>> documents - asking that the chairs will officially poll the WG on this >> >>> matter shortly. The documents are brief, and addresses issues >> >>> requested by the ADs, so we hope that processing them should also be a >> >>> brief affair. >> >>> >> >>> Best regards >> >>> 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 >> > >> > >> _______________________________________________ >> 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 sratliff@cisco.com Sat Mar 16 20:53:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351E321F84CA for ; Sat, 16 Mar 2013 20:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhHWdjYBXUET for ; Sat, 16 Mar 2013 20:53:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 178E721F84B1 for ; Sat, 16 Mar 2013 20:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6454; q=dns/txt; s=iport; t=1363492436; x=1364702036; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BHDsOYAz9yNiCTjmgfKVekBUQmbfYKi4Q6YCSQc7KAE=; b=fL5losZucB7nPGOf6ONKo3TM9NwlKEK9hO16++XGxwL2dv+7UWKivw0X dPdmFUE/HhpN/29FWfKyeEjmeAG9kIyZ0lodiSHx2mKwMMGre8fEANSNL WGOFWMJwgqgZ5+wzXbWeCrftAOr80w5jIhMvSNIB+eG0CW20ZQo+0qo2i w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOw9RVGtJXHB/2dsb2JhbABDxTCBbRZ0gioBAQEDAQEBAWsLBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIE4dnAwkGDLg3DYlbjEyBGX0CJgsHBoJZYQOTGIRlj2ODCoFzNQ X-IronPort-AV: E=Sophos;i="4.84,858,1355097600"; d="scan'208";a="188285613" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 17 Mar 2013 03:53:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2H3rtsj008389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Mar 2013 03:53:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 22:53:55 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Security documents for OLSRv2/NHDP Thread-Index: AQHOIaWznpJD/yD5G0K5xcEOhuWrxJinkyqAgAAC/YCAAYsbgIAAHm+AgAAR3ACAAEUOgA== Date: Sun, 17 Mar 2013 03:53:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10057F19@xmb-aln-x03.cisco.com> References: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: text/plain; charset="Windows-1252" Content-ID: <61D8B3265434614BA1957BC99F5126D1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 03:53:57 -0000 Ulrich,=20 Just to be clear: Since the plan is to add a normative reference to OLSRv2,= it (meaning the OLSRv2 draft) will be held up, pending WG adoption/accepta= nce/WGLC of this new draft=85 (Taking my co-chair hat off, and speaking just as a WG participant):=20 I would have preferred inserting the text directly into OLSRv2 (and NHDP if= need be) instead of creating the normative reference. I think this is a ta= d late in the game to be doing such a thing.=20 Regards, Stan On Mar 16, 2013, at 7:46 PM, Ulrich Herberg wrote: > AB, >=20 > we specified a integrity and replay security protection for OLSRv2, as > requested by Stephen. We could have added that directly in OLSRv2, but > since NHDP uses the same security mechanism, that would have been a > copy of the same text. So we decided to specify the mechanism in a new > draft, which is normatively referenced by OLSRv2, e.g.: > "A conformant implementation of OLSRv2 MUST, at minimum, implement the > security mechanisms specified in [draft-herberg-manet-nhdp-olsrv2-sec] > ..." > At the same time this new draft "updates" (in the IETF sense) NHDP by > mandating to implement the security mechanism. >=20 > The new OLSRv2 revision (as well as new revisions of the two security > drafts) will be submitted in the next few days, we are just doing > final reviews amongst the authors. >=20 > Best regards > Ulrich >=20 >=20 > On Sat, Mar 16, 2013 at 6:42 PM, Adrian Farrel wrot= e: >> Yes, I believe the plan is to add more security text to the OLSRv2 draft= . The >> choice of words is confusing :-) >> "Update" has a general meaning: to update a draft means to make some rev= isions. >> "Update" has a specific meaning: to update an RFC means to add a meta-da= ta tag >> formally noting that one RFC updates another. >>=20 >> Adrian >>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Abdussalam Baryun >>> Sent: 16 March 2013 20:54 >>> To: manet >>> Subject: Re: [manet] Security documents for OLSRv2/NHDP >>>=20 >>> I agreed to update of RFC6130 and have no objection of others, but >>> want to discuss/ask. >>>=20 >>> If IESG-DISCUSS was about OLSRv2 document why the process was to >>> update RFC6130 only? and if publication 1 mandates OLSRv2 messages, >>> then IMO it needs to update OLSRv2 document as well, or do you mean >>> the publication-3 is a new version -18 that includes the security of >>> OLSRv2 messaging and refers to publication-1. >>>=20 >>> AB >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> This message is owned by the author and sent to IETF MANET address and >>> not sent to private mail-boxes. This message is an IETF input not >>> private input. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>> On 3/15/13, Christopher Dearlove >>> wrote: >>>> OLSRv2 will reference this draft, and therefore it's not an update in = the >>>> technical sense in which the term is being used here, as a formal upda= te to >>>> RFC 6130. >>>>=20 >>>> On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: >>>>=20 >>>>> Hi Ulrich, >>>>>=20 >>>>> Do I understand that publication 1 updates both RFC6130 and OLSRv2, o= r >>>>> do you mean only updates RFC6130, >>>>>=20 >>>>> AB >>>>> On 3/15/13, Ulrich Herberg wrote: >>>>>> Dear all, >>>>>>=20 >>>>>> The OLSRv2 authors have had a discussion with Stephen Farrell (Secur= ity >>>>>> AD) >>>>>> and Adrian about how to resolve the remaining security related DISCU= SS >>>>>> on OLSRv2, and we agreed on a way forward that involves the followin= g >>>>>> steps: >>>>>>=20 >>>>>> 1) Publication of: >>>>>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>>>>>=20 >>>>>> This document mandates (at least) implementation of HMAC/SHA2 >>>>>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 shoul= d >>>>>> use that mechanism unless they have a more appropriate solution (e.g= ., >>>>>> different cipher) for that particular deployment. This document also >>>>>> updates NHDP and mandates to implement the same HMAC/SHA2 >>> protection >>>>>> for HELLO messages. >>>>>>=20 >>>>>> 2) Publication of: >>>>>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>>>>>=20 >>>>>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622= . >>>>>> The differences are minor to RFC6622 and can be seen here: >>>>>> http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-ma= net- >>> rfc6622-bis >>>>>> Essentially, RFC6622 does not protect the IP source address of the >>>>>> interface over which the control message is sent. Since that address >>>>>> is used to establish neighbors in NHDP (and therefore must be >>>>>> protected), a new type extension 3 of the ICV TLV has been added to >>>>>> the registry. >>>>>>=20 >>>>>> 3) Publication of an update to OLSRv2, referencing the use of the >>>>>> defined security mechanism, and resolving other smaller issues from >>>>>> Stephen's DISCUSS. >>>>>>=20 >>>>>> In order to not hold up OLSRv2 further, and upon discussions with St= an >>>>>> and Adrian, we would like to request WG adoption of these two new >>>>>> documents - asking that the chairs will officially poll the WG on th= is >>>>>> matter shortly. The documents are brief, and addresses issues >>>>>> requested by the ADs, so we hope that processing them should also be= a >>>>>> brief affair. >>>>>>=20 >>>>>> Best regards >>>>>> 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 >>>>=20 >>>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@googlemail.com Sun Mar 17 01:12:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D5421F880B for ; Sun, 17 Mar 2013 01:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5RrIkjkuqqj for ; Sun, 17 Mar 2013 01:12:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F02721F8803 for ; Sun, 17 Mar 2013 01:12:49 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so1651257wib.10 for ; Sun, 17 Mar 2013 01:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=s+QnfBsXrsi3c0dEEhPA6TIUdT8y2xzvLTcnxHM2pdc=; b=GuffEkki6iB6PWmW55cD3AzrZ6XeU2LKTi1nQL6FwfLi3QYVe86J+K/joovf3+KeTy M/flyj6FWMLvtmkYdQyfV9+RvhuWwAN2qQxeR7rn7kZlVxhx3CihyG7ZUujRtm0bc62K ThSYdYZ8mEGNhq6UdYTIRAahtmYXdCBcssnw7p81Kqr2EPiwA6cmhA8gIr9vF+PfFykc UVnQxAqTDDi9sItE2acGYbmrjtarN+Df8hQD7FBcPRE0T9orDKnoQnf6W+B49XUoFhzV yD+4w/MmgzVDcDRzFGE/RK0FGjPYMnQxDwoUgiBD1LXiBgMn8JaAYPxV4PwTt4E8Nrn3 FLUQ== X-Received: by 10.180.101.41 with SMTP id fd9mr10710973wib.20.1363507969305; Sun, 17 Mar 2013 01:12:49 -0700 (PDT) Received: from [192.168.254.3] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPS id h10sm7782614wic.8.2013.03.17.01.12.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 01:12:48 -0700 (PDT) References: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C10057F19@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10057F19@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Sun, 17 Mar 2013 08:13:01 +0000 To: "Stan Ratliff (sratliff)" Cc: manet Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 08:12:51 -0000 As Ulrich said, done that way we end up repeating a whole lot of text in bot= h documents, which really isn't sensible, and introduces an editorial issue o= f keeping the two aligned. Putting it all together gives a much more coheren= t presentation. As for late in the day, we worked on the assumption that what was good enoug= h for NHDP was good enough for OLSRv2. We were, as you know, working towards= security in the WG. However in effect a new security AD had a different vie= w to an old security AD, that something had to be done now, before OLSRv2 wa= s published, and held a DISCUSS accordingly. And as OLSRv2 security depends o= n NHDP security that needed doing too. No one wants everything finished as soon as soon as possible more than I and= the other authors do. But we are here, and doing the best we can. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 17 Mar 2013, at 03:53, "Stan Ratliff (sratliff)" wro= te: > Ulrich,=20 >=20 > Just to be clear: Since the plan is to add a normative reference to OLSRv2= , it (meaning the OLSRv2 draft) will be held up, pending WG adoption/accepta= nce/WGLC of this new draft=E2=80=A6 >=20 > (Taking my co-chair hat off, and speaking just as a WG participant):=20 > I would have preferred inserting the text directly into OLSRv2 (and NHDP i= f need be) instead of creating the normative reference. I think this is a ta= d late in the game to be doing such a thing.=20 >=20 > Regards, > Stan >=20 >=20 > On Mar 16, 2013, at 7:46 PM, Ulrich Herberg wrote: >=20 >> AB, >>=20 >> we specified a integrity and replay security protection for OLSRv2, as >> requested by Stephen. We could have added that directly in OLSRv2, but >> since NHDP uses the same security mechanism, that would have been a >> copy of the same text. So we decided to specify the mechanism in a new >> draft, which is normatively referenced by OLSRv2, e.g.: >> "A conformant implementation of OLSRv2 MUST, at minimum, implement the >> security mechanisms specified in [draft-herberg-manet-nhdp-olsrv2-sec] >> ..." >> At the same time this new draft "updates" (in the IETF sense) NHDP by >> mandating to implement the security mechanism. >>=20 >> The new OLSRv2 revision (as well as new revisions of the two security >> drafts) will be submitted in the next few days, we are just doing >> final reviews amongst the authors. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> On Sat, Mar 16, 2013 at 6:42 PM, Adrian Farrel wrot= e: >>> Yes, I believe the plan is to add more security text to the OLSRv2 draft= . The >>> choice of words is confusing :-) >>> "Update" has a general meaning: to update a draft means to make some rev= isions. >>> "Update" has a specific meaning: to update an RFC means to add a meta-da= ta tag >>> formally noting that one RFC updates another. >>>=20 >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >>>> Abdussalam Baryun >>>> Sent: 16 March 2013 20:54 >>>> To: manet >>>> Subject: Re: [manet] Security documents for OLSRv2/NHDP >>>>=20 >>>> I agreed to update of RFC6130 and have no objection of others, but >>>> want to discuss/ask. >>>>=20 >>>> If IESG-DISCUSS was about OLSRv2 document why the process was to >>>> update RFC6130 only? and if publication 1 mandates OLSRv2 messages, >>>> then IMO it needs to update OLSRv2 document as well, or do you mean >>>> the publication-3 is a new version -18 that includes the security of >>>> OLSRv2 messaging and refers to publication-1. >>>>=20 >>>> AB >>>>=20 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> This message is owned by the author and sent to IETF MANET address and >>>> not sent to private mail-boxes. This message is an IETF input not >>>> private input. >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>=20 >>>> On 3/15/13, Christopher Dearlove >>>> wrote: >>>>> OLSRv2 will reference this draft, and therefore it's not an update in t= he >>>>> technical sense in which the term is being used here, as a formal upda= te to >>>>> RFC 6130. >>>>>=20 >>>>> On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Hi Ulrich, >>>>>>=20 >>>>>> Do I understand that publication 1 updates both RFC6130 and OLSRv2, o= r >>>>>> do you mean only updates RFC6130, >>>>>>=20 >>>>>> AB >>>>>> On 3/15/13, Ulrich Herberg wrote: >>>>>>> Dear all, >>>>>>>=20 >>>>>>> The OLSRv2 authors have had a discussion with Stephen Farrell (Secur= ity >>>>>>> AD) >>>>>>> and Adrian about how to resolve the remaining security related DISCU= SS >>>>>>> on OLSRv2, and we agreed on a way forward that involves the followin= g >>>>>>> steps: >>>>>>>=20 >>>>>>> 1) Publication of: >>>>>>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>>>>>>=20 >>>>>>> This document mandates (at least) implementation of HMAC/SHA2 >>>>>>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 shoul= d >>>>>>> use that mechanism unless they have a more appropriate solution (e.g= ., >>>>>>> different cipher) for that particular deployment. This document also= >>>>>>> updates NHDP and mandates to implement the same HMAC/SHA2 >>>> protection >>>>>>> for HELLO messages. >>>>>>>=20 >>>>>>> 2) Publication of: >>>>>>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>>>>>>=20 >>>>>>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622= . >>>>>>> The differences are minor to RFC6622 and can be seen here: >>>>>>> http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-ma= net- >>>> rfc6622-bis >>>>>>> Essentially, RFC6622 does not protect the IP source address of the >>>>>>> interface over which the control message is sent. Since that address= >>>>>>> is used to establish neighbors in NHDP (and therefore must be >>>>>>> protected), a new type extension 3 of the ICV TLV has been added to >>>>>>> the registry. >>>>>>>=20 >>>>>>> 3) Publication of an update to OLSRv2, referencing the use of the >>>>>>> defined security mechanism, and resolving other smaller issues from >>>>>>> Stephen's DISCUSS. >>>>>>>=20 >>>>>>> In order to not hold up OLSRv2 further, and upon discussions with St= an >>>>>>> and Adrian, we would like to request WG adoption of these two new >>>>>>> documents - asking that the chairs will officially poll the WG on th= is >>>>>>> matter shortly. The documents are brief, and addresses issues >>>>>>> requested by the ADs, so we hope that processing them should also be= a >>>>>>> brief affair. >>>>>>>=20 >>>>>>> Best regards >>>>>>> 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 >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 adrian@olddog.co.uk Sun Mar 17 15:50:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89821F874F for ; Sun, 17 Mar 2013 15:50:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxzhuogt-PxA for ; Sun, 17 Mar 2013 15:50:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4321F84E3 for ; Sun, 17 Mar 2013 15:50:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2HMoqBZ009187 for ; Sun, 17 Mar 2013 22:50:52 GMT Received: from 950129200 (65-114-90-17.dia.static.qwest.net [65.114.90.17]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2HMomYP009153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 17 Mar 2013 22:50:49 GMT From: "Adrian Farrel" To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> In-Reply-To: Date: Sun, 17 Mar 2013 22:50:47 -0000 Message-ID: <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaqHVYsvJGKbCcB+kuzqAyZbArbQHX0OD8Ad23sNMCmYULIQLpRWCEAe610oSZODj5IA== Content-Language: en-gb Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:50:55 -0000 Hi, > Unfortunately, for some participants the audio did not work. If anyone has any details on this (other than "it did not work") please contact me unicast and we will see whether there is anything the technical team can learn for next time. Thanks, Adrian From henning.rogge@fkie.fraunhofer.de Mon Mar 18 02:58:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1EF21F8962 for ; Mon, 18 Mar 2013 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtrhN2rDVJUP for ; Mon, 18 Mar 2013 02:58:00 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D126A21F898B for ; Mon, 18 Mar 2013 02:57:59 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UHWpK-0002HD-Ek for manet@ietf.org; Mon, 18 Mar 2013 10:57:58 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHWpK-0000AN-C8 for manet@ietf.org; Mon, 18 Mar 2013 10:57:58 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 18 Mar 2013 10:57:58 +0100 Message-ID: <5146E525.7060702@fkie.fraunhofer.de> Date: Mon, 18 Mar 2013 10:57:57 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> In-Reply-To: <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060002090109050109090505" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16867/Mon Mar 18 10:39:33 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 09:58:01 -0000 --------------ms060002090109050109090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, are the slides of the meeting available? I tried to download them from=20 the IETF side and got a "size zero" file. https://datatracker.ietf.org/meeting/86/agenda.html Both the tar and the PDF link for MANET is empty for me. Henning Rogge On 03/17/2013 11:50 PM, Adrian Farrel wrote: > Hi, > >> Unfortunately, for some participants the audio did not work. > > If anyone has any details on this (other than "it did not work") please= contact > me unicast and we will see whether there is anything the technical team= can > learn for next time. --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060002090109050109090505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAzMTgwOTU3NTdaMCMGCSqGSIb3DQEJBDEWBBQuzdL7B/K0accOcuHufZ7nZGWV/jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAilKPOrrFv8bN1jkE7p9YVHoBQ2LwE1CsxXhGwxHFQwqj rL1MfhxqJOQkznqgOqaBEwVAV+Zy2cwJLRCdB5GO7M8yN2xIL83dd2Ro5bHHUfo01MLtjsix RADe5t7AIhAZGdZUyq753rhizIWtxgTGNoJaL4wNCEZeCm4TYAv9n2IhmScKZsEY0mvOZTXV 4gWxg1xtdfd5BA6F9/VbpXQqxjt4nt0pmuq2keSurYAFN0YIfNvUkFIY53yFATD0YuqmneWY ckBsyFro6M53PC7rw3xVnrcTObjS5cfjMNMzfmXHF2ygMkltvG6WktJwUShfPn1fR5kM0udv KFvhXuq7YwAAAAAAAA== --------------ms060002090109050109090505-- From john.dowdell@cassidian.com Mon Mar 18 03:05:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830B921F8A00 for ; Mon, 18 Mar 2013 03:05:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3LkaXFb+ggC for ; Mon, 18 Mar 2013 03:05:35 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id B86D121F89E5 for ; Mon, 18 Mar 2013 03:05:34 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 18 Mar 2013 11:05:29 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 18 Mar 2013 11:05:29 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 11:05:28 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 11:05:28 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 10:05:28 +0000 From: "Dowdell, John" To: "adrian@olddog.co.uk" , "manet@ietf.org" Thread-Topic: [manet] Audiocast (UNCLASSIFIED) Thread-Index: AQFaqHVYRjiay4Ut0kqujmwa92rdEgHX0OD8Ad23sNMCmYULIQLpRWCEAe610oSZODj5IIAAvQCg Date: Mon, 18 Mar 2013 10:05:27 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB0781FB93@SUCNPTEXM02.com.ad.uk.ds.corp> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2013 10:05:28.0580 (UTC) FILETIME=[1E166440:01CE23C0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19726.006 X-TM-AS-Result: No--14.984300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:05:40 -0000 Adrian As a remote listener, I joined just as the last meeting was finishing. Audi= o was good. Then the audio stream stopped. I can't tell if this was an admi= nistrative thing (maybe to make a cut for the recording archive) but the be= st thing for me would be if the stream could continue if there is only a 10= minute break between meetings, and be cut and archived later. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 17 March 2013 22:51 To: manet@ietf.org Subject: Re: [manet] Audiocast (UNCLASSIFIED) Hi, > Unfortunately, for some participants the audio did not work. If anyone has any details on this (other than "it did not work") please con= tact me unicast and we will see whether there is anything the technical team can learn for next time. Thanks, Adrian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From c.chauvenet@watteco.com Mon Mar 18 03:14:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2814C21F8C96 for ; Mon, 18 Mar 2013 03:14:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbeLhIQjfxv1 for ; Mon, 18 Mar 2013 03:14:12 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFFD21F8C93 for ; Mon, 18 Mar 2013 03:14:11 -0700 (PDT) Received: from mail100-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Mar 2013 10:14:10 +0000 Received: from mail100-ch1 (localhost [127.0.0.1]) by mail100-ch1-R.bigfish.com (Postfix) with ESMTP id 79F993C01BC; Mon, 18 Mar 2013 10:14:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.85; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0511HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzc89bh542I1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh1954cbh8275bhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail100-ch1 (localhost.localdomain [127.0.0.1]) by mail100-ch1 (MessageSwitch) id 1363601647672902_7087; Mon, 18 Mar 2013 10:14:07 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail100-ch1.bigfish.com (Postfix) with ESMTP id 98998300068; Mon, 18 Mar 2013 10:14:07 +0000 (UTC) Received: from AMXPRD0511HT001.eurprd05.prod.outlook.com (157.56.250.85) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Mar 2013 10:14:05 +0000 Received: from AMXPRD0511MB552.eurprd05.prod.outlook.com ([169.254.3.138]) by AMXPRD0511HT001.eurprd05.prod.outlook.com ([10.242.10.162]) with mapi id 14.16.0263.000; Mon, 18 Mar 2013 10:14:02 +0000 From: C Chauvenet To: "adrian@olddog.co.uk" Thread-Topic: [manet] Audiocast (UNCLASSIFIED) Thread-Index: AQFaqHVYZGMLqGG5ZkmPa927+JRw4gHX0OD8Ad23sNMCmYULIQLpRWCEAe610oSZODj5IIAAvQCggAADcwA= Date: Mon, 18 Mar 2013 10:14:01 +0000 Message-ID: <79A5D951-560A-4575-A6D6-5573013EAE84@watteco.com> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <603F5FD847B5174CBDA37A9DC00532FB0781FB93@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB0781FB93@SUCNPTEXM02.com.ad.uk.ds.corp> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: MANET IETF Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:14:13 -0000 Hi, Some additional feedback as a remote listener :=20 I had the same experience as John Dowdell, but the audio came back about 15= minutes after the beginning of the MANET session, so I was able to follow = most of the session live, just missing the very beginning.=20 >From what I remember from the VLC logs, I get something like a "404 not fou= nd" error on the web link...(Sorry I did not save these logs on a file). There was a lot of questions from the jabber during this session. Are the j= abber logs also recorded ? Best, C=E9dric.=20 Le 18 mars 2013 =E0 11:05, Dowdell, John a =E9crit : > Adrian >=20 > As a remote listener, I joined just as the last meeting was finishing. Au= dio was good. Then the audio stream stopped. I can't tell if this was an ad= ministrative thing (maybe to make a cut for the recording archive) but the = best thing for me would be if the stream could continue if there is only a = 10 minute break between meetings, and be cut and archived later. >=20 > John >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Adrian Farrel > Sent: 17 March 2013 22:51 > To: manet@ietf.org > Subject: Re: [manet] Audiocast (UNCLASSIFIED) >=20 > Hi, >=20 >> Unfortunately, for some participants the audio did not work. >=20 > If anyone has any details on this (other than "it did not work") please c= ontact > me unicast and we will see whether there is anything the technical team c= an > learn for next time. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to th= is e-mail is private and in addition may include commercially sensitive inf= ormation. The contents of this e-mail are for the intended recipient only a= nd therefore if you wish to disclose the information contained within this = e-mail or attached files, please contact the sender prior to any such discl= osure. If you are not the intended recipient, any disclosure, copying or di= stribution is prohibited. Please also contact the sender and inform them of= the error and delete the e-mail, including any attached files from your sy= stem. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs= , Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c= om > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From internet-drafts@ietf.org Mon Mar 18 04:39:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF72321F8CD9; Mon, 18 Mar 2013 04:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLr-pwTWv+4n; Mon, 18 Mar 2013 04:39:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3410D21F8CE8; Mon, 18 Mar 2013 04:39:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130318113922.28024.70279.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 04:39:22 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-18.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:39:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : The Optimized Link State Routing Protocol version 2 Author(s) : Thomas Heide Clausen Christopher Dearlove Philippe Jacquet Ulrich Herberg Filename : draft-ietf-manet-olsrv2-18.txt Pages : 113 Date : 2013-03-18 Abstract: This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Chris.Dearlove@baesystems.com Mon Mar 18 04:41:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4416B21F8CF3 for ; Mon, 18 Mar 2013 04:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32DCVhvoCZtk for ; Mon, 18 Mar 2013 04:41:42 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0E21F8CEF for ; Mon, 18 Mar 2013 04:41:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="320680511" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 18 Mar 2013 11:41:40 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r2IBfdjF019651 for ; Mon, 18 Mar 2013 11:41:39 GMT X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="10884911" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 18 Mar 2013 11:41:38 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Mon, 18 Mar 2013 11:41:38 +0000 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , "adrian@olddog.co.uk" Thread-Topic: [manet] Security documents for OLSRv2/NHDP Thread-Index: AQHOIaWw8dKPX6XC70KiDN5H0c0zsJinP1iAgAAC/oCAAYsagIAAHnCAgAAR3ACAAlnQYA== Date: Mon, 18 Mar 2013 11:41:38 +0000 Message-ID: References: <005e01ce2297$97702bc0$c6508340$@olddog.co.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:41:43 -0000 The new versions are now submitted. OLSRv2 security (integrity) is at -02, = RFC6622bis is at -02 and OLSRv2 is at -18. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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 U= lrich Herberg Sent: 16 March 2013 23:47 To: adrian@olddog.co.uk Cc: manet Subject: Re: [manet] Security documents for OLSRv2/NHDP ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- AB, we specified a integrity and replay security protection for OLSRv2, as requested by Stephen. We could have added that directly in OLSRv2, but since NHDP uses the same security mechanism, that would have been a copy of the same text. So we decided to specify the mechanism in a new draft, which is normatively referenced by OLSRv2, e.g.: "A conformant implementation of OLSRv2 MUST, at minimum, implement the security mechanisms specified in [draft-herberg-manet-nhdp-olsrv2-sec] ..." At the same time this new draft "updates" (in the IETF sense) NHDP by mandating to implement the security mechanism. The new OLSRv2 revision (as well as new revisions of the two security drafts) will be submitted in the next few days, we are just doing final reviews amongst the authors. Best regards Ulrich On Sat, Mar 16, 2013 at 6:42 PM, Adrian Farrel wrote: > Yes, I believe the plan is to add more security text to the OLSRv2 draft.= The > choice of words is confusing :-) > "Update" has a general meaning: to update a draft means to make some revi= sions. > "Update" has a specific meaning: to update an RFC means to add a meta-dat= a tag > formally noting that one RFC updates another. > > Adrian > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Abdussalam Baryun >> Sent: 16 March 2013 20:54 >> To: manet >> Subject: Re: [manet] Security documents for OLSRv2/NHDP >> >> I agreed to update of RFC6130 and have no objection of others, but >> want to discuss/ask. >> >> If IESG-DISCUSS was about OLSRv2 document why the process was to >> update RFC6130 only? and if publication 1 mandates OLSRv2 messages, >> then IMO it needs to update OLSRv2 document as well, or do you mean >> the publication-3 is a new version -18 that includes the security of >> OLSRv2 messaging and refers to publication-1. >> >> AB >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> This message is owned by the author and sent to IETF MANET address and >> not sent to private mail-boxes. This message is an IETF input not >> private input. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> On 3/15/13, Christopher Dearlove >> wrote: >> > OLSRv2 will reference this draft, and therefore it's not an update in = the >> > technical sense in which the term is being used here, as a formal upda= te to >> > RFC 6130. >> > >> > On 15 Mar 2013, at 21:09, Abdussalam Baryun wrote: >> > >> >> Hi Ulrich, >> >> >> >> Do I understand that publication 1 updates both RFC6130 and OLSRv2, o= r >> >> do you mean only updates RFC6130, >> >> >> >> AB >> >> On 3/15/13, Ulrich Herberg wrote: >> >>> Dear all, >> >>> >> >>> The OLSRv2 authors have had a discussion with Stephen Farrell (Secur= ity >> >>> AD) >> >>> and Adrian about how to resolve the remaining security related DISCU= SS >> >>> on OLSRv2, and we agreed on a way forward that involves the followin= g >> >>> steps: >> >>> >> >>> 1) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >> >>> >> >>> This document mandates (at least) implementation of HMAC/SHA2 >> >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 shoul= d >> >>> use that mechanism unless they have a more appropriate solution (e.g= ., >> >>> different cipher) for that particular deployment. This document also >> >>> updates NHDP and mandates to implement the same HMAC/SHA2 >> protection >> >>> for HELLO messages. >> >>> >> >>> 2) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >> >>> >> >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622= . >> >>> The differences are minor to RFC6622 and can be seen here: >> >>> http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-ma= net- >> rfc6622-bis >> >>> Essentially, RFC6622 does not protect the IP source address of the >> >>> interface over which the control message is sent. Since that address >> >>> is used to establish neighbors in NHDP (and therefore must be >> >>> protected), a new type extension 3 of the ICV TLV has been added to >> >>> the registry. >> >>> >> >>> 3) Publication of an update to OLSRv2, referencing the use of the >> >>> defined security mechanism, and resolving other smaller issues from >> >>> Stephen's DISCUSS. >> >>> >> >>> In order to not hold up OLSRv2 further, and upon discussions with St= an >> >>> and Adrian, we would like to request WG adoption of these two new >> >>> documents - asking that the chairs will officially poll the WG on th= is >> >>> matter shortly. The documents are brief, and addresses issues >> >>> requested by the ADs, so we hope that processing them should also be= a >> >>> brief affair. >> >>> >> >>> Best regards >> >>> 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 >> > >> > >> _______________________________________________ >> 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 _______________________________________________ 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 henning.rogge@fkie.fraunhofer.de Mon Mar 18 04:59:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6108421F8CF4 for ; Mon, 18 Mar 2013 04:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UJembOPEFCA for ; Mon, 18 Mar 2013 04:59:53 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 8D37B21F8CE8 for ; Mon, 18 Mar 2013 04:59:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UHYjG-0000vh-Oi; Mon, 18 Mar 2013 12:59:50 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHYjG-0003eA-M3; Mon, 18 Mar 2013 12:59:50 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 18 Mar 2013 12:59:50 +0100 Message-ID: <514701B6.9080500@fkie.fraunhofer.de> Date: Mon, 18 Mar 2013 12:59:50 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16868/Mon Mar 18 11:39:46 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 19fa4d6b0cee0cc72caa2ae612b5140b Cc: Stan Ratliff Subject: [manet] Comments to DLEP discussion at IETF 86 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:59:54 -0000 Hi, just listened to the discussion about DLEP, so here is my comment on it. Asymmetric metrics ------------------ I agree with Teco that asymmetric "maximum data rate" is useful. There=20 are both radios and modems with asymmetric capabilities. But I think we do NOT need asymmetric for "resources". The reason for this split is that I see a difference between "node=20 metrics" and "link metrics". I think the Resource TLV talks more about resources of a node, not about=20 the connection between two nodes. So it has no "direction". But most=20 TLVs could have "incoming" and "outgoing", even things like "radio=20 channel frequency". Experimental metric ------------------- I think we should keep a 'large enough' experimental metric space (not=20 only 2-4), but I also think we should add more "standardized" metric TLVs. Maybe we could have a look at the metric section of my ID and discuss=20 which one we could/should include into the DLEP RFC Leaving everything beyond the most basic metrics to "vendor specific"=20 encoding will make interoperability much harder. About "vendor specific" TLVs... I am not sure how much I like this,=20 because it can use up the 256 TLV types quickly. DLEP-draft vs. rfc5444-dlep-draft --------------------------------- I think we should not reopen this discussion. We have talked about the=20 "rfc5444 vs. custom format" and "session vs. timer-based" approach for=20 quite some time, but I think we should focus on more important things. The most important thing is that we arrive at a DLEP specification that=20 is strict and specific enough that we can assume that two independent=20 implementations (one radio, one router) will be able to interoperate=20 without any coordination between the implementors. Based on our discussions (about the ack-mechanism for example) I would=20 say we made progress in this area, but we have to keep an eye on this. The second are we have to take care of is what list of metrics (optional=20 or not) we include into the DLEP RFC. At the moment we have a quite=20 "minimalistic" list of metrics, which means that vendors have to make up=20 (incompatible) encodings for the same metric over and over. I also had a discussion with Stan and a few others about metric related=20 (and controversial) topics, I will try to summarize them in a different=20 mail. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From prvs=6789b228c7=bcheng@ll.mit.edu Mon Mar 18 06:56:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6932821F8D61 for ; Mon, 18 Mar 2013 06:56:03 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Ejl+3Dqfx6 for ; Mon, 18 Mar 2013 06:56:02 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4043B21F8D86 for ; Mon, 18 Mar 2013 06:56:01 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r2IDQP7S002284; Mon, 18 Mar 2013 09:55:52 -0400 From: "Cheng, Bow-Nan - 0665 - MITLL" To: Henning Rogge , "manet@ietf.org" Date: Mon, 18 Mar 2013 09:55:46 -0400 Thread-Topic: [manet] Comments to DLEP discussion at IETF 86 Thread-Index: Ac4j4Eoba7A0uFAmSN2cqYfDZwhoew== Message-ID: In-Reply-To: <514701B6.9080500@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3446445337_128025311" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-18_01:2013-03-18, 2013-03-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303180093 Subject: Re: [manet] Comments to DLEP discussion at IETF 86 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:56:03 -0000 --B_3446445337_128025311 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks for the comments Henning, Regarding the Asymmetric metrics discussion, I agree that binning the metrics into "node metrics" and "link metrics" is a good idea. And for node metrics, have it be only 1 metric and for link metrics, make them bi-directional. I think it'd be pretty important for us to clearly define the metrics and leave no ambiguity if that's the case. For example, the "Resources" metric is a bit ambiguous. The example in Section 7.10 is "Battery power", but I've seen people use "Resources" to indicate something like link load (or rather, link resources being used) which could be bi-directional. If it's battery power, then call it out and put it under the "node metrics". If something else, call it out. I do understand the author's intent to make some metrics "dimensionless" and flexible, but the problem is metrics like RLQ and Resources are listed in draft 03 as "MUST be reported". It then gets to be a big problem when one radio manufacturer uses it for one thing, and another radio manufacturer uses it for another thing. If its a radio-specific metric and we want to make it "dimensionless" for radio manufacturers to do something specific to their radio, then it probably should go under "OPTIONAL". -Bow-Nan=20 -- Bow-Nan Cheng, Ph.D. MIT Lincoln Laboratory Airborne Networks Group 244 Wood St Lexington MA 02420 781-981-4997 On 3/18/13 7:59 AM, "Henning Rogge" wrote: >Hi, > >just listened to the discussion about DLEP, so here is my comment on it. > > >Asymmetric metrics >------------------ > >I agree with Teco that asymmetric "maximum data rate" is useful. There >are both radios and modems with asymmetric capabilities. > >But I think we do NOT need asymmetric for "resources". > >The reason for this split is that I see a difference between "node >metrics" and "link metrics". > >I think the Resource TLV talks more about resources of a node, not about >the connection between two nodes. So it has no "direction". But most >TLVs could have "incoming" and "outgoing", even things like "radio >channel frequency". > > > >Experimental metric >------------------- > >I think we should keep a 'large enough' experimental metric space (not >only 2-4), but I also think we should add more "standardized" metric TLVs. > >Maybe we could have a look at the metric section of my ID and discuss >which one we could/should include into the DLEP RFC > >Leaving everything beyond the most basic metrics to "vendor specific" >encoding will make interoperability much harder. > >About "vendor specific" TLVs... I am not sure how much I like this, >because it can use up the 256 TLV types quickly. > > > >DLEP-draft vs. rfc5444-dlep-draft >--------------------------------- > >I think we should not reopen this discussion. We have talked about the >"rfc5444 vs. custom format" and "session vs. timer-based" approach for >quite some time, but I think we should focus on more important things. > >The most important thing is that we arrive at a DLEP specification that >is strict and specific enough that we can assume that two independent >implementations (one radio, one router) will be able to interoperate >without any coordination between the implementors. > >Based on our discussions (about the ack-mechanism for example) I would >say we made progress in this area, but we have to keep an eye on this. > >The second are we have to take care of is what list of metrics (optional >or not) we include into the DLEP RFC. At the moment we have a quite >"minimalistic" list of metrics, which means that vendors have to make up >(incompatible) encodings for the same metric over and over. > > > > > >I also had a discussion with Stan and a few others about metric related >(and controversial) topics, I will try to summarize them in a different >mail. > >Henning Rogge > >--=20 >Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >Kommunikation, Informationsverarbeitung und Ergonomie FKIE >Kommunikationssysteme (KOM) >Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >Telefon +49 228 9435-961, Fax +49 228 9435 685 >mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet --B_3446445337_128025311 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUBAYJKoZIhvcNAQcCoIIT9TCCE/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EecwggTNMIIDtaADAgECAgpmR0phAAAAAFLvMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTIwOTI2MTgwODE3WhcNMTMwOTI2MTgwODE3WjBgMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMR8wHQYDVQQDExZDaGVuZy5Cb3ctTmFuLjUwMDEwNzM5MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA0LdTMTV8InyZdZ0vdcELnmJ9TDZExAe1BZ/RUnaOUocBklSr 2GNhq10z3FCDuPU5MSLRPplWU2kVe4iZMTPizeGTbUaKk5lXH7ebZMOiuM4Nj/zUz+rg4S6A 4YwvTnNZwjtUfyxHap7khBmmVruX7YPk+XKaJg8QQuCoGp7uNWmVPR1a4rnusVop05BuMJMX xvfLgH1+5/LiSxSse67srzOyYijiTwOqC41t5yCvDJ80DxlXbSsGnqGIp6FyRcMv9Bdgtrrm nH24z+TcQYixSBfgRmIwMJ8Y9l950RYytXIJxYsxMefM2I2WeAm5ii0bpdXLQaoZ+fgg6H/O QnGy7QIDAQABo4IBljCCAZIwHQYDVR0OBBYEFCdenk/MFEee1t9lrnD2yvkq0o8sMA4GA1Ud DwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3JkVeGYp+JDAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EyMGIGCCsGAQUFBwEB BFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EyMCMG CCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8EAjAAMD0GCSsG AQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFk AgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwHAYDVR0RBBUwE4ERYmNoZW5nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEL BQADggEBAJBwHIp50DE1iqaCZCM//pYWNGyrh+qv83P+GBKHeJMMROD1bTxXDrQF3qr1+ZNm 378Oz31rEo6l154BbgjdvMVocYqPP8x+Cr+CsAHFvTNAvPDCF1UmgWmMP6pWO4+wGX+k2MBI TxSrJDaSxX0SI4cdNLwJLO63D4JdcvJeqVNNoOCIZYMoieQVP4r3hHmki/zJP73wl77uK/LW Ff0rC2s3kkZ769SPG4ul6LTYSIRSMnliKpFy5Ay+A9Wx+EgUeIGzIwDPhirP1jO+OZFij7RL DcgODGSZoN2NkeXkM8iGVFEBfVKdDauU+6oGYx1A5mo2I5hde8IMpO0LcWLgYCMwggS3MIID n6ADAgECAgEUMA0GCSqGSIb3DQEBCwUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwHhcNMDkxMjE0MTIwMDAwWhcNMTUxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpN SVRMTCBDQS0yMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApwTLI2FIh+w3oDMH BWFmTOjpJ2M0YBDuYDYDxPSSZ0IHwwfqNaNVUzAVnCWD1yCOAsoS4Q70o3wr0zyOB5kQyiKe VF+TdgQs8LuwSSTMFCRxWkuETAAu572IejCBIsaZdmlgqZGF++G9gngw0K4hpalwr8ZoNkIT 5TZpODjaS//NCsfcCioVfzU4XueLBc2dqc/WFBF+QxNGudoRbwNfRMxob+31HLnFIystM1z0 O9C2MDlly5acQKJSnIMEVbEuv3LHvGB/X8vCALFygF4pIEGhbORCYoCyAyj0yrUWn+ecirDk UqaA6ztXL7p7QOT5yB/6gBXwArxkUxCtUTS4fQIDAQABo4IBlTCCAZEwEgYDVR0TAQH/BAgw BgEB/wIBADAdBgNVHQ4EFgQUjkp9iaFjFxyBiDRXNyZFXhmKfiQwHwYDVR0jBBgwFoAUZ6p6 z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/BAQDAgGGMGEGCCsGAQUFBwEBBFUwUzAtBggr BgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5sbC5taXQuZWR1MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu bGwubWl0LmVkdS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjAN BgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xIC AQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsq hkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAiHcGodD9cfwLoMIv54Qaug7PEFwKpM0i 2ay/gwA1o5Oh2BTaOuMdwaNeXOqGlvxnE6WQArd0rT2tzr7IAJygrZPNW0NFldjGi/9KplGM jd259TYlq0A/GiwLLL/Wi2OXVMpRjjta9+3fW91/mLRcrYNBUQn5eWq2AGIVNUgwh8EnA9qO uyLP6mAURjCGHAnG+zx+VKLQUsITvtVgsSKg/mHEbrMg95BHHOHVuiBt+mFYce2iJMOQFJnh R+8ZdBNV/tCOEPnJjDXTIgK2Mea2Bt+AGQfn++9H3Y1j1FKU0/NmqYYoiJrrVskKZqBFgbJ7 F951U0XRwlYvgn9wseGA1jCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5 NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/V UkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012E CHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4Yq SevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02R XDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqD AgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDD Q+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX 9Nqg1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mL WbZ4G+g4HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z 4zbj3YCXzt3dVqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6Mq lhZx9ipDcUZ/ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0 ADCCBNAwggO4oAMCAQICCh/XPXQAAAAALD0wDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEG A1UEAxMKTUlUTEwgQ0EtMjAeFw0xMTExMzAxOTI1MjJaFw0xMjExMjkxOTI1MjJaMGAxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxHzAdBgNVBAMTFkNoZW5nLkJvdy1OYW4uNTAwMTA3MzkwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDdxmrHWxnUaFSfiNUM8BV5wFyFsFt1SiKmvJN0Ui77veb97y2D ffUdKIOZYmIvZ2g9saQBXkwUxPYDqh8FzEw3QNIOVcLuDytMVKMyS1BGSOSTw/daRiL9ZMT0 ZMz3+adWtG8LHWb0vZcbXI8R2/nBZfiBWd+0cKj9RKjBuRfYxr/DL4kn2r2d1EsrGqR7CM5o SeUAduukVNgoCb4G3XDS37MnkSMSB1OWgMLFGn9oShzAxHTyZmdhAfCdafUgwLzjjE6usPQr 5zOuoegdUw7gALD/XbXn9pKFfT12p4YgKFrfCBt0CkMTOzG7GQkgn/Xcl+aYvzb53bG6IdZ3 /8HvAgMBAAGjggGZMIIBlTAdBgNVHQ4EFgQUFrle2xdmVOWJjyy2lmom3/rMKeIwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYI KwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQC AQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzAN BgsqhkiG9xICAQMBCDAcBgNVHREEFTATgRFiY2hlbmdAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAdnUkMV+GYalb1DvK3d1sLeQB2adomR3BR+A+f+1S22CoOZwaIyxDa48zf5id xCVfnKWY6fn/AuB4oGEW7qndwwEQe9tL5jUky4EMWLsw3HRLtt0Jj/dz6p0rQN0THwNcPgI7 TCU97INZW1TVNmYhAbAcWZpskNXS8IKdkD9wvombF0VI8gXZqrXuQkrI2bXe0ojDZrdGgfbt /TO/nxz5awxR4EoECQD6uYCtxngx26DkvLoVUab5dYqlAxirJdC0gpvSbRVBNuv+FgU6xQsN eLknKxcNyOZ9f3if4u04b4B/0k9qZjmvBKtYT6PIyN+iiotFcmvOJhbQcViYND+lQzGCAeUw ggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZkdKYQAAAABS7zAJBgUr DgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFGCUp7ZjCdQVF0TJOI430PIc1F/fMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxODEzNTUzN1owDQYJKoZI hvcNAQEBBQAEggEAMBx6FMD/jsW6VGwFbRwqzMASTlI8IJfbrRu73SetIwsdLpyXzzFtOX24 ZwKUnwRu8htiT7coSUCzKb7qC4oDiSoIFAqA2IcU6JeAOD4BVX8QiNLWFjB1MagZJWn3wbyx Tbq9jkHh+thh5B4izHAv0b0txBM4QsfTQxCIS/CQ2wHSlMdyL/2GDjZskSgf+l56cupKpSLU VSnkE6Hgru2NUmLSsaBgE5KdR/KBeLR1+nBu71PJpkoRdWJlIXdJdGTk+S45zkAqusATVukQ VajWPHuSTmqejWDpjl4B5AdVRqHXaa1njMOLmAjyRmb60CE7iaJFxKtQ0JFDYH6X0yMNbg== --B_3446445337_128025311-- From jpmacker@gmail.com Mon Mar 18 07:10:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F055721F8EF9 for ; Mon, 18 Mar 2013 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t63HqM7G5kVm for ; Mon, 18 Mar 2013 07:10:10 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D386221F8DEE for ; Mon, 18 Mar 2013 07:10:03 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id fq11so3322236vbb.24 for ; Mon, 18 Mar 2013 07:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qhpPIY8BZRYoLP2urhToigxx1G60t5LLBSq3A9h42xw=; b=oc8X1sKgz03oixEPyuCwyC+k3+8nD9Ypxsa8pqCXM9GrIARNVUXnVbOiZJF3eLkjHX j8pBL7NgKkOGMM3tJX1iBECBFqNUyaixr/6ezkqJ9MhKW2Wvw33ugT6EhDhbb/aMYqVq IqjgKERynXslDLhuqupLFFs2BcrdyhvYuDzfsAM81HSqhvS2prJtRL8BuwitLIjFvM4O /98Ohgrqt5mUOjdFJZPG3fy1cXN3OVB+RGhAHoa8lqgYHf5v4wNmIo5ZetyeRPkZKJtK rd1mqJz23xOe156fCoG7/rca5VdB9I9KfxjNHVFXInCptLzIJj90BkfguM1bgFCuC3Iz fPhw== X-Received: by 10.58.12.69 with SMTP id w5mr20388523veb.16.1363615803325; Mon, 18 Mar 2013 07:10:03 -0700 (PDT) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil. [132.250.217.206]) by mx.google.com with ESMTPS id b7sm23559598veq.7.2013.03.18.07.10.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 07:10:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Macker In-Reply-To: <5146E525.7060702@fkie.fraunhofer.de> Date: Mon, 18 Mar 2013 10:09:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1015E117-F502-4E16-B907-C33EFA236B99@gmail.com> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> <5146E525.7060702@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:10:15 -0000 https://datatracker.ietf.org/meeting/86/materials.html#wg-manet Looks ok to me its what I used directly for the meeting slides. On Mar 18, 2013, at 5:57 AM, Henning Rogge = wrote: > Hi, >=20 > are the slides of the meeting available? I tried to download them from = the IETF side and got a "size zero" file. >=20 > https://datatracker.ietf.org/meeting/86/agenda.html >=20 > Both the tar and the PDF link for MANET is empty for me. >=20 > Henning Rogge >=20 > On 03/17/2013 11:50 PM, Adrian Farrel wrote: >> Hi, >>=20 >>> Unfortunately, for some participants the audio did not work. >>=20 >> If anyone has any details on this (other than "it did not work") = please contact >> me unicast and we will see whether there is anything the technical = team can >> learn for next time. >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Mar 18 08:08:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB66E21F88F5 for ; Mon, 18 Mar 2013 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaJMnhKYZctl for ; Mon, 18 Mar 2013 08:08:59 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id C436921F88E3 for ; Mon, 18 Mar 2013 08:08:58 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id m1so4392776ves.8 for ; Mon, 18 Mar 2013 08:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jl4IAfjWFBgv6tM1TQwPMoSvogkdSg+wUrWGtogsSgM=; b=3J1sAq4GCucgshbZ2ruIT7MBYY6vOXC3R+Op1QfGAVEDs2m69IJnvKXO2wU9Fc0NC7 yA4Jx6HWwh5D/W+J9jOXf4tkUF2V6P61I62tXe8YOLOYDFkl9rlceEWXunNMJVTuOiSg Q09ubZ7EfF0GQjTB4+OBoTnU8ZiNi3rgY7Ie4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=jl4IAfjWFBgv6tM1TQwPMoSvogkdSg+wUrWGtogsSgM=; b=CqlfoXdM0pPYPWezDubi8VcMxZAbI1UWUy2xQbJNLXLqBnp8E5I6ga7RWsu7s/JVWO y14swHcxrmTbZy4PV9oehlBElq5Hsi8IMYPkEvPQSESaWhmZRdBK1J9BIaSQAEPbhiuq huopQUa3+jQyhJjJxPON6vTxApI8YjVzJ8bNYxfN4ygViTwy2TKxO0a3uwIP22rDptrQ KpmYPD2tYQCqpNqWqr89rbBfNqR0cqz4P5oDZSGPSKnlPa2TGtzzXx5FxkuXE1vBf//k 7aToV3EV9telf0/2MTU8GNuTkzRddBrx07hx8QCCCJ1SONy+v5X+drpoBQhgJ21Lf8Lc /u9A== MIME-Version: 1.0 X-Received: by 10.220.154.66 with SMTP id n2mr20093460vcw.40.1363619337876; Mon, 18 Mar 2013 08:08:57 -0700 (PDT) Received: by 10.220.107.83 with HTTP; Mon, 18 Mar 2013 08:08:57 -0700 (PDT) In-Reply-To: <79A5D951-560A-4575-A6D6-5573013EAE84@watteco.com> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <603F5FD847B5174CBDA37A9DC00532FB0781FB93@SUCNPTEXM02.com.ad.uk.ds.corp> <79A5D951-560A-4575-A6D6-5573013EAE84@watteco.com> Date: Mon, 18 Mar 2013 08:08:57 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmdvpXw6aoWvrMwGB+xPZOWoXkx5AsgqpIEYZB/zFYQZWg5O1H7O4fJ8IppzF/a2nydAQRl Cc: MANET IETF Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:08:59 -0000 C=E9dric, my assumption is that the audio streaming was scheduled to be interrupted during the break, but maybe the scheduling was done wrong (maybe they scheduled a 20 minutes break between the two sessions, but it was actually only 10). As for jabber logs, they are always recorded: http://www.ietf.org/jabber/logs/manet/2013-03-14.html Ulrich On Mon, Mar 18, 2013 at 3:14 AM, C Chauvenet wrot= e: > Hi, > > Some additional feedback as a remote listener : > > I had the same experience as John Dowdell, but the audio came back about = 15 minutes after the beginning of the MANET session, so I was able to follo= w most of the session live, just missing the very beginning. > > From what I remember from the VLC logs, I get something like a "404 not f= ound" error on the web link...(Sorry I did not save these logs on a file). > > There was a lot of questions from the jabber during this session. Are the= jabber logs also recorded ? > > Best, > > C=E9dric. > > Le 18 mars 2013 =E0 11:05, Dowdell, John a =E9crit : > >> Adrian >> >> As a remote listener, I joined just as the last meeting was finishing. A= udio was good. Then the audio stream stopped. I can't tell if this was an a= dministrative thing (maybe to make a cut for the recording archive) but the= best thing for me would be if the stream could continue if there is only a= 10 minute break between meetings, and be cut and archived later. >> >> John >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Adrian Farrel >> Sent: 17 March 2013 22:51 >> To: manet@ietf.org >> Subject: Re: [manet] Audiocast (UNCLASSIFIED) >> >> Hi, >> >>> Unfortunately, for some participants the audio did not work. >> >> If anyone has any details on this (other than "it did not work") please = contact >> me unicast and we will see whether there is anything the technical team = can >> learn for next time. >> >> Thanks, >> Adrian >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> The information contained within this e-mail and any files attached to t= his e-mail is private and in addition may include commercially sensitive in= formation. The contents of this e-mail are for the intended recipient only = and therefore if you wish to disclose the information contained within this= e-mail or attached files, please contact the sender prior to any such disc= losure. If you are not the intended recipient, any disclosure, copying or d= istribution is prohibited. Please also contact the sender and inform them o= f the error and delete the e-mail, including any attached files from your s= ystem. Cassidian Limited, Registered Office : Quadrant House, Celtic Spring= s, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.= com >> _______________________________________________ >> 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 Mar 18 08:12:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DAD21F8F44 for ; Mon, 18 Mar 2013 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSOzf3H5JcEo for ; Mon, 18 Mar 2013 08:12:40 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8E21F88E3 for ; Mon, 18 Mar 2013 08:12:37 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id cz11so4433357veb.31 for ; Mon, 18 Mar 2013 08:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=xt4Hp3eqiT1GKdtYSX5VMUaGceDasm5zp4GQMc2W3EQ=; b=cYg0jNnsKyl8UlU/4AZ3XMo2AwnlCLNYZ5wkpwAagYl2MxMrdbV51uWIqAoWtRADjt 4rSOd1ouNHwYYYLu9YfuO/o1x5r2j/AYKdaLNh7+88rMiKchYeUecuvLEmI9TM0yx+Al yzVYEXhWB4aMQXE7KNa9/jmPbhj50zSRY81e4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=xt4Hp3eqiT1GKdtYSX5VMUaGceDasm5zp4GQMc2W3EQ=; b=Q0sVP5Ft68lEgZXUCeXGSsAuKp6BBI+kdZFjVbxUrCKqYMNNZTQ/QRY+5+qemjM1VF /rC6LuhSOT7zPATmeGqdvxeon9rIDsgtp2aFpHDfzMaOKK6Hf0SlRIu1XKnOhEBWsCnr EGK1XUFUOkbfPmwLzjreK+STDucW04Yeswale1v7hkJASRBY3msX/xQDO8HGn3VckpwA zq8m/MePdpOaneTF0Rj45mnGhTwh3cOFOWVsBJz4Ulju/TtPrHh/qUM25PtaDeNIi/Fg jvUQPzBpjuZekS4Is1fmA4jwpc0udbJStWj4L/e6DgJxwskbU6ilwDSU1VdGb+HhSEkt 4bnQ== MIME-Version: 1.0 X-Received: by 10.58.205.179 with SMTP id lh19mr20336731vec.7.1363619557300; Mon, 18 Mar 2013 08:12:37 -0700 (PDT) Received: by 10.220.107.83 with HTTP; Mon, 18 Mar 2013 08:12:37 -0700 (PDT) In-Reply-To: <5146E525.7060702@fkie.fraunhofer.de> References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> <5146E525.7060702@fkie.fraunhofer.de> Date: Mon, 18 Mar 2013 08:12:37 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlyqXlS/8yzPZCsg+Fd4IDlvHCBBnpsUe4XR86ScLr9ORWG4e3OeTsqOI9pZV2k95+lEZmw Cc: manet@ietf.org Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:12:40 -0000 Joe, I can confirm what Henning writes. The links on the web site ("tar|pdf") he references return empty files. Best regards Ulrich On Mon, Mar 18, 2013 at 2:57 AM, Henning Rogge wrote: > Hi, > > are the slides of the meeting available? I tried to download them from th= e > IETF side and got a "size zero" file. > > https://datatracker.ietf.org/meeting/86/agenda.html > > Both the tar and the PDF link for MANET is empty for me. > > Henning Rogge > > > On 03/17/2013 11:50 PM, Adrian Farrel wrote: >> >> Hi, >> >>> Unfortunately, for some participants the audio did not work. >> >> >> If anyone has any details on this (other than "it did not work") please >> contact >> me unicast and we will see whether there is anything the technical team >> can >> learn for next time. > > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From hrogge@googlemail.com Mon Mar 18 08:29:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F67A21F89CC for ; Mon, 18 Mar 2013 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VhJfp3ntUqw for ; Mon, 18 Mar 2013 08:29:44 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DD21F8B3B for ; Mon, 18 Mar 2013 08:29:28 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so6261218lab.9 for ; Mon, 18 Mar 2013 08:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=CkWAYrry8TatcFbAq27ivT/U10XBpKAijxQyT53r0EE=; b=O5mEt33prfXzZmSoSHNEqe1Wxb5F3RYUPEl5vQpvUlQ0NxU/TLjmdnyCMe0tmdcy8P Ybq22m/i4/sNdmtKP1kPuYy15VA23ews2prZ4eqkBHwoQTvxV5N3CdleUIfI1sul8Ymx fdqUFpG9CUOX9tP5dP4mIYq7OieHjeApuNvev+hxWFkJPvuISTSCWK2PbwabKMvzIrHL +yCwQgncD7Dz6+kVabBNeamaz3cTDOiqYj8bGN0+Znybd2kyaHZVHkDNYe762VnGsjaN WtdGoDo/82ebghPxVoJ9fe9LWviphymuYRkEMyOXCN7EtvKCXAJOBd/p7raw2AXLIPae HqJA== X-Received: by 10.152.123.34 with SMTP id lx2mr15079868lab.52.1363620567374; Mon, 18 Mar 2013 08:29:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Mon, 18 Mar 2013 08:29:07 -0700 (PDT) In-Reply-To: References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <00f001ce2361$dfa1b600$9ee52200$@olddog.co.uk> <5146E525.7060702@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 18 Mar 2013 16:29:07 +0100 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:29:45 -0000 But I got the correct ones from the other links... The audio file is also quite longer than the session, it contains more than half an hour of "empty" background noises. You can hear that some people are talking, but you cannot understand them. Henning Rogge On Mon, Mar 18, 2013 at 4:12 PM, Ulrich Herberg wrote= : > Joe, > > I can confirm what Henning writes. The links on the web site > ("tar|pdf") he references return empty files. > > Best regards > Ulrich > > On Mon, Mar 18, 2013 at 2:57 AM, Henning Rogge > wrote: >> Hi, >> >> are the slides of the meeting available? I tried to download them from t= he >> IETF side and got a "size zero" file. >> >> https://datatracker.ietf.org/meeting/86/agenda.html >> >> Both the tar and the PDF link for MANET is empty for me. >> >> Henning Rogge >> >> >> On 03/17/2013 11:50 PM, Adrian Farrel wrote: >>> >>> Hi, >>> >>>> Unfortunately, for some participants the audio did not work. >>> >>> >>> If anyone has any details on this (other than "it did not work") please >>> contact >>> me unicast and we will see whether there is anything the technical team >>> can >>> learn for next time. >> >> >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >> _______________________________________________ >> 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 --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ulrich@herberg.name Mon Mar 18 13:24:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED7C21F90E0 for ; Mon, 18 Mar 2013 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xMlWOk2JN+G for ; Mon, 18 Mar 2013 13:24:48 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7849A21F8F4F for ; Mon, 18 Mar 2013 13:24:48 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jx10so4704273veb.39 for ; Mon, 18 Mar 2013 13:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=BZ9b43357ZCpuMs5QYazhEQwl5LF2xX6Hzeg3cZi7U4=; b=yKKDTDYiAFTBiH/T3B44M7aJp4gIoC1BD1lL6gFrwLxkwIAv6+VuEigG/t0DU8cuGO iAFeSO8LMkbNlieorFu8aiMqEqfhQ0u1FBAW5Gl++f7J2U8NwCtysJgPLmfxW/i8CXQm pJmR4GkZv4GumVi+QcKK9TEUNvYlmCU2VKj0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=BZ9b43357ZCpuMs5QYazhEQwl5LF2xX6Hzeg3cZi7U4=; b=JdbNlyHs5O6tL+KfMwhyUdT5LnNMbfdzpYVdOeI95aH2ZtWBAsUvrbuXtDymjYBbUW 5DKY/YQoalVYAP/v7jUl/m1ka0BF1nYxObr0E9VzoEp29wtW9OU0l7Cz6Bcb19a/lMeI 3spXUPqJdQxqqzDcS0eRBuQL5skFii8WDyQ01MgLDHAlm9NH72laot+05L8fU+n5mf+L G1hu1ink1FfVk17GkQyFyAgyPeh4FEq8FjwI/Xyv5v55pWjm1vCINu9i8x9TK2BaYfPf J1wUDEsRDEJQ3HTh91+1zSUWEQ7dDdJ0/hMwaMYYidIBUlt8LmvaapovC6Byv5eQFV6h p1qQ== MIME-Version: 1.0 X-Received: by 10.52.90.211 with SMTP id by19mr18731074vdb.114.1363638287858; Mon, 18 Mar 2013 13:24:47 -0700 (PDT) Received: by 10.220.107.83 with HTTP; Mon, 18 Mar 2013 13:24:47 -0700 (PDT) Date: Mon, 18 Mar 2013 13:24:47 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlzFkwJ8dWKYGscRG4NiIjiuiAACkgrVxjYLjcC81GZqZV1H3xJ7A8ODB20CuUbtHEnqQRR Subject: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:24:49 -0000 Hello, I have uploaded the minutes to: http://www.ietf.org/proceedings/86/minutes/minutes-86-manet I would like to thank Brian Adamson who wrote the minutes! Regards Ulrich From sratliff@cisco.com Mon Mar 18 13:39:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752EF21F906E for ; Mon, 18 Mar 2013 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcINLHtZwy85 for ; Mon, 18 Mar 2013 13:39:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED021F905C for ; Mon, 18 Mar 2013 13:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=529; q=dns/txt; s=iport; t=1363639157; x=1364848757; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ny15kqsKw8IwYKso9dub0iat6iPQ16jA06aptVL2Wt8=; b=YIT2Zo4VizyuwhY+bFpaEeqA99DbfO+mNUqQWZWGIFhwXjS7v/FCqICQ epDsReplTriLyx7pmbsAe1XU4icpC58l4AsREILFjc1BYHEx1HUxSv62k 6Kt4HFunflpMa08sozXOpfxNkw9K3VHMzfD5n5rCNz6JO0LidSy6Ib/iz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAIl6R1GtJV2Y/2dsb2JhbABDh1q9R4FWFnSCJAEBAQMBAQEBNzQLBQsCAQgiFBAnCyUCBAENBQgBiAUGDMILjmICMQeCX2EDp2CDCoIo X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188796412" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 18 Mar 2013 20:39:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2IKdG52023524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 20:39:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 15:39:15 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg , Brian Adamson Thread-Topic: [manet] Minutes Thread-Index: AQHOJBanV/Z/iALG00qblkavpiBRb5isPPIA Date: Mon, 18 Mar 2013 20:39:15 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1005DF6E@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <9076AF7D5DC179418333C87E272DD121@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:39:17 -0000 Echoing Ulrich -=20 Thank you, Brian, for offering to take the minutes. It's greatly appreciate= d.=20 Regards, Stan On Mar 18, 2013, at 4:24 PM, Ulrich Herberg wrote: > Hello, >=20 > I have uploaded the minutes to: > http://www.ietf.org/proceedings/86/minutes/minutes-86-manet >=20 > I would like to thank Brian Adamson who wrote the minutes! >=20 > Regards > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From internet-drafts@ietf.org Wed Mar 20 03:43:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CA221F851C; Wed, 20 Mar 2013 03:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Ux-ggl0s88; Wed, 20 Mar 2013 03:43:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749121F8454; Wed, 20 Mar 2013 03:43:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130320104352.27601.32752.idtracker@ietfa.amsl.com> Date: Wed, 20 Mar 2013 03:43:52 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 10:43:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Security Threats for NHDP Author(s) : Ulrich Herberg Jiazi Yi Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-threats-02.txt Pages : 17 Date : 2013-03-20 Abstract: This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yi.jiazi@gmail.com Wed Mar 20 04:10:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450D821F8814 for ; Wed, 20 Mar 2013 04:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.97 X-Spam-Level: * X-Spam-Status: No, score=1.97 tagged_above=-999 required=5 tests=[AWL=5.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaSpfRK+H7yq for ; Wed, 20 Mar 2013 04:10:52 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79221F883E for ; Wed, 20 Mar 2013 04:10:52 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id dq12so1176895wgb.0 for ; Wed, 20 Mar 2013 04:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=X6W39HPwDCSvRK37PG/9F48gkpM7Wq2hkcmf/HFEUzM=; b=e7qFF7GkbU9wCDe2PWLR9X1HQsmbWrMY2tWTkHlrByI9fw/n3LPWb5nCE7HmIi3hfj 0iu2OLRcF1V/UX8e0vK9f7M5hD+XCJBKaPkYBWU0BngvDAeFk1MqEWlMdqX1dMK1v/gn 9SfTC2iDNHya+m46jA+b+2r8hAUNlmu7i0pMr3CQbDjZVo0PWZFZT97/SNic+PLrVV7r ea/Qvq82yQLdivyBjulOm5Gvs4CrYvC0TZi5XbrJ2xbgnH1ptVSIRfdWRN5K1HlE6PFQ onQT65qUge4wMLfiQLmp9O3c2gWOgKa28F2OW3MbLfqLzna2cqWOlxv8bZgPR/5Hdkhi oOaA== X-Received: by 10.180.82.33 with SMTP id f1mr2963324wiy.13.1363777850994; Wed, 20 Mar 2013 04:10:50 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id ej8sm6162430wib.9.2013.03.20.04.10.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 04:10:50 -0700 (PDT) Sender: Jiazi YI From: Jiazi Yi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Mar 2013 12:10:50 +0100 References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> To: manet List Message-Id: <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:10:53 -0000 Dear all,=20 The authors of nhdp-sec-threats have submitted a new revision based on = the comments during WGLC.=20 The only technical change is that, a new sub-section is added on link = quality update: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.8. Attack on Link Quality Update According to NHDP, "Link quality is a mechanism whereby a router MAY take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC. As such, it is a link admission mechanism.". Section 14.4 of NHDP [RFC6130] then lists several examples of which information can be used to update link quality. One of the listed examples is to update link quality based on [RFC5444] packet exchanges between neighbor routers, e.g., an NHDP Router may update the link quality of a neighbor based on receipt or loss of packets if they include a sequential packet sequence number. NHDP does not specify how to acquire link quality updates normatively, however, attack vectors may be introduced if an implementation chooses to calculate link quality based on packet sequence numbers. The consequences of such threats would depend on specific implementations. For example, if the link quality update is based on sequential packet sequence number from neighbor routers, a Comprised NDHP Router can spoof packets appearing to be from another Legitimate NHDP Router that skips some packet sequence numbers. The NHDP Router receiving the spoofed packets may degrade the link quality as it appears that several packets have been dropped. Eventually, the router remove the neighbor when the link quality drops below HYST_REJECT. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Your comments are welcome.=20 @chairs: I suppose that if this section gets approved, there is no need for = another WGLC for the whole document? best Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-nhdp-sec-threats-02.txt > Date: March 20, 2013 11:43:53 AM GMT+01:00 > To: jiazi@jiaziyi.com > Cc: t.clausen@computer.org, ulrich@herberg.name >=20 >=20 > A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Filename: draft-ietf-manet-nhdp-sec-threats > Revision: 02 > Title: Security Threats for NHDP > Creation date: 2013-03-20 > Group: manet > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.t= xt > Status: = http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats > Htmlized: = http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02 >=20 > Abstract: > This document analyses common security threats of the Neighborhood > Discovery Protocol (NHDP), and describes their potential impacts on > MANET routing protocols using NHDP. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From adrian@olddog.co.uk Thu Mar 21 02:47:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907D21F9024 for ; Thu, 21 Mar 2013 02:47:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy0migibNmnK for ; Thu, 21 Mar 2013 02:47:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3121F8F02 for ; Thu, 21 Mar 2013 02:47:36 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2L9lYbf004387; Thu, 21 Mar 2013 09:47:34 GMT Received: from 950129200 ([88.128.80.2]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2L9lTfa004286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 09:47:31 GMT From: "Adrian Farrel" To: "'C Chauvenet'" References: <1D6AC7FE-95DA-4912-B097-A3E6C81C2BBF@nrl.navy.mil> <3DC26342A93F204C804384C87DDBECBF3D742D1A@ucolhp9k.easf.csd.disa.mil> <603F5FD847B5174CBDA37A9DC00532FB0781FB93@SUCNPTEXM02.com.ad.uk.ds.corp> <79A5D951-560A-4575-A6D6-5573013EAE84@watteco.com> In-Reply-To: <79A5D951-560A-4575-A6D6-5573013EAE84@watteco.com> Date: Thu, 21 Mar 2013 09:47:31 -0000 Message-ID: <032b01ce2619$1e7ab840$5b7028c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaqHVYsvJGKbCcB+kuzqAyZbArbQHX0OD8Ad23sNMCmYULIQLpRWCEAe610oQDHcVSIgKzKbpRAdumoOOZAELAYA== Content-Language: en-gb Cc: 'MANET IETF' Subject: Re: [manet] Audiocast (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:47:41 -0000 In answer to Cedric specifically... All meeting materials are at https://datatracker.ietf.org/meeting/86/materials.html until the = secretariat has a chance to convert them to pdf and pop them in a tar ball. jabber logs are archived (for ever, or until the next nuclear strike) at http://www.ietf.org/jabber/logs/ Adrian > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com] > Sent: 18 March 2013 10:14 > To: adrian@olddog.co.uk > Cc: MANET IETF; Dowdell, John > Subject: Re: [manet] Audiocast (UNCLASSIFIED) >=20 > Hi, >=20 > Some additional feedback as a remote listener : >=20 > I had the same experience as John Dowdell, but the audio came back = about 15 > minutes after the beginning of the MANET session, so I was able to = follow most > of the session live, just missing the very beginning. >=20 > From what I remember from the VLC logs, I get something like a "404 = not found" > error on the web link...(Sorry I did not save these logs on a file). >=20 > There was a lot of questions from the jabber during this session. Are = the jabber > logs also recorded ? >=20 > Best, >=20 > C=E9dric. >=20 > Le 18 mars 2013 =E0 11:05, Dowdell, John a =E9crit : >=20 > > Adrian > > > > As a remote listener, I joined just as the last meeting was = finishing. Audio was > good. Then the audio stream stopped. I can't tell if this was an administrative > thing (maybe to make a cut for the recording archive) but the best = thing for me > would be if the stream could continue if there is only a 10 minute = break between > meetings, and be cut and archived later. > > > > John > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of > Adrian Farrel > > Sent: 17 March 2013 22:51 > > To: manet@ietf.org > > Subject: Re: [manet] Audiocast (UNCLASSIFIED) > > > > Hi, > > > >> Unfortunately, for some participants the audio did not work. > > > > If anyone has any details on this (other than "it did not work") = please contact > > me unicast and we will see whether there is anything the technical = team can > > learn for next time. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > The information contained within this e-mail and any files attached = to this e- > mail is private and in addition may include commercially sensitive information. > The contents of this e-mail are for the intended recipient only and = therefore if > you wish to disclose the information contained within this e-mail or = attached files, > please contact the sender prior to any such disclosure. If you are not = the > intended recipient, any disclosure, copying or distribution is = prohibited. Please > also contact the sender and inform them of the error and delete the = e-mail, > including any attached files from your system. Cassidian Limited, = Registered > Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ > Company No: 04191036 http://www.cassidian.com > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > From internet-drafts@ietf.org Thu Mar 21 09:06:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08F521F90D3; Thu, 21 Mar 2013 09:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Its4+r5QJoCO; Thu, 21 Mar 2013 09:06:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2327121F90DA; Thu, 21 Mar 2013 09:06:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130321160621.6054.19421.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2013 09:06:21 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:06:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Manet Simplified M= ulticast Framework Relay Set Process Author(s) : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-07.txt Pages : 56 Date : 2013-03-21 Abstract: 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 Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Mar 23 11:55:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43121F8BDD; Sat, 23 Mar 2013 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOt3Ubq+LVoC; Sat, 23 Mar 2013 11:55:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B0521F8BBD; Sat, 23 Mar 2013 11:55:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130323185536.14265.64705.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2013 11:55:36 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 18:55:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Check Value and Timestamp TLV Definitions for = Mobile Ad Hoc Networks (MANETs) Author(s) : Ulrich Herberg Thomas Heide Clausen Christopher Dearlove Filename : draft-ietf-manet-rfc6622-bis-00.txt Pages : 21 Date : 2013-03-22 Abstract: This document extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Mar 23 11:56:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F188421F8BF6; Sat, 23 Mar 2013 11:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-UG+SdiGKNi; Sat, 23 Mar 2013 11:56:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BE621F8BE9; Sat, 23 Mar 2013 11:56:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130323185605.12588.46033.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2013 11:56:05 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-sec-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 18:56:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Protection for Control Messages in NHDP and OL= SRv2 Author(s) : Ulrich Herberg Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-sec-00.txt Pages : 13 Date : 2013-03-22 Abstract: This document specifies integrity and replay protection for required implementation in the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This document specifies how an included integrity check value (ICV) and a timestamp TLV, defined in RFC6622bis, are used by NHDP and OLSRv2 for countering a number of security threats. The ICV TLV uses a SHA-256 based HMAC and a single shared secret key. The timestamp TLV is based on POSIX time, assuming router synchronization. The mechanism in this specification can also be used for other MANET protocols using RFC5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-sec-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sratliff@cisco.com Sat Mar 23 11:57:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA321F861B for ; Sat, 23 Mar 2013 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LwNIbTHxZTB for ; Sat, 23 Mar 2013 11:57:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2897821F8613 for ; Sat, 23 Mar 2013 11:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2963; q=dns/txt; s=iport; t=1364065057; x=1365274657; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HY/Czv4Ckoyt+gC4QnXYBtXZ1OUBFxJcNDmV1mqt55E=; b=WS6KAcJCabmI7M2dFScOkQJs4p6cd5G0DO74E6f/wZW9mLkpW1h84rtA YKeGH0OwFcvOZZnIkOrGur+k/jXNEVWJdrV9DsuHxK9gwV/uBqxCB524q NG7o/FpR8x7Z7GljbxvafcmaApiIPPxXiGKFSu/Y8SjDS7WpzgGc9nsiA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFz6TVGtJV2d/2dsb2JhbABExXSBdBZ0giQBAQEDAQEBATc0CwULAgEIGAoUECcLJQIEDgUIE4dzBgzBCY1YgQ0CMQeCX2EDkyGEZY9lgwqBczU X-IronPort-AV: E=Sophos;i="4.84,897,1355097600"; d="scan'208";a="190731991" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 23 Mar 2013 18:57:36 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2NIva88023516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Mar 2013 18:57:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sat, 23 Mar 2013 13:57:36 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Security documents for OLSRv2/NHDP Thread-Index: AQHOIaWznpJD/yD5G0K5xcEOhuWrxJincEmAgAyQywA= Date: Sat, 23 Mar 2013 18:57:36 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Dearlove , "" , Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 18:57:38 -0000 WG Participants: The polling period has passed, *without* negative opinions on accepting the= documents as WG documents. Therefore, they have been submitted via the dat= a-tracker, and you should get email on their posting.=20 Regards, Stan On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote: > Ulrich,=20 >=20 > Thanks for this email. OK, Working Group participants: Consider this a 1-= week poll for adoption of these docs as WG documents. Polling period ends M= arch 22. And, silence will be deemed to be agreement that the documents *sh= ould be* accepted as WG docs.=20 >=20 > Regards, > Stan >=20 > On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: >=20 >> Dear all, >>=20 >> The OLSRv2 authors have had a discussion with Stephen Farrell (Security = AD) >> and Adrian about how to resolve the remaining security related DISCUSS >> on OLSRv2, and we agreed on a way forward that involves the following >> steps: >>=20 >> 1) Publication of: >> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>=20 >> This document mandates (at least) implementation of HMAC/SHA2 >> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >> use that mechanism unless they have a more appropriate solution (e.g., >> different cipher) for that particular deployment. This document also >> updates NHDP and mandates to implement the same HMAC/SHA2 protection >> for HELLO messages. >>=20 >> 2) Publication of: >> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>=20 >> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >> The differences are minor to RFC6622 and can be seen here: >> http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-manet-= rfc6622-bis >> Essentially, RFC6622 does not protect the IP source address of the >> interface over which the control message is sent. Since that address >> is used to establish neighbors in NHDP (and therefore must be >> protected), a new type extension 3 of the ICV TLV has been added to >> the registry. >>=20 >> 3) Publication of an update to OLSRv2, referencing the use of the >> defined security mechanism, and resolving other smaller issues from >> Stephen's DISCUSS. >>=20 >> In order to not hold up OLSRv2 further, and upon discussions with Stan >> and Adrian, we would like to request WG adoption of these two new >> documents - asking that the chairs will officially poll the WG on this >> matter shortly. The documents are brief, and addresses issues >> requested by the ADs, so we hope that processing them should also be a >> brief affair. >>=20 >> Best regards >> 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 christopher.dearlove@googlemail.com Sat Mar 23 12:04:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6321F8D19 for ; Sat, 23 Mar 2013 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Zi2gapCviE for ; Sat, 23 Mar 2013 12:04:38 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5921F8CF5 for ; Sat, 23 Mar 2013 12:04:37 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so9716053wib.1 for ; Sat, 23 Mar 2013 12:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=crmrH1lqR+X7YunNGQxGD8NGDLGFYq3eJC7ilFkoJ6c=; b=KqA7Vqa0Qog5jtVobQ0VaNzqzwmbwXmrwshSCz8ECg6rGMR6mmDumX0CmuG4GWhU4U 5VB991qKg0XbVIXJtiK6DRx0JShlbJOvPxwEGc+KigaKhUASIet86ApT5nsXwLRRhWnQ LQpPHUaXKaDhCjxa1XW12jTtc8eLTNNjdDG/DmeTCh6dLwDJ2Y3rjApAEPptgl5xVH+d nuGgm/B3OzuP7aRZQ5oF1n9RO8uNGxIEKq/8stDisq0RDMtsF+CuWuIEu1AsmloCBm6e H1QFmrn5dH+WBTPAK3r9StMzdUfWxAPpuhvNMAiyfLIx4A9AMjd+G9C+rVZSizlewvwT G8pQ== X-Received: by 10.194.83.105 with SMTP id p9mr9673627wjy.56.1364065477084; Sat, 23 Mar 2013 12:04:37 -0700 (PDT) Received: from [192.168.254.4] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPS id ej8sm18251964wib.9.2013.03.23.12.04.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 12:04:36 -0700 (PDT) References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Sat, 23 Mar 2013 19:04:55 +0000 To: "Stan Ratliff (sratliff)" Cc: Christopher Dearlove , "" , Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:04:39 -0000 Thanks, Stan. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 23 Mar 2013, at 18:57, "Stan Ratliff (sratliff)" wro= te: > WG Participants: >=20 > The polling period has passed, *without* negative opinions on accepting th= e documents as WG documents. Therefore, they have been submitted via the dat= a-tracker, and you should get email on their posting.=20 >=20 > Regards, > Stan >=20 > On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote: >=20 >> Ulrich,=20 >>=20 >> Thanks for this email. OK, Working Group participants: Consider this a 1-= week poll for adoption of these docs as WG documents. Polling period ends Ma= rch 22. And, silence will be deemed to be agreement that the documents *shou= ld be* accepted as WG docs.=20 >>=20 >> Regards, >> Stan >>=20 >> On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: >>=20 >>> Dear all, >>>=20 >>> The OLSRv2 authors have had a discussion with Stephen Farrell (Security A= D) >>> and Adrian about how to resolve the remaining security related DISCUSS >>> on OLSRv2, and we agreed on a way forward that involves the following >>> steps: >>>=20 >>> 1) Publication of: >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >>>=20 >>> This document mandates (at least) implementation of HMAC/SHA2 >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >>> use that mechanism unless they have a more appropriate solution (e.g., >>> different cipher) for that particular deployment. This document also >>> updates NHDP and mandates to implement the same HMAC/SHA2 protection >>> for HELLO messages. >>>=20 >>> 2) Publication of: >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >>>=20 >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >>> The differences are minor to RFC6622 and can be seen here: >>> http://tools.ietf.org/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-manet-= rfc6622-bis >>> Essentially, RFC6622 does not protect the IP source address of the >>> interface over which the control message is sent. Since that address >>> is used to establish neighbors in NHDP (and therefore must be >>> protected), a new type extension 3 of the ICV TLV has been added to >>> the registry. >>>=20 >>> 3) Publication of an update to OLSRv2, referencing the use of the >>> defined security mechanism, and resolving other smaller issues from >>> Stephen's DISCUSS. >>>=20 >>> In order to not hold up OLSRv2 further, and upon discussions with Stan >>> and Adrian, we would like to request WG adoption of these two new >>> documents - asking that the chairs will officially poll the WG on this >>> matter shortly. The documents are brief, and addresses issues >>> requested by the ADs, so we hope that processing them should also be a >>> brief affair. >>>=20 >>> Best regards >>> 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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Mar 23 13:06:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DAF21F8595 for ; Sat, 23 Mar 2013 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUZOSIsaC5IW for ; Sat, 23 Mar 2013 13:06:38 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE921F856C for ; Sat, 23 Mar 2013 13:06:38 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa10so434024pad.27 for ; Sat, 23 Mar 2013 13:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=+3wvkhsgMIksK/aLoTVej7HKgdkF8nzFAYnMmE6MF18=; b=z30kWHlx4BDyHffjZgw4lZ2sYx2zS1fb0r99RDaJ9+amFmT5KPgifM4q/EYNQ30Fmi UhV25Z3dT2TxX89rjFwj4roBSd4LEx74pc5+pMR0FQ3SCaXc3g/qMI7ivQE0R9quLl+M KJk6ZQYiEwjIG+hiXEfyF4v44zB0oxZ+iLCIORDMqkqL9uqvXnCdsMhzP+TvTmMGC8Tm ixaTq/iOEdIiIKk2unEu1WKKuhEDGKTBTny0oJpvqlzq7/Kkdiiv8grz6vjyIbYVbwcV 41R85kBk8lPLf10tjIAWHceLgV4wqMZWsZVIc8AXZgXun02wppM8FBr8j7NP2rnuXy3l tPNQ== MIME-Version: 1.0 X-Received: by 10.66.164.41 with SMTP id yn9mr9932720pab.93.1364069198450; Sat, 23 Mar 2013 13:06:38 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sat, 23 Mar 2013 13:06:38 -0700 (PDT) In-Reply-To: <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> Date: Sat, 23 Mar 2013 21:06:38 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:06:40 -0000 To: Editors and co-chairs I agree with changes but draft needs to not ignore participants/efforts, please add my name in the acknowledgement section, if not please explain, otherwise I will need to report to AD, Regards Abdussalam Baryun On 3/20/13, Jiazi Yi wrote: > Dear all, > > The authors of nhdp-sec-threats have submitted a new revision based on the > comments during WGLC. > > The only technical change is that, a new sub-section is added on link > quality update: > > ========== > 4.8. Attack on Link Quality Update > > According to NHDP, "Link quality is a mechanism whereby a router MAY > take considerations other than message exchange into account for > determining when a link is and is not a candidate for being > considered as HEARD or SYMMETRIC. As such, it is a link admission > mechanism.". > > Section 14.4 of NHDP [RFC6130] then lists several examples of which > information can be used to update link quality. One of the listed > examples is to update link quality based on [RFC5444] packet > exchanges between neighbor routers, e.g., an NHDP Router may update > the link quality of a neighbor based on receipt or loss of packets if > they include a sequential packet sequence number. > > NHDP does not specify how to acquire link quality updates > normatively, however, attack vectors may be introduced if an > implementation chooses to calculate link quality based on packet > sequence numbers. The consequences of such threats would depend on > specific implementations. For example, if the link quality update is > based on sequential packet sequence number from neighbor routers, a > Comprised NDHP Router can spoof packets appearing to be from another > Legitimate NHDP Router that skips some packet sequence numbers. The > NHDP Router receiving the spoofed packets may degrade the link > quality as it appears that several packets have been dropped. > Eventually, the router remove the neighbor when the link quality > drops below HYST_REJECT. > ========== > > Your comments are welcome. > > @chairs: > I suppose that if this section gets approved, there is no need for another > WGLC for the whole document? > > best > > Jiazi > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >> draft-ietf-manet-nhdp-sec-threats-02.txt >> Date: March 20, 2013 11:43:53 AM GMT+01:00 >> To: jiazi@jiaziyi.com >> Cc: t.clausen@computer.org, ulrich@herberg.name >> >> >> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >> has been successfully submitted by Jiazi Yi and posted to the >> IETF repository. >> >> Filename: draft-ietf-manet-nhdp-sec-threats >> Revision: 02 >> Title: Security Threats for NHDP >> Creation date: 2013-03-20 >> Group: manet >> Number of pages: 17 >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.txt >> Status: >> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >> Htmlized: >> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-02 >> >> Abstract: >> This document analyses common security threats of the Neighborhood >> Discovery Protocol (NHDP), and describes their potential impacts on >> MANET routing protocols using NHDP. >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From yi.jiazi@gmail.com Sat Mar 23 15:29:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0959E21F87CB; Sat, 23 Mar 2013 15:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHkCW9bg+diP; Sat, 23 Mar 2013 15:29:26 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id A34A521F87AB; Sat, 23 Mar 2013 15:29:25 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so2856644wib.0 for ; Sat, 23 Mar 2013 15:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=nRj3ZgdcSXjcxCxOQfZb3iS/8gZXLiecmtDljiLEl1Q=; b=vab7VcnNpVJzNVNwgvPfSjrpjqw+1mu+O4rGfl7Svst9obTXx78sb2E7N4W9eCkexi KfXsQRqdiLoduDiITXmby6CzL9TU1lknpa1EdU3oScOQ9GMfZbfHPMBf0pjhF6XMDExh 0eG8Te7EkxRDgcFrrwf2BimV5P98QqyWTrV8qNluMWvjaN5j44EsxiQ+rUDMu4zzm4+4 j/MVFt9A8l+E4V6CZsHgz0UJ2v7VYUUgbN6BxXUJf/6wEcuURz7O+snAAaCScuDoH0Zr f1YfYYwbbpbX//s4PILUuco/Dg9MO/+Nl/MKLbfAxUMDheOH+hXRNYhLJDnbyF4O1vdm SKZg== X-Received: by 10.194.92.231 with SMTP id cp7mr10245447wjb.19.1364077764661; Sat, 23 Mar 2013 15:29:24 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id dp5sm19224167wib.1.2013.03.23.15.29.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 15:29:23 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Sat, 23 Mar 2013 23:29:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1227E12F-9593-4A8C-A54D-B210A61060D2@jiaziyi.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet List , ietf Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 22:29:27 -0000 Dear AB,=20 On this particular issue (threats of packet sequence number), as far as = I can remember, the change was not based on (or influenced by) your = input. In the meantime, the input from Chris, Henning, Teco, etc., does = have impact on the document.=20 It is true that you mentioned several times that message sequence number = threat should be kept in nhdp-sec-threat. However, you didn't provide = valid technical argument why it should be kept. Actually, there is no = doubt that the original section of sequence number in -00 revision was = wrong.=20 My understanding of "IETF input" must be based on technical argument.=20 Simply saying "I want *foo*, not *bar*" - without explaining why - = doesn't say much thing. Even *foo* was adopted in the end.=20 In the contrast, even some one is against *foo*, but he provided valid = arguments during the discussion that help improving the design, he = should be regarded as contributor.=20 Last but not least, we acknowledged all the MANET participants - if you = regard yourself as one of the participants, then you are acknowledged.=20= btw, I remembered that you brought a discussion on RFC Acknowledgement = http://www.ietf.org/mail-archive/web/ietf/current/msg77065.html before. = I didn't follow that thread, but I think other participants have already = explained fairly well how it works.=20 My personal suggestion is that, if you put move attention to the = previous sections of the document(s), rather than acknowledgment = section, you would be naturally listed there - that's how IETF works.=20 sincerely=20 Jiazi On Mar 23, 2013, at 9:17 PM, Abdussalam Baryun = wrote: > Hi Jiazi (draft editor) >=20 > Please note that I had effort to make below change in this draft, but > my name is not in acknowledgement as others were. Please add my name. > I don't think the changes was not influenced by my inputs and > discussions. I don't think that the changes was to happen if I ignored > the draft ( i.e. it was in WGLC and not much discussions). I don't > think I should be discouraged, >=20 > Best regards > Abdussalam Baryun, > +++++++++++++++++ > If the IETF culture is to encourage participants then editors SHOULD > add efforts owners in acknowledgements, otherwise participants MAY be > discouraged (depends on individual culture). > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 > The below message in MANET WG list >=20 > On 3/20/13, Jiazi Yi wrote: >> Dear all, >>=20 >> The authors of nhdp-sec-threats have submitted a new revision based = on the >> comments during WGLC. >>=20 >> The only technical change is that, a new sub-section is added on link >> quality update: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 4.8. Attack on Link Quality Update >>=20 >> According to NHDP, "Link quality is a mechanism whereby a router MAY >> take considerations other than message exchange into account for >> determining when a link is and is not a candidate for being >> considered as HEARD or SYMMETRIC. As such, it is a link admission >> mechanism.". >>=20 >> Section 14.4 of NHDP [RFC6130] then lists several examples of which >> information can be used to update link quality. One of the listed >> examples is to update link quality based on [RFC5444] packet >> exchanges between neighbor routers, e.g., an NHDP Router may update >> the link quality of a neighbor based on receipt or loss of packets = if >> they include a sequential packet sequence number. >>=20 >> NHDP does not specify how to acquire link quality updates >> normatively, however, attack vectors may be introduced if an >> implementation chooses to calculate link quality based on packet >> sequence numbers. The consequences of such threats would depend on >> specific implementations. For example, if the link quality update = is >> based on sequential packet sequence number from neighbor routers, a >> Comprised NDHP Router can spoof packets appearing to be from another >> Legitimate NHDP Router that skips some packet sequence numbers. The >> NHDP Router receiving the spoofed packets may degrade the link >> quality as it appears that several packets have been dropped. >> Eventually, the router remove the neighbor when the link quality >> drops below HYST_REJECT. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Your comments are welcome. >>=20 >> @chairs: >> I suppose that if this section gets approved, there is no need for = another >> WGLC for the whole document? >>=20 >> best >>=20 >> Jiazi >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-ietf-manet-nhdp-sec-threats-02.txt >>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>> To: jiazi@jiaziyi.com >>> Cc: t.clausen@computer.org, ulrich@herberg.name >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>> has been successfully submitted by Jiazi Yi and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-ietf-manet-nhdp-sec-threats >>> Revision: 02 >>> Title: Security Threats for NHDP >>> Creation date: 2013-03-20 >>> Group: manet >>> Number of pages: 17 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.t= xt >>> Status: >>> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >>> Htmlized: >>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 >>> Diff: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02 >>>=20 >>> Abstract: >>> This document analyses common security threats of the Neighborhood >>> Discovery Protocol (NHDP), and describes their potential impacts on >>> MANET routing protocols using NHDP. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 From sratliff@cisco.com Sat Mar 23 16:54:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC50E21F8CD1 for ; Sat, 23 Mar 2013 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erlqe9ci2ZL3 for ; Sat, 23 Mar 2013 16:54:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9921F8CD0 for ; Sat, 23 Mar 2013 16:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3927; q=dns/txt; s=iport; t=1364082843; x=1365292443; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fxY2HEZ0/+kP6evhfw+QW+1PFl5h2FH7IgxPVQ98Jv0=; b=L+x7bSYc2nJHwqyGb1mMB6u/O+tR0hHmqroSWp69OLQvsXaRyN3nF9aS gOF5UpCFDImZ/Xw+5GOXiHaAFgOWwcpDOILXDaBKfvJ8yqVSVHQx3N1ZA apJAk3NlM9uFTByT38BXtzLIIivrQhQejncO7L/ZxtQWps2NQxLyKKLkp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAKk/TlGtJXG8/2dsb2JhbABDhV/AF4F2FnSCJAEBAQMBAQEBawkCBQsCAQgOAwMBAgsLGScLHQgCBA4FCAGIBQYHBcBtF45lAiYLBwYEglVhA5gGj2WBVIE2gig X-IronPort-AV: E=Sophos;i="4.84,897,1355097600"; d="scan'208";a="190566872" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 23 Mar 2013 23:54:02 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2NNs2qM008495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Mar 2013 23:54:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sat, 23 Mar 2013 18:54:01 -0500 From: "Stan Ratliff (sratliff)" To: Jiazi Yi Thread-Topic: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt Thread-Index: AQHOJVuZVwb3qf3gIEC7x0MP3Om2/Ji0THsA Date: Sat, 23 Mar 2013 23:54:01 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> In-Reply-To: <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.215] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4735698D7932AE42BE09BCA851122E29@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 23:54:03 -0000 Jiazi,=20 You've added a new sub-section, so my opinion is yes, we *do* need another = WGLC for the document. There may not be a ton of text here, but adding a se= ction (or a sub-section) is a pretty significant change. Therefore, I think= the WG should have an opportunity to express its consensus. Unless, of cou= rse, I get over-ridden by my co-chair and/or the ADs=85 ;-) Regards, Stan On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: > Dear all,=20 >=20 > The authors of nhdp-sec-threats have submitted a new revision based on th= e comments during WGLC.=20 >=20 > The only technical change is that, a new sub-section is added on link qua= lity update: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 4.8. Attack on Link Quality Update >=20 > According to NHDP, "Link quality is a mechanism whereby a router MAY > take considerations other than message exchange into account for > determining when a link is and is not a candidate for being > considered as HEARD or SYMMETRIC. As such, it is a link admission > mechanism.". >=20 > Section 14.4 of NHDP [RFC6130] then lists several examples of which > information can be used to update link quality. One of the listed > examples is to update link quality based on [RFC5444] packet > exchanges between neighbor routers, e.g., an NHDP Router may update > the link quality of a neighbor based on receipt or loss of packets if > they include a sequential packet sequence number. >=20 > NHDP does not specify how to acquire link quality updates > normatively, however, attack vectors may be introduced if an > implementation chooses to calculate link quality based on packet > sequence numbers. The consequences of such threats would depend on > specific implementations. For example, if the link quality update is > based on sequential packet sequence number from neighbor routers, a > Comprised NDHP Router can spoof packets appearing to be from another > Legitimate NHDP Router that skips some packet sequence numbers. The > NHDP Router receiving the spoofed packets may degrade the link > quality as it appears that several packets have been dropped. > Eventually, the router remove the neighbor when the link quality > drops below HYST_REJECT. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Your comments are welcome.=20 >=20 > @chairs: > I suppose that if this section gets approved, there is no need for anothe= r WGLC for the whole document? >=20 > best >=20 > Jiazi >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-threats-= 02.txt >> Date: March 20, 2013 11:43:53 AM GMT+01:00 >> To: jiazi@jiaziyi.com >> Cc: t.clausen@computer.org, ulrich@herberg.name >>=20 >>=20 >> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >> has been successfully submitted by Jiazi Yi and posted to the >> IETF repository. >>=20 >> Filename: draft-ietf-manet-nhdp-sec-threats >> Revision: 02 >> Title: Security Threats for NHDP >> Creation date: 2013-03-20 >> Group: manet >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-nh= dp-sec-threats-02.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-s= ec-threats >> Htmlized: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-th= reats-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhd= p-sec-threats-02 >>=20 >> Abstract: >> This document analyses common security threats of the Neighborhood >> Discovery Protocol (NHDP), and describes their potential impacts on >> MANET routing protocols using NHDP. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From internet-drafts@ietf.org Sat Mar 23 17:03:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87DE21F8CB6; Sat, 23 Mar 2013 17:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXVnyPJu7+gq; Sat, 23 Mar 2013 17:03:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE921F8BBC; Sat, 23 Mar 2013 17:03:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130324000333.19971.66494.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2013 17:03:33 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:03:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Check Value and Timestamp TLV Definitions for = Mobile Ad Hoc Networks (MANETs) Author(s) : Ulrich Herberg Thomas Heide Clausen Christopher Dearlove Filename : draft-ietf-manet-rfc6622-bis-01.txt Pages : 22 Date : 2013-03-23 Abstract: This document extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Mar 23 17:05:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6650921F8CBD; Sat, 23 Mar 2013 17:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF6fVsoUPjr1; Sat, 23 Mar 2013 17:05:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9320821F8CD0; Sat, 23 Mar 2013 17:05:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130324000555.2111.48314.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2013 17:05:55 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-sec-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:05:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Protection for Control Messages in NHDP and OL= SRv2 Author(s) : Ulrich Herberg Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-sec-01.txt Pages : 13 Date : 2013-03-23 Abstract: This document specifies integrity and replay protection for required implementation in the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This document specifies how an included integrity check value (ICV) and a timestamp TLV, defined in RFC6622bis, are used by NHDP and OLSRv2 for countering a number of security threats. The ICV TLV uses a SHA-256 based HMAC and one or more shared secret keys. The timestamp TLV is based on POSIX time, and assumes that the clocks in all routers in the network can be synchronized with sufficient precision. The mechanism in this specification can also be used for other MANET protocols using RFC5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-sec-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-olsrv2-sec-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Mar 23 17:07:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96321F856C; Sat, 23 Mar 2013 17:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yskkfwCvxDMj; Sat, 23 Mar 2013 17:07:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B521F8533; Sat, 23 Mar 2013 17:07:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130324000747.30841.80739.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2013 17:07:47 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:07:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : The Optimized Link State Routing Protocol version 2 Author(s) : Thomas Heide Clausen Christopher Dearlove Philippe Jacquet Ulrich Herberg Filename : draft-ietf-manet-olsrv2-19.txt Pages : 113 Date : 2013-03-23 Abstract: This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ulrich@herberg.name Sat Mar 23 17:19:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F79421F8CA7 for ; Sat, 23 Mar 2013 17:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbqIXPzwVDgv for ; Sat, 23 Mar 2013 17:19:32 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF421F8CA6 for ; Sat, 23 Mar 2013 17:19:31 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hr11so3996963vcb.17 for ; Sat, 23 Mar 2013 17:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Sej5nyKEsSY5z21cgyqwJL88Q1jrvgggwg8+PFh39B4=; b=Y3yY+MdnmofkcpKpPNKeiYYbdIukFcdu/3+jK47bL7W9r+GFyFveFGCpwd2IGkVos8 QaRVgFNf3wUUgWaJMRAyt8jlmLIcbPMiLzpxleUjVrKmawfrkt5IGu4y2LdwfV47WHd4 voH/90l6qS/kRv7rMu/t9BIs37I42LHILEszk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Sej5nyKEsSY5z21cgyqwJL88Q1jrvgggwg8+PFh39B4=; b=CQvF3XcJE0lD5bKVOCoVZQ8gnUlMEI65wkQzy1X4oI1t+VMGpIWKObElpwbayaCHQs tCFfrLfRHSZCH4i0SjpKZltzwzeWiEei7f2GuLjZMr0kjgUvKZOIlxh+pmcP3s2xVelt KLnSG2bWYThw2QF6ZDn2AJjHD082GVrUZ+1NOy+Us3pv0FmiNX17X4YmkLTETpewSZUk bnsSZBjDQLy2OFlYzM16adADlEMU/MMKPxeFPlErbS/UmQQiMneHNv2w+Uu4cE6iSo+6 lqyXpsSOcCM1lPyE6Pkxx3el3CbAtBlBGLgsND+WuzJtzHG1vyXK0T2jhW8pDAdpG5sw 7CFw== MIME-Version: 1.0 X-Received: by 10.52.19.239 with SMTP id i15mr7703066vde.47.1364084371163; Sat, 23 Mar 2013 17:19:31 -0700 (PDT) Received: by 10.220.141.81 with HTTP; Sat, 23 Mar 2013 17:19:30 -0700 (PDT) In-Reply-To: <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> Date: Sat, 23 Mar 2013 17:19:30 -0700 Message-ID: From: Ulrich Herberg To: Christopher Dearlove Content-Type: multipart/alternative; boundary=20cf3078114c64adac04d8a0a43d X-Gm-Message-State: ALoCoQmBQzY5rv/dw1h74QCu1qeKp5QhjPJwE7O7Xih4M8Gg/knZ20uL5YN8z+7KxKSzVOWchXLV Cc: Christopher Dearlove , "" , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:19:33 -0000 --20cf3078114c64adac04d8a0a43d Content-Type: text/plain; charset=ISO-8859-1 Dear all, as you have seen, we have submitted the two documents as WG documents (with the same contents as the individual counterparts), and we have updated them to a -01 revision. Brief summary of changes (besides editorial changes) from -00 to -01: 1) nhdp-olsrv2-sec: - Stephen Farrell has caught one oversight in the OLSRv-18, which is that we talk about "one single shared secret key" that is used in the default use case of integrity and replay protection. As he pointed out, there could be a small number of N shared keys that are all pre-deployed. Using RFC6622-bis, it is straight-forward to select the index of the key that is used within the MANET. This led to a minimal update of both OLSRv2 and nhdp-olsrv2-sec 2) RFC6622-bis: - Stephen suggested to normatively cite this document from OLSRv2 (it is already transitively cited via nhdp-olsrv2-sec anyway). - We added one subsection "changes to RFC6622" that describes the differences to RFC6622 The authors believe that the two security documents are stable. Note in particular that (i) nhdp-olsrv2-sec is the same mechanism that has been discussed in draft-ietf-manet-nhdp-sec, just applied to both OLSRv2 and NHDP (and updating RFC6130). nhdp-sec has been in the WG for a long time. (ii) RFC6622-bis has the same specification as RFC6622 with the exception of one additional type extension for the ICV TLV that has the same TLV value structure, but includes the IP source address of the IP datagram, when calculating the ICV. (iii) OLSRv2-19 has normative references to both security documents; it will not be published as RFC as long as these two documents are not finished. Therefore, I hope that we can initiate a first WG LC on both security documents very soon. Thanks Ulrich On Sat, Mar 23, 2013 at 12:04 PM, Christopher Dearlove < christopher.dearlove@googlemail.com> wrote: > Thanks, Stan. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 23 Mar 2013, at 18:57, "Stan Ratliff (sratliff)" > wrote: > > > WG Participants: > > > > The polling period has passed, *without* negative opinions on accepting > the documents as WG documents. Therefore, they have been submitted via the > data-tracker, and you should get email on their posting. > > > > Regards, > > Stan > > > > On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote: > > > >> Ulrich, > >> > >> Thanks for this email. OK, Working Group participants: Consider this a > 1-week poll for adoption of these docs as WG documents. Polling period ends > March 22. And, silence will be deemed to be agreement that the documents > *should be* accepted as WG docs. > >> > >> Regards, > >> Stan > >> > >> On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: > >> > >>> Dear all, > >>> > >>> The OLSRv2 authors have had a discussion with Stephen Farrell > (Security AD) > >>> and Adrian about how to resolve the remaining security related DISCUSS > >>> on OLSRv2, and we agreed on a way forward that involves the following > >>> steps: > >>> > >>> 1) Publication of: > >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 > >>> > >>> This document mandates (at least) implementation of HMAC/SHA2 > >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should > >>> use that mechanism unless they have a more appropriate solution (e.g., > >>> different cipher) for that particular deployment. This document also > >>> updates NHDP and mandates to implement the same HMAC/SHA2 protection > >>> for HELLO messages. > >>> > >>> 2) Publication of: > >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 > >>> > >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. > >>> The differences are minor to RFC6622 and can be seen here: > >>> > http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis > >>> Essentially, RFC6622 does not protect the IP source address of the > >>> interface over which the control message is sent. Since that address > >>> is used to establish neighbors in NHDP (and therefore must be > >>> protected), a new type extension 3 of the ICV TLV has been added to > >>> the registry. > >>> > >>> 3) Publication of an update to OLSRv2, referencing the use of the > >>> defined security mechanism, and resolving other smaller issues from > >>> Stephen's DISCUSS. > >>> > >>> In order to not hold up OLSRv2 further, and upon discussions with Stan > >>> and Adrian, we would like to request WG adoption of these two new > >>> documents - asking that the chairs will officially poll the WG on this > >>> matter shortly. The documents are brief, and addresses issues > >>> requested by the ADs, so we hope that processing them should also be a > >>> brief affair. > >>> > >>> Best regards > >>> 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 > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > --20cf3078114c64adac04d8a0a43d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

as you have seen, we have submitted the two documents as W= G documents (with the same contents as the individual counterparts), and we= have updated them to a -01 revision.

Brief summary of changes (besi= des editorial changes) from -00 to -01:
1) nhdp-olsrv2-sec:
=A0=A0 - Stephen Farrell has caught one oversight i= n the OLSRv-18, which is that we talk about "one single shared secret = key" that is used in the default use case of integrity and replay prot= ection. As he pointed out, there could be a small number of N shared keys t= hat are all pre-deployed. Using RFC6622-bis, it is straight-forward to sele= ct the index of the key that is used within the MANET.
This led to a minimal update of both OLSRv2 and nhdp-olsrv2-sec

2) R= FC6622-bis:
=A0 - Stephen suggested to normatively cite this document fr= om OLSRv2 (it is already transitively cited via nhdp-olsrv2-sec anyway). =A0 - We added one subsection "changes to RFC6622" that describes= the differences to RFC6622


The authors believe that the two sec= urity documents are stable. Note in particular that
=A0=A0 (i) nhdp-ols= rv2-sec is the same mechanism that has been discussed in draft-ietf-manet-n= hdp-sec, just applied to both OLSRv2 and NHDP (and updating RFC6130). nhdp-= sec has been in the WG for a long time.
=A0=A0 (ii) RFC6622-bis has the same specification as RFC6622 with the exce= ption of one additional type extension for the ICV TLV that has the same TL= V value structure, but includes the IP source address of the IP datagram, w= hen calculating the ICV.
=A0 (iii) OLSRv2-19 has normative references to both security documents; it= will not be published as RFC as long as these two documents are not finish= ed.

Therefore, I hope that we can initiate a first WG LC on both sec= urity documents very soon.

Thanks
Ulrich


On Sat, Mar 23, = 2013 at 12:04 PM, Christopher Dearlove <christopher.dear= love@googlemail.com> wrote:
Thanks, Stan.

--
Christopher Dearlove
christopher.dearlove@gmai= l.com (iPhone)
chris@mnemosyne.demon.co.uk<= /a> (home)

On 23 Mar 2013, at 18:57, &qu= ot;Stan Ratliff (sratliff)" <= sratliff@cisco.com> wrote:

> WG Participants:
>
> The polling period has passed, *without* negative opinions on acceptin= g the documents as WG documents. Therefore, they have been submitted via th= e data-tracker, and you should get email on their posting.
>
> Regards,
> Stan
>
> On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote:
>
>> Ulrich,
>>
>> Thanks for this email. OK, Working Group participants: Consider th= is a 1-week poll for adoption of these docs as WG documents. Polling period= ends March 22. And, silence will be deemed to be agreement that the docume= nts *should be* accepted as WG docs.
>>
>> Regards,
>> Stan
>>
>> On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote:
>>
>>> Dear all,
>>>
>>> The OLSRv2 authors have had a discussion with Stephen Farrell = (Security AD)
>>> and Adrian about how to resolve the remaining security related= DISCUSS
>>> on OLSRv2, and we agreed on a way forward that involves the fo= llowing
>>> steps:
>>>
>>> 1) Publication of:
>>> http://tools.ietf.org/html/draft-herberg-= manet-nhdp-olsrv2-sec-01
>>>
>>> This document mandates (at least) implementation of HMAC/SHA2<= br> >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2= should
>>> use that mechanism unless they have a more appropriate solutio= n (e.g.,
>>> different cipher) for that particular deployment. This documen= t also
>>> updates NHDP and mandates to implement the same HMAC/SHA2 prot= ection
>>> for HELLO messages.
>>>
>>> 2) Publication of:
>>> http://tools.ietf.org/html/draft-herberg-mane= t-rfc6622-bis-01
>>>
>>> This document obsoletes RFC6622bis by fixing an oversight in R= FC6622.
>>> The differences are minor to RFC6622 and can be seen here:
>>> http://tools.ietf.o= rg/rfcdiff?url1=3Drfc6622&url2=3Ddraft-herberg-manet-rfc6622-bis >>> Essentially, RFC6622 does not protect the IP source address of= the
>>> interface over which the control message is sent. Since that a= ddress
>>> is used to establish neighbors in NHDP (and therefore must be<= br> >>> protected), a new type extension 3 of the ICV TLV has been add= ed to
>>> the registry.
>>>
>>> 3) Publication of an update to OLSRv2, referencing the use of = the
>>> defined security mechanism, and resolving other smaller issues= from
>>> Stephen's DISCUSS.
>>>
>>> In order to not hold up OLSRv2 further, and upon discussions w= ith Stan
>>> and Adrian, we would like to request WG adoption of these two = new
>>> documents - asking that the chairs will officially poll the WG= on this
>>> matter shortly. The documents are brief, and addresses issues<= br> >>> requested by the ADs, so we hope that processing them should a= lso be a
>>> brief affair.
>>>
>>> Best regards
>>> 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
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--20cf3078114c64adac04d8a0a43d-- From thomas@thomasclausen.org Sat Mar 23 17:40:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304C21F8B1E for ; Sat, 23 Mar 2013 17:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqPzVGOgQOcu for ; Sat, 23 Mar 2013 17:40:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9E821F8AD8 for ; Sat, 23 Mar 2013 17:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0F3721BD7F6A; Sat, 23 Mar 2013 17:40:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7F3B81BD7E9B; Sat, 23 Mar 2013 17:40:39 -0700 (PDT) References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Thomas Heide Clausen Date: Sun, 24 Mar 2013 01:40:38 +0100 To: "Stan Ratliff (sratliff)" Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:40:41 -0000 Given the extremely limited change from -01 to -02, may I suggest that it be= an 1 week WGLC (although, I do not see the need for a WGLC at all)? Sent from my iPad On 24 mars 2013, at 00:54, "Stan Ratliff (sratliff)" wr= ote: > Jiazi,=20 >=20 > You've added a new sub-section, so my opinion is yes, we *do* need another= WGLC for the document. There may not be a ton of text here, but adding a se= ction (or a sub-section) is a pretty significant change. Therefore, I think t= he WG should have an opportunity to express its consensus. Unless, of course= , I get over-ridden by my co-chair and/or the ADs=E2=80=A6 ;-) >=20 > Regards, > Stan >=20 > On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: >=20 >> Dear all,=20 >>=20 >> The authors of nhdp-sec-threats have submitted a new revision based on th= e comments during WGLC.=20 >>=20 >> The only technical change is that, a new sub-section is added on link qua= lity update: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 4.8. Attack on Link Quality Update >>=20 >> According to NHDP, "Link quality is a mechanism whereby a router MAY >> take considerations other than message exchange into account for >> determining when a link is and is not a candidate for being >> considered as HEARD or SYMMETRIC. As such, it is a link admission >> mechanism.". >>=20 >> Section 14.4 of NHDP [RFC6130] then lists several examples of which >> information can be used to update link quality. One of the listed >> examples is to update link quality based on [RFC5444] packet >> exchanges between neighbor routers, e.g., an NHDP Router may update >> the link quality of a neighbor based on receipt or loss of packets if >> they include a sequential packet sequence number. >>=20 >> NHDP does not specify how to acquire link quality updates >> normatively, however, attack vectors may be introduced if an >> implementation chooses to calculate link quality based on packet >> sequence numbers. The consequences of such threats would depend on >> specific implementations. For example, if the link quality update is >> based on sequential packet sequence number from neighbor routers, a >> Comprised NDHP Router can spoof packets appearing to be from another >> Legitimate NHDP Router that skips some packet sequence numbers. The >> NHDP Router receiving the spoofed packets may degrade the link >> quality as it appears that several packets have been dropped. >> Eventually, the router remove the neighbor when the link quality >> drops below HYST_REJECT. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Your comments are welcome.=20 >>=20 >> @chairs: >> I suppose that if this section gets approved, there is no need for anothe= r WGLC for the whole document? >>=20 >> best >>=20 >> Jiazi >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-threats-= 02.txt >>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>> To: jiazi@jiaziyi.com >>> Cc: t.clausen@computer.org, ulrich@herberg.name >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>> has been successfully submitted by Jiazi Yi and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-ietf-manet-nhdp-sec-threats >>> Revision: 02 >>> Title: Security Threats for NHDP >>> Creation date: 2013-03-20 >>> Group: manet >>> Number of pages: 17 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-nh= dp-sec-threats-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-s= ec-threats >>> Htmlized: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-th= reats-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhd= p-sec-threats-02 >>>=20 >>> Abstract: >>> This document analyses common security threats of the Neighborhood >>> Discovery Protocol (NHDP), and describes their potential impacts on >>> MANET routing protocols using NHDP. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> 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 hrogge@googlemail.com Sat Mar 23 21:33:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90C21F8BB7 for ; Sat, 23 Mar 2013 21:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hggR8kMtVsCv for ; Sat, 23 Mar 2013 21:33:58 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1321F8B97 for ; Sat, 23 Mar 2013 21:33:57 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so9544473lab.19 for ; Sat, 23 Mar 2013 21:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=dza/uv0BFHZTHddFPxIJ91LLeLWHthXp1QdQTPN9Of4=; b=McSvoZHwH8pXbLT6t1OSe+YV9qhJQmHhRzdYkMTd7zba1ahcXDDEzcNPJO0HZ+VKsJ I/uKoxZg89Gif32Wa0f8pPy20TAssCu/p7gA2qUBtjlz7tsatNVgh8aMcM45YVs6llcA jlOyfPfF5y+lzAFY5jU31qQOUfhRfD48nGVEC9aNr1euM5vXqucFkdbhxpUmQy+/+lWw 2ZHFTEIx2RgdtNsZHiD08stiaTNb0GnnjSr066NRUCMJKET0Vf/xS2mWvkIa7X8nw8QK 8u7vmNdelwmXpKy1fUUWbKjPpV4jLF308vHG/ntF7U/M4qzi5xuZVegQjIVCo4rps8bJ DICg== X-Received: by 10.112.18.168 with SMTP id x8mr3746942lbd.102.1364099636572; Sat, 23 Mar 2013 21:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Sat, 23 Mar 2013 21:33:36 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> From: Henning Rogge Date: Sun, 24 Mar 2013 05:33:36 +0100 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" , Christopher Dearlove , "" , Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 04:33:59 -0000 Just to state it, using timestamps and synchronized clocks in Mesh networks can be a real mess. We did it a couple of years ago when using SNMPv3 and it gave us all kinds of headaches. But maybe the ubiquitous presence of GPS (and with this a global clock) can help. Including a 32 byte checksum into each OLSRv2 message is something between overkill and insanity. I hope people keep in mind that you can get a similar protection by using linklayer based security on the mesh interface (WPA2 for example). Henning Rogge On Sun, Mar 24, 2013 at 1:19 AM, Ulrich Herberg wrote: > Dear all, > > as you have seen, we have submitted the two documents as WG documents (with > the same contents as the individual counterparts), and we have updated them > to a -01 revision. > > Brief summary of changes (besides editorial changes) from -00 to -01: > 1) nhdp-olsrv2-sec: > - Stephen Farrell has caught one oversight in the OLSRv-18, which is that > we talk about "one single shared secret key" that is used in the default use > case of integrity and replay protection. As he pointed out, there could be a > small number of N shared keys that are all pre-deployed. Using RFC6622-bis, > it is straight-forward to select the index of the key that is used within > the MANET. > This led to a minimal update of both OLSRv2 and nhdp-olsrv2-sec > > 2) RFC6622-bis: > - Stephen suggested to normatively cite this document from OLSRv2 (it is > already transitively cited via nhdp-olsrv2-sec anyway). > - We added one subsection "changes to RFC6622" that describes the > differences to RFC6622 > > > The authors believe that the two security documents are stable. Note in > particular that > (i) nhdp-olsrv2-sec is the same mechanism that has been discussed in > draft-ietf-manet-nhdp-sec, just applied to both OLSRv2 and NHDP (and > updating RFC6130). nhdp-sec has been in the WG for a long time. > (ii) RFC6622-bis has the same specification as RFC6622 with the exception > of one additional type extension for the ICV TLV that has the same TLV value > structure, but includes the IP source address of the IP datagram, when > calculating the ICV. > (iii) OLSRv2-19 has normative references to both security documents; it > will not be published as RFC as long as these two documents are not > finished. > > Therefore, I hope that we can initiate a first WG LC on both security > documents very soon. > > Thanks > Ulrich > > > > On Sat, Mar 23, 2013 at 12:04 PM, Christopher Dearlove > wrote: >> >> Thanks, Stan. >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >> On 23 Mar 2013, at 18:57, "Stan Ratliff (sratliff)" >> wrote: >> >> > WG Participants: >> > >> > The polling period has passed, *without* negative opinions on accepting >> > the documents as WG documents. Therefore, they have been submitted via the >> > data-tracker, and you should get email on their posting. >> > >> > Regards, >> > Stan >> > >> > On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote: >> > >> >> Ulrich, >> >> >> >> Thanks for this email. OK, Working Group participants: Consider this a >> >> 1-week poll for adoption of these docs as WG documents. Polling period ends >> >> March 22. And, silence will be deemed to be agreement that the documents >> >> *should be* accepted as WG docs. >> >> >> >> Regards, >> >> Stan >> >> >> >> On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: >> >> >> >>> Dear all, >> >>> >> >>> The OLSRv2 authors have had a discussion with Stephen Farrell >> >>> (Security AD) >> >>> and Adrian about how to resolve the remaining security related DISCUSS >> >>> on OLSRv2, and we agreed on a way forward that involves the following >> >>> steps: >> >>> >> >>> 1) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >> >>> >> >>> This document mandates (at least) implementation of HMAC/SHA2 >> >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >> >>> use that mechanism unless they have a more appropriate solution (e.g., >> >>> different cipher) for that particular deployment. This document also >> >>> updates NHDP and mandates to implement the same HMAC/SHA2 protection >> >>> for HELLO messages. >> >>> >> >>> 2) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >> >>> >> >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >> >>> The differences are minor to RFC6622 and can be seen here: >> >>> >> >>> http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis >> >>> Essentially, RFC6622 does not protect the IP source address of the >> >>> interface over which the control message is sent. Since that address >> >>> is used to establish neighbors in NHDP (and therefore must be >> >>> protected), a new type extension 3 of the ICV TLV has been added to >> >>> the registry. >> >>> >> >>> 3) Publication of an update to OLSRv2, referencing the use of the >> >>> defined security mechanism, and resolving other smaller issues from >> >>> Stephen's DISCUSS. >> >>> >> >>> In order to not hold up OLSRv2 further, and upon discussions with Stan >> >>> and Adrian, we would like to request WG adoption of these two new >> >>> documents - asking that the chairs will officially poll the WG on this >> >>> matter shortly. The documents are brief, and addresses issues >> >>> requested by the ADs, so we hope that processing them should also be a >> >>> brief affair. >> >>> >> >>> Best regards >> >>> 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 >> > >> > _______________________________________________ >> > 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 > -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From internet-drafts@ietf.org Sat Mar 23 21:45:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E9821F8C55; Sat, 23 Mar 2013 21:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.059 X-Spam-Level: X-Spam-Status: No, score=-98.059 tagged_above=-999 required=5 tests=[AWL=-4.321, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR4da9DfuOaQ; Sat, 23 Mar 2013 21:45:03 -0700 (PDT) Received: from jlonline.com (pip15.ptt.js.cn [61.155.13.245]) by ietfa.amsl.com (Postfix) with SMTP id 1F84F21F841C; Sat, 23 Mar 2013 21:44:59 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm2514eb856; Sun, 24 Mar 2013 12:35:22 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm7e5149c535; Wed, 20 Mar 2013 18:50:20 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Wed, 20 Mar 2013 18:50:19 +0800 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03421F8480; Wed, 20 Mar 2013 03:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1363776236; bh=G5Ck4v2qs3Wdj389VeMe1nKypBuAb9abiMEFPWtAtWA=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=yOtbuxqO2rVWVdLqHT3R84iCSG4w7eQUcN4EutDLRB37g5Bu9bDL05DQdP8N2o0hc DYk2Kyd1YOvtWYAeztTEeqrELhQA1tSpDtkvR8qmFULU37p1WcAT7PsvqMLsr7W8OS +LAmYHOP/fhIkM4WUWAFS1JVhyBuRsP1xDuqiMOQ= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CA221F851C; Wed, 20 Mar 2013 03:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Ux-ggl0s88; Wed, 20 Mar 2013 03:43:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749121F8454; Wed, 20 Mar 2013 03:43:52 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130320104352.27601.32752.idtracker@ietfa.amsl.com> Date: Wed, 20 Mar 2013 03:43:52 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: 2MGbQS4B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 04:45:05 -0000 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 : Security Threats for NHDP Author(s) : Ulrich Herberg Jiazi Yi Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-threats-02.txt Pages : 17 Date : 2013-03-20 Abstract: This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hrogge@googlemail.com Sun Mar 24 02:06:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD13B21F8962 for ; Sun, 24 Mar 2013 02:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqBfiXG5yV3e for ; Sun, 24 Mar 2013 02:06:01 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD821F8930 for ; Sun, 24 Mar 2013 02:06:00 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fr10so9466829lab.26 for ; Sun, 24 Mar 2013 02:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=l4dTX9kzM0m9WPLJ46sy0+lscsm/C5noUtXEGtf+npk=; b=XE45PLaYtSEnMgE10lwU/YATeHQlxbn89nYAo2EaZ8ndR/zek5k4YW19LFNGJ1V1tS pY3/k03i0PzGemfbFiNiNEYf9cZEgKL+zSVeC+yHzjK7Z48k7cBorpNcUJfaIXApQgdw sp3nEP5RyfRjXNLu/kOTC0mivNn06rnIJYdberpKRfXC/hk03Wh24dLdUrpxJ8JFWjnP vTTItYXZwabsr9F8xdIbgDKUMR+V3qW9lDDx3ZZLEnbm2Y4rFKcYvzFHVrwLnZUs/vKR mq35Sm1b+CcVETy6ILdMSuicOjlhoUBk2h0+fNl4bi7WsuCS8Y58qB6Z0YgbkEujXMa3 UA9g== X-Received: by 10.112.46.231 with SMTP id y7mr3967548lbm.128.1364115959555; Sun, 24 Mar 2013 02:05:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Sun, 24 Mar 2013 02:05:39 -0700 (PDT) In-Reply-To: <49A8E6AA-0A1B-4F0E-9240-82F736CA3270@mnemosyne.demon.co.uk> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> <49A8E6AA-0A1B-4F0E-9240-82F736CA3270@mnemosyne.demon.co.uk> From: Henning Rogge Date: Sun, 24 Mar 2013 10:05:39 +0100 Message-ID: To: Christopher Dearlove Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Christopher Dearlove , "" , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:06:01 -0000 On Sun, Mar 24, 2013 at 9:42 AM, Christopher Dearlove wrote: > We are of course not designing only to run over IEEE 802.11. WPA2 was just an example. I think there are quite a few IP capable radio technologies with their own linklayer encryption, both commercial and military. > But if you have appropriate link-layer security then you can use it inste= ad, and still be fully compliant, because all the words about usage say you= can do something else. You can even do nothing, but this is not recommende= d. However it became a security requirement to include something for when y= ou do need it. (Our later security discussions were not "do you need authen= tication?", but "do you need automatic key management?" - hence the detaile= d argument why we don't.) Maybe we should suggest opening "autoconf" again and increasing the scope to manet key management? ;) (No, this is not meant serious) > Otherwise we'd still be blocked in the IESG. I know... > I'm also aware of potential cases where the question is not "is this too = much?" but rather "is this enough?". So then the opposite of overkill, and = definitely not insanity. And I think you need not to think of it as a check= sum. This is not protection against accidental corruption (for which it wou= ld be overkill, I agree), this is protection against deliberate attack. And= to get 128 bits of protection (close to the minimum for any serious use) y= ou need something this size (256 bits). I disagree with you on this point, but its not worth delaying the RFC longer over this. the "can implement something else that works better" rescues the document in my opinion. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hrogge@googlemail.com Sun Mar 24 02:10:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFAC21F898B for ; Sun, 24 Mar 2013 02:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWwzjl-NQzPU for ; Sun, 24 Mar 2013 02:10:38 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4821F8970 for ; Sun, 24 Mar 2013 02:10:37 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so9674059lab.3 for ; Sun, 24 Mar 2013 02:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=QiYDxh3zTg2eY4dp2+qQHyLJxDch0jgS3Woawgc0NHw=; b=o4ZGtSKCrqe3BU7v7r3AFyuX8EOLC0cny3Q0l7zqLDrxtHrNBfULqexQLRqUDsyOe1 ZuvcpTBBuabPu10oj3W/ZPpzp7NsOjLEQHyCvN+IMTjMPHfQWCwpLW9GNUAxGEyo9MY2 CkO02c1G+AkhoW12N8CaxNGrQhsgXndtiy0tNrVup8Nqllhw3EPIQdAG0xQXaz/T9fqV XPDb3zh0ppTdtYn9ANtEeB4buZa3wdDSbGQnN+Gm3ODSbi2MKE92oCpxfxrReYZ0TbBs jxfNwBYMXQcQSfapBYzDJSCbzShLgdmsamLOIknkfgnkIsu0GdP0ul49qy8Ls5oukD6V 3MPw== X-Received: by 10.112.46.231 with SMTP id y7mr3972804lbm.128.1364116236392; Sun, 24 Mar 2013 02:10:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Sun, 24 Mar 2013 02:10:16 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Sun, 24 Mar 2013 10:10:16 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:10:39 -0000 Hi, I think the new document is good. Henning Rogge On Sun, Mar 24, 2013 at 12:54 AM, Stan Ratliff (sratliff) wrote: > Jiazi, > > You've added a new sub-section, so my opinion is yes, we *do* need anothe= r WGLC for the document. There may not be a ton of text here, but adding a = section (or a sub-section) is a pretty significant change. Therefore, I thi= nk the WG should have an opportunity to express its consensus. Unless, of c= ourse, I get over-ridden by my co-chair and/or the ADs=85 ;-) > > Regards, > Stan > > On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: > >> Dear all, >> >> The authors of nhdp-sec-threats have submitted a new revision based on t= he comments during WGLC. >> >> The only technical change is that, a new sub-section is added on link qu= ality update: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 4.8. Attack on Link Quality Update >> >> According to NHDP, "Link quality is a mechanism whereby a router MAY >> take considerations other than message exchange into account for >> determining when a link is and is not a candidate for being >> considered as HEARD or SYMMETRIC. As such, it is a link admission >> mechanism.". >> >> Section 14.4 of NHDP [RFC6130] then lists several examples of which >> information can be used to update link quality. One of the listed >> examples is to update link quality based on [RFC5444] packet >> exchanges between neighbor routers, e.g., an NHDP Router may update >> the link quality of a neighbor based on receipt or loss of packets if >> they include a sequential packet sequence number. >> >> NHDP does not specify how to acquire link quality updates >> normatively, however, attack vectors may be introduced if an >> implementation chooses to calculate link quality based on packet >> sequence numbers. The consequences of such threats would depend on >> specific implementations. For example, if the link quality update is >> based on sequential packet sequence number from neighbor routers, a >> Comprised NDHP Router can spoof packets appearing to be from another >> Legitimate NHDP Router that skips some packet sequence numbers. The >> NHDP Router receiving the spoofed packets may degrade the link >> quality as it appears that several packets have been dropped. >> Eventually, the router remove the neighbor when the link quality >> drops below HYST_REJECT. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Your comments are welcome. >> >> @chairs: >> I suppose that if this section gets approved, there is no need for anoth= er WGLC for the whole document? >> >> best >> >> Jiazi >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-threats= -02.txt >>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>> To: jiazi@jiaziyi.com >>> Cc: t.clausen@computer.org, ulrich@herberg.name >>> >>> >>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>> has been successfully submitted by Jiazi Yi and posted to the >>> IETF repository. >>> >>> Filename: draft-ietf-manet-nhdp-sec-threats >>> Revision: 02 >>> Title: Security Threats for NHDP >>> Creation date: 2013-03-20 >>> Group: manet >>> Number of pages: 17 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-n= hdp-sec-threats-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-= sec-threats >>> Htmlized: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-t= hreats-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nh= dp-sec-threats-02 >>> >>> Abstract: >>> This document analyses common security threats of the Neighborhood >>> Discovery Protocol (NHDP), and describes their potential impacts on >>> MANET routing protocols using NHDP. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> 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 --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Sun Mar 24 04:48:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FE621F87D2 for ; Sun, 24 Mar 2013 04:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bTwnLQHKOIq for ; Sun, 24 Mar 2013 04:48:07 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id BB85A21F84F8 for ; Sun, 24 Mar 2013 04:48:07 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so3698357pbc.40 for ; Sun, 24 Mar 2013 04:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BGyPutsPsk46kq/5d1bX38DaJJvAGYdZtNxBAVkWxSo=; b=ceFTEHoJlASAppDvLSJLz1K16WHH1+Fn0CQFAgKJWwcckQZhlqc1bHJd+THi43o58Q 90bQmoMFsUHzD2rsfZlOW32JUvjtqdcjYTkjS11RLR6sDTzw6KqcqlWfnBQ/KXtlFQ+B LQo/i6M8uJbrAGU4KjIy52HH8zZF2qRz8S5PMdoK0T8u2FcQ6M1JB/QFEEMF+ktsmIKj A611Dg/ocHVB6zQ4y9CGrMdLeCWDDZ/UtzxwE6ej5xW5z4BxKdGy3+okZTF9ITl4ipyT QyT7O5NVKk1AzhXaz2dbYDIZA7nPUXOdkIQCKIp7Q/wRFU/t7fZpjDS1pnjCut1x4hNe 1GMQ== MIME-Version: 1.0 X-Received: by 10.68.247.163 with SMTP id yf3mr11955380pbc.113.1364125686347; Sun, 24 Mar 2013 04:48:06 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sun, 24 Mar 2013 04:48:06 -0700 (PDT) In-Reply-To: <1227E12F-9593-4A8C-A54D-B210A61060D2@jiaziyi.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <1227E12F-9593-4A8C-A54D-B210A61060D2@jiaziyi.com> Date: Sun, 24 Mar 2013 12:48:06 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 11:48:09 -0000 I disagree with the editors ack-decision, and also will request Request/suggest +++++++++++++ A two week WGLC not one week, the reason below, Reason ++++++ There are some new drafts/updates related to; RFC6130, security-doc, and OLSRv2, which need review related to this draft. AB On 3/23/13, Jiazi Yi wrote: > Dear AB, > > On this particular issue (threats of packet sequence number), as far as I > can remember, the change was not based on (or influenced by) your input. In > the meantime, the input from Chris, Henning, Teco, etc., does have impact on > the document. > > It is true that you mentioned several times that message sequence number > threat should be kept in nhdp-sec-threat. However, you didn't provide valid > technical argument why it should be kept. Actually, there is no doubt that > the original section of sequence number in -00 revision was wrong. > > My understanding of "IETF input" must be based on technical argument. > Simply saying "I want *foo*, not *bar*" - without explaining why - doesn't > say much thing. Even *foo* was adopted in the end. > In the contrast, even some one is against *foo*, but he provided valid > arguments during the discussion that help improving the design, he should be > regarded as contributor. > > Last but not least, we acknowledged all the MANET participants - if you > regard yourself as one of the participants, then you are acknowledged. > > btw, I remembered that you brought a discussion on RFC Acknowledgement > http://www.ietf.org/mail-archive/web/ietf/current/msg77065.html before. I > didn't follow that thread, but I think other participants have already > explained fairly well how it works. > My personal suggestion is that, if you put move attention to the previous > sections of the document(s), rather than acknowledgment section, you would > be naturally listed there - that's how IETF works. > > sincerely > > Jiazi > > On Mar 23, 2013, at 9:17 PM, Abdussalam Baryun > wrote: > >> Hi Jiazi (draft editor) >> >> Please note that I had effort to make below change in this draft, but >> my name is not in acknowledgement as others were. Please add my name. >> I don't think the changes was not influenced by my inputs and >> discussions. I don't think that the changes was to happen if I ignored >> the draft ( i.e. it was in WGLC and not much discussions). I don't >> think I should be discouraged, >> >> Best regards >> Abdussalam Baryun, >> +++++++++++++++++ >> If the IETF culture is to encourage participants then editors SHOULD >> add efforts owners in acknowledgements, otherwise participants MAY be >> discouraged (depends on individual culture). >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> The below message in MANET WG list >> >> On 3/20/13, Jiazi Yi wrote: >>> Dear all, >>> >>> The authors of nhdp-sec-threats have submitted a new revision based on >>> the >>> comments during WGLC. >>> >>> The only technical change is that, a new sub-section is added on link >>> quality update: >>> >>> ========== >>> 4.8. Attack on Link Quality Update >>> >>> According to NHDP, "Link quality is a mechanism whereby a router MAY >>> take considerations other than message exchange into account for >>> determining when a link is and is not a candidate for being >>> considered as HEARD or SYMMETRIC. As such, it is a link admission >>> mechanism.". >>> >>> Section 14.4 of NHDP [RFC6130] then lists several examples of which >>> information can be used to update link quality. One of the listed >>> examples is to update link quality based on [RFC5444] packet >>> exchanges between neighbor routers, e.g., an NHDP Router may update >>> the link quality of a neighbor based on receipt or loss of packets if >>> they include a sequential packet sequence number. >>> >>> NHDP does not specify how to acquire link quality updates >>> normatively, however, attack vectors may be introduced if an >>> implementation chooses to calculate link quality based on packet >>> sequence numbers. The consequences of such threats would depend on >>> specific implementations. For example, if the link quality update is >>> based on sequential packet sequence number from neighbor routers, a >>> Comprised NDHP Router can spoof packets appearing to be from another >>> Legitimate NHDP Router that skips some packet sequence numbers. The >>> NHDP Router receiving the spoofed packets may degrade the link >>> quality as it appears that several packets have been dropped. >>> Eventually, the router remove the neighbor when the link quality >>> drops below HYST_REJECT. >>> ========== >>> >>> Your comments are welcome. >>> >>> @chairs: >>> I suppose that if this section gets approved, there is no need for >>> another >>> WGLC for the whole document? >>> >>> best >>> >>> Jiazi >>> >>> Begin forwarded message: >>> >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for >>>> draft-ietf-manet-nhdp-sec-threats-02.txt >>>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>>> To: jiazi@jiaziyi.com >>>> Cc: t.clausen@computer.org, ulrich@herberg.name >>>> >>>> >>>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>>> has been successfully submitted by Jiazi Yi and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-ietf-manet-nhdp-sec-threats >>>> Revision: 02 >>>> Title: Security Threats for NHDP >>>> Creation date: 2013-03-20 >>>> Group: manet >>>> Number of pages: 17 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-02 >>>> >>>> Abstract: >>>> This document analyses common security threats of the Neighborhood >>>> Discovery Protocol (NHDP), and describes their potential impacts on >>>> MANET routing protocols using NHDP. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> > > From abdussalambaryun@gmail.com Sun Mar 24 04:54:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26E21F88ED for ; Sun, 24 Mar 2013 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBYoNXPfZpAu for ; Sun, 24 Mar 2013 04:54:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C842821F88CF for ; Sun, 24 Mar 2013 04:54:34 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz17so255388pbc.17 for ; Sun, 24 Mar 2013 04:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4r7skQhouW6jC0E3RbQZnTcYqBwtgWORxYEjdsNPze0=; b=QeUdgIxMGJiZsUCSnowx3JDyG9tGte9Gr3OLtdFsUmRxfEd82wPG4vRGO8HxeyN/hQ Pxo2Gu8OjSzhsOuaMfdV6biTn1xzvZPrNKkXaoErCHedkE5Bc67eDau8WKpFxWJki5ZT YxMCLOrt6KCmXFqkjjqlVL2MaBvbwJYbd94K4WtYACZx1gtDR2jflLvo9RAVhRGZeNgq 7awtEQe3zEFCFfVKMi4S5wok2dLjFwYskL8kmibj8eIaCzIINclblaS2x9ozysb4Fiuw 2mv1BW/0HTVDJ0OxUiMi0N8mIqHLz1Ql6Zb+x8YE1mOf/gRPvrGGubMr0qNMQmr2U35q ryQA== MIME-Version: 1.0 X-Received: by 10.68.245.202 with SMTP id xq10mr11951020pbc.163.1364126074510; Sun, 24 Mar 2013 04:54:34 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sun, 24 Mar 2013 04:54:34 -0700 (PDT) In-Reply-To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10053162@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10066D80@xmb-aln-x03.cisco.com> <75F201E8-8BD0-4BF7-95D9-A8A7D4352F6B@gmail.com> Date: Sun, 24 Mar 2013 12:54:34 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" , Christopher Dearlove , "" , Thomas Clausen Subject: Re: [manet] Security documents for OLSRv2/NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 11:54:35 -0000 > Therefore, I hope that we can initiate a first WG LC on both security > documents very soon. Please give me chance to review and comment, I will need one month at least but two preferable, for the new documents, AB On 3/24/13, Ulrich Herberg wrote: > Dear all, > > as you have seen, we have submitted the two documents as WG documents (with > the same contents as the individual counterparts), and we have updated them > to a -01 revision. > > Brief summary of changes (besides editorial changes) from -00 to -01: > 1) nhdp-olsrv2-sec: > - Stephen Farrell has caught one oversight in the OLSRv-18, which is > that we talk about "one single shared secret key" that is used in the > default use case of integrity and replay protection. As he pointed out, > there could be a small number of N shared keys that are all pre-deployed. > Using RFC6622-bis, it is straight-forward to select the index of the key > that is used within the MANET. > This led to a minimal update of both OLSRv2 and nhdp-olsrv2-sec > > 2) RFC6622-bis: > - Stephen suggested to normatively cite this document from OLSRv2 (it is > already transitively cited via nhdp-olsrv2-sec anyway). > - We added one subsection "changes to RFC6622" that describes the > differences to RFC6622 > > > The authors believe that the two security documents are stable. Note in > particular that > (i) nhdp-olsrv2-sec is the same mechanism that has been discussed in > draft-ietf-manet-nhdp-sec, just applied to both OLSRv2 and NHDP (and > updating RFC6130). nhdp-sec has been in the WG for a long time. > (ii) RFC6622-bis has the same specification as RFC6622 with the > exception of one additional type extension for the ICV TLV that has the > same TLV value structure, but includes the IP source address of the IP > datagram, when calculating the ICV. > (iii) OLSRv2-19 has normative references to both security documents; it > will not be published as RFC as long as these two documents are not > finished. > > Therefore, I hope that we can initiate a first WG LC on both security > documents very soon. > > Thanks > Ulrich > > > On Sat, Mar 23, 2013 at 12:04 PM, Christopher Dearlove < > christopher.dearlove@googlemail.com> wrote: > >> Thanks, Stan. >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >> On 23 Mar 2013, at 18:57, "Stan Ratliff (sratliff)" >> wrote: >> >> > WG Participants: >> > >> > The polling period has passed, *without* negative opinions on accepting >> the documents as WG documents. Therefore, they have been submitted via >> the >> data-tracker, and you should get email on their posting. >> > >> > Regards, >> > Stan >> > >> > On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote: >> > >> >> Ulrich, >> >> >> >> Thanks for this email. OK, Working Group participants: Consider this a >> 1-week poll for adoption of these docs as WG documents. Polling period >> ends >> March 22. And, silence will be deemed to be agreement that the documents >> *should be* accepted as WG docs. >> >> >> >> Regards, >> >> Stan >> >> >> >> On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote: >> >> >> >>> Dear all, >> >>> >> >>> The OLSRv2 authors have had a discussion with Stephen Farrell >> (Security AD) >> >>> and Adrian about how to resolve the remaining security related >> >>> DISCUSS >> >>> on OLSRv2, and we agreed on a way forward that involves the following >> >>> steps: >> >>> >> >>> 1) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01 >> >>> >> >>> This document mandates (at least) implementation of HMAC/SHA2 >> >>> integrity protection of OLSRv2 messages. Deployments of OLSRv2 should >> >>> use that mechanism unless they have a more appropriate solution >> >>> (e.g., >> >>> different cipher) for that particular deployment. This document also >> >>> updates NHDP and mandates to implement the same HMAC/SHA2 protection >> >>> for HELLO messages. >> >>> >> >>> 2) Publication of: >> >>> http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01 >> >>> >> >>> This document obsoletes RFC6622bis by fixing an oversight in RFC6622. >> >>> The differences are minor to RFC6622 and can be seen here: >> >>> >> http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis >> >>> Essentially, RFC6622 does not protect the IP source address of the >> >>> interface over which the control message is sent. Since that address >> >>> is used to establish neighbors in NHDP (and therefore must be >> >>> protected), a new type extension 3 of the ICV TLV has been added to >> >>> the registry. >> >>> >> >>> 3) Publication of an update to OLSRv2, referencing the use of the >> >>> defined security mechanism, and resolving other smaller issues from >> >>> Stephen's DISCUSS. >> >>> >> >>> In order to not hold up OLSRv2 further, and upon discussions with >> >>> Stan >> >>> and Adrian, we would like to request WG adoption of these two new >> >>> documents - asking that the chairs will officially poll the WG on >> >>> this >> >>> matter shortly. The documents are brief, and addresses issues >> >>> requested by the ADs, so we hope that processing them should also be >> >>> a >> >>> brief affair. >> >>> >> >>> Best regards >> >>> 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 >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > From abdussalambaryun@gmail.com Sun Mar 24 04:58:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB81521F8A3E for ; Sun, 24 Mar 2013 04:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qrpx3lFm9Dr for ; Sun, 24 Mar 2013 04:58:06 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5821F8A14 for ; Sun, 24 Mar 2013 04:58:06 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id up1so3702397pbc.9 for ; Sun, 24 Mar 2013 04:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=bIVNe58RFgexy6cjsUfUPlhahMQMiwI5V9aNN72D6PE=; b=iGj0Om50vsfXQtL71MyfzBViN/6ju0o/aLfp+o/NiLg3NU23T0EObthXSkEiMDcsle 2/OgHQR5riMWfvzavbPcPY99t+CkiDZ/YqX+Qug1/7hAx0KbQIWLiGBz18leTLptuo5D wbEsQ0E9uuSfH/4f+eJE0zunxOeotzLGXq5WQOubu7PhmpDot+x0NEoI1auMlSgM4kub Err2Ex6XM+sC9j2TfomF1RKJvNrKlMHEFqatH9a0IM9p0fv/zxsnoVNC0QD+jdJ1RsCQ 1r7GOVpaiBrMPPn1+NgZlOG2jUGIZIljXp6AIV+gSZFYdpM2vCpqUvasswfbciEbw4Gv 7IDg== MIME-Version: 1.0 X-Received: by 10.68.87.98 with SMTP id w2mr4701437pbz.190.1364126286492; Sun, 24 Mar 2013 04:58:06 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sun, 24 Mar 2013 04:58:06 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> Date: Sun, 24 Mar 2013 12:58:06 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 11:58:07 -0000 Hi Stan, I agree and will add that this significant change can be related to the other new sec-documents, which they need review as well before submitting this draft. AB On 3/24/13, Stan Ratliff (sratliff) wrote: > Jiazi, > > You've added a new sub-section, so my opinion is yes, we *do* need anothe= r > WGLC for the document. There may not be a ton of text here, but adding a > section (or a sub-section) is a pretty significant change. Therefore, I > think the WG should have an opportunity to express its consensus. Unless,= of > course, I get over-ridden by my co-chair and/or the ADs=85 ;-) > > Regards, > Stan > > On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: > >> Dear all, >> >> The authors of nhdp-sec-threats have submitted a new revision based on t= he >> comments during WGLC. >> >> The only technical change is that, a new sub-section is added on link >> quality update: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 4.8. Attack on Link Quality Update >> >> According to NHDP, "Link quality is a mechanism whereby a router MAY >> take considerations other than message exchange into account for >> determining when a link is and is not a candidate for being >> considered as HEARD or SYMMETRIC. As such, it is a link admission >> mechanism.". >> >> Section 14.4 of NHDP [RFC6130] then lists several examples of which >> information can be used to update link quality. One of the listed >> examples is to update link quality based on [RFC5444] packet >> exchanges between neighbor routers, e.g., an NHDP Router may update >> the link quality of a neighbor based on receipt or loss of packets if >> they include a sequential packet sequence number. >> >> NHDP does not specify how to acquire link quality updates >> normatively, however, attack vectors may be introduced if an >> implementation chooses to calculate link quality based on packet >> sequence numbers. The consequences of such threats would depend on >> specific implementations. For example, if the link quality update is >> based on sequential packet sequence number from neighbor routers, a >> Comprised NDHP Router can spoof packets appearing to be from another >> Legitimate NHDP Router that skips some packet sequence numbers. The >> NHDP Router receiving the spoofed packets may degrade the link >> quality as it appears that several packets have been dropped. >> Eventually, the router remove the neighbor when the link quality >> drops below HYST_REJECT. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Your comments are welcome. >> >> @chairs: >> I suppose that if this section gets approved, there is no need for anoth= er >> WGLC for the whole document? >> >> best >> >> Jiazi >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-ietf-manet-nhdp-sec-threats-02.txt >>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>> To: jiazi@jiaziyi.com >>> Cc: t.clausen@computer.org, ulrich@herberg.name >>> >>> >>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>> has been successfully submitted by Jiazi Yi and posted to the >>> IETF repository. >>> >>> Filename: draft-ietf-manet-nhdp-sec-threats >>> Revision: 02 >>> Title: Security Threats for NHDP >>> Creation date: 2013-03-20 >>> Group: manet >>> Number of pages: 17 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-0= 2.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >>> Htmlized: >>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02 >>> >>> Abstract: >>> This document analyses common security threats of the Neighborhood >>> Discovery Protocol (NHDP), and describes their potential impacts on >>> MANET routing protocols using NHDP. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> 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 drdanhe@gmail.com Sun Mar 24 05:37:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3992E21F8CF0 for ; Sun, 24 Mar 2013 05:37:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPUaIICecjWV for ; Sun, 24 Mar 2013 05:37:20 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2309D21F8CD6 for ; Sun, 24 Mar 2013 05:37:19 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so4841433iae.11 for ; Sun, 24 Mar 2013 05:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=176tpvn2toNepkv4ptBqrvvP7mnz5GWu6sAgGzNQ26A=; b=MB9tyvVfcgl4n9o/vMAgR83KpcMwmEqmRmiKi19zxMFXqnjRKHBSjJLqgv0SKB16/9 RfWbmXcOfiAEzuA9oHl80ZF5uNybWTmvvPNZH9tm1hYm0dfe8Lrk1eGCf/2U9VG+rXnd ujYWe9ia39QRl1Reol+jBTPHMKRVA3smZHhqfZtyh8bclfIHQoxSf+6MjMiMjq9a9Stf 43MreRl0XJsxFlelBPkfWNKCh5Lspys0H0oWeO4MQPLoutKbOS7nUpOaXJDoTJVpJNU6 BhNxZCrWtp6KIPtzFmbg92jPg8DTRNxP8xMz8zxgYLPdnIsojRaxUD5XKVW1UyVhiG5v 95Hw== MIME-Version: 1.0 X-Received: by 10.42.215.196 with SMTP id hf4mr4603252icb.23.1364128639351; Sun, 24 Mar 2013 05:37:19 -0700 (PDT) Received: by 10.50.56.5 with HTTP; Sun, 24 Mar 2013 05:37:19 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> Date: Sun, 24 Mar 2013 12:37:19 +0000 Message-ID: From: Daniel He To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf301d3dc6fa096004d8aaf2e3 Cc: manet List Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 12:37:21 -0000 --20cf301d3dc6fa096004d8aaf2e3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stan and others, I reviewed the text added. It is not a significant change even if you think "Attack on Link Quality Update" SHOULD be counted in. the whole perspective of the draft is good. however, "NHDP does not specify how to acquire link quality updates > normatively", it looks like that HNDP assumed the link quality update is secure and underlying mechanism took care of this. I don't know this section is a must. it is only [optional]! Even if this section is removed, the draft doesn't change a thing. Cheers, Dan On 23 March 2013 23:54, Stan Ratliff (sratliff) wrote: > Jiazi, > > You've added a new sub-section, so my opinion is yes, we *do* need anothe= r > WGLC for the document. There may not be a ton of text here, but adding a > section (or a sub-section) is a pretty significant change. Therefore, I > think the WG should have an opportunity to express its consensus. Unless, > of course, I get over-ridden by my co-chair and/or the ADs=85 ;-) > > Regards, > Stan > > On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: > > > Dear all, > > > > The authors of nhdp-sec-threats have submitted a new revision based on > the comments during WGLC. > > > > The only technical change is that, a new sub-section is added on link > quality update: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 4.8. Attack on Link Quality Update > > > > According to NHDP, "Link quality is a mechanism whereby a router MAY > > take considerations other than message exchange into account for > > determining when a link is and is not a candidate for being > > considered as HEARD or SYMMETRIC. As such, it is a link admission > > mechanism.". > > > > Section 14.4 of NHDP [RFC6130] then lists several examples of which > > information can be used to update link quality. One of the listed > > examples is to update link quality based on [RFC5444] packet > > exchanges between neighbor routers, e.g., an NHDP Router may update > > the link quality of a neighbor based on receipt or loss of packets if > > they include a sequential packet sequence number. > > > > NHDP does not specify how to acquire link quality updates > > normatively, however, attack vectors may be introduced if an > > implementation chooses to calculate link quality based on packet > > sequence numbers. The consequences of such threats would depend on > > specific implementations. For example, if the link quality update is > > based on sequential packet sequence number from neighbor routers, a > > Comprised NDHP Router can spoof packets appearing to be from another > > Legitimate NHDP Router that skips some packet sequence numbers. The > > NHDP Router receiving the spoofed packets may degrade the link > > quality as it appears that several packets have been dropped. > > Eventually, the router remove the neighbor when the link quality > > drops below HYST_REJECT. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Your comments are welcome. > > > > @chairs: > > I suppose that if this section gets approved, there is no need for > another WGLC for the whole document? > > > > best > > > > Jiazi > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > draft-ietf-manet-nhdp-sec-threats-02.txt > >> Date: March 20, 2013 11:43:53 AM GMT+01:00 > >> To: jiazi@jiaziyi.com > >> Cc: t.clausen@computer.org, ulrich@herberg.name > >> > >> > >> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt > >> has been successfully submitted by Jiazi Yi and posted to the > >> IETF repository. > >> > >> Filename: draft-ietf-manet-nhdp-sec-threats > >> Revision: 02 > >> Title: Security Threats for NHDP > >> Creation date: 2013-03-20 > >> Group: manet > >> Number of pages: 17 > >> URL: > http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.= txt > >> Status: > http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats > >> Htmlized: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 > >> Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02 > >> > >> Abstract: > >> This document analyses common security threats of the Neighborhood > >> Discovery Protocol (NHDP), and describes their potential impacts on > >> MANET routing protocols using NHDP. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > 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 > --20cf301d3dc6fa096004d8aaf2e3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stan and others,

I reviewed=A0 the text added. It is not=A0 a sig= nificant change
even if you think "Attack on Link Quality Update&qu= ot; SHOULD be counted in.
the whole perspective of the draft is good.
however,=A0 "NHDP does not specify how to acquire link quality upd= ates
> =A0normatively", it looks like that HNDP assumed the link quality= update
is secure and underlying mechanism took care of this. I don'= t know this
section is a must. it is only [optional]! Even if this secti= on is removed,
the draft doesn't change a thing.

Cheers,
Dan

On 23 March 2013 23:54, Stan Ratliff (sratliff) <sratl= iff@cisco.com> wrote:
Jiazi,

You've added a new sub-section, so my opinion is yes, we *do* need anot= her WGLC for the document. There may not be a ton of text here, but adding = a section (or a sub-section) is a pretty significant change. Therefore, I t= hink the WG should have an opportunity to express its consensus. Unless, of= course, I get over-ridden by my co-chair and/or the ADs=85 ;-)

Regards,
Stan

On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote:

> Dear all,
>
> The authors of nhdp-sec-threats have submitted a new revision based on= the comments during WGLC.
>
> The only technical change is that, a new sub-section is added on link = quality update:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 4.8. =A0Attack on Link Quality Update
>
> =A0According to NHDP, "Link quality is a mechanism whereby a rout= er MAY
> =A0take considerations other than message exchange into account for > =A0determining when a link is and is not a candidate for being
> =A0considered as HEARD or SYMMETRIC. =A0As such, it is a link admissio= n
> =A0mechanism.".
>
> =A0Section 14.4 of NHDP [RFC6130] then lists several examples of which=
> =A0information can be used to update link quality. =A0One of the liste= d
> =A0examples is to update link quality based on [RFC5444] packet
> =A0exchanges between neighbor routers, e.g., an NHDP Router may update=
> =A0the link quality of a neighbor based on receipt or loss of packets = if
> =A0they include a sequential packet sequence number.
>
> =A0NHDP does not specify how to acquire link quality updates
> =A0normatively, however, attack vectors may be introduced if an
> =A0implementation chooses to calculate link quality based on packet > =A0sequence numbers. =A0The consequences of such threats would depend = on
> =A0specific implementations. =A0For example, if the link quality updat= e is
> =A0based on sequential packet sequence number from neighbor routers, a=
> =A0Comprised NDHP Router can spoof packets appearing to be from anothe= r
> =A0Legitimate NHDP Router that skips some packet sequence numbers. =A0= The
> =A0NHDP Router receiving the spoofed packets may degrade the link
> =A0quality as it appears that several packets have been dropped.
> =A0Eventually, the router remove the neighbor when the link quality > =A0drops below HYST_REJECT.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Your comments are welcome.
>
> @chairs:
> I suppose that if this section gets approved, there is no need for ano= ther WGLC for the whole document?
>
> best
>
> Jiazi
>
> Begin forwarded message:
>
>> From: internet-drafts@= ietf.org
>> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-th= reats-02.txt
>> Date: March 20, 2013 11:43:53 AM GMT+01:00
>> To: jiazi@jiaziyi.com
>> Cc: t.clausen@computer.o= rg, ulrich@herberg.name
>>
>>
>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt
>> has been successfully submitted by Jiazi Yi and posted to the
>> IETF repository.
>>
>> Filename: =A0 =A0 draft-ietf-manet-nhdp-sec-threats
>> Revision: =A0 =A0 02
>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Security Threats for NHDP >> Creation date: =A0 =A0 =A0 =A02013-03-20
>> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0manet
>> Number of pages: 17
>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.txt=
>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker= .ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/= html/draft-ietf-manet-nhdp-sec-threats-02
>> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www= .ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-02
>>
>> Abstract:
>> =A0This document analyses common security threats of the Neighborh= ood
>> =A0Discovery Protocol (NHDP), and describes their potential impact= s on
>> =A0MANET routing protocols using NHDP.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf301d3dc6fa096004d8aaf2e3-- From ulrich@herberg.name Sun Mar 24 10:51:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323A21F8D51 for ; Sun, 24 Mar 2013 10:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mueqJwg2kud for ; Sun, 24 Mar 2013 10:51:11 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBFD21F8D30 for ; Sun, 24 Mar 2013 10:51:11 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so3795500pbc.29 for ; Sun, 24 Mar 2013 10:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=hSL3hx9zFMBZkHFR3LxxnCpTF0xgcfbK1GQV7TjojR0=; b=scTWLpnpfqRZPxnAPDGhF2l0H5d4BK66mmCKBq94s4IUbFcXcAun524Hrlyy4ZtCqi 44i0RySFLvFN4fK3iui17c6pumfn7Z07WI2CltOF4V6x2TH1Q3lgod96qWXKnIo/PC0h HEqEwQjChEkqOmcgq8F3IGBpQBzCRntOl52n8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=hSL3hx9zFMBZkHFR3LxxnCpTF0xgcfbK1GQV7TjojR0=; b=Ny9CpIhpRjDqagn+2JpNOTvesGehRpdmv4NFSly9X6kcBTe7KCENIrTD3T+MhRvswl 4v1xMHjqpGyMP0vCAEUHnniVdy9gxemk4Q4/P0gp5LlkILplvFR8vUaTCpPTD0OvcsY+ PhY9swinP2ajpi3RYMaRSSVs0daD+bvjmYtmCm1D3+GGZ0dMD8cXQ38y7A26RwuV8BnK Ae6H6/vQZCwD+XtojVHiqfAgAMxS6aZCmfpxDGn7LmhghxSexiBCJuQYiZ6+m0PxZTNL FM5dnX4tsos2rE5N7myu0Jtt6u9Hu/P7DhWArow1geO+VlmlE5K5LIC+xzF/jILAA1zJ RU8Q== X-Received: by 10.66.119.202 with SMTP id kw10mr12716608pab.181.1364147471238; Sun, 24 Mar 2013 10:51:11 -0700 (PDT) Received: from [10.0.1.6] (c-98-234-221-160.hsd1.ca.comcast.net. [98.234.221.160]) by mx.google.com with ESMTPS id zm1sm10264949pbc.26.2013.03.24.10.51.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Mar 2013 10:51:10 -0700 (PDT) References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1E77D323-E5FD-4E5A-A2C8-8B6AAFE6FCBB Content-Transfer-Encoding: 7bit Message-Id: <5831D73F-BB8A-48D6-BD16-B28F812377A6@herberg.name> X-Mailer: iPad Mail (10B146) From: Ulrich Herberg Date: Sun, 24 Mar 2013 10:51:11 -0700 To: Daniel He X-Gm-Message-State: ALoCoQmMSfqfIyz2zZ3Jz6D9E/5qLdjzKgn0KIyOQKBA9NlW+IXUuDY91Ydu3Iv6Vknq/PYE7z3y Cc: manet List , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 17:51:13 -0000 --Apple-Mail-1E77D323-E5FD-4E5A-A2C8-8B6AAFE6FCBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I agree with Daniel. The change is minimal, and it is a very short section t= o read, so I hope that a one week WGLC would be sufficient. Best regards Ulrich Sent from my iPad On Mar 24, 2013, at 5:37, Daniel He wrote: > Hi Stan and others, >=20 > I reviewed the text added. It is not a significant change > even if you think "Attack on Link Quality Update" SHOULD be counted in. > the whole perspective of the draft is good. >=20 > however, "NHDP does not specify how to acquire link quality updates > > normatively", it looks like that HNDP assumed the link quality update > is secure and underlying mechanism took care of this. I don't know this > section is a must. it is only [optional]! Even if this section is removed,= =20 > the draft doesn't change a thing. >=20 > Cheers, > Dan >=20 > On 23 March 2013 23:54, Stan Ratliff (sratliff) wrote= : >> Jiazi, >>=20 >> You've added a new sub-section, so my opinion is yes, we *do* need anothe= r WGLC for the document. There may not be a ton of text here, but adding a s= ection (or a sub-section) is a pretty significant change. Therefore, I think= the WG should have an opportunity to express its consensus. Unless, of cour= se, I get over-ridden by my co-chair and/or the ADs=E2=80=A6 ;-) >>=20 >> Regards, >> Stan >>=20 >> On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote: >>=20 >> > Dear all, >> > >> > The authors of nhdp-sec-threats have submitted a new revision based on t= he comments during WGLC. >> > >> > The only technical change is that, a new sub-section is added on link q= uality update: >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > 4.8. Attack on Link Quality Update >> > >> > According to NHDP, "Link quality is a mechanism whereby a router MAY >> > take considerations other than message exchange into account for >> > determining when a link is and is not a candidate for being >> > considered as HEARD or SYMMETRIC. As such, it is a link admission >> > mechanism.". >> > >> > Section 14.4 of NHDP [RFC6130] then lists several examples of which >> > information can be used to update link quality. One of the listed >> > examples is to update link quality based on [RFC5444] packet >> > exchanges between neighbor routers, e.g., an NHDP Router may update >> > the link quality of a neighbor based on receipt or loss of packets if >> > they include a sequential packet sequence number. >> > >> > NHDP does not specify how to acquire link quality updates >> > normatively, however, attack vectors may be introduced if an >> > implementation chooses to calculate link quality based on packet >> > sequence numbers. The consequences of such threats would depend on >> > specific implementations. For example, if the link quality update is >> > based on sequential packet sequence number from neighbor routers, a >> > Comprised NDHP Router can spoof packets appearing to be from another >> > Legitimate NHDP Router that skips some packet sequence numbers. The >> > NHDP Router receiving the spoofed packets may degrade the link >> > quality as it appears that several packets have been dropped. >> > Eventually, the router remove the neighbor when the link quality >> > drops below HYST_REJECT. >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > Your comments are welcome. >> > >> > @chairs: >> > I suppose that if this section gets approved, there is no need for anot= her WGLC for the whole document? >> > >> > best >> > >> > Jiazi >> > >> > Begin forwarded message: >> > >> >> From: internet-drafts@ietf.org >> >> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-threat= s-02.txt >> >> Date: March 20, 2013 11:43:53 AM GMT+01:00 >> >> To: jiazi@jiaziyi.com >> >> Cc: t.clausen@computer.org, ulrich@herberg.name >> >> >> >> >> >> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >> >> has been successfully submitted by Jiazi Yi and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-ietf-manet-nhdp-sec-threats >> >> Revision: 02 >> >> Title: Security Threats for NHDP >> >> Creation date: 2013-03-20 >> >> Group: manet >> >> Number of pages: 17 >> >> URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-= nhdp-sec-threats-02.txt >> >> Status: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp= -sec-threats >> >> Htmlized: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-= threats-02 >> >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-n= hdp-sec-threats-02 >> >> >> >> Abstract: >> >> This document analyses common security threats of the Neighborhood >> >> Discovery Protocol (NHDP), and describes their potential impacts on >> >> MANET routing protocols using NHDP. >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> >> >> > >> > _______________________________________________ >> > 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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-1E77D323-E5FD-4E5A-A2C8-8B6AAFE6FCBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree w= ith Daniel. The change is minimal, and it is a very short section to read, s= o I hope that a one week WGLC would be sufficient.

= Best regards
Ulrich

Sent from my iPad

On Mar 2= 4, 2013, at 5:37, Daniel He <drdanhe= @gmail.com> wrote:

Hi Sta= n and others,

I reviewed  the text added. It is not  a sign= ificant change
even if you think "Attack on Link Quality Update" SHOULD b= e counted in.
the whole perspective of the draft is good.

however,  "NHDP does not specify how to acquire link quality update= s
>  normatively", it looks like that HNDP assumed the link quality up= date
is secure and underlying mechanism took care of this. I don't know t= his
section is a must. it is only [optional]! Even if this section is rem= oved,
the draft doesn't change a thing.

Cheers,
Dan

On 23 March 2013 23:54, Stan Ratliff (sratliff) <sratliff@cis= co.com> wrote:
Jiazi,

You've added a new sub-section, so my opinion is yes, we *do* need another W= GLC for the document. There may not be a ton of text here, but adding a sect= ion (or a sub-section) is a pretty significant change. Therefore, I think th= e WG should have an opportunity to express its consensus. Unless, of course,= I get over-ridden by my co-chair and/or the ADs=E2=80=A6 ;-)

Regards,
Stan

On Mar 20, 2013, at 7:10 AM, Jiazi Yi wrote:

> Dear all,
>
> The authors of nhdp-sec-threats have submitted a new revision based on t= he comments during WGLC.
>
> The only technical change is that, a new sub-section is added on link q= uality update:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 4.8.  Attack on Link Quality Update
>
>  According to NHDP, "Link quality is a mechanism whereby a router M= AY
>  take considerations other than message exchange into account for<= br> >  determining when a link is and is not a candidate for being
>  considered as HEARD or SYMMETRIC.  As such, it is a link adm= ission
>  mechanism.".
>
>  Section 14.4 of NHDP [RFC6130] then lists several examples of whi= ch
>  information can be used to update link quality.  One of the l= isted
>  examples is to update link quality based on [RFC5444] packet
>  exchanges between neighbor routers, e.g., an NHDP Router may upda= te
>  the link quality of a neighbor based on receipt or loss of packet= s if
>  they include a sequential packet sequence number.
>
>  NHDP does not specify how to acquire link quality updates
>  normatively, however, attack vectors may be introduced if an
>  implementation chooses to calculate link quality based on packet<= br> >  sequence numbers.  The consequences of such threats would de= pend on
>  specific implementations.  For example, if the link quality u= pdate is
>  based on sequential packet sequence number from neighbor routers,= a
>  Comprised NDHP Router can spoof packets appearing to be from anot= her
>  Legitimate NHDP Router that skips some packet sequence numbers. &= nbsp;The
>  NHDP Router receiving the spoofed packets may degrade the link >  quality as it appears that several packets have been dropped.
= >  Eventually, the router remove the neighbor when the link quality<= br> >  drops below HYST_REJECT.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Your comments are welcome.
>
> @chairs:
> I suppose that if this section gets approved, there is no need for anot= her WGLC for the whole document?
>
> best
>
> Jiazi
>
> Begin forwarded message:
>
>> From: internet-drafts@i= etf.org
>> Subject: New Version Notification for draft-ietf-manet-nhdp-sec-thr= eats-02.txt
>> Date: March 20, 2013 11:43:53 AM GMT+01:00
>> To: jiazi@jiaziyi.com
>> Cc: t.clausen@computer.or= g, ulrich@herberg.name
>>
>>
>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt
>> has been successfully submitted by Jiazi Yi and posted to the
>> IETF repository.
>>
>> Filename:     draft-ietf-manet-nhdp-sec-threats
>> Revision:     02
>> Title:                Secur= ity Threats for NHDP
>> Creation date:        2013-03-20
>> Group:                manet=
>> Number of pages: 17
>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threa= ts-02.txt
>> Status:          http:= //datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
>> Htmlized:        http://tools= .ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02
>> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-0= 2
>>
>> Abstract:
>>  This document analyses common security threats of the Neighbo= rhood
>>  Discovery Protocol (NHDP), and describes their potential impa= cts on
>>  MANET routing protocols using NHDP.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-1E77D323-E5FD-4E5A-A2C8-8B6AAFE6FCBB-- From internet-drafts@ietf.org Mon Mar 25 10:21:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90721F90B1; Mon, 25 Mar 2013 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP2JvEH8hsFM; Mon, 25 Mar 2013 10:21:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDA421F9060; Mon, 25 Mar 2013 10:21:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 10:21:18 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:21:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic Link Exchange Protocol (DLEP) Author(s) : Stan Ratliff Bo Berry Greg Harrison Darryl Satterwhite Shawn Jury Filename : draft-ietf-manet-dlep-04.txt Pages : 48 Date : 2013-03-25 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dlep-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sratliff@cisco.com Mon Mar 25 10:23:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738221F9433 for ; Mon, 25 Mar 2013 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGuhwTxvVJvg for ; Mon, 25 Mar 2013 10:23:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE721F9081 for ; Mon, 25 Mar 2013 10:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2095; q=dns/txt; s=iport; t=1364232196; x=1365441796; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E6tr7Sux0zeXMasvRaKmr8sTdReiUmhMktM2hCrxTus=; b=O/Ha8lNxWZIE2mAu/wgvW+oJ3EvtDjtyN79ggArJg+fQ4x83rl1gJ3BX 0vmBnEtQULY0kADVdjJhyHZtcLhKg9PaZvBRvKv1BMHdO1Bhqbuebakps ueehqn8Y4nYtNpxk3m0DJ0USjOqDekHyw6IykUqwNUJ7QMgRTmnU32jQC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAFqHUFGtJV2Z/2dsb2JhbABDhXC/eIIGFnSCJAEBAQMBAQEBNzQbAgEIIhQQJwslAgQTCAGIBQYHBcMOjmUCOIJfYQOTIYRlj2WDCoIo X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="188209603" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 25 Mar 2013 17:23:08 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2PHN8oL015996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Mar 2013 17:23:08 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 12:23:08 -0500 From: "Stan Ratliff (sratliff)" To: manet List Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-04.txt Thread-Index: AQHOKX0z5IHQaN4zhUKX7SuqZaqtKpi2+6uA Date: Mon, 25 Mar 2013 17:23:07 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DA31@xmb-aln-x03.cisco.com> References: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> In-Reply-To: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:23:17 -0000 WG - As promised, DLEP-04. As I mentioned in Orlando, the changes are:=20 1. Went back to modem-initiated discovery 2. Inbound and outbound metrics=20 I'm sure something got missed, so your review & comments are appreciated.=20 Regards, Stan On Mar 25, 2013, at 1:21 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of = the IETF. >=20 > Title : Dynamic Link Exchange Protocol (DLEP) > Author(s) : Stan Ratliff > Bo Berry > Greg Harrison > Darryl Satterwhite > Shawn Jury > Filename : draft-ietf-manet-dlep-04.txt > Pages : 48 > Date : 2013-03-25 >=20 > Abstract: > When routing devices rely on modems to effect communications over > wireless links, they need timely and accurate knowledge of the > characteristics of the link (speed, state, etc.) in order to make > forwarding decisions. In mobile or other environments where these > characteristics change frequently, manual configurations or the > inference of state through routing or transport protocols does not > allow the router to make the best decisions. A bidirectional, event- > driven communication channel between the router and the modem is > necessary. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dlep-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Mon Mar 25 10:30:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E86121F94F2 for ; Mon, 25 Mar 2013 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRu3yzUWd9Ah for ; Mon, 25 Mar 2013 10:30:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CB46C21F9482 for ; Mon, 25 Mar 2013 10:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1364232647; x=1365442247; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GztCil2/CWV/kXOd0av3EBharWp0e5WnBq7/Aw24EGg=; b=fiZurOtzqBAGR8azNGtdfyfWwHjP+o5846ZebxRZxbFA7IiTulA7LPMl Yzw1YrfWOR4NRyZuWObaliGeCWl8fNgVBRnGm9mALA2nGx/6S7mycM+tY YW9fgg8TmScTutbNTWj4AKYTgTcHTFCLGYQbj8GRO+4/WiyWfpRJXefr0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD6JUFGtJXHB/2dsb2JhbABDxWiCBhZ0giUBAQQ6PRICAQgiFBAyJQIEG4gMwyKOZQI4gl9hA6drgVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="191207975" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Mar 2013 17:30:46 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2PHUk8f014572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Mar 2013 17:30:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 12:30:46 -0500 From: "Stan Ratliff (sratliff)" To: manet List Thread-Topic: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt Thread-Index: AQHOKLgsGWmP8soRWUeiNxKT2lHUPZi2/1eA Date: Mon, 25 Mar 2013 17:30:45 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DAC3@xmb-aln-x03.cisco.com> References: <20130320104353.27601.24590.idtracker@ietfa.amsl.com> <76F7932F-CABE-4825-80DB-461E95288402@jiaziyi.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10067A97@xmb-aln-x03.cisco.com> <5831D73F-BB8A-48D6-BD16-B28F812377A6@herberg.name> In-Reply-To: <5831D73F-BB8A-48D6-BD16-B28F812377A6@herberg.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:30:55 -0000 WG,=20 I've re-started the WGLC on this document. There's a 2-week WGLC period, en= ding on April 8, 2013.=20 Regards, Stan= From bebemaster@gmail.com Mon Mar 25 14:01:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51A21F9016 for ; Mon, 25 Mar 2013 14:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pQwwql4HI9I for ; Mon, 25 Mar 2013 14:01:42 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 220B221F8FEC for ; Mon, 25 Mar 2013 14:01:40 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so12321091lab.30 for ; Mon, 25 Mar 2013 14:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=LjFsG7bSOdSlaDOl2B4zvoZp90/FRiN7bGLlsA5w14E=; b=aNTRo9sBkmWO41rQzgugFHMDx1fX2+fqfB4CPX18sHNoki3EsggGdVHeD526G78+Y0 UhObBivOr06sFNpLmCdokhXTtFrs5NmnU/iVaEMhhOR1JEidXJhzGP8YV7WsjpVdPr2v k6Vv7FZIya48Oxm0T1EZ/h6Hk3syvb6mhnDq5KqjkDJOQ5PUeWbsZx6AdKYakLeoIbro gLzg/iHVNPb8oGVXhTPUDEK/WwxZFinE4rC+mQLN2Y+h0/LtK/42xQ0ZjDjM70PjiN0w oSKa+tMHBS47W+JTu/7Nv91Id5tCQG9AKDjAcLsDGmHdfyL07EFDGad0YYPqeauYdsg5 btOg== MIME-Version: 1.0 X-Received: by 10.112.28.169 with SMTP id c9mr7017455lbh.84.1364245299718; Mon, 25 Mar 2013 14:01:39 -0700 (PDT) Received: by 10.152.132.162 with HTTP; Mon, 25 Mar 2013 14:01:39 -0700 (PDT) Date: Mon, 25 Mar 2013 17:01:39 -0400 Message-ID: From: Justin Dean To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec554d83279f7a104d8c61c4a Subject: [manet] rfc6622-bis-01 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 21:01:57 -0000 --bcaec554d83279f7a104d8c61c4a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Below I have included my comments in-line tagged with JD. The new TLV subtype assignment confuses the issue of replacement of 6622. Are there situations where ICV TLVs with subtype 1 as defined in 6622 are more appropriate? My guess is No. In any case I shouldn't be guessing, so that should be made more clear. Replacement of and not just extension of 6622 is my largest overarching issue with the document. It seems to supersede 6622 in two different ways. Functionally the definition of a new superior type of TCV TLV depreciates use of 6622. But also in terms of text of usage of the format and TLV type= . But 6622 doesn't necessary "break" with the addition of a new superior TCV type but its just becomes depreciated. I can't help but think the document would be much tighter if it worked to augment 6622 instead of replace, I do understand the rational for replacement however as reading one document is simpler than two and this one really is more useful. Despite that and despite the number of comments below I do believe that with a few editorial changes the document should be moved forward. Mobile Ad hoc Networking (MANET) U. Herberg Internet-Draft Fujitsu Laboratories of America Obsoletes: 6622 (if approved) T. Clausen Intended status: Standards Track LIX, Ecole Polytechnique Expires: September 24, 2013 C. Dearlove BAE Systems ATC March 23, 2013 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) draft-ietf-manet-rfc6622-bis-01 Abstract This document extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 24, 2013. Copyright Notice Copyright (c) 2013 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 Herberg, et al. Expires September 24, 2013 [Page 1] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 (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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 5 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 6 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 7 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 8 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Message ICV TLV . . . . . . . . . . . . . . . . . . . . . 8 9.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 9 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Address Block ICV TLV . . . . . . . . . . . . . . . . . . 9 10.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 9 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 10 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 10 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 12.2. Considerations for Calculating the ICV . . . . . . . . . . 11 12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 12 12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 12 12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 12 12.3. Example of a Message Including an ICV . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14 13.2. Packet TLV Type Registrations . . . . . . . . . . . . . . 14 13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15 13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16 13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 17 13.6. Cryptographic Functions . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 21 Herberg, et al. Expires September 24, 2013 [Page 2] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 1. Introduction This document, which extends and replaces [RFC6622], specifies: JD: This document extends and replaces [RFC6622]. It specifies: o Two TLVs for carrying Integrity Check Values (ICVs) and timestamps in packets, messages, and address blocks as defined by [RFC5444]. JD: Two TLV structures; One for carrying Integrity Check Values (ICVs), and one for timestamps. TLV type assignments for packet, message and addres= s block TLVs for these structures. o A generic framework for ICVs, accounting (for Message TLVs) for mutable message header fields ( and ), where these fields are present in messages. This document retains the IANA registries, defined in [RFC6622], for recording code points for hash-functions, cryptographic functions, and ICV calculations. This document requests additional allocations from these registries. Moreover, in Section 12, this document defines the following: o A method for generating ICVs using a combination of a cryptographic function and a hash function. JD: There is text in section 5 which should be moved to here. 1.1. Differences from RFC6622 This document obsoletes [RFC6622]. The changes introduced by this document are, however, small. In addition to editorial updates, this document adds a new type extension for the ICV TLV that is specified in Section 12 of this document. The TLV value of a TLV with this type extension has the same internal structure as a TLV with type extension 1, but is calculated also over the source address of the IP datagram carrying the packet, message, or address block. The rationale for adding this type extension is that some MANET protocols, such as [RFC6130] and [OLSRv2], use the IP source address of the IP datagram carrying the packet, message or address block, e.g., to identify links with neighbor routers. If this address is not otherwise contained in the packet, message, or address block payload (which is permitted, e.g., in [RFC6130]), the address is not protected against tampering. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the terminology and notation defined in [RFC5444]. In particular, the following TLV fields and notation from [RFC5444] Herberg, et al. Expires September 24, 2013 [Page 3] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 are used in this specification: is the hop limit of a message, as specified in Section 5.2 of [RFC5444]. is the hop count of a message, as specified in Section 5.2 of [RFC5444]. is the length of the value field in a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. single-length is the length of a single value in the value field in a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (It is equal to except in a multivalue Address Block TLV.) 3. Applicability Statement MANET routing protocols using the format defined in [RFC5444] are accorded the ability to carry additional information in control messages and packets, through the inclusion of TLVs. Information so included MAY be used by a MANET routing protocol, or by an extension of a MANET routing protocol, according to its specification. This document specifies how to include an ICV for a packet, a message, and addresses in address blocks within a message, using such TLVs. This document also specifies how to treat "mutable" fields, specifically the and fields, if present in the message header when calculating ICVs, such that the resulting ICV can be correctly verified by any recipient. This document describes a generic framework for creating ICVs, and how to include these ICVs in TLVs. In Section 12, an example method for calculating such ICVs is given, using a cryptographic function and a hash function. 4. Security Architecture Basic MANET routing protocol specifications are often "oblivious to security"; however, they may have a clause allowing a control message to be rejected as "badly formed" or "insecure" prior to the message being processed or forwarded. In particular, MANET routing protocols such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 [OLSRv2] recognize external reasons (such as failure to verify an ICV) for rejecting a message that would be considered "invalid for processing". This architecture is a result of the observation that with respect to security in MANETs, "one size rarely fits all" and that MANET routing Herberg, et al. Expires September 24, 2013 [Page 4] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 protocol deployment domains have varying security requirements ranging from "unbreakable" to "virtually none". The virtue of this approach is that MANET routing protocol specifications (and implementations) can remain "generic", with extensions providing proper security mechanisms specific to a deployment domain. The MANET routing protocol "security architecture", in which this specification situates itself, can therefore be summarized as follows: o MANET routing protocol specifications, with a clause allowing an extension to reject a message (prior to processing/forwarding) as "badly formed" or "insecure". o MANET routing protocol security extensions, rejecting messages as "badly formed" or "insecure", as appropriate for a given security requirement specific to a deployment domain. o Code points and an exchange format for information, necessary for specification of such MANET routing protocol security extensions. This document addresses the last of the issues listed above by specifying a common exchange format for cryptographic ICVs, making reservations from within the Packet TLV, Message TLV, and Address Block TLV registries of [RFC5444], to be used (and shared) among MANET routing protocol security extensions. For the specific decomposition of an ICV using a cryptographic function and a hash function (specified in Section 12), this document reports the two IANA registries from [RFC6622] for code points for hash functions and cryptographic functions adhering to [RFC5444]. With respect to [RFC5444], this document is: o Intended to be used in the non-normative, but intended, mode of use described in Appendix B of [RFC5444]. o A specific example of the Security Considerations section of [RFC5444] (the authentication part). 5. Overview and Functioning This document specifies a syntactical representation of security- related information for use with [RFC5444] addresses, messages, and packets, and also reports and updates IANA registrations (from [RFC6622]) of TLV types and type extension registries for these TLV types. Herberg, et al. Expires September 24, 2013 [Page 5] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 Moreover, this document provides guidelines for how MANET routing protocols, and MANET routing protocol extensions using this specification, should treat ICV and Timestamp TLVs, and mutable fields in messages. This specification does not represent a stand- alone protocol; MANET routing protocols, and MANET routing protocol extensions using this specification, MUST provide instructions as to how to handle packets, messages, and addresses with security information, associated as specified in this document. JD: The above paragraphs are to me clearer than the introduction on what the goal of this document is. Specifically the statement "This specification does not represent a stand alone protocol" should be much more prominent than it currently is. This document reports previously assigned TLV types (from [RFC6622]) from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]. When a TLV type is assigned from one of these registries, a registry for type extensions for that TLV type is created by IANA. This document reports and updates these type extension registries, in order to specify internal structure (and accompanying processing) of the field of a TLV. For example, and as defined in this document, an ICV TLV with type extension =3D 0 specifies that the field has no pre-defined internal structure but is simply a sequence of octets. An ICV TLV with type extension =3D 1 specifies that the field has a pre- defined internal structure and defines its interpretation. An ICV TLV with type extension =3D 2 specifies a modified version of this definition. (Specifically, with type extension =3D 1 or type extension =3D 2, the field contains the result of combining a cryptographic function and a hash function, calculated over the contents of the packet, message or address block, with sub-fields indicating which hash function and cryptographic function have been used; this is specified in Section 12. The difference between the two type extensions is that the ICV TLV with type extension =3D 2 is calculated also over the source address of the IP datagram carrying the packet, message, or address block.) JD: Seems long winded without saying very much here. Should type extension 1 still be used? (No) Will it break anything? (No) Other documents can request assignments for other type extensions; if they do so, they MUST specify their internal structure (if any) and interpretation. 6. General ICV TLV Structure The value of the ICV TLV is: :=3D where Herberg, et al. Expires September 24, 2013 [Page 6] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 is a field, of octets, which contains the information to be interpreted by the ICV verification process, as specified by the type extension. Note that this does not stipulate how to calculate the nor the internal structure thereof, if any; such information MUST be specified by the type extension for the ICV TLV type; see Section 13. This document specifies three such type extensions -- one for ICVs without pre-defined structures, and two for ICVs constructed combining a cryptographic function and a hash function. 7. General Timestamp TLV Structure The value of the Timestamp TLV is: :=3D where: is an unsigned integer field, of length , which contains the timestamp. Note that this does not stipulate how to calculate the nor the internal structure thereof, if any; such information MUST be specified by the type extension for the TIMESTAMP TLV type; see Section 13. A timestamp is essentially "freshness information". As such, its setting and interpretation are to be determined by the MANET routing protocol, or MANET routing protocol extension, that uses the timestamp and can, for example, correspond to a POSIX timestamp, GPS timestamp, or a simple sequence number. JD: Some mention of difficulty of insuring time synchronization across a MANET and how it's out of scope of this document should be included. 8. Packet TLVs Two Packet TLVs are defined: one for including the cryptographic ICV of a packet and one for including the timestamp indicating the time at which the cryptographic ICV was calculated. 8.1. Packet ICV TLV A Packet ICV TLV is an example of an ICV TLV as described in Section 6. The following considerations apply: o Because packets as defined in [RFC5444] are never forwarded by routers, no special considerations are required regarding mutable Herberg, et al. Expires September 24, 2013 [Page 7] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 fields (e.g., and ), if present within any messages in the packet, when calculating the ICV. o Any Packet ICV TLVs already present in the Packet TLV block MUST be removed before calculating the ICV, and the Packet TLV block size MUST be recalculated accordingly. Removed ICV TLVs MUST be restored after having calculated the ICV value. JD: More clearly specify what "remove" means. I am assuming that the TLV block size or phastlv bit needs to be updated but that needs to be said= . The rationale for removing any Packet ICV TLV already present prior to calculating the ICV is that several ICVs may be added to the same packet, e.g., using different ICV functions. 8.2. Packet TIMESTAMP TLV A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If a packet contains a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV, in order to include it in the calculation of the ICV. JD: Shouldn't ALL packet TLVs (which are relevant for the ICV in question) other than ones listed as TCV TLVs be added before TCV TLVs are added? 9. Message TLVs Two Message TLVs are defined: one for including the cryptographic ICV of a message and one for including the timestamp indicating the time at which the cryptographic ICV was calculated. 9.1. Message ICV TLV A Message ICV TLV is an example of an ICV TLV as described in Section 6. When determining the for a message, the following considerations MUST be applied: o The fields and , if present, MUST both be assumed to have the value 0 (zero) when calculating the ICV. o Any Message ICV TLVs already present in the Message TLV block MUST be removed before calculating the ICV, and the message size as well as the Message TLV block size MUST be recalculated accordingly. Removed ICV TLVs MUST be restored after having calculated the ICV value. JD: MUST be restored and size fields updated as well. Also all relevant TLVs other than TCV TLVs must be added prior to TCV value calcuations. The rationale for removing any Message ICV TLV already present prior to calculating the ICV is that several ICVs may be added to the same message, e.g., using different ICV functions. Herberg, et al. Expires September 24, 2013 [Page 8] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 9.2. Message TIMESTAMP TLV A Message TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If a message contains a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV, in order to include it in the calculation of the ICV. 10. Address Block TLVs Two Address Block TLVs are defined: one for associating a cryptographic ICV to an address and one for including the timestamp indicating the time at which the cryptographic ICV was calculated. 10.1. Address Block ICV TLV An Address Block ICV TLV is an example of an ICV TLV as described in Section 6. The ICV is calculated over the address, concatenated with any other values -- for example, any other Address Block TLV fields -- associated with that address. A MANET routing protocol or MANET routing protocol extension using Address Block ICV TLVs MUST specify how to include any such concatenated attribute of the address in the calculation and verification processes for the ICV. When determining the for an address, the following consideration MUST be applied: o If other TLV values are concatenated with the address for calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs already associated with the address. The rationale for not concatenating the address with any ICV TLV values already associated with the address when calculating the ICV is that several ICVs may be added to the same address, e.g., using different ICV functions. JD: It may be helpful to point out that a list of TLV values associated with and address will not likely exist as such within a packet. This TCV is distinct from packet/message TCVs in this regard. 10.2. Address Block TIMESTAMP TLV An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If both a TIMESTAMP TLV and an ICV TLV are associated with an address, the TIMESTAMP TLV MUST be covered when calculating the value of the ICV to be contained in the ICV TLV value (i.e., concatenated with the associated address and any other values as described in Section 10.1). 11. ICV: Basic The basic ICV, represented by way of an ICV TLV with type extension =3D 0, is a simple bit-field containing the cryptographic ICV. This assumes that the mechanism stipulating how ICVs are calculated and Herberg, et al. Expires September 24, 2013 [Page 9] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 verified is established outside of this specification, e.g., by way of administrative configuration or external out-of-band signaling. Thus, the , when using type extension =3D 0, is :=3D where: is an unsigned integer field, of length , which contains the cryptographic ICV. 12. ICV: Hash Function and Cryptographic Function One common way of calculating an ICV is combining a cryptographic function and a hash function applied to the content. This decomposition is specified in this section, using either type extension =3D 1 or type extension =3D 2, in the ICV TLVs. JD: nix "using either type extension =3D 1 or type extension =3D 2, in the = ICV TLVs" 12.1. General ICV TLV Structure The following data structure allows representation of a cryptographic ICV, including specification of the appropriate hash function and cryptographic function used for calculating the ICV: :=3D where: is an 8-bit unsigned integer field specifying the hash function. is an 8-bit unsigned integer field specifying the cryptographic function. is an 8-bit unsigned integer field specifying the length of the field in number of octets. The value 0x00 is reserved for using a single pre-installed, shared key. JD: Functional change suggestion. Might we reserve a small number of values similar to 0 but which may have different as yet to be determined meanings. For example, use of a key provided out of bound such as a packet level "global" for this packet key for message TCV TLVs. Repeatedly providing a key seems like it may become cumbersome. is a field specifying the key identifier of the key that was used to calculate the ICV of the message, which allows unique identification of different keys with the same originator. It is the responsibility of each key originator to make sure that actively used keys that it issues have distinct key identifiers. If equals 0x00, the field is not Herberg, et al. Expires September 24, 2013 [Page 10] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 contained in the TLV, and a single pre-installed, shared key is used. is an unsigned integer field, whose length is - 3 - , except in a multivslue Address Block TLV, in which it is single-length - 3 - , and which contains the cryptographic ICV. The version of this TLV, specified in this section, assumes that, unless otherwise specified, calculating the ICV can be decomposed into: ICV-value =3D cryptographic-function(hash-function(content)) In some cases a different combination of cryptographic function and hash function may be specified. This is the case for the HMAC function, which is specified as defined in Section 13.6, using the hash function twice. The hash function and the cryptographic function correspond to the entries in two IANA registries, which are reported by this specification and are described in Section 13. 12.1.1. Rationale The rationale for separating the hash function and the cryptographic function into two octets instead of having all combinations in a single octet -- possibly as a TLV type extension -- is that adding further hash functions or cryptographic functions in the future may lead to a non-contiguous number space. The rationale for not including a field that lists parameters of the cryptographic ICV in the TLV is that, before being able to validate a cryptographic ICV, routers have to exchange or acquire keys (e.g., public keys). Any additional parameters can be provided together with the keys in that bootstrap process. It is therefore not necessary, and would even entail an extra overhead, to transmit the parameters within every message. One implicitly available parameter is the length of an ICV, which is - 3 - (or single-length - 3 - in a multivalue Address Block TLV) and which depends on the choice of the cryptographic function. 12.2. Considerations for Calculating the ICV The considerations listed in the following subsections MUST be applied when calculating the ICV for Packet, Message, and Address Block ICV TLVs, respectively. Herberg, et al. Expires September 24, 2013 [Page 11] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 12.2.1. Packet ICV TLV When determining the for a packet, with type extension =3D 1, the ICV is calculated over the fields , , , and -- if present -- (in that order), concatenated with the entire packet, including the packet header, all Packet TLVs (other than Packet ICV TLVs), and all included Messages and their message headers, in accordance with Section 8.1. When determining the for a packet, with type extension =3D 2, the same procedure is used, except that the source address of the IP datagram carrying the packet is also concatenated, in the first position, with the data used. JD: don't use concatenated use proceded by or followed by. Might also mention network byte ordering issues as at this point we are dealing with packets. 12.2.2. Message ICV TLV When determining the for a message, with type extension =3D 1, the ICV is calculated over the fields , , , and -- if present -- (in that order), concatenated with the entire message. The considerations in Section 9.1 MUST be applied. When determining the for a message, with type extension =3D 2, the same procedure is used, except that the source address of the IP datagram carrying the message is also concatenated, in the first position, with the data used. 12.2.3. Address Block ICV TLV When determining the for an address, block, with type extension =3D 2, the ICV is calculated over the fields , , , and -- if present -- (in that order), concatenated with the address, and concatenated with any other values -- for example, any other address block TLV that is associated with that address. A MANET routing protocol or MANET routing protocol extension using Address Block ICV TLVs MUST specify how to include any such concatenated attribute of the address in the verification process of the ICV. The considerations in Section 10.1 MUST be applied. When determining the for an address block, with type extension =3D 2, the same procedure is used, except that the source address of the IP datagram carrying the address block is also concatenated, in the first position, with the data used. JD: Typo first mention of type extension =3D 2 should be =3D1. Seems like we should be able to specify a generalized method for including the values. Why not just specify that all address tlv type/value pairs associated with = an address be included in order type.subtype order? Punting is fine but I don'= t see why it needs to be done. 12.3. Example of a Message Including an ICV The sample message depicted in Figure 1 is derived from Appendix D of [RFC5444]. The message contains an ICV Message TLV, with the value representing an ICV that is 16 octets long of the whole message, and a key identifier that is 4 octets long. The type extension of the Herberg, et al. Expires September 24, 2013 [Page 12] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 Message TLV is 1, for the specific decomposition of an ICV using a cryptographic function and a hash function, as specified in Section 12. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PV=3D0 | PF=3D8 | Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MF=3D15 | MAL=3D3 | Message Length =3D 44 | Msg Orig Addr = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Originator Address (cont) | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | Message Sequence Number | Msg TLV Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length =3D 27 | ICV | MTLVF =3D 144 | MTLVExt =3D 1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Value Len =3D 23 | Hash Func | Crypto Func |Key ID length=3D4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Example Message with ICV JD: Shouldn't we change this to type =3D 2 as that is the only "new" thing this document is specifying and encouraging? Structure should stay the same. 13. IANA Considerations This specification reports the following, originally specified in [RFC6622]: o Two Packet TLV types, which have been allocated from the 0-223 range of the "Packet TLV Types" repository of [RFC5444], as specified in Table 1. o Two Message TLV types, which have been allocated from the 0-127 range of the "Message TLV Types" repository of [RFC5444], as specified in Table 2. o Two Address Block TLV types, which have been allocated from the 0-127 range of the "Address Block TLV Types" repository of [RFC5444], as specified in Table 3. Herberg, et al. Expires September 24, 2013 [Page 13] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 This specification updates the following, created in [RFC6622]: o A type extension registry for each of these TLV types with values as listed in Tables 1, 2, and 3. The following terms are used as defined in [BCP26]: "Namespace", "Registration", and "Designated Expert". The following policy is used as defined in [BCP26]: "Expert Review". 13.1. Expert Review: Evaluation Guidelines For TLV type extensions registries where an Expert Review is required, the Designated Expert SHOULD take the same general recommendations into consideration as those specified by [RFC5444]. For the Timestamp TLV, the same type extensions for all Packet, Message, and Address Block TLVs SHOULD be numbered identically. 13.2. Packet TLV Type Registrations IANA has, in accordance with [RFC6622], made allocations from the "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs specified in Table 1. IANA are requested to modify this allocation (defining type extension =3D 2) as indicated. Herberg, et al. Expires September 24, 2013 [Page 14] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 +-----------+------+-----------+------------------------------------+ | Name | Type | Type | Description | | | | Extension | | +-----------+------+-----------+------------------------------------+ | ICV | 5 | 0 | ICV of a packet | | | | 1-2 | ICV, using a cryptographic | | | | | function and a hash function, as | | | | | specified in Section 12 of this | | | | | document | | | | 3-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | | | | | length, given by the TLV Length | | | | | field. The MANET routing protocol | | | | | has to define how to interpret | | | | | this timestamp | | | | 1 | Unsigned 32-bit timestamp, as | | | | | specified in [IEEE 1003.1-2008 | | | | | (POSIX)] | | | | 2 | NTP timestamp format, as defined | | | | | in [RFC5905] | | | | 3 | Signed timestamp of arbitrary | | | | | length with no constraints such as | | | | | monotonicity. In particular, it | | | | | may represent any random value | | | | 4-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | +-----------+------+-----------+------------------------------------+ JD: Mostly a style thing but dislike how 1-2 are included together. Suggest separating them out and indicating the difference (source IP address used). Same suggestion for other IANA tables. Table 1: Packet TLV Types More than one ICV Packet TLV with the same type extension MAY be included in a packet if these represent different ICV calculations (e.g., with type extension 1 or 2 and different cryptographic function and/or hash function, or with a different key identifier). ICV Packet TLVs that carry what is declared to be the same information MUST NOT be included in the same packet. 13.3. Message TLV Type Registrations IANA has, in accordance with [RFC6622], made allocations from the "Message TLV Types" namespace of [RFC5444] for the Message TLVs specified in Table 2. IANA are requested to modify this allocation (defining type extension =3D 2) as indicated. Herberg, et al. Expires September 24, 2013 [Page 15] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 +-----------+------+-----------+------------------------------------+ | Name | Type | Type | Description | | | | Extension | | +-----------+------+-----------+------------------------------------+ | ICV | 5 | 0 | ICV of a message | | | | 1-2 | ICV, using a cryptographic | | | | | function and a hash function, as | | | | | specified in Section 12 of this | | | | | document | | | | 3-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | | | | | length, given by the TLV Length | | | | | field. | | | | 1 | Unsigned 32-bit timestamp, as | | | | | specified in [IEEE 1003.1-2008 | | | | | (POSIX)] | | | | 2 | NTP timestamp format, as defined | | | | | in [RFC5905] | | | | 3 | Signed timestamp of arbitrary | | | | | length with no constraints such as | | | | | monotonicity. In particular, it | | | | | may represent any random value | | | | 4-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | +-----------+------+-----------+------------------------------------+ Table 2: Message TLV Types More than one ICV Message TLV with the same type extension MAY be included in a message if these represent different ICV calculations (e.g., with type extension 1 or 2 and different cryptographic function and/or hash function, or with a different key identifier). ICV Message TLVs that carry what is declared to be the same information MUST NOT be included in the same message. 13.4. Address Block TLV Type Registrations IANA has, in accordance with [RFC6622], made allocations from the "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs specified in Table 3. IANA are requested to modify this allocation (defining type extension =3D 2) as indicated. Herberg, et al. Expires September 24, 2013 [Page 16] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 +-----------+------+-----------+------------------------------------+ | Name | Type | Type | Description | | | | Extension | | +-----------+------+-----------+------------------------------------+ | ICV | 5 | 0 | ICV of an object (e.g., an | | | | | address) | | | | 1-2 | ICV, using a cryptographic | | | | | function and a hash function, as | | | | | specified in Section 12 of this | | | | | document | | | | 3-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | | | | | length, given by the TLV Length | | | | | field | | | | 1 | Unsigned 32-bit timestamp, as | | | | | specified in [IEEE 1003.1-2008 | | | | | (POSIX)] | | | | 2 | NTP timestamp format, as defined | | | | | in [RFC5905] | | | | 3 | Signed timestamp of arbitrary | | | | | length with no constraints such as | | | | | monotonicity. In particular, it | | | | | may represent any random value | | | | 4-251 | Unassigned; Expert Review | | | | 252-255 | Experimental Use | +-----------+------+-----------+------------------------------------+ Table 3: Address Block TLV Types More than one ICV Address Block TLV with the same type extension MAY be associated with an address if these represent different ICV calculations (e.g., with type extension 1 or 2 and different cryptographic function and/or hash function, or with a different key identifier). ICV Address Block TLVs that carry what is declared to be the same information MUST NOT be associated with the same address. 13.5. Hash Functions IANA has, in accordance with [RFC6622], created a new registry for hash functions that can be used when creating an ICV, as specified in Section 12 of this document. The initial assignments and allocation policies are specified in Table 4. This registry is unchanged by this specification. Herberg, et al. Expires September 24, 2013 [Page 17] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 +-------------+-----------+-----------------------------------------+ | Hash | Algorithm | Description | | Function | | | | Value | | | +-------------+-----------+-----------------------------------------+ | 0 | none | The "identity function": The hash value | | | | of an object is the object itself | | 1 | SHA1 | [NIST-FIPS-180-2] | | 2 | SHA224 | [NIST-FIPS-180-2-change] | | 3 | SHA256 | [NIST-FIPS-180-2] | | 4 | SHA384 | [NIST-FIPS-180-2] | | 5 | SHA512 | [NIST-FIPS-180-2] | | 6-251 | | Unassigned; Expert Review | | 252-255 | | Experimental Use | +-------------+-----------+-----------------------------------------+ Table 4: Hash Function Registry 13.6. Cryptographic Functions IANA has, in accordance with [RFC6622], created a new registry for the cryptographic functions, as specified in Section 12 of this document. Initial assignments and allocation policies are specified in Table 5. This registry is unchanged by this specification. +----------------+-----------+--------------------------------------+ | Cryptographic | Algorithm | Description | | Function Value | | | +----------------+-----------+--------------------------------------+ | 0 | none | The "identity function": The value | | | | of an encrypted hash is the hash | | | | itself | | 1 | RSA | [RFC3447] | | 2 | DSA | [NIST-FIPS-186-3] | | 3 | HMAC | [RFC2104] | | 4 | 3DES | [NIST-SP-800-67] | | 5 | AES | [NIST-FIPS-197] | | 6 | ECDSA | [ANSI-X9-62-2005] | | 7-251 | | Unassigned; Expert Review | | 252-255 | | Experimental Use | +----------------+-----------+--------------------------------------+ Table 5: Cryptographic Function Registry Herberg, et al. Expires September 24, 2013 [Page 18] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 14. Security Considerations This document does not specify a protocol. It provides a syntactical component for cryptographic ICVs of messages and packets, as defined in [RFC5444]. It can be used to address security issues of a MANET routing protocol or MANET routing protocol extension. As such, it has the same security considerations as [RFC5444]. In addition, a MANET routing protocol or MANET routing protocol extension that uses this specification MUST specify how to use the framework, and the TLVs presented in this document. In addition, the protection that the MANET routing protocol or MANET routing protocol extensions attain by using this framework MUST be described. As an example, a MANET routing protocol that uses this component to reject "badly formed" or "insecure" messages if a control message does not contain a valid ICV SHOULD indicate the security assumption that if the ICV is valid, the message is considered valid. It also SHOULD indicate the security issues that are counteracted by this measure (e.g., link or identity spoofing) as well as the issues that are not counteracted (e.g., compromised keys). 15. Acknowledgements The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan (Ecole Polytechnique), and Henning Rogge (FGAN) for their constructive comments on [RFC6622]. The authors also appreciate the detailed reviews of [RFC6622] from the Area Directors, in particular Stewart Bryant (Cisco), Stephen Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as well as Donald Eastlake (Huawei) from the Security Directorate. 16. References 16.1. Normative References [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and Herberg, et al. Expires September 24, 2013 [Page 19] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [NIST-FIPS-197] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001. [NIST-FIPS-186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009. [ANSI-X9-62-2005] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-2005, November 2005. [NIST-SP-800-67] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", Special Publication 800-67, May 2004. [NIST-FIPS-180-2] National Institute of Standards and Technology, "Specifications for the Secure Hash Standard", FIPS 180-2, August 2002. [NIST-FIPS-180-2-change] National Institute of Standards and Technology, "Federal Information Processing Standards Publication 180-2 (+ Change Notice to include SHA-224)", Herberg, et al. Expires September 24, 2013 [Page 20] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 FIPS 180-2, August 2002. [IEEE 1003.1-2008 (POSIX)] IEEE Computer Society, "1003.1-2008 Standard for Information Technology - Portable Operating System Interface (POSIX) Base Specifications, Issue 7", December 2008. 16.2. Informative References [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 6622, May 2012. [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", Work in Progress, March 2012. Authors' Addresses Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA 94085 USA EMail: ulrich@herberg.name URI: http://www.herberg.name/ Thomas Heide Clausen LIX, Ecole Polytechnique 91128 Palaiseau Cedex France Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.thomasclausen.org/ Herberg, et al. Expires September 24, 2013 [Page 21] =0C Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Herberg, et al. Expires September 24, 2013 [Page 22] --bcaec554d83279f7a104d8c61c4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Below I have included my comments in-line tagged with JD.  The new TLV=
 
subtype assignment confuses the issue of replacement of 6622.  Are the=
re
situations where ICV TLVs with subtype 1 as defined in 6622 are 

more appropriate?  My guess is No. In any case I shouldn't be guessing,=

so that should be made more clear. 

Replacement of and not just =
extension of 6622 is my largest overarching
issue with the document.  It=
 seems to supersede 6622 in two different ways.

Functionally the definition of a new superior type of TCV TLV depreciatesuse of 6622.  But also in terms of text of usage of the format and TLV ty=
pe.
But 6622 doesn't necessary "break" with the addition o=
f a new superior TCV 

type but its just becomes depreciated.  I can't help but think the docu=
ment
would be much tighter if it worked to augment 6622 instead of repla=
ce, I do
understand the rational for replacement however as reading one =
document is

simpler than two and this one really is more useful.

Despite that an=
d despite the number of comments below 
I do believe that with a few edi=
torial changes the document should be 
moved forward.



Mobile Ad hoc Networking (MANET)                              U. Herberg
Internet-Draft                           Fujitsu Laboratories of America
Obsoletes: 6622 (if approved)                                 T. Clausen
Intended status: Standards Track                LIX, Ecole Polytechnique
Expires: September 24, 2013                                  C. Dearlove
                                                         BAE Systems ATC
                                                          March 23, 2013


          Integrity Check Value and Timestamp TLV Definitions
                  for Mobile Ad Hoc Networks (MANETs)
                    draft-ietf-manet-rfc6622-bis-01

Abstract

   This document extends and replaces RFC 6622.  It describes general
   and flexible TLVs for representing cryptographic Integrity Check
   Values (ICVs) (i.e., digital signatures or Message Authentication
   Codes (MACs)) as well as timestamps, using the generalized Mobile Ad
   Hoc Network (MANET) packet/message format defined in RFC 5444.  It
   defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
   for affixing ICVs and timestamps to a packet, a message, and an
   address, respectively.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at htt=
p://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 24, 2013.

Copyright Notice

   Copyright (c) 2013 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



Herberg, et al.        Expires September 24, 2013               [Page 1]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   (http://trustee.ietf.or=
g/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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Differences from RFC6622 . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   4.  Security Architecture  . . . . . . . . . . . . . . . . . . . .  4
   5.  Overview and Functioning . . . . . . . . . . . . . . . . . . .  5
   6.  General ICV TLV Structure  . . . . . . . . . . . . . . . . . .  6
   7.  General Timestamp TLV Structure  . . . . . . . . . . . . . . .  7
   8.  Packet TLVs  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . .  7
     8.2.  Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . .  8
   9.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Message ICV TLV  . . . . . . . . . . . . . . . . . . . . .  8
     9.2.  Message TIMESTAMP TLV  . . . . . . . . . . . . . . . . . .  9
   10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Address Block ICV TLV  . . . . . . . . . . . . . . . . . .  9
     10.2. Address Block TIMESTAMP TLV  . . . . . . . . . . . . . . .  9
   11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   12. ICV: Hash Function and Cryptographic Function  . . . . . . . . 10
     12.1. General ICV TLV Structure  . . . . . . . . . . . . . . . . 10
       12.1.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . 11
     12.2. Considerations for Calculating the ICV . . . . . . . . . . 11
       12.2.1.  Packet ICV TLV  . . . . . . . . . . . . . . . . . . . 12
       12.2.2.  Message ICV TLV . . . . . . . . . . . . . . . . . . . 12
       12.2.3.  Address Block ICV TLV . . . . . . . . . . . . . . . . 12
     12.3. Example of a Message Including an ICV  . . . . . . . . . . 12
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14
     13.2. Packet TLV Type Registrations  . . . . . . . . . . . . . . 14
     13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15
     13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16
     13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 17
     13.6. Cryptographic Functions  . . . . . . . . . . . . . . . . . 18
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     16.2. Informative References . . . . . . . . . . . . . . . . . . 21



Herberg, et al.        Expires September 24, 2013               [Page 2]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


1.  Introduction

   This document, which extends and replaces [RFC6622], specifies:

JD: This document extends and replaces [RFC6622].  It specifies:

   o  Two TLVs for carrying Integrity Check Values (ICVs) and timestamp=
s
      in packets, messages, and address blocks as defined by [RFC5444].

JD: Two TLV structures; One for carrying Integrity Check Values (ICVs),=

and one for timestamps. TLV type assignments for packet, message and ad=
dress
block TLVs for these structures.

   o  A generic framework for ICVs, accounting (for Message TLVs) for
      mutable message header fields (<msg-hop-limit> and
      <msg-hop-count>), where these fields are present in messages.

   This document retains the IANA registries, defined in [RFC6622], for
   recording code points for hash-functions, cryptographic functions,
   and ICV calculations.  This document requests additional allocations
   from these registries.

   Moreover, in Section 12, this document defines the following:

   o  A method for generating ICVs using a combination of a
      cryptographic function and a hash function.
JD: There is text in section 5 which should be moved to here.

1.1.  Differences from RFC6622

   This document obsoletes [RFC6622].  The changes introduced by this
   document are, however, small.  In addition to editorial updates, this
   document adds a new type extension for the ICV TLV that is specified
   in Section 12 of this document.  The TLV value of a TLV with this
   type extension has the same internal structure as a TLV with type
   extension 1, but is calculated also over the source address of the IP
   datagram carrying the packet, message, or address block.

   The rationale for adding this type extension is that some MANET
   protocols, such as [RFC6130] and [OLSRv2], use the IP source address
   of the IP datagram carrying the packet, message or address block,
   e.g., to identify links with neighbor routers.  If this address is
   not otherwise contained in the packet, message, or address block
   payload (which is permitted, e.g., in [RFC6130]), the address is not
   protected against tampering.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED&quo=
t;, "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", &qu=
ot;NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described=
 in
   [RFC2119].

   This document uses the terminology and notation defined in [RFC5444].
   In particular, the following TLV fields and notation from [RFC5444]



Herberg, et al.        Expires September 24, 2013               [Page 3]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   are used in this specification:

   <msg-hop-limit>  is the hop limit of a message, as specified in
      Section 5.2 of [RFC5444].

   <msg-hop-count>  is the hop count of a message, as specified in
      Section 5.2 of [RFC5444].

   <length>  is the length of the value field in a TLV in octets, as
      specified in Section 5.4.1 of [RFC5444].

   single-length  is the length of a single value in the value field in
      a TLV in octets, as specified in Section 5.4.1 of [RFC5444].  (It
      is equal to <length> except in a multivalue Address Block TLV.)

3.  Applicability Statement

   MANET routing protocols using the format defined in [RFC5444] are
   accorded the ability to carry additional information in control
   messages and packets, through the inclusion of TLVs.  Information so
   included MAY be used by a MANET routing protocol, or by an extension
   of a MANET routing protocol, according to its specification.

   This document specifies how to include an ICV for a packet, a
   message, and addresses in address blocks within a message, using such
   TLVs.  This document also specifies how to treat "mutable" fie=
lds,
   specifically the <msg-hop-count> and <msg-hop-limit> fields,=
 if
   present in the message header when calculating ICVs, such that the
   resulting ICV can be correctly verified by any recipient.

   This document describes a generic framework for creating ICVs, and
   how to include these ICVs in TLVs.  In Section 12, an example method
   for calculating such ICVs is given, using a cryptographic function
   and a hash function.

4.  Security Architecture

   Basic MANET routing protocol specifications are often "oblivious to
   security"; however, they may have a clause allowing a control messa=
ge
   to be rejected as "badly formed" or "insecure" prior=
 to the message
   being processed or forwarded.  In particular, MANET routing protocols
   such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
   Optimized Link State Routing Protocol version 2 [OLSRv2] recognize
   external reasons (such as failure to verify an ICV) for rejecting a
   message that would be considered "invalid for processing".

   This architecture is a result of the observation that with respect to
   security in MANETs, "one size rarely fits all" and that MANET =
routing



Herberg, et al.        Expires September 24, 2013               [Page 4]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   protocol deployment domains have varying security requirements
   ranging from "unbreakable" to "virtually none".  The=
 virtue of this
   approach is that MANET routing protocol specifications (and
   implementations) can remain "generic", with extensions providi=
ng
   proper security mechanisms specific to a deployment domain.

   The MANET routing protocol "security architecture", in which t=
his
   specification situates itself, can therefore be summarized as
   follows:

   o  MANET routing protocol specifications, with a clause allowing an
      extension to reject a message (prior to processing/forwarding) as
      "badly formed" or "insecure".

   o  MANET routing protocol security extensions, rejecting messages as
      "badly formed" or "insecure", as appropriate for =
a given security
      requirement specific to a deployment domain.

   o  Code points and an exchange format for information, necessary for
      specification of such MANET routing protocol security extensions.

   This document addresses the last of the issues listed above by
   specifying a common exchange format for cryptographic ICVs, making
   reservations from within the Packet TLV, Message TLV, and Address
   Block TLV registries of [RFC5444], to be used (and shared) among
   MANET routing protocol security extensions.

   For the specific decomposition of an ICV using a cryptographic
   function and a hash function (specified in Section 12), this document
   reports the two IANA registries from [RFC6622] for code points for
   hash functions and cryptographic functions adhering to [RFC5444].

   With respect to [RFC5444], this document is:

   o  Intended to be used in the non-normative, but intended, mode of
      use described in Appendix B of [RFC5444].

   o  A specific example of the Security Considerations section of
      [RFC5444] (the authentication part).

5.  Overview and Functioning

   This document specifies a syntactical representation of security-
   related information for use with [RFC5444] addresses, messages, and
   packets, and also reports and updates IANA registrations (from
   [RFC6622]) of TLV types and type extension registries for these TLV
   types.



Herberg, et al.        Expires September 24, 2013               [Page 5]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Moreover, this document provides guidelines for how MANET routing
   protocols, and MANET routing protocol extensions using this
   specification, should treat ICV and Timestamp TLVs, and mutable
   fields in messages.  This specification does not represent a stand-
   alone protocol; MANET routing protocols, and MANET routing protocol
   extensions using this specification, MUST provide instructions as to
   how to handle packets, messages, and addresses with security
   information, associated as specified in this document.
JD: The above paragraphs are to me clearer than the introduction on 
wha=
t the goal of this document is.  Specifically the statement 
"This =
specification does not represent a stand alone protocol" should

be much more prominent than it currently is. 

   This document reports previously assigned TLV types (from [RFC6622])
   from the registries defined for Packet, Message, and Address Block
   TLVs in [RFC5444].  When a TLV type is assigned from one of these
   registries, a registry for type extensions for that TLV type is
   created by IANA.  This document reports and updates these type
   extension registries, in order to specify internal structure (and
   accompanying processing) of the <value> field of a TLV.

   For example, and as defined in this document, an ICV TLV with type
   extension =3D 0 specifies that the <value> field has no pre-define=
d
   internal structure but is simply a sequence of octets.  An ICV TLV
   with type extension =3D 1 specifies that the <value> field has a p=
re-
   defined internal structure and defines its interpretation.  An ICV
   TLV with type extension =3D 2 specifies a modified version of this
   definition.  (Specifically, with type extension =3D 1 or type extension
   =3D 2, the <value> field contains the result of combining a
   cryptographic function and a hash function, calculated over the
   contents of the packet, message or address block, with sub-fields
   indicating which hash function and cryptographic function have been
   used; this is specified in Section 12.  The difference between the
   two type extensions is that the ICV TLV with type extension =3D 2 is
   calculated also over the source address of the IP datagram carrying
   the packet, message, or address block.)
JD: Seems long winded without saying very much here.  Should type
extens=
ion 1 still be used?  (No) Will it break anything? (No)

   Other documents can request assignments for other type extensions; if
   they do so, they MUST specify their internal structure (if any) and
   interpretation.

6.  General ICV TLV Structure

   The value of the ICV TLV is:

      <value> :=3D <ICV-value>

   where







Herberg, et al.        Expires September 24, 2013               [Page 6]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   <ICV-value>  is a field, of <length> octets, which contains =
the
      information to be interpreted by the ICV verification process, as
      specified by the type extension.

   Note that this does not stipulate how to calculate the <ICV-value>
   nor the internal structure thereof, if any; such information MUST be
   specified by the type extension for the ICV TLV type; see Section 13.
   This document specifies three such type extensions -- one for ICVs
   without pre-defined structures, and two for ICVs constructed
   combining a cryptographic function and a hash function.

7.  General Timestamp TLV Structure

   The value of the Timestamp TLV is:

      <value> :=3D <time-value>

   where:

   <time-value>  is an unsigned integer field, of length <length&g=
t;, which
      contains the timestamp.

      Note that this does not stipulate how to calculate the
      <time-value> nor the internal structure thereof, if any; such
      information MUST be specified by the type extension for the
      TIMESTAMP TLV type; see Section 13.

   A timestamp is essentially "freshness information".  As such, =
its
   setting and interpretation are to be determined by the MANET routing
   protocol, or MANET routing protocol extension, that uses the
   timestamp and can, for example, correspond to a POSIX timestamp, GPS
   timestamp, or a simple sequence number.
JD: Some mention of difficult=
y of insuring time synchronization across a
MANET and how it's out o=
f scope of this document should be included.
=A08.  Packet TLVs

   Two Packet TLVs are defined: one for including the cryptographic ICV
   of a packet and one for including the timestamp indicating the time
   at which the cryptographic ICV was calculated.

8.1.  Packet ICV TLV

   A Packet ICV TLV is an example of an ICV TLV as described in
   Section 6.

   The following considerations apply:

   o  Because packets as defined in [RFC5444] are never forwarded by
      routers, no special considerations are required regarding mutable



Herberg, et al.        Expires September 24, 2013               [Page 7]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


      fields (e.g., <msg-hop-count> and <msg-hop-limit>), if pr=
esent
      within any messages in the packet, when calculating the ICV.

   o  Any Packet ICV TLVs already present in the Packet TLV block MUST
      be removed before calculating the ICV, and the Packet TLV block
      size MUST be recalculated accordingly.  Removed ICV TLVs MUST be
      restored after having calculated the ICV value.

JD: More clearly specify what "remove" means.  I am assuming =
that the
TLV block size or phastlv bit needs to be updated but that needs to be said=
.

   The rationale for removing any Packet ICV TLV already present p=
rior
   to calculating the ICV is that several ICVs may be added to the same
   packet, e.g., using different ICV functions.

8.2.  Packet TIMESTAMP TLV

   A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described
   in Section 7.  If a packet contains a TIMESTAMP TLV and an ICV TLV,
   the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV,
   in order to include it in the calculation of the ICV.
JD: Shouldn't ALL packet TLVs (which are relevant for the ICV in questi=
on)
other than ones listed as TCV TLVs be added before TCV TLVs are adde=
d?

9.  Message TLVs

   Two Message TLVs are defined: one for including the cryptographic ICV
   of a message and one for including the timestamp indicating the time
   at which the cryptographic ICV was calculated.

9.1.  Message ICV TLV

   A Message ICV TLV is an example of an ICV TLV as described in
   Section 6.  When determining the <ICV-value> for a message, the
   following considerations MUST be applied:

   o  The fields <msg-hop-limit> and <msg-hop-count>, if presen=
t, MUST
      both be assumed to have the value 0 (zero) when calculating the
      ICV.

   o  Any Message ICV TLVs already present in the Message TLV block MUST
      be removed before calculating the ICV, and the message size as
      well as the Message TLV block size MUST be recalculated
      accordingly.  Removed ICV TLVs MUST be restored after having
      calculated the ICV value.
JD: MUST be restored and size fields updated as well.  Also all relevant TLVs other than TCV TLVs must be added prior to TCV value calcuations.  =A0The rationale for removing any Message ICV TLV already present prior
   to calculating the ICV is that several ICVs may be added to the same
   message, e.g., using different ICV functions.







Herberg, et al.        Expires September 24, 2013               [Page 8]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


9.2.  Message TIMESTAMP TLV

   A Message TIMESTAMP TLV is an example of a Timestamp TLV as described
   in Section 7.  If a message contains a TIMESTAMP TLV and an ICV TLV,
   the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV,
   in order to include it in the calculation of the ICV.

10.  Address Block TLVs

   Two Address Block TLVs are defined: one for associating a
   cryptographic ICV to an address and one for including the timestamp
   indicating the time at which the cryptographic ICV was calculated.

10.1.  Address Block ICV TLV

   An Address Block ICV TLV is an example of an ICV TLV as described in
   Section 6.  The ICV is calculated over the address, concatenated with
   any other values -- for example, any other Address Block TLV <value&g=
t;
   fields -- associated with that address.  A MANET routing protocol or
   MANET routing protocol extension using Address Block ICV TLVs MUST
   specify how to include any such concatenated attribute of the address
   in the calculation and verification processes for the ICV.  When
   determining the <ICV-value> for an address, the following
   consideration MUST be applied:

   o  If other TLV values are concatenated with the address for
      calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs
      already associated with the address.

   The rationale for not concatenating the address with any ICV TLV
   values already associated with the address when calculating the ICV
   is that several ICVs may be added to the same address, e.g., using
   different ICV functions.
JD: It may be helpful to point out that a list of TLV values associated
=
with and address will not likely exist as such within a packet.  This TCVis distinct from packet/message TCVs in this regard.

10.2.  Addres=
s Block TIMESTAMP TLV

   An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as
   described in Section 7.  If both a TIMESTAMP TLV and an ICV TLV are
   associated with an address, the TIMESTAMP TLV <value> MUST be cove=
red
   when calculating the value of the ICV to be contained in the ICV TLV
   value (i.e., concatenated with the associated address and any other
   values as described in Section 10.1).

11.  ICV: Basic

   The basic ICV, represented by way of an ICV TLV with type extension =3D
   0, is a simple bit-field containing the cryptographic ICV.  This
   assumes that the mechanism stipulating how ICVs are calculated and



Herberg, et al.        Expires September 24, 2013               [Page 9]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   verified is established outside of this specification, e.g., by way
   of administrative configuration or external out-of-band signaling.
   Thus, the <ICV-value>, when using type extension =3D 0, is

      <ICV-value> :=3D <ICV-data>

   where:

   <ICV-data>  is an unsigned integer field, of length <length>=
, which
      contains the cryptographic ICV.

12.  ICV: Hash Function and Cryptographic Function

   One common way of calculating an ICV is combining a cryptographic
   function and a hash function applied to the content.  This
   decomposition is specified in this section, using either type
   extension =3D 1 or type extension =3D 2, in the ICV TLVs.
JD: nix "using either type extension =3D 1 or type extension =3D 2, in=
 the ICV TLVs"
12.1.  General ICV TLV Structure

   The following data structure allows representation of a cryptographic
   ICV, including specification of the appropriate hash function and
   cryptographic function used for calculating the ICV:

                   <ICV-value> :=3D <hash-function>
                                  <cryptographic-function>
                                  <key-id-length>
                                  <key-id>
                                  <ICV-data>

   where:

   <hash-function>  is an 8-bit unsigned integer field specifying the
      hash function.

   <cryptographic-function>  is an 8-bit unsigned integer field
      specifying the cryptographic function.

   <key-id-length>  is an 8-bit unsigned integer field specifying the
      length of the <key-id> field in number of octets.  The value 0x=
00
      is reserved for using a single pre-installed, shared key.
JD: Functional change suggestion.  Might we reserve a small number of
va=
lues similar to 0 but which may have different as yet to be determined mean=
ings.
For example, use of a key provided out of bound such as a packet l=
evel

"global" for this packet key for message TCV TLVs. Repeatedly pro=
viding a
key seems like it may become cumbersome. 
  =A0<key-id>=
;  is a field specifying the key identifier of the key that
      was used to calculate the ICV of the message, which allows unique
      identification of different keys with the same originator.  It is
      the responsibility of each key originator to make sure that
      actively used keys that it issues have distinct key identifiers.
      If <key-id-length> equals 0x00, the <key-id> field is not



Herberg, et al.        Expires September 24, 2013              [Page 10]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


      contained in the TLV, and a single pre-installed, shared key is
      used.

   <ICV-data>  is an unsigned integer field, whose length is <leng=
th> -
       3 - <key-id-length>, except in a multivslue Address Block TLV,=
 in
      which it is single-length - 3 - <key-id-length>, and which
      contains the cryptographic ICV.

   The version of this TLV, specified in this section, assumes that,
   unless otherwise specified, calculating the ICV can be decomposed
   into:

      ICV-value =3D cryptographic-function(hash-function(content))

   In some cases a different combination of cryptographic function and
   hash function may be specified.  This is the case for the HMAC
   function, which is specified as defined in Section 13.6, using the
   hash function twice.

   The hash function and the cryptographic function correspond to the
   entries in two IANA registries, which are reported by this
   specification and are described in Section 13.

12.1.1.  Rationale

   The rationale for separating the hash function and the cryptographic
   function into two octets instead of having all combinations in a
   single octet -- possibly as a TLV type extension -- is that adding
   further hash functions or cryptographic functions in the future may
   lead to a non-contiguous number space.

   The rationale for not including a field that lists parameters of the
   cryptographic ICV in the TLV is that, before being able to validate a
   cryptographic ICV, routers have to exchange or acquire keys (e.g.,
   public keys).  Any additional parameters can be provided together
   with the keys in that bootstrap process.  It is therefore not
   necessary, and would even entail an extra overhead, to transmit the
   parameters within every message.  One implicitly available parameter
   is the length of an ICV, which is <length> - 3 - <key-id-length=
> (or
   single-length - 3 - <key-id-length> in a multivalue Address Block
   TLV) and which depends on the choice of the cryptographic function.

12.2.  Considerations for Calculating the ICV

   The considerations listed in the following subsections MUST be
   applied when calculating the ICV for Packet, Message, and Address
   Block ICV TLVs, respectively.




Herberg, et al.        Expires September 24, 2013              [Page 11]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


12.2.1.  Packet ICV TLV

   When determining the <ICV-value> for a packet, with type extension=
 =3D
   1, the ICV is calculated over the fields <hash-function>,
   <cryptographic-function>, <key-id-length>, and -- if present=
 --
   <key-id> (in that order), concatenated with the entire packet,
   including the packet header, all Packet TLVs (other than Packet ICV
   TLVs), and all included Messages and their message headers, in
   accordance with Section 8.1.  When determining the <ICV-value> for=
 a
   packet, with type extension =3D 2, the same procedure is used, except
   that the source address of the IP datagram carrying the packet is
   also concatenated, in the first position, with the data used.
JD: don't use concatenated use proceded by or followed by. Might also <=
br>mention network byte ordering issues as at this point we are dealing wit=
h
packets.

12.2.2.  Message ICV TLV

   When determining the <ICV-value> for a message, with type extensio=
n =3D
   1, the ICV is calculated over the fields <hash-function>,
   <cryptographic-function>, <key-id-length>, and -- if present=
 --
   <key-id> (in that order), concatenated with the entire message.  T=
he
   considerations in Section 9.1 MUST be applied.  When determining the
   <ICV-value> for a message, with type extension =3D 2, the same
   procedure is used, except that the source address of the IP datagram
   carrying the message is also concatenated, in the first position,
   with the data used.

12.2.3.  Address Block ICV TLV

   When determining the <ICV-value> for an address, block, with type
   extension =3D 2, the ICV is calculated over the fields <hash-function=
>,
   <cryptographic-function>, <key-id-length>, and -- if present=
 --
   <key-id> (in that order), concatenated with the address, and
   concatenated with any other values -- for example, any other address
   block TLV <value> that is associated with that address.  A MANET
   routing protocol or MANET routing protocol extension using Address
   Block ICV TLVs MUST specify how to include any such concatenated
   attribute of the address in the verification process of the ICV.  The
   considerations in Section 10.1 MUST be applied.  When determining the
   <ICV-value> for an address block, with type extension =3D 2, the s=
ame
   procedure is used, except that the source address of the IP datagram
   carrying the address block is also concatenated, in the first
   position, with the data used.
JD: Typo first mention of type extension =3D 2 should be =3D1. Seems likewe should be able to specify a generalized method for including the value=
s.
Why not just specify that all address tlv type/value pairs associated=
 with an

address be included in order type.subtype order? Punting is fine but I don&=
#39;t
see why it needs to be done.
12.3.  Example of a Message Includ=
ing an ICV

   The sample message depicted in Figure 1 is derived from Appendix D of
   [RFC5444].  The message contains an ICV Message TLV, with the value
   representing an ICV that is 16 octets long of the whole message, and
   a key identifier that is 4 octets long.  The type extension of the



Herberg, et al.        Expires September 24, 2013              [Page 12]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Message TLV is 1, for the specific decomposition of an ICV using a
   cryptographic function and a hash function, as specified in
   Section 12.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=3D0 |  PF=3D8  |    Packet Sequence Number     | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MF=3D15 | MAL=3D3 |      Message Length =3D 44      | Msg Orig Addr =
|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Message Originator Address (cont)       |   Hop Limit   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |    Message Sequence Number    | Msg TLV Block |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length =3D 27   |     ICV       |  MTLVF =3D 144  |  MTLVExt =3D 1  =
|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Value Len =3D 23 |   Hash Func   |  Crypto Func  |Key ID length=3D4|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Key Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Example Message with ICV

JD: Shouldn't we change this to type =3D 2 as that is the only "ne=
w" thing
this document is specifying and encouraging?  Structure sh=
ould stay the
same.

13.  IANA Considerations

   This specification reports the following, originally specified in
   [RFC6622]:

   o  Two Packet TLV types, which have been allocated from the 0-223
      range of the "Packet TLV Types" repository of [RFC5444], as
      specified in Table 1.

   o  Two Message TLV types, which have been allocated from the 0-127
      range of the "Message TLV Types" repository of [RFC5444], a=
s
      specified in Table 2.

   o  Two Address Block TLV types, which have been allocated from the
      0-127 range of the "Address Block TLV Types" repository of
      [RFC5444], as specified in Table 3.



Herberg, et al.        Expires September 24, 2013              [Page 13]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   This specification updates the following, created in [RFC6622]:

   o  A type extension registry for each of these TLV types with values
      as listed in Tables 1, 2, and 3.

   The following terms are used as defined in [BCP26]: "Namespace"=
;,
   "Registration", and "Designated Expert".

   The following policy is used as defined in [BCP26]: "Expert Review&=
quot;.

13.1.  Expert Review: Evaluation Guidelines

   For TLV type extensions registries where an Expert Review is
   required, the Designated Expert SHOULD take the same general
   recommendations into consideration as those specified by [RFC5444].

   For the Timestamp TLV, the same type extensions for all Packet,
   Message, and Address Block TLVs SHOULD be numbered identically.

13.2.  Packet TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs
   specified in Table 1.  IANA are requested to modify this allocation
   (defining type extension =3D 2) as indicated.


























Herberg, et al.        Expires September 24, 2013              [Page 14]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |           ICV of a packet          |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           | field.  The MANET routing protocol |
   |           |      |           |   has to define how to interpret   |
   |           |      |           |           this timestamp           |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

JD: Mostly a style thing but dislike how 1-2 are included together. Suggest separating them out and indicating the difference 
(source IP a=
ddress used).  Same suggestion for other IANA tables.
                  =
=A0Table 1: Packet TLV Types

   More than one ICV Packet TLV with the same type extension MAY be
   included in a packet if these represent different ICV calculations
   (e.g., with type extension 1 or 2 and different cryptographic
   function and/or hash function, or with a different key identifier).
   ICV Packet TLVs that carry what is declared to be the same
   information MUST NOT be included in the same packet.

13.3.  Message TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Message TLV Types" namespace of [RFC5444] for the Message TLV=
s
   specified in Table 2.  IANA are requested to modify this allocation
   (defining type extension =3D 2) as indicated.







Herberg, et al.        Expires September 24, 2013              [Page 15]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |          ICV of a message          |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           |               field.               |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

                        Table 2: Message TLV Types

   More than one ICV Message TLV with the same type extension MAY be
   included in a message if these represent different ICV calculations
   (e.g., with type extension 1 or 2 and different cryptographic
   function and/or hash function, or with a different key identifier).
   ICV Message TLVs that carry what is declared to be the same
   information MUST NOT be included in the same message.

13.4.  Address Block TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Address Block TLV Types" namespace of [RFC5444] for the Packe=
t TLVs
   specified in Table 3.  IANA are requested to modify this allocation
   (defining type extension =3D 2) as indicated.









Herberg, et al.        Expires September 24, 2013              [Page 16]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |     ICV of an object (e.g., an     |
   |           |      |           |              address)              |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           |                field               |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

                     Table 3: Address Block TLV Types

   More than one ICV Address Block TLV with the same type extension MAY
   be associated with an address if these represent different ICV
   calculations (e.g., with type extension 1 or 2 and different
   cryptographic function and/or hash function, or with a different key
   identifier).  ICV Address Block TLVs that carry what is declared to
   be the same information MUST NOT be associated with the same address.

13.5.  Hash Functions

   IANA has, in accordance with [RFC6622], created a new registry for
   hash functions that can be used when creating an ICV, as specified in
   Section 12 of this document.  The initial assignments and allocation
   policies are specified in Table 4.  This registry is unchanged by
   this specification.







Herberg, et al.        Expires September 24, 2013              [Page 17]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-------------+-----------+-----------------------------------------+
   |     Hash    | Algorithm |               Description               |
   |   Function  |           |                                         |
   |    Value    |           |                                         |
   +-------------+-----------+-----------------------------------------+
   |      0      |    none   | The "identity function": The hash =
value |
   |             |           |    of an object is the object itself    |
   |      1      |    SHA1   |            [NIST-FIPS-180-2]            |
   |      2      |   SHA224  |         [NIST-FIPS-180-2-change]        |
   |      3      |   SHA256  |            [NIST-FIPS-180-2]            |
   |      4      |   SHA384  |            [NIST-FIPS-180-2]            |
   |      5      |   SHA512  |            [NIST-FIPS-180-2]            |
   |    6-251    |           |        Unassigned; Expert Review        |
   |   252-255   |           |             Experimental Use            |
   +-------------+-----------+-----------------------------------------+

                      Table 4: Hash Function Registry

13.6.  Cryptographic Functions

   IANA has, in accordance with [RFC6622], created a new registry for
   the cryptographic functions, as specified in Section 12 of this
   document.  Initial assignments and allocation policies are specified
   in Table 5.  This registry is unchanged by this specification.

   +----------------+-----------+--------------------------------------+
   |  Cryptographic | Algorithm |              Description             |
   | Function Value |           |                                      |
   +----------------+-----------+--------------------------------------+
   |        0       |    none   |  The "identity function": The v=
alue  |
   |                |           |   of an encrypted hash is the hash   |
   |                |           |                itself                |
   |        1       |    RSA    |               [RFC3447]              |
   |        2       |    DSA    |           [NIST-FIPS-186-3]          |
   |        3       |    HMAC   |               [RFC2104]              |
   |        4       |    3DES   |           [NIST-SP-800-67]           |
   |        5       |    AES    |            [NIST-FIPS-197]           |
   |        6       |   ECDSA   |           [ANSI-X9-62-2005]          |
   |      7-251     |           |       Unassigned; Expert Review      |
   |     252-255    |           |           Experimental Use           |
   +----------------+-----------+--------------------------------------+

                 Table 5: Cryptographic Function Registry





Herberg, et al.        Expires September 24, 2013              [Page 18]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


14.  Security Considerations

   This document does not specify a protocol.  It provides a syntactical
   component for cryptographic ICVs of messages and packets, as defined
   in [RFC5444].  It can be used to address security issues of a MANET
   routing protocol or MANET routing protocol extension.  As such, it
   has the same security considerations as [RFC5444].

   In addition, a MANET routing protocol or MANET routing protocol
   extension that uses this specification MUST specify how to use the
   framework, and the TLVs presented in this document.  In addition, the
   protection that the MANET routing protocol or MANET routing protocol
   extensions attain by using this framework MUST be described.

   As an example, a MANET routing protocol that uses this component to
   reject "badly formed" or "insecure" messages if a co=
ntrol message
   does not contain a valid ICV SHOULD indicate the security assumption
   that if the ICV is valid, the message is considered valid.  It also
   SHOULD indicate the security issues that are counteracted by this
   measure (e.g., link or identity spoofing) as well as the issues that
   are not counteracted (e.g., compromised keys).

15.  Acknowledgements

   The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE
   Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan
   (Ecole Polytechnique), and Henning Rogge (FGAN) for their
   constructive comments on [RFC6622].

   The authors also appreciate the detailed reviews of [RFC6622] from
   the Area Directors, in particular Stewart Bryant (Cisco), Stephen
   Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as
   well as Donald Eastlake (Huawei) from the Security Directorate.

16.  References

16.1.  Normative References

   [BCP26]                     Narten, T. and H. Alvestrand, "Guidelin=
es
                               for Writing an IANA Considerations
                               Section in RFCs", BCP 26, RFC 5226,
                               May 2008.

   [RFC2119]                   Bradner, S., "Key words for use in RFCs
                               to Indicate Requirement Levels", BCP 14=
,
                               RFC 2119, March 1997.

   [RFC5444]                   Clausen, T., Dearlove, C., Dean, J., and



Herberg, et al.        Expires September 24, 2013              [Page 19]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


                               C. Adjih, "Generalized Mobile Ad Hoc
                               Network (MANET) Packet/Message Format",
                               RFC 5444, February 2009.

   [RFC5905]                   Mills, D., Martin, J., Ed., Burbank, J.,
                               and W. Kasch, "Network Time Protocol
                               Version 4: Protocol and Algorithms
                               Specification", RFC 5905, June 2010.

   [RFC3447]                   Jonsson, J. and B. Kaliski, "Public-Key
                               Cryptography Standards (PKCS) #1: RSA
                               Cryptography Specifications Version 2.1"=
;,
                               RFC 3447, February 2003.

   [RFC2104]                   Krawczyk, H., Bellare, M., and R.
                               Canetti, "HMAC: Keyed-Hashing for Messa=
ge
                               Authentication", RFC 2104, February 199=
7.

   [NIST-FIPS-197]             National Institute of Standards and
                               Technology, "Specification for the
                               Advanced Encryption Standard (AES)",
                               FIPS 197, November 2001.

   [NIST-FIPS-186-3]           National Institute of Standards and
                               Technology, "Digital Signature Standard
                               (DSS)", FIPS 186-3, June 2009.

   [ANSI-X9-62-2005]           American National Standards Institute,
                               "Public Key Cryptography for the
                               Financial Services Industry: The Elliptic
                               Curve Digital Signature Algorithm
                               (ECDSA)", ANSI X9.62-2005, November 200=
5.

   [NIST-SP-800-67]            National Institute of Standards and
                               Technology, "Recommendation for the
                               Triple Data Encryption Algorithm
                               (TDEA) Block Cipher", Special
                               Publication 800-67, May 2004.

   [NIST-FIPS-180-2]           National Institute of Standards and
                               Technology, "Specifications for the
                               Secure Hash Standard", FIPS 180-2,
                               August 2002.

   [NIST-FIPS-180-2-change]    National Institute of Standards and
                               Technology, "Federal Information
                               Processing Standards Publication 180-2 (+
                               Change Notice to include SHA-224)",



Herberg, et al.        Expires September 24, 2013              [Page 20]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


                               FIPS 180-2, August 2002.

   [IEEE 1003.1-2008 (POSIX)]  IEEE Computer Society, "1003.1-2008
                               Standard for Information Technology -
                               Portable Operating System Interface
                               (POSIX) Base Specifications, Issue 7",
                               December 2008.

16.2.  Informative References

   [RFC6130]                   Clausen, T., Dearlove, C., and J. Dean,
                               "Mobile Ad Hoc Network (MANET)
                               Neighborhood Discovery Protocol (NHDP)"=
,
                               RFC 6130, April 2011.

   [RFC6622]                   Herberg, U. and T. Clausen, "Integrity
                               Check Value and Timestamp TLV Definitions
                               for Mobile Ad Hoc Networks (MANETs)",
                               RFC 6622, May 2012.

   [OLSRv2]                    Clausen, T., Dearlove, C., Jacquet, P.,
                               and U. Herberg, "The Optimized Link Sta=
te
                               Routing Protocol version 2", Work
                               in Progress, March 2012.

Authors' Addresses

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E. Arques Ave.
   Sunnyvale, CA  94085
   USA

   EMail: ulrich@herberg.name
   URI:   http://www.herberg.name/


   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex
   France

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org<=
/a>
   URI:   http://www.thomasclause=
n.org/






Herberg, et al.        Expires September 24, 2013              [Page 21]
=0C
Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Christopher Dearlove
   BAE Systems Advanced Technology Centre
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

   Phone: +44 1245 242194
   EMail: chris.dearlove@b=
aesystems.com
   URI:   http://www.baesystems.com/=











































Herberg, et al.        Expires September 24, 2013              [Page 22]
=0C
--bcaec554d83279f7a104d8c61c4a-- From christopher.dearlove@googlemail.com Mon Mar 25 15:21:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6821F86F7 for ; Mon, 25 Mar 2013 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.885 X-Spam-Level: X-Spam-Status: No, score=0.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZXz2i5yC+kt for ; Mon, 25 Mar 2013 15:21:12 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 77DC121F8881 for ; Mon, 25 Mar 2013 15:21:11 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so2665757wid.11 for ; Mon, 25 Mar 2013 15:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=MUc6kTLPB5YKM8GNWqq5dHsVQ12kt7i3oc4MoS0E7AY=; b=GuoxBeih8RhKAkR37aOXoprbbBbbKQ5oqacyaopfaLlUlEBvdVw+cMQZ/9nvtGWKYl yL04Ms5vAsSokBXGKWD1wo2fs/BxsbIQsu6LFONMMhtrMgLouFezz0fHaB9nq5qg6waE 4o7+0QF/0CAVV7rMqJ0pWlGQ71PULUn84TJS1s9oELzTwo0kVmLzpCQtOVOZQ+J0GCvI SLG57UqT3PZ1jWgfToXQOUY6Li3Rq+I6zMqBGTxKa7LkfBrFnPaLvDixaI7fP0u5TVXw Nj7+QDT4sl6AyYBgkrc0Ml99Zc7xNNChpOsjZeZwaWhD2jc/bhTcXOZJpmUJEFuP73Bo t0zw== X-Received: by 10.194.81.40 with SMTP id w8mr20824799wjx.14.1364250070593; Mon, 25 Mar 2013 15:21:10 -0700 (PDT) Received: from [192.168.0.103] (host217-34-193-60.in-addr.btopenworld.com. [217.34.193.60]) by mx.google.com with ESMTPS id dm9sm30697129wib.3.2013.03.25.15.21.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:21:09 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-4--604169073 Message-Id: <67C015F6-19DE-4A72-887B-C7E78131E0BA@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Mon, 25 Mar 2013 22:21:21 +0000 To: Justin Dean Cc: "manet@ietf.org" Subject: Re: [manet] rfc6622-bis-01 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:21:18 -0000 --Apple-Mail-4--604169073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To take my last comment further, I don't agree it's the job of this document= to describe when to use what. If one one should be used, we'd have said so.= The fact that both are included indicates both are available. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 25 Mar 2013, at 21:01, Justin Dean wrote: > Below I have included my comments in-line tagged with JD. The new TLV=20 > subtype assignment confuses the issue of replacement of 6622. Are there > situations where ICV TLVs with subtype 1 as defined in 6622 are=20 >=20 > more appropriate? My guess is No. In any case I shouldn't be guessing, > so that should be made more clear.=20 >=20 > Replacement of and not just extension of 6622 is my largest overarching > issue with the document. It seems to supersede 6622 in two different ways= . >=20 > Functionally the definition of a new superior type of TCV TLV depreciates > use of 6622. But also in terms of text of usage of the format and TLV typ= e. > But 6622 doesn't necessary "break" with the addition of a new superior TCV= =20 >=20 > type but its just becomes depreciated. I can't help but think the documen= t > would be much tighter if it worked to augment 6622 instead of replace, I d= o > understand the rational for replacement however as reading one document is= >=20 > simpler than two and this one really is more useful. >=20 > Despite that and despite the number of comments below=20 > I do believe that with a few editorial changes the document should be=20 > moved forward. >=20 >=20 >=20 > Mobile Ad hoc Networking (MANET) U. Herberg > Internet-Draft Fujitsu Laboratories of America > Obsoletes: 6622 (if approved) T. Clausen > Intended status: Standards Track LIX, Ecole Polytechnique > Expires: September 24, 2013 C. Dearlove > BAE Systems ATC > March 23, 2013 >=20 >=20 > Integrity Check Value and Timestamp TLV Definitions > for Mobile Ad Hoc Networks (MANETs) > draft-ietf-manet-rfc6622-bis-01 >=20 > Abstract >=20 > This document extends and replaces RFC 6622. It describes general > and flexible TLVs for representing cryptographic Integrity Check > Values (ICVs) (i.e., digital signatures or Message Authentication > Codes (MACs)) as well as timestamps, using the generalized Mobile Ad > Hoc Network (MANET) packet/message format defined in RFC 5444. It > defines two Packet TLVs, two Message TLVs, and two Address Block TLVs > for affixing ICVs and timestamps to a packet, a message, and an > address, respectively. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > 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." >=20 > This Internet-Draft will expire on September 24, 2013. >=20 > Copyright Notice >=20 > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 1] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > (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 Simplified BSD License. >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 > 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 > 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 5 > 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 6 > 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 7 > 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 8.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . . 7 > 8.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 8 > 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 9.1. Message ICV TLV . . . . . . . . . . . . . . . . . . . . . 8 > 9.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 9 > 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 9 > 10.1. Address Block ICV TLV . . . . . . . . . . . . . . . . . . 9 > 10.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 9 > 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 10 > 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 10 > 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 > 12.2. Considerations for Calculating the ICV . . . . . . . . . . 11 > 12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 12 > 12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 12 > 12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 12 > 12.3. Example of a Message Including an ICV . . . . . . . . . . 12 > 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14 > 13.2. Packet TLV Type Registrations . . . . . . . . . . . . . . 14 > 13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15 > 13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16 > 13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 17 > 13.6. Cryptographic Functions . . . . . . . . . . . . . . . . . 18 > 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 > 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 > 16.2. Informative References . . . . . . . . . . . . . . . . . . 21 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 2] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > 1. Introduction >=20 > This document, which extends and replaces [RFC6622], specifies: >=20 > JD: This document extends and replaces [RFC6622]. It specifies: >=20 > o Two TLVs for carrying Integrity Check Values (ICVs) and timestamps > in packets, messages, and address blocks as defined by [RFC5444]. >=20 > JD: Two TLV structures; One for carrying Integrity Check Values (ICVs), > and one for timestamps. TLV type assignments for packet, message and addre= ss > block TLVs for these structures. >=20 > o A generic framework for ICVs, accounting (for Message TLVs) for > mutable message header fields ( and > ), where these fields are present in messages. >=20 > This document retains the IANA registries, defined in [RFC6622], for > recording code points for hash-functions, cryptographic functions, > and ICV calculations. This document requests additional allocations > from these registries. >=20 > Moreover, in Section 12, this document defines the following: >=20 > o A method for generating ICVs using a combination of a > cryptographic function and a hash function. > JD: There is text in section 5 which should be moved to here. >=20 > 1.1. Differences from RFC6622 >=20 > This document obsoletes [RFC6622]. The changes introduced by this > document are, however, small. In addition to editorial updates, this > document adds a new type extension for the ICV TLV that is specified > in Section 12 of this document. The TLV value of a TLV with this > type extension has the same internal structure as a TLV with type > extension 1, but is calculated also over the source address of the IP > datagram carrying the packet, message, or address block. >=20 > The rationale for adding this type extension is that some MANET > protocols, such as [RFC6130] and [OLSRv2], use the IP source address > of the IP datagram carrying the packet, message or address block, > e.g., to identify links with neighbor routers. If this address is > not otherwise contained in the packet, message, or address block > payload (which is permitted, e.g., in [RFC6130]), the address is not > protected against tampering. >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. >=20 > This document uses the terminology and notation defined in [RFC5444]. > In particular, the following TLV fields and notation from [RFC5444] >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 3] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > are used in this specification: >=20 > is the hop limit of a message, as specified in > Section 5.2 of [RFC5444]. >=20 > is the hop count of a message, as specified in > Section 5.2 of [RFC5444]. >=20 > is the length of the value field in a TLV in octets, as > specified in Section 5.4.1 of [RFC5444]. >=20 > single-length is the length of a single value in the value field in > a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (It > is equal to except in a multivalue Address Block TLV.) >=20 > 3. Applicability Statement >=20 > MANET routing protocols using the format defined in [RFC5444] are > accorded the ability to carry additional information in control > messages and packets, through the inclusion of TLVs. Information so > included MAY be used by a MANET routing protocol, or by an extension > of a MANET routing protocol, according to its specification. >=20 > This document specifies how to include an ICV for a packet, a > message, and addresses in address blocks within a message, using such > TLVs. This document also specifies how to treat "mutable" fields, > specifically the and fields, if > present in the message header when calculating ICVs, such that the > resulting ICV can be correctly verified by any recipient. >=20 > This document describes a generic framework for creating ICVs, and > how to include these ICVs in TLVs. In Section 12, an example method > for calculating such ICVs is given, using a cryptographic function > and a hash function. >=20 > 4. Security Architecture >=20 > Basic MANET routing protocol specifications are often "oblivious to > security"; however, they may have a clause allowing a control message > to be rejected as "badly formed" or "insecure" prior to the message > being processed or forwarded. In particular, MANET routing protocols > such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the > Optimized Link State Routing Protocol version 2 [OLSRv2] recognize > external reasons (such as failure to verify an ICV) for rejecting a > message that would be considered "invalid for processing". >=20 > This architecture is a result of the observation that with respect to > security in MANETs, "one size rarely fits all" and that MANET routing >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 4] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > protocol deployment domains have varying security requirements > ranging from "unbreakable" to "virtually none". The virtue of this > approach is that MANET routing protocol specifications (and > implementations) can remain "generic", with extensions providing > proper security mechanisms specific to a deployment domain. >=20 > The MANET routing protocol "security architecture", in which this > specification situates itself, can therefore be summarized as > follows: >=20 > o MANET routing protocol specifications, with a clause allowing an > extension to reject a message (prior to processing/forwarding) as > "badly formed" or "insecure". >=20 > o MANET routing protocol security extensions, rejecting messages as > "badly formed" or "insecure", as appropriate for a given security > requirement specific to a deployment domain. >=20 > o Code points and an exchange format for information, necessary for > specification of such MANET routing protocol security extensions. >=20 > This document addresses the last of the issues listed above by > specifying a common exchange format for cryptographic ICVs, making > reservations from within the Packet TLV, Message TLV, and Address > Block TLV registries of [RFC5444], to be used (and shared) among > MANET routing protocol security extensions. >=20 > For the specific decomposition of an ICV using a cryptographic > function and a hash function (specified in Section 12), this document > reports the two IANA registries from [RFC6622] for code points for > hash functions and cryptographic functions adhering to [RFC5444]. >=20 > With respect to [RFC5444], this document is: >=20 > o Intended to be used in the non-normative, but intended, mode of > use described in Appendix B of [RFC5444]. >=20 > o A specific example of the Security Considerations section of > [RFC5444] (the authentication part). >=20 > 5. Overview and Functioning >=20 > This document specifies a syntactical representation of security- > related information for use with [RFC5444] addresses, messages, and > packets, and also reports and updates IANA registrations (from > [RFC6622]) of TLV types and type extension registries for these TLV > types. >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 5] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > Moreover, this document provides guidelines for how MANET routing > protocols, and MANET routing protocol extensions using this > specification, should treat ICV and Timestamp TLVs, and mutable > fields in messages. This specification does not represent a stand- > alone protocol; MANET routing protocols, and MANET routing protocol > extensions using this specification, MUST provide instructions as to > how to handle packets, messages, and addresses with security > information, associated as specified in this document. > JD: The above paragraphs are to me clearer than the introduction on=20 > what the goal of this document is. Specifically the statement=20 > "This specification does not represent a stand alone protocol" should >=20 > be much more prominent than it currently is.=20 >=20 > This document reports previously assigned TLV types (from [RFC6622]) > from the registries defined for Packet, Message, and Address Block > TLVs in [RFC5444]. When a TLV type is assigned from one of these > registries, a registry for type extensions for that TLV type is > created by IANA. This document reports and updates these type > extension registries, in order to specify internal structure (and > accompanying processing) of the field of a TLV. >=20 > For example, and as defined in this document, an ICV TLV with type > extension =3D 0 specifies that the field has no pre-defined > internal structure but is simply a sequence of octets. An ICV TLV > with type extension =3D 1 specifies that the field has a pre- > defined internal structure and defines its interpretation. An ICV > TLV with type extension =3D 2 specifies a modified version of this > definition. (Specifically, with type extension =3D 1 or type extension= > =3D 2, the field contains the result of combining a > cryptographic function and a hash function, calculated over the > contents of the packet, message or address block, with sub-fields > indicating which hash function and cryptographic function have been > used; this is specified in Section 12. The difference between the > two type extensions is that the ICV TLV with type extension =3D 2 is > calculated also over the source address of the IP datagram carrying > the packet, message, or address block.) > JD: Seems long winded without saying very much here. Should type > extension 1 still be used? (No) Will it break anything? (No) >=20 > Other documents can request assignments for other type extensions; if > they do so, they MUST specify their internal structure (if any) and > interpretation. >=20 > 6. General ICV TLV Structure >=20 > The value of the ICV TLV is: >=20 > :=3D >=20 > where >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 6] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > is a field, of octets, which contains the > information to be interpreted by the ICV verification process, as > specified by the type extension. >=20 > Note that this does not stipulate how to calculate the > nor the internal structure thereof, if any; such information MUST be > specified by the type extension for the ICV TLV type; see Section 13. > This document specifies three such type extensions -- one for ICVs > without pre-defined structures, and two for ICVs constructed > combining a cryptographic function and a hash function. >=20 > 7. General Timestamp TLV Structure >=20 > The value of the Timestamp TLV is: >=20 > :=3D >=20 > where: >=20 > is an unsigned integer field, of length , which > contains the timestamp. >=20 > Note that this does not stipulate how to calculate the > nor the internal structure thereof, if any; such > information MUST be specified by the type extension for the > TIMESTAMP TLV type; see Section 13. >=20 > A timestamp is essentially "freshness information". As such, its > setting and interpretation are to be determined by the MANET routing > protocol, or MANET routing protocol extension, that uses the > timestamp and can, for example, correspond to a POSIX timestamp, GPS > timestamp, or a simple sequence number. > JD: Some mention of difficulty of insuring time synchronization across a > MANET and how it's out of scope of this document should be included. > 8. Packet TLVs >=20 > Two Packet TLVs are defined: one for including the cryptographic ICV > of a packet and one for including the timestamp indicating the time > at which the cryptographic ICV was calculated. >=20 > 8.1. Packet ICV TLV >=20 > A Packet ICV TLV is an example of an ICV TLV as described in > Section 6. >=20 > The following considerations apply: >=20 > o Because packets as defined in [RFC5444] are never forwarded by > routers, no special considerations are required regarding mutable >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 7] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > fields (e.g., and ), if present > within any messages in the packet, when calculating the ICV. >=20 > o Any Packet ICV TLVs already present in the Packet TLV block MUST > be removed before calculating the ICV, and the Packet TLV block > size MUST be recalculated accordingly. Removed ICV TLVs MUST be > restored after having calculated the ICV value. >=20 > JD: More clearly specify what "remove" means. I am assuming that the > TLV block size or phastlv bit needs to be updated but that needs to be sai= d. >=20 > The rationale for removing any Packet ICV TLV already present prior > to calculating the ICV is that several ICVs may be added to the same > packet, e.g., using different ICV functions. >=20 > 8.2. Packet TIMESTAMP TLV >=20 > A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described > in Section 7. If a packet contains a TIMESTAMP TLV and an ICV TLV, > the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV, > in order to include it in the calculation of the ICV. > JD: Shouldn't ALL packet TLVs (which are relevant for the ICV in question)= > other than ones listed as TCV TLVs be added before TCV TLVs are added? >=20 > 9. Message TLVs >=20 > Two Message TLVs are defined: one for including the cryptographic ICV > of a message and one for including the timestamp indicating the time > at which the cryptographic ICV was calculated. >=20 > 9.1. Message ICV TLV >=20 > A Message ICV TLV is an example of an ICV TLV as described in > Section 6. When determining the for a message, the > following considerations MUST be applied: >=20 > o The fields and , if present, MUST > both be assumed to have the value 0 (zero) when calculating the > ICV. >=20 > o Any Message ICV TLVs already present in the Message TLV block MUST > be removed before calculating the ICV, and the message size as > well as the Message TLV block size MUST be recalculated > accordingly. Removed ICV TLVs MUST be restored after having > calculated the ICV value. > JD: MUST be restored and size fields updated as well. Also all relevant=20= > TLVs other than TCV TLVs must be added prior to TCV value calcuations. > The rationale for removing any Message ICV TLV already present prior > to calculating the ICV is that several ICVs may be added to the same > message, e.g., using different ICV functions. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 8] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > 9.2. Message TIMESTAMP TLV >=20 > A Message TIMESTAMP TLV is an example of a Timestamp TLV as described > in Section 7. If a message contains a TIMESTAMP TLV and an ICV TLV, > the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV, > in order to include it in the calculation of the ICV. >=20 > 10. Address Block TLVs >=20 > Two Address Block TLVs are defined: one for associating a > cryptographic ICV to an address and one for including the timestamp > indicating the time at which the cryptographic ICV was calculated. >=20 > 10.1. Address Block ICV TLV >=20 > An Address Block ICV TLV is an example of an ICV TLV as described in > Section 6. The ICV is calculated over the address, concatenated with > any other values -- for example, any other Address Block TLV > fields -- associated with that address. A MANET routing protocol or > MANET routing protocol extension using Address Block ICV TLVs MUST > specify how to include any such concatenated attribute of the address > in the calculation and verification processes for the ICV. When > determining the for an address, the following > consideration MUST be applied: >=20 > o If other TLV values are concatenated with the address for > calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs > already associated with the address. >=20 > The rationale for not concatenating the address with any ICV TLV > values already associated with the address when calculating the ICV > is that several ICVs may be added to the same address, e.g., using > different ICV functions. > JD: It may be helpful to point out that a list of TLV values associated > with and address will not likely exist as such within a packet. This TCV > is distinct from packet/message TCVs in this regard. >=20 > 10.2. Address Block TIMESTAMP TLV >=20 > An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as > described in Section 7. If both a TIMESTAMP TLV and an ICV TLV are > associated with an address, the TIMESTAMP TLV MUST be covered > when calculating the value of the ICV to be contained in the ICV TLV > value (i.e., concatenated with the associated address and any other > values as described in Section 10.1). >=20 > 11. ICV: Basic >=20 > The basic ICV, represented by way of an ICV TLV with type extension =3D= > 0, is a simple bit-field containing the cryptographic ICV. This > assumes that the mechanism stipulating how ICVs are calculated and >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 9] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > verified is established outside of this specification, e.g., by way > of administrative configuration or external out-of-band signaling. > Thus, the , when using type extension =3D 0, is >=20 > :=3D >=20 > where: >=20 > is an unsigned integer field, of length , which > contains the cryptographic ICV. >=20 > 12. ICV: Hash Function and Cryptographic Function >=20 > One common way of calculating an ICV is combining a cryptographic > function and a hash function applied to the content. This > decomposition is specified in this section, using either type > extension =3D 1 or type extension =3D 2, in the ICV TLVs. > JD: nix "using either type extension =3D 1 or type extension =3D 2, in the= ICV TLVs" > 12.1. General ICV TLV Structure >=20 > The following data structure allows representation of a cryptographic > ICV, including specification of the appropriate hash function and > cryptographic function used for calculating the ICV: >=20 > :=3D > > > > >=20 > where: >=20 > is an 8-bit unsigned integer field specifying the > hash function. >=20 > is an 8-bit unsigned integer field > specifying the cryptographic function. >=20 > is an 8-bit unsigned integer field specifying the > length of the field in number of octets. The value 0x00 > is reserved for using a single pre-installed, shared key. > JD: Functional change suggestion. Might we reserve a small number of > values similar to 0 but which may have different as yet to be determined m= eanings. > For example, use of a key provided out of bound such as a packet level >=20 > "global" for this packet key for message TCV TLVs. Repeatedly providing a > key seems like it may become cumbersome.=20 > is a field specifying the key identifier of the key that > was used to calculate the ICV of the message, which allows unique > identification of different keys with the same originator. It is > the responsibility of each key originator to make sure that > actively used keys that it issues have distinct key identifiers. > If equals 0x00, the field is not >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 10] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > contained in the TLV, and a single pre-installed, shared key is > used. >=20 > is an unsigned integer field, whose length is - > 3 - , except in a multivslue Address Block TLV, in > which it is single-length - 3 - , and which > contains the cryptographic ICV. >=20 > The version of this TLV, specified in this section, assumes that, > unless otherwise specified, calculating the ICV can be decomposed > into: >=20 > ICV-value =3D cryptographic-function(hash-function(content)) >=20 > In some cases a different combination of cryptographic function and > hash function may be specified. This is the case for the HMAC > function, which is specified as defined in Section 13.6, using the > hash function twice. >=20 > The hash function and the cryptographic function correspond to the > entries in two IANA registries, which are reported by this > specification and are described in Section 13. >=20 > 12.1.1. Rationale >=20 > The rationale for separating the hash function and the cryptographic > function into two octets instead of having all combinations in a > single octet -- possibly as a TLV type extension -- is that adding > further hash functions or cryptographic functions in the future may > lead to a non-contiguous number space. >=20 > The rationale for not including a field that lists parameters of the > cryptographic ICV in the TLV is that, before being able to validate a > cryptographic ICV, routers have to exchange or acquire keys (e.g., > public keys). Any additional parameters can be provided together > with the keys in that bootstrap process. It is therefore not > necessary, and would even entail an extra overhead, to transmit the > parameters within every message. One implicitly available parameter > is the length of an ICV, which is - 3 - (or > single-length - 3 - in a multivalue Address Block > TLV) and which depends on the choice of the cryptographic function. >=20 > 12.2. Considerations for Calculating the ICV >=20 > The considerations listed in the following subsections MUST be > applied when calculating the ICV for Packet, Message, and Address > Block ICV TLVs, respectively. >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 11] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > 12.2.1. Packet ICV TLV >=20 > When determining the for a packet, with type extension =3D > 1, the ICV is calculated over the fields , > , , and -- if present -- > (in that order), concatenated with the entire packet, > including the packet header, all Packet TLVs (other than Packet ICV > TLVs), and all included Messages and their message headers, in > accordance with Section 8.1. When determining the for a > packet, with type extension =3D 2, the same procedure is used, except > that the source address of the IP datagram carrying the packet is > also concatenated, in the first position, with the data used. > JD: don't use concatenated use proceded by or followed by. Might also=20 > mention network byte ordering issues as at this point we are dealing with > packets. >=20 > 12.2.2. Message ICV TLV >=20 > When determining the for a message, with type extension =3D= > 1, the ICV is calculated over the fields , > , , and -- if present -- > (in that order), concatenated with the entire message. The > considerations in Section 9.1 MUST be applied. When determining the > for a message, with type extension =3D 2, the same > procedure is used, except that the source address of the IP datagram > carrying the message is also concatenated, in the first position, > with the data used. >=20 > 12.2.3. Address Block ICV TLV >=20 > When determining the for an address, block, with type > extension =3D 2, the ICV is calculated over the fields ,= > , , and -- if present -- > (in that order), concatenated with the address, and > concatenated with any other values -- for example, any other address > block TLV that is associated with that address. A MANET > routing protocol or MANET routing protocol extension using Address > Block ICV TLVs MUST specify how to include any such concatenated > attribute of the address in the verification process of the ICV. The > considerations in Section 10.1 MUST be applied. When determining the > for an address block, with type extension =3D 2, the same > procedure is used, except that the source address of the IP datagram > carrying the address block is also concatenated, in the first > position, with the data used. > JD: Typo first mention of type extension =3D 2 should be =3D1. Seems like > we should be able to specify a generalized method for including the values= . > Why not just specify that all address tlv type/value pairs associated with= an >=20 > address be included in order type.subtype order? Punting is fine but I don= 't > see why it needs to be done. > 12.3. Example of a Message Including an ICV >=20 > The sample message depicted in Figure 1 is derived from Appendix D of > [RFC5444]. The message contains an ICV Message TLV, with the value > representing an ICV that is 16 octets long of the whole message, and > a key identifier that is 4 octets long. The type extension of the >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 12] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > Message TLV is 1, for the specific decomposition of an ICV using a > cryptographic function and a hash function, as specified in > Section 12. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PV=3D0 | PF=3D8 | Packet Sequence Number | Message Type |= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MF=3D15 | MAL=3D3 | Message Length =3D 44 | Msg Orig Addr= | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Originator Address (cont) | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop Count | Message Sequence Number | Msg TLV Block | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length =3D 27 | ICV | MTLVF =3D 144 | MTLVExt =3D 1 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Value Len =3D 23 | Hash Func | Crypto Func |Key ID length=3D4|= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ICV Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ICV Value (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ICV Value (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ICV Value (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 1: Example Message with ICV >=20 > JD: Shouldn't we change this to type =3D 2 as that is the only "new" thing= > this document is specifying and encouraging? Structure should stay the > same. >=20 > 13. IANA Considerations >=20 > This specification reports the following, originally specified in > [RFC6622]: >=20 > o Two Packet TLV types, which have been allocated from the 0-223 > range of the "Packet TLV Types" repository of [RFC5444], as > specified in Table 1. >=20 > o Two Message TLV types, which have been allocated from the 0-127 > range of the "Message TLV Types" repository of [RFC5444], as > specified in Table 2. >=20 > o Two Address Block TLV types, which have been allocated from the > 0-127 range of the "Address Block TLV Types" repository of > [RFC5444], as specified in Table 3. >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 13] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > This specification updates the following, created in [RFC6622]: >=20 > o A type extension registry for each of these TLV types with values > as listed in Tables 1, 2, and 3. >=20 > The following terms are used as defined in [BCP26]: "Namespace", > "Registration", and "Designated Expert". >=20 > The following policy is used as defined in [BCP26]: "Expert Review". >=20 > 13.1. Expert Review: Evaluation Guidelines >=20 > For TLV type extensions registries where an Expert Review is > required, the Designated Expert SHOULD take the same general > recommendations into consideration as those specified by [RFC5444]. >=20 > For the Timestamp TLV, the same type extensions for all Packet, > Message, and Address Block TLVs SHOULD be numbered identically. >=20 > 13.2. Packet TLV Type Registrations >=20 > IANA has, in accordance with [RFC6622], made allocations from the > "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs > specified in Table 1. IANA are requested to modify this allocation > (defining type extension =3D 2) as indicated. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 14] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > +-----------+------+-----------+------------------------------------+ > | Name | Type | Type | Description | > | | | Extension | | > +-----------+------+-----------+------------------------------------+ > | ICV | 5 | 0 | ICV of a packet | > | | | 1-2 | ICV, using a cryptographic | > | | | | function and a hash function, as | > | | | | specified in Section 12 of this | > | | | | document | > | | | 3-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | > | | | | length, given by the TLV Length | > | | | | field. The MANET routing protocol | > | | | | has to define how to interpret | > | | | | this timestamp | > | | | 1 | Unsigned 32-bit timestamp, as | > | | | | specified in [IEEE 1003.1-2008 | > | | | | (POSIX)] | > | | | 2 | NTP timestamp format, as defined | > | | | | in [RFC5905] | > | | | 3 | Signed timestamp of arbitrary | > | | | | length with no constraints such as | > | | | | monotonicity. In particular, it | > | | | | may represent any random value | > | | | 4-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > +-----------+------+-----------+------------------------------------+ >=20 > JD: Mostly a style thing but dislike how 1-2 are included together.=20 > Suggest separating them out and indicating the difference=20 > (source IP address used). Same suggestion for other IANA tables. > Table 1: Packet TLV Types >=20 > More than one ICV Packet TLV with the same type extension MAY be > included in a packet if these represent different ICV calculations > (e.g., with type extension 1 or 2 and different cryptographic > function and/or hash function, or with a different key identifier). > ICV Packet TLVs that carry what is declared to be the same > information MUST NOT be included in the same packet. >=20 > 13.3. Message TLV Type Registrations >=20 > IANA has, in accordance with [RFC6622], made allocations from the > "Message TLV Types" namespace of [RFC5444] for the Message TLVs > specified in Table 2. IANA are requested to modify this allocation > (defining type extension =3D 2) as indicated. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 15] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > +-----------+------+-----------+------------------------------------+ > | Name | Type | Type | Description | > | | | Extension | | > +-----------+------+-----------+------------------------------------+ > | ICV | 5 | 0 | ICV of a message | > | | | 1-2 | ICV, using a cryptographic | > | | | | function and a hash function, as | > | | | | specified in Section 12 of this | > | | | | document | > | | | 3-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | > | | | | length, given by the TLV Length | > | | | | field. | > | | | 1 | Unsigned 32-bit timestamp, as | > | | | | specified in [IEEE 1003.1-2008 | > | | | | (POSIX)] | > | | | 2 | NTP timestamp format, as defined | > | | | | in [RFC5905] | > | | | 3 | Signed timestamp of arbitrary | > | | | | length with no constraints such as | > | | | | monotonicity. In particular, it | > | | | | may represent any random value | > | | | 4-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > +-----------+------+-----------+------------------------------------+ >=20 > Table 2: Message TLV Types >=20 > More than one ICV Message TLV with the same type extension MAY be > included in a message if these represent different ICV calculations > (e.g., with type extension 1 or 2 and different cryptographic > function and/or hash function, or with a different key identifier). > ICV Message TLVs that carry what is declared to be the same > information MUST NOT be included in the same message. >=20 > 13.4. Address Block TLV Type Registrations >=20 > IANA has, in accordance with [RFC6622], made allocations from the > "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs > specified in Table 3. IANA are requested to modify this allocation > (defining type extension =3D 2) as indicated. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 16] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > +-----------+------+-----------+------------------------------------+ > | Name | Type | Type | Description | > | | | Extension | | > +-----------+------+-----------+------------------------------------+ > | ICV | 5 | 0 | ICV of an object (e.g., an | > | | | | address) | > | | | 1-2 | ICV, using a cryptographic | > | | | | function and a hash function, as | > | | | | specified in Section 12 of this | > | | | | document | > | | | 3-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > | TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | > | | | | length, given by the TLV Length | > | | | | field | > | | | 1 | Unsigned 32-bit timestamp, as | > | | | | specified in [IEEE 1003.1-2008 | > | | | | (POSIX)] | > | | | 2 | NTP timestamp format, as defined | > | | | | in [RFC5905] | > | | | 3 | Signed timestamp of arbitrary | > | | | | length with no constraints such as | > | | | | monotonicity. In particular, it | > | | | | may represent any random value | > | | | 4-251 | Unassigned; Expert Review | > | | | 252-255 | Experimental Use | > +-----------+------+-----------+------------------------------------+ >=20 > Table 3: Address Block TLV Types >=20 > More than one ICV Address Block TLV with the same type extension MAY > be associated with an address if these represent different ICV > calculations (e.g., with type extension 1 or 2 and different > cryptographic function and/or hash function, or with a different key > identifier). ICV Address Block TLVs that carry what is declared to > be the same information MUST NOT be associated with the same address. >=20 > 13.5. Hash Functions >=20 > IANA has, in accordance with [RFC6622], created a new registry for > hash functions that can be used when creating an ICV, as specified in > Section 12 of this document. The initial assignments and allocation > policies are specified in Table 4. This registry is unchanged by > this specification. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 17] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > +-------------+-----------+-----------------------------------------+ > | Hash | Algorithm | Description | > | Function | | | > | Value | | | > +-------------+-----------+-----------------------------------------+ > | 0 | none | The "identity function": The hash value | > | | | of an object is the object itself | > | 1 | SHA1 | [NIST-FIPS-180-2] | > | 2 | SHA224 | [NIST-FIPS-180-2-change] | > | 3 | SHA256 | [NIST-FIPS-180-2] | > | 4 | SHA384 | [NIST-FIPS-180-2] | > | 5 | SHA512 | [NIST-FIPS-180-2] | > | 6-251 | | Unassigned; Expert Review | > | 252-255 | | Experimental Use | > +-------------+-----------+-----------------------------------------+ >=20 > Table 4: Hash Function Registry >=20 > 13.6. Cryptographic Functions >=20 > IANA has, in accordance with [RFC6622], created a new registry for > the cryptographic functions, as specified in Section 12 of this > document. Initial assignments and allocation policies are specified > in Table 5. This registry is unchanged by this specification. >=20 > +----------------+-----------+--------------------------------------+ > | Cryptographic | Algorithm | Description | > | Function Value | | | > +----------------+-----------+--------------------------------------+ > | 0 | none | The "identity function": The value | > | | | of an encrypted hash is the hash | > | | | itself | > | 1 | RSA | [RFC3447] | > | 2 | DSA | [NIST-FIPS-186-3] | > | 3 | HMAC | [RFC2104] | > | 4 | 3DES | [NIST-SP-800-67] | > | 5 | AES | [NIST-FIPS-197] | > | 6 | ECDSA | [ANSI-X9-62-2005] | > | 7-251 | | Unassigned; Expert Review | > | 252-255 | | Experimental Use | > +----------------+-----------+--------------------------------------+ >=20 > Table 5: Cryptographic Function Registry >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 18] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > 14. Security Considerations >=20 > This document does not specify a protocol. It provides a syntactical > component for cryptographic ICVs of messages and packets, as defined > in [RFC5444]. It can be used to address security issues of a MANET > routing protocol or MANET routing protocol extension. As such, it > has the same security considerations as [RFC5444]. >=20 > In addition, a MANET routing protocol or MANET routing protocol > extension that uses this specification MUST specify how to use the > framework, and the TLVs presented in this document. In addition, the > protection that the MANET routing protocol or MANET routing protocol > extensions attain by using this framework MUST be described. >=20 > As an example, a MANET routing protocol that uses this component to > reject "badly formed" or "insecure" messages if a control message > does not contain a valid ICV SHOULD indicate the security assumption > that if the ICV is valid, the message is considered valid. It also > SHOULD indicate the security issues that are counteracted by this > measure (e.g., link or identity spoofing) as well as the issues that > are not counteracted (e.g., compromised keys). >=20 > 15. Acknowledgements >=20 > The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE > Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan > (Ecole Polytechnique), and Henning Rogge (FGAN) for their > constructive comments on [RFC6622]. >=20 > The authors also appreciate the detailed reviews of [RFC6622] from > the Area Directors, in particular Stewart Bryant (Cisco), Stephen > Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as > well as Donald Eastlake (Huawei) from the Security Directorate. >=20 > 16. References >=20 > 16.1. Normative References >=20 > [BCP26] Narten, T. and H. Alvestrand, "Guidelines > for Writing an IANA Considerations > Section in RFCs", BCP 26, RFC 5226, > May 2008. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs > to Indicate Requirement Levels", BCP 14, > RFC 2119, March 1997. >=20 > [RFC5444] Clausen, T., Dearlove, C., Dean, J., and >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 19] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > C. Adjih, "Generalized Mobile Ad Hoc > Network (MANET) Packet/Message Format", > RFC 5444, February 2009. >=20 > [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., > and W. Kasch, "Network Time Protocol > Version 4: Protocol and Algorithms > Specification", RFC 5905, June 2010. >=20 > [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key > Cryptography Standards (PKCS) #1: RSA > Cryptography Specifications Version 2.1", > RFC 3447, February 2003. >=20 > [RFC2104] Krawczyk, H., Bellare, M., and R. > Canetti, "HMAC: Keyed-Hashing for Message > Authentication", RFC 2104, February 1997. >=20 > [NIST-FIPS-197] National Institute of Standards and > Technology, "Specification for the > Advanced Encryption Standard (AES)", > FIPS 197, November 2001. >=20 > [NIST-FIPS-186-3] National Institute of Standards and > Technology, "Digital Signature Standard > (DSS)", FIPS 186-3, June 2009. >=20 > [ANSI-X9-62-2005] American National Standards Institute, > "Public Key Cryptography for the > Financial Services Industry: The Elliptic > Curve Digital Signature Algorithm > (ECDSA)", ANSI X9.62-2005, November 2005. >=20 > [NIST-SP-800-67] National Institute of Standards and > Technology, "Recommendation for the > Triple Data Encryption Algorithm > (TDEA) Block Cipher", Special > Publication 800-67, May 2004. >=20 > [NIST-FIPS-180-2] National Institute of Standards and > Technology, "Specifications for the > Secure Hash Standard", FIPS 180-2, > August 2002. >=20 > [NIST-FIPS-180-2-change] National Institute of Standards and > Technology, "Federal Information > Processing Standards Publication 180-2 (+ > Change Notice to include SHA-224)", >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 20] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > FIPS 180-2, August 2002. >=20 > [IEEE 1003.1-2008 (POSIX)] IEEE Computer Society, "1003.1-2008 > Standard for Information Technology - > Portable Operating System Interface > (POSIX) Base Specifications, Issue 7", > December 2008. >=20 > 16.2. Informative References >=20 > [RFC6130] Clausen, T., Dearlove, C., and J. Dean, > "Mobile Ad Hoc Network (MANET) > Neighborhood Discovery Protocol (NHDP)", > RFC 6130, April 2011. >=20 > [RFC6622] Herberg, U. and T. Clausen, "Integrity > Check Value and Timestamp TLV Definitions > for Mobile Ad Hoc Networks (MANETs)", > RFC 6622, May 2012. >=20 > [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., > and U. Herberg, "The Optimized Link State > Routing Protocol version 2", Work > in Progress, March 2012. >=20 > Authors' Addresses >=20 > Ulrich Herberg > Fujitsu Laboratories of America > 1240 E. Arques Ave. > Sunnyvale, CA 94085 > USA >=20 > EMail: ulrich@herberg.name > URI: http://www.herberg.name/ >=20 >=20 > Thomas Heide Clausen > LIX, Ecole Polytechnique > 91128 Palaiseau Cedex > France >=20 > Phone: +33 6 6058 9349 > EMail: T.Clausen@computer.org > URI: http://www.thomasclausen.org/ >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 21] > =0C > Internet-Draft ICV and Timestamp TLVs for MANETs March 2013 >=20 >=20 > Christopher Dearlove > BAE Systems Advanced Technology Centre > West Hanningfield Road > Great Baddow, Chelmsford > United Kingdom >=20 > Phone: +44 1245 242194 > EMail: chris.dearlove@baesystems.com > URI: http://www.baesystems.com/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Herberg, et al. Expires September 24, 2013 [Page 22] > =0C > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-4--604169073 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
To take my last comment further, I don't agree it's the job of this document to describe when to use what. If one one should be used, we'd have said so. The fact that both are included indicates both are available.

--  
Christopher Dearlove

On 25 Mar 2013, at 21:01, Justin Dean <bebemaster@gmail.com> wrote:

Below I have included my comments in-line tagged with JD.  The new TLV 
subtype assignment confuses the issue of replacement of 6622.  Are there
situations where ICV TLVs with subtype 1 as defined in 6622 are 

more appropriate?  My guess is No. In any case I shouldn't be guessing,
so that should be made more clear. 

Replacement of and not just extension of 6622 is my largest overarching
issue with the document.  It seems to supersede 6622 in two different ways.

Functionally the definition of a new superior type of TCV TLV depreciates
use of 6622.  But also in terms of text of usage of the format and TLV type.
But 6622 doesn't necessary "break" with the addition of a new superior TCV 

type but its just becomes depreciated.  I can't help but think the document
would be much tighter if it worked to augment 6622 instead of replace, I do
understand the rational for replacement however as reading one document is

simpler than two and this one really is more useful.

Despite that and despite the number of comments below 
I do believe that with a few editorial changes the document should be 
moved forward.



Mobile Ad hoc Networking (MANET)                              U. Herberg
Internet-Draft                           Fujitsu Laboratories of America
Obsoletes: 6622 (if approved)                                 T. Clausen
Intended status: Standards Track                LIX, Ecole Polytechnique
Expires: September 24, 2013                                  C. Dearlove
                                                         BAE Systems ATC
                                                          March 23, 2013


          Integrity Check Value and Timestamp TLV Definitions
                  for Mobile Ad Hoc Networks (MANETs)
                    draft-ietf-manet-rfc6622-bis-01

Abstract

   This document extends and replaces RFC 6622.  It describes general
   and flexible TLVs for representing cryptographic Integrity Check
   Values (ICVs) (i.e., digital signatures or Message Authentication
   Codes (MACs)) as well as timestamps, using the generalized Mobile Ad
   Hoc Network (MANET) packet/message format defined in RFC 5444.  It
   defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
   for affixing ICVs and timestamps to a packet, a message, and an
   address, respectively.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 24, 2013.

Copyright Notice

   Copyright (c) 2013 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



Herberg, et al.        Expires September 24, 2013               [Page 1]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   (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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Differences from RFC6622 . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   4.  Security Architecture  . . . . . . . . . . . . . . . . . . . .  4
   5.  Overview and Functioning . . . . . . . . . . . . . . . . . . .  5
   6.  General ICV TLV Structure  . . . . . . . . . . . . . . . . . .  6
   7.  General Timestamp TLV Structure  . . . . . . . . . . . . . . .  7
   8.  Packet TLVs  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . .  7
     8.2.  Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . .  8
   9.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Message ICV TLV  . . . . . . . . . . . . . . . . . . . . .  8
     9.2.  Message TIMESTAMP TLV  . . . . . . . . . . . . . . . . . .  9
   10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Address Block ICV TLV  . . . . . . . . . . . . . . . . . .  9
     10.2. Address Block TIMESTAMP TLV  . . . . . . . . . . . . . . .  9
   11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   12. ICV: Hash Function and Cryptographic Function  . . . . . . . . 10
     12.1. General ICV TLV Structure  . . . . . . . . . . . . . . . . 10
       12.1.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . 11
     12.2. Considerations for Calculating the ICV . . . . . . . . . . 11
       12.2.1.  Packet ICV TLV  . . . . . . . . . . . . . . . . . . . 12
       12.2.2.  Message ICV TLV . . . . . . . . . . . . . . . . . . . 12
       12.2.3.  Address Block ICV TLV . . . . . . . . . . . . . . . . 12
     12.3. Example of a Message Including an ICV  . . . . . . . . . . 12
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14
     13.2. Packet TLV Type Registrations  . . . . . . . . . . . . . . 14
     13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15
     13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16
     13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 17
     13.6. Cryptographic Functions  . . . . . . . . . . . . . . . . . 18
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     16.2. Informative References . . . . . . . . . . . . . . . . . . 21



Herberg, et al.        Expires September 24, 2013               [Page 2]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


1.  Introduction

   This document, which extends and replaces [RFC6622], specifies:

JD: This document extends and replaces [RFC6622].  It specifies:

   o  Two TLVs for carrying Integrity Check Values (ICVs) and timestamps
      in packets, messages, and address blocks as defined by [RFC5444].

JD: Two TLV structures; One for carrying Integrity Check Values (ICVs),
and one for timestamps. TLV type assignments for packet, message and address
block TLVs for these structures.

   o  A generic framework for ICVs, accounting (for Message TLVs) for
      mutable message header fields (<msg-hop-limit> and
      <msg-hop-count>), where these fields are present in messages.

   This document retains the IANA registries, defined in [RFC6622], for
   recording code points for hash-functions, cryptographic functions,
   and ICV calculations.  This document requests additional allocations
   from these registries.

   Moreover, in Section 12, this document defines the following:

   o  A method for generating ICVs using a combination of a
      cryptographic function and a hash function.
JD: There is text in section 5 which should be moved to here.

1.1.  Differences from RFC6622

   This document obsoletes [RFC6622].  The changes introduced by this
   document are, however, small.  In addition to editorial updates, this
   document adds a new type extension for the ICV TLV that is specified
   in Section 12 of this document.  The TLV value of a TLV with this
   type extension has the same internal structure as a TLV with type
   extension 1, but is calculated also over the source address of the IP
   datagram carrying the packet, message, or address block.

   The rationale for adding this type extension is that some MANET
   protocols, such as [RFC6130] and [OLSRv2], use the IP source address
   of the IP datagram carrying the packet, message or address block,
   e.g., to identify links with neighbor routers.  If this address is
   not otherwise contained in the packet, message, or address block
   payload (which is permitted, e.g., in [RFC6130]), the address is not
   protected against tampering.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   This document uses the terminology and notation defined in [RFC5444].
   In particular, the following TLV fields and notation from [RFC5444]



Herberg, et al.        Expires September 24, 2013               [Page 3]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   are used in this specification:

   <msg-hop-limit>  is the hop limit of a message, as specified in
      Section 5.2 of [RFC5444].

   <msg-hop-count>  is the hop count of a message, as specified in
      Section 5.2 of [RFC5444].

   <length>  is the length of the value field in a TLV in octets, as
      specified in Section 5.4.1 of [RFC5444].

   single-length  is the length of a single value in the value field in
      a TLV in octets, as specified in Section 5.4.1 of [RFC5444].  (It
      is equal to <length> except in a multivalue Address Block TLV.)

3.  Applicability Statement

   MANET routing protocols using the format defined in [RFC5444] are
   accorded the ability to carry additional information in control
   messages and packets, through the inclusion of TLVs.  Information so
   included MAY be used by a MANET routing protocol, or by an extension
   of a MANET routing protocol, according to its specification.

   This document specifies how to include an ICV for a packet, a
   message, and addresses in address blocks within a message, using such
   TLVs.  This document also specifies how to treat "mutable" fields,
   specifically the <msg-hop-count> and <msg-hop-limit> fields, if
   present in the message header when calculating ICVs, such that the
   resulting ICV can be correctly verified by any recipient.

   This document describes a generic framework for creating ICVs, and
   how to include these ICVs in TLVs.  In Section 12, an example method
   for calculating such ICVs is given, using a cryptographic function
   and a hash function.

4.  Security Architecture

   Basic MANET routing protocol specifications are often "oblivious to
   security"; however, they may have a clause allowing a control message
   to be rejected as "badly formed" or "insecure" prior to the message
   being processed or forwarded.  In particular, MANET routing protocols
   such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
   Optimized Link State Routing Protocol version 2 [OLSRv2] recognize
   external reasons (such as failure to verify an ICV) for rejecting a
   message that would be considered "invalid for processing".

   This architecture is a result of the observation that with respect to
   security in MANETs, "one size rarely fits all" and that MANET routing



Herberg, et al.        Expires September 24, 2013               [Page 4]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   protocol deployment domains have varying security requirements
   ranging from "unbreakable" to "virtually none".  The virtue of this
   approach is that MANET routing protocol specifications (and
   implementations) can remain "generic", with extensions providing
   proper security mechanisms specific to a deployment domain.

   The MANET routing protocol "security architecture", in which this
   specification situates itself, can therefore be summarized as
   follows:

   o  MANET routing protocol specifications, with a clause allowing an
      extension to reject a message (prior to processing/forwarding) as
      "badly formed" or "insecure".

   o  MANET routing protocol security extensions, rejecting messages as
      "badly formed" or "insecure", as appropriate for a given security
      requirement specific to a deployment domain.

   o  Code points and an exchange format for information, necessary for
      specification of such MANET routing protocol security extensions.

   This document addresses the last of the issues listed above by
   specifying a common exchange format for cryptographic ICVs, making
   reservations from within the Packet TLV, Message TLV, and Address
   Block TLV registries of [RFC5444], to be used (and shared) among
   MANET routing protocol security extensions.

   For the specific decomposition of an ICV using a cryptographic
   function and a hash function (specified in Section 12), this document
   reports the two IANA registries from [RFC6622] for code points for
   hash functions and cryptographic functions adhering to [RFC5444].

   With respect to [RFC5444], this document is:

   o  Intended to be used in the non-normative, but intended, mode of
      use described in Appendix B of [RFC5444].

   o  A specific example of the Security Considerations section of
      [RFC5444] (the authentication part).

5.  Overview and Functioning

   This document specifies a syntactical representation of security-
   related information for use with [RFC5444] addresses, messages, and
   packets, and also reports and updates IANA registrations (from
   [RFC6622]) of TLV types and type extension registries for these TLV
   types.



Herberg, et al.        Expires September 24, 2013               [Page 5]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Moreover, this document provides guidelines for how MANET routing
   protocols, and MANET routing protocol extensions using this
   specification, should treat ICV and Timestamp TLVs, and mutable
   fields in messages.  This specification does not represent a stand-
   alone protocol; MANET routing protocols, and MANET routing protocol
   extensions using this specification, MUST provide instructions as to
   how to handle packets, messages, and addresses with security
   information, associated as specified in this document.
JD: The above paragraphs are to me clearer than the introduction on 
what the goal of this document is.  Specifically the statement 
"This specification does not represent a stand alone protocol" should

be much more prominent than it currently is. 

   This document reports previously assigned TLV types (from [RFC6622])
   from the registries defined for Packet, Message, and Address Block
   TLVs in [RFC5444].  When a TLV type is assigned from one of these
   registries, a registry for type extensions for that TLV type is
   created by IANA.  This document reports and updates these type
   extension registries, in order to specify internal structure (and
   accompanying processing) of the <value> field of a TLV.

   For example, and as defined in this document, an ICV TLV with type
   extension = 0 specifies that the <value> field has no pre-defined
   internal structure but is simply a sequence of octets.  An ICV TLV
   with type extension = 1 specifies that the <value> field has a pre-
   defined internal structure and defines its interpretation.  An ICV
   TLV with type extension = 2 specifies a modified version of this
   definition.  (Specifically, with type extension = 1 or type extension
   = 2, the <value> field contains the result of combining a
   cryptographic function and a hash function, calculated over the
   contents of the packet, message or address block, with sub-fields
   indicating which hash function and cryptographic function have been
   used; this is specified in Section 12.  The difference between the
   two type extensions is that the ICV TLV with type extension = 2 is
   calculated also over the source address of the IP datagram carrying
   the packet, message, or address block.)
JD: Seems long winded without saying very much here.  Should type
extension 1 still be used?  (No) Will it break anything? (No)

   Other documents can request assignments for other type extensions; if
   they do so, they MUST specify their internal structure (if any) and
   interpretation.

6.  General ICV TLV Structure

   The value of the ICV TLV is:

      <value> := <ICV-value>

   where







Herberg, et al.        Expires September 24, 2013               [Page 6]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   <ICV-value>  is a field, of <length> octets, which contains the
      information to be interpreted by the ICV verification process, as
      specified by the type extension.

   Note that this does not stipulate how to calculate the <ICV-value>
   nor the internal structure thereof, if any; such information MUST be
   specified by the type extension for the ICV TLV type; see Section 13.
   This document specifies three such type extensions -- one for ICVs
   without pre-defined structures, and two for ICVs constructed
   combining a cryptographic function and a hash function.

7.  General Timestamp TLV Structure

   The value of the Timestamp TLV is:

      <value> := <time-value>

   where:

   <time-value>  is an unsigned integer field, of length <length>, which
      contains the timestamp.

      Note that this does not stipulate how to calculate the
      <time-value> nor the internal structure thereof, if any; such
      information MUST be specified by the type extension for the
      TIMESTAMP TLV type; see Section 13.

   A timestamp is essentially "freshness information".  As such, its
   setting and interpretation are to be determined by the MANET routing
   protocol, or MANET routing protocol extension, that uses the
   timestamp and can, for example, correspond to a POSIX timestamp, GPS
   timestamp, or a simple sequence number.
JD: Some mention of difficulty of insuring time synchronization across a
MANET and how it's out of scope of this document should be included.
 8.  Packet TLVs

   Two Packet TLVs are defined: one for including the cryptographic ICV
   of a packet and one for including the timestamp indicating the time
   at which the cryptographic ICV was calculated.

8.1.  Packet ICV TLV

   A Packet ICV TLV is an example of an ICV TLV as described in
   Section 6.

   The following considerations apply:

   o  Because packets as defined in [RFC5444] are never forwarded by
      routers, no special considerations are required regarding mutable



Herberg, et al.        Expires September 24, 2013               [Page 7]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


      fields (e.g., <msg-hop-count> and <msg-hop-limit>), if present
      within any messages in the packet, when calculating the ICV.

   o  Any Packet ICV TLVs already present in the Packet TLV block MUST
      be removed before calculating the ICV, and the Packet TLV block
      size MUST be recalculated accordingly.  Removed ICV TLVs MUST be
      restored after having calculated the ICV value.

JD: More clearly specify what "remove" means.  I am assuming that the
TLV block size or phastlv bit needs to be updated but that needs to be said.

   The rationale for removing any Packet ICV TLV already present prior
   to calculating the ICV is that several ICVs may be added to the same
   packet, e.g., using different ICV functions.

8.2.  Packet TIMESTAMP TLV

   A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described
   in Section 7.  If a packet contains a TIMESTAMP TLV and an ICV TLV,
   the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV,
   in order to include it in the calculation of the ICV.
JD: Shouldn't ALL packet TLVs (which are relevant for the ICV in question)
other than ones listed as TCV TLVs be added before TCV TLVs are added?

9.  Message TLVs

   Two Message TLVs are defined: one for including the cryptographic ICV
   of a message and one for including the timestamp indicating the time
   at which the cryptographic ICV was calculated.

9.1.  Message ICV TLV

   A Message ICV TLV is an example of an ICV TLV as described in
   Section 6.  When determining the <ICV-value> for a message, the
   following considerations MUST be applied:

   o  The fields <msg-hop-limit> and <msg-hop-count>, if present, MUST
      both be assumed to have the value 0 (zero) when calculating the
      ICV.

   o  Any Message ICV TLVs already present in the Message TLV block MUST
      be removed before calculating the ICV, and the message size as
      well as the Message TLV block size MUST be recalculated
      accordingly.  Removed ICV TLVs MUST be restored after having
      calculated the ICV value.
JD: MUST be restored and size fields updated as well.  Also all relevant 
TLVs other than TCV TLVs must be added prior to TCV value calcuations.
   The rationale for removing any Message ICV TLV already present prior
   to calculating the ICV is that several ICVs may be added to the same
   message, e.g., using different ICV functions.







Herberg, et al.        Expires September 24, 2013               [Page 8]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


9.2.  Message TIMESTAMP TLV

   A Message TIMESTAMP TLV is an example of a Timestamp TLV as described
   in Section 7.  If a message contains a TIMESTAMP TLV and an ICV TLV,
   the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV,
   in order to include it in the calculation of the ICV.

10.  Address Block TLVs

   Two Address Block TLVs are defined: one for associating a
   cryptographic ICV to an address and one for including the timestamp
   indicating the time at which the cryptographic ICV was calculated.

10.1.  Address Block ICV TLV

   An Address Block ICV TLV is an example of an ICV TLV as described in
   Section 6.  The ICV is calculated over the address, concatenated with
   any other values -- for example, any other Address Block TLV <value>
   fields -- associated with that address.  A MANET routing protocol or
   MANET routing protocol extension using Address Block ICV TLVs MUST
   specify how to include any such concatenated attribute of the address
   in the calculation and verification processes for the ICV.  When
   determining the <ICV-value> for an address, the following
   consideration MUST be applied:

   o  If other TLV values are concatenated with the address for
      calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs
      already associated with the address.

   The rationale for not concatenating the address with any ICV TLV
   values already associated with the address when calculating the ICV
   is that several ICVs may be added to the same address, e.g., using
   different ICV functions.
JD: It may be helpful to point out that a list of TLV values associated
with and address will not likely exist as such within a packet.  This TCV
is distinct from packet/message TCVs in this regard.

10.2.  Address Block TIMESTAMP TLV

   An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as
   described in Section 7.  If both a TIMESTAMP TLV and an ICV TLV are
   associated with an address, the TIMESTAMP TLV <value> MUST be covered
   when calculating the value of the ICV to be contained in the ICV TLV
   value (i.e., concatenated with the associated address and any other
   values as described in Section 10.1).

11.  ICV: Basic

   The basic ICV, represented by way of an ICV TLV with type extension =
   0, is a simple bit-field containing the cryptographic ICV.  This
   assumes that the mechanism stipulating how ICVs are calculated and



Herberg, et al.        Expires September 24, 2013               [Page 9]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   verified is established outside of this specification, e.g., by way
   of administrative configuration or external out-of-band signaling.
   Thus, the <ICV-value>, when using type extension = 0, is

      <ICV-value> := <ICV-data>

   where:

   <ICV-data>  is an unsigned integer field, of length <length>, which
      contains the cryptographic ICV.

12.  ICV: Hash Function and Cryptographic Function

   One common way of calculating an ICV is combining a cryptographic
   function and a hash function applied to the content.  This
   decomposition is specified in this section, using either type
   extension = 1 or type extension = 2, in the ICV TLVs.
JD: nix "using either type extension = 1 or type extension = 2, in the ICV TLVs"
12.1.  General ICV TLV Structure

   The following data structure allows representation of a cryptographic
   ICV, including specification of the appropriate hash function and
   cryptographic function used for calculating the ICV:

                   <ICV-value> := <hash-function>
                                  <cryptographic-function>
                                  <key-id-length>
                                  <key-id>
                                  <ICV-data>

   where:

   <hash-function>  is an 8-bit unsigned integer field specifying the
      hash function.

   <cryptographic-function>  is an 8-bit unsigned integer field
      specifying the cryptographic function.

   <key-id-length>  is an 8-bit unsigned integer field specifying the
      length of the <key-id> field in number of octets.  The value 0x00
      is reserved for using a single pre-installed, shared key.
JD: Functional change suggestion.  Might we reserve a small number of
values similar to 0 but which may have different as yet to be determined meanings.
For example, use of a key provided out of bound such as a packet level

"global" for this packet key for message TCV TLVs. Repeatedly providing a
key seems like it may become cumbersome. 
   <key-id>  is a field specifying the key identifier of the key that
      was used to calculate the ICV of the message, which allows unique
      identification of different keys with the same originator.  It is
      the responsibility of each key originator to make sure that
      actively used keys that it issues have distinct key identifiers.
      If <key-id-length> equals 0x00, the <key-id> field is not



Herberg, et al.        Expires September 24, 2013              [Page 10]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


      contained in the TLV, and a single pre-installed, shared key is
      used.

   <ICV-data>  is an unsigned integer field, whose length is <length> -
       3 - <key-id-length>, except in a multivslue Address Block TLV, in
      which it is single-length - 3 - <key-id-length>, and which
      contains the cryptographic ICV.

   The version of this TLV, specified in this section, assumes that,
   unless otherwise specified, calculating the ICV can be decomposed
   into:

      ICV-value = cryptographic-function(hash-function(content))

   In some cases a different combination of cryptographic function and
   hash function may be specified.  This is the case for the HMAC
   function, which is specified as defined in Section 13.6, using the
   hash function twice.

   The hash function and the cryptographic function correspond to the
   entries in two IANA registries, which are reported by this
   specification and are described in Section 13.

12.1.1.  Rationale

   The rationale for separating the hash function and the cryptographic
   function into two octets instead of having all combinations in a
   single octet -- possibly as a TLV type extension -- is that adding
   further hash functions or cryptographic functions in the future may
   lead to a non-contiguous number space.

   The rationale for not including a field that lists parameters of the
   cryptographic ICV in the TLV is that, before being able to validate a
   cryptographic ICV, routers have to exchange or acquire keys (e.g.,
   public keys).  Any additional parameters can be provided together
   with the keys in that bootstrap process.  It is therefore not
   necessary, and would even entail an extra overhead, to transmit the
   parameters within every message.  One implicitly available parameter
   is the length of an ICV, which is <length> - 3 - <key-id-length> (or
   single-length - 3 - <key-id-length> in a multivalue Address Block
   TLV) and which depends on the choice of the cryptographic function.

12.2.  Considerations for Calculating the ICV

   The considerations listed in the following subsections MUST be
   applied when calculating the ICV for Packet, Message, and Address
   Block ICV TLVs, respectively.




Herberg, et al.        Expires September 24, 2013              [Page 11]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


12.2.1.  Packet ICV TLV

   When determining the <ICV-value> for a packet, with type extension =
   1, the ICV is calculated over the fields <hash-function>,
   <cryptographic-function>, <key-id-length>, and -- if present --
   <key-id> (in that order), concatenated with the entire packet,
   including the packet header, all Packet TLVs (other than Packet ICV
   TLVs), and all included Messages and their message headers, in
   accordance with Section 8.1.  When determining the <ICV-value> for a
   packet, with type extension = 2, the same procedure is used, except
   that the source address of the IP datagram carrying the packet is
   also concatenated, in the first position, with the data used.
JD: don't use concatenated use proceded by or followed by. Might also 
mention network byte ordering issues as at this point we are dealing with
packets.

12.2.2.  Message ICV TLV

   When determining the <ICV-value> for a message, with type extension =
   1, the ICV is calculated over the fields <hash-function>,
   <cryptographic-function>, <key-id-length>, and -- if present --
   <key-id> (in that order), concatenated with the entire message.  The
   considerations in Section 9.1 MUST be applied.  When determining the
   <ICV-value> for a message, with type extension = 2, the same
   procedure is used, except that the source address of the IP datagram
   carrying the message is also concatenated, in the first position,
   with the data used.

12.2.3.  Address Block ICV TLV

   When determining the <ICV-value> for an address, block, with type
   extension = 2, the ICV is calculated over the fields <hash-function>,
   <cryptographic-function>, <key-id-length>, and -- if present --
   <key-id> (in that order), concatenated with the address, and
   concatenated with any other values -- for example, any other address
   block TLV <value> that is associated with that address.  A MANET
   routing protocol or MANET routing protocol extension using Address
   Block ICV TLVs MUST specify how to include any such concatenated
   attribute of the address in the verification process of the ICV.  The
   considerations in Section 10.1 MUST be applied.  When determining the
   <ICV-value> for an address block, with type extension = 2, the same
   procedure is used, except that the source address of the IP datagram
   carrying the address block is also concatenated, in the first
   position, with the data used.
JD: Typo first mention of type extension = 2 should be =1. Seems like
we should be able to specify a generalized method for including the values.
Why not just specify that all address tlv type/value pairs associated with an

address be included in order type.subtype order? Punting is fine but I don't
see why it needs to be done.
12.3.  Example of a Message Including an ICV

   The sample message depicted in Figure 1 is derived from Appendix D of
   [RFC5444].  The message contains an ICV Message TLV, with the value
   representing an ICV that is 16 octets long of the whole message, and
   a key identifier that is 4 octets long.  The type extension of the



Herberg, et al.        Expires September 24, 2013              [Page 12]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Message TLV is 1, for the specific decomposition of an ICV using a
   cryptographic function and a hash function, as specified in
   Section 12.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=0 |  PF=8  |    Packet Sequence Number     | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MF=15 | MAL=3 |      Message Length = 44      | Msg Orig Addr |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Message Originator Address (cont)       |   Hop Limit   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |    Message Sequence Number    | Msg TLV Block |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length = 27   |     ICV       |  MTLVF = 144  |  MTLVExt = 1  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Value Len = 23 |   Hash Func   |  Crypto Func  |Key ID length=4|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Key Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ICV Value (cont)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Example Message with ICV

JD: Shouldn't we change this to type = 2 as that is the only "new" thing
this document is specifying and encouraging?  Structure should stay the
same.

13.  IANA Considerations

   This specification reports the following, originally specified in
   [RFC6622]:

   o  Two Packet TLV types, which have been allocated from the 0-223
      range of the "Packet TLV Types" repository of [RFC5444], as
      specified in Table 1.

   o  Two Message TLV types, which have been allocated from the 0-127
      range of the "Message TLV Types" repository of [RFC5444], as
      specified in Table 2.

   o  Two Address Block TLV types, which have been allocated from the
      0-127 range of the "Address Block TLV Types" repository of
      [RFC5444], as specified in Table 3.



Herberg, et al.        Expires September 24, 2013              [Page 13]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   This specification updates the following, created in [RFC6622]:

   o  A type extension registry for each of these TLV types with values
      as listed in Tables 1, 2, and 3.

   The following terms are used as defined in [BCP26]: "Namespace",
   "Registration", and "Designated Expert".

   The following policy is used as defined in [BCP26]: "Expert Review".

13.1.  Expert Review: Evaluation Guidelines

   For TLV type extensions registries where an Expert Review is
   required, the Designated Expert SHOULD take the same general
   recommendations into consideration as those specified by [RFC5444].

   For the Timestamp TLV, the same type extensions for all Packet,
   Message, and Address Block TLVs SHOULD be numbered identically.

13.2.  Packet TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs
   specified in Table 1.  IANA are requested to modify this allocation
   (defining type extension = 2) as indicated.


























Herberg, et al.        Expires September 24, 2013              [Page 14]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |           ICV of a packet          |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           | field.  The MANET routing protocol |
   |           |      |           |   has to define how to interpret   |
   |           |      |           |           this timestamp           |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

JD: Mostly a style thing but dislike how 1-2 are included together. 
Suggest separating them out and indicating the difference 
(source IP address used).  Same suggestion for other IANA tables.
                   Table 1: Packet TLV Types

   More than one ICV Packet TLV with the same type extension MAY be
   included in a packet if these represent different ICV calculations
   (e.g., with type extension 1 or 2 and different cryptographic
   function and/or hash function, or with a different key identifier).
   ICV Packet TLVs that carry what is declared to be the same
   information MUST NOT be included in the same packet.

13.3.  Message TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Message TLV Types" namespace of [RFC5444] for the Message TLVs
   specified in Table 2.  IANA are requested to modify this allocation
   (defining type extension = 2) as indicated.







Herberg, et al.        Expires September 24, 2013              [Page 15]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |          ICV of a message          |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           |               field.               |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

                        Table 2: Message TLV Types

   More than one ICV Message TLV with the same type extension MAY be
   included in a message if these represent different ICV calculations
   (e.g., with type extension 1 or 2 and different cryptographic
   function and/or hash function, or with a different key identifier).
   ICV Message TLVs that carry what is declared to be the same
   information MUST NOT be included in the same message.

13.4.  Address Block TLV Type Registrations

   IANA has, in accordance with [RFC6622], made allocations from the
   "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs
   specified in Table 3.  IANA are requested to modify this allocation
   (defining type extension = 2) as indicated.









Herberg, et al.        Expires September 24, 2013              [Page 16]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-----------+------+-----------+------------------------------------+
   |    Name   | Type |    Type   |             Description            |
   |           |      | Extension |                                    |
   +-----------+------+-----------+------------------------------------+
   |    ICV    |   5  |     0     |     ICV of an object (e.g., an     |
   |           |      |           |              address)              |
   |           |      |    1-2    |     ICV, using a cryptographic     |
   |           |      |           |  function and a hash function, as  |
   |           |      |           |   specified in Section 12 of this  |
   |           |      |           |              document              |
   |           |      |   3-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
   |           |      |           |   length, given by the TLV Length  |
   |           |      |           |                field               |
   |           |      |     1     |    Unsigned 32-bit timestamp, as   |
   |           |      |           |   specified in [IEEE 1003.1-2008   |
   |           |      |           |              (POSIX)]              |
   |           |      |     2     |  NTP timestamp format, as defined  |
   |           |      |           |            in [RFC5905]            |
   |           |      |     3     |    Signed timestamp of arbitrary   |
   |           |      |           | length with no constraints such as |
   |           |      |           |  monotonicity.  In particular, it  |
   |           |      |           |   may represent any random value   |
   |           |      |   4-251   |      Unassigned; Expert Review     |
   |           |      |  252-255  |          Experimental Use          |
   +-----------+------+-----------+------------------------------------+

                     Table 3: Address Block TLV Types

   More than one ICV Address Block TLV with the same type extension MAY
   be associated with an address if these represent different ICV
   calculations (e.g., with type extension 1 or 2 and different
   cryptographic function and/or hash function, or with a different key
   identifier).  ICV Address Block TLVs that carry what is declared to
   be the same information MUST NOT be associated with the same address.

13.5.  Hash Functions

   IANA has, in accordance with [RFC6622], created a new registry for
   hash functions that can be used when creating an ICV, as specified in
   Section 12 of this document.  The initial assignments and allocation
   policies are specified in Table 4.  This registry is unchanged by
   this specification.







Herberg, et al.        Expires September 24, 2013              [Page 17]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   +-------------+-----------+-----------------------------------------+
   |     Hash    | Algorithm |               Description               |
   |   Function  |           |                                         |
   |    Value    |           |                                         |
   +-------------+-----------+-----------------------------------------+
   |      0      |    none   | The "identity function": The hash value |
   |             |           |    of an object is the object itself    |
   |      1      |    SHA1   |            [NIST-FIPS-180-2]            |
   |      2      |   SHA224  |         [NIST-FIPS-180-2-change]        |
   |      3      |   SHA256  |            [NIST-FIPS-180-2]            |
   |      4      |   SHA384  |            [NIST-FIPS-180-2]            |
   |      5      |   SHA512  |            [NIST-FIPS-180-2]            |
   |    6-251    |           |        Unassigned; Expert Review        |
   |   252-255   |           |             Experimental Use            |
   +-------------+-----------+-----------------------------------------+

                      Table 4: Hash Function Registry

13.6.  Cryptographic Functions

   IANA has, in accordance with [RFC6622], created a new registry for
   the cryptographic functions, as specified in Section 12 of this
   document.  Initial assignments and allocation policies are specified
   in Table 5.  This registry is unchanged by this specification.

   +----------------+-----------+--------------------------------------+
   |  Cryptographic | Algorithm |              Description             |
   | Function Value |           |                                      |
   +----------------+-----------+--------------------------------------+
   |        0       |    none   |  The "identity function": The value  |
   |                |           |   of an encrypted hash is the hash   |
   |                |           |                itself                |
   |        1       |    RSA    |               [RFC3447]              |
   |        2       |    DSA    |           [NIST-FIPS-186-3]          |
   |        3       |    HMAC   |               [RFC2104]              |
   |        4       |    3DES   |           [NIST-SP-800-67]           |
   |        5       |    AES    |            [NIST-FIPS-197]           |
   |        6       |   ECDSA   |           [ANSI-X9-62-2005]          |
   |      7-251     |           |       Unassigned; Expert Review      |
   |     252-255    |           |           Experimental Use           |
   +----------------+-----------+--------------------------------------+

                 Table 5: Cryptographic Function Registry





Herberg, et al.        Expires September 24, 2013              [Page 18]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


14.  Security Considerations

   This document does not specify a protocol.  It provides a syntactical
   component for cryptographic ICVs of messages and packets, as defined
   in [RFC5444].  It can be used to address security issues of a MANET
   routing protocol or MANET routing protocol extension.  As such, it
   has the same security considerations as [RFC5444].

   In addition, a MANET routing protocol or MANET routing protocol
   extension that uses this specification MUST specify how to use the
   framework, and the TLVs presented in this document.  In addition, the
   protection that the MANET routing protocol or MANET routing protocol
   extensions attain by using this framework MUST be described.

   As an example, a MANET routing protocol that uses this component to
   reject "badly formed" or "insecure" messages if a control message
   does not contain a valid ICV SHOULD indicate the security assumption
   that if the ICV is valid, the message is considered valid.  It also
   SHOULD indicate the security issues that are counteracted by this
   measure (e.g., link or identity spoofing) as well as the issues that
   are not counteracted (e.g., compromised keys).

15.  Acknowledgements

   The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE
   Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan
   (Ecole Polytechnique), and Henning Rogge (FGAN) for their
   constructive comments on [RFC6622].

   The authors also appreciate the detailed reviews of [RFC6622] from
   the Area Directors, in particular Stewart Bryant (Cisco), Stephen
   Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as
   well as Donald Eastlake (Huawei) from the Security Directorate.

16.  References

16.1.  Normative References

   [BCP26]                     Narten, T. and H. Alvestrand, "Guidelines
                               for Writing an IANA Considerations
                               Section in RFCs", BCP 26, RFC 5226,
                               May 2008.

   [RFC2119]                   Bradner, S., "Key words for use in RFCs
                               to Indicate Requirement Levels", BCP 14,
                               RFC 2119, March 1997.

   [RFC5444]                   Clausen, T., Dearlove, C., Dean, J., and



Herberg, et al.        Expires September 24, 2013              [Page 19]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


                               C. Adjih, "Generalized Mobile Ad Hoc
                               Network (MANET) Packet/Message Format",
                               RFC 5444, February 2009.

   [RFC5905]                   Mills, D., Martin, J., Ed., Burbank, J.,
                               and W. Kasch, "Network Time Protocol
                               Version 4: Protocol and Algorithms
                               Specification", RFC 5905, June 2010.

   [RFC3447]                   Jonsson, J. and B. Kaliski, "Public-Key
                               Cryptography Standards (PKCS) #1: RSA
                               Cryptography Specifications Version 2.1",
                               RFC 3447, February 2003.

   [RFC2104]                   Krawczyk, H., Bellare, M., and R.
                               Canetti, "HMAC: Keyed-Hashing for Message
                               Authentication", RFC 2104, February 1997.

   [NIST-FIPS-197]             National Institute of Standards and
                               Technology, "Specification for the
                               Advanced Encryption Standard (AES)",
                               FIPS 197, November 2001.

   [NIST-FIPS-186-3]           National Institute of Standards and
                               Technology, "Digital Signature Standard
                               (DSS)", FIPS 186-3, June 2009.

   [ANSI-X9-62-2005]           American National Standards Institute,
                               "Public Key Cryptography for the
                               Financial Services Industry: The Elliptic
                               Curve Digital Signature Algorithm
                               (ECDSA)", ANSI X9.62-2005, November 2005.

   [NIST-SP-800-67]            National Institute of Standards and
                               Technology, "Recommendation for the
                               Triple Data Encryption Algorithm
                               (TDEA) Block Cipher", Special
                               Publication 800-67, May 2004.

   [NIST-FIPS-180-2]           National Institute of Standards and
                               Technology, "Specifications for the
                               Secure Hash Standard", FIPS 180-2,
                               August 2002.

   [NIST-FIPS-180-2-change]    National Institute of Standards and
                               Technology, "Federal Information
                               Processing Standards Publication 180-2 (+
                               Change Notice to include SHA-224)",



Herberg, et al.        Expires September 24, 2013              [Page 20]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


                               FIPS 180-2, August 2002.

   [IEEE 1003.1-2008 (POSIX)]  IEEE Computer Society, "1003.1-2008
                               Standard for Information Technology -
                               Portable Operating System Interface
                               (POSIX) Base Specifications, Issue 7",
                               December 2008.

16.2.  Informative References

   [RFC6130]                   Clausen, T., Dearlove, C., and J. Dean,
                               "Mobile Ad Hoc Network (MANET)
                               Neighborhood Discovery Protocol (NHDP)",
                               RFC 6130, April 2011.

   [RFC6622]                   Herberg, U. and T. Clausen, "Integrity
                               Check Value and Timestamp TLV Definitions
                               for Mobile Ad Hoc Networks (MANETs)",
                               RFC 6622, May 2012.

   [OLSRv2]                    Clausen, T., Dearlove, C., Jacquet, P.,
                               and U. Herberg, "The Optimized Link State
                               Routing Protocol version 2", Work
                               in Progress, March 2012.

Authors' Addresses

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E. Arques Ave.
   Sunnyvale, CA  94085
   USA

   EMail: ulrich@herberg.name
   URI:   http://www.herberg.name/


   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex
   France

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org/






Herberg, et al.        Expires September 24, 2013              [Page 21]

Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013


   Christopher Dearlove
   BAE Systems Advanced Technology Centre
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

   Phone: +44 1245 242194
   EMail: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/










































Herberg, et al.        Expires September 24, 2013              [Page 22]
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-4--604169073-- From bkantarc@uottawa.ca Mon Mar 25 20:21:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7D21F890D for ; Mon, 25 Mar 2013 20:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.037 X-Spam-Level: **** X-Spam-Status: No, score=4.037 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TR=0.935, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, SARE_RD_TO_BAD_TLD=2.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrxdh+H-dPHL for ; Mon, 25 Mar 2013 20:21:05 -0700 (PDT) Received: from smtp1.itu.edu.tr (smtp1.itu.edu.tr [160.75.2.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EB21F8903 for ; Mon, 25 Mar 2013 20:21:03 -0700 (PDT) Received: from moufcpc101 ([137.122.91.232]) (authenticated aid=ITUec8aa06da52a8f1ebd017cfae50385f2 bits=0) by smtp1.itu.edu.tr with ESMTP id r2Q3KoGg014819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2013 05:20:58 +0200 From: "Burak Kantarci" To: Date: Mon, 25 Mar 2013 23:20:50 -0400 Message-ID: <028601ce29d0$ef6bf850$ce43e8f0$@ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0287_01CE29AF.685A5850" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4iVZOtIUZfop5dT+KDpAP2VLbsjAABgkSQ Content-Language: en-ca X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp1.itu.edu.tr [160.75.2.3]); Tue, 26 Mar 2013 05:20:59 +0200 (EET) X-ITU-MailScanner-Information: Please contact with ITU BIDB for more information X-ITU-MailScanner-ID: r2Q3KoGg014819 X-ITU-MailScanner: Found to be clean X-ITU-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=4.061, required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00, ITU_FORGED_FROM_AUTH_MAIL 5.50) X-ITU-MailScanner-SpamScore: ssss X-ITU-MailScanner-From: bkantarc@uottawa.ca X-ITU-MailScanner-To: manet@ietf.org X-ITU-MailScanner-Watermark: 1364872859.71375@ccIB2iYeCL3DFVm6NzU44g Subject: [manet] {Disarmed} IEEE GLOBECOM 2013 Green Track (Last four days) Deadline:Mar 29 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 03:21:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0287_01CE29AF.685A5850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies for possible multiple copies. CALL FOR PAPERS IEEE GLOBECOM (Global Communications Conference) 2013 Symposium on Selected Areas in Communications Green Communication Systems and Networks Track Submission deadline: March 29, 2013 23:59:00 EDT ====================================== Track Chair Stefano Bregni, Politecnico di Milano, Italy, bregni@elet.polimi.it Neelesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.iisc.ernet.in ====================================== EDAS Submission Link: https://www.edas.info/newPaper.php?c=13183&track=24871 ====================================== Submission Guidelines Prospective authors are invited to submit original technical papers. For full details, please visit the following website: http://www.ieee-globecom.org/2013/submguide.html ============================== Scope and Topics of Interest Green communications and computing has been increasingly emphasized in recent years, on the grounds not only of ecological concerns but also of significant economic drivers (cost saving). The current explosive growth in the number of devices connected to the Internet and in transmission capacity calls for "green solutions" to address the challenges in energy efficient and/or resource-efficient and/or environmentally-friendly communications and computing systems. This track solicits contributions describing current trends and cutting-edge research in communication and computing systems and networks that incorporate "green" constraints in their design and operation. It covers a wide range of green communications topics, including not only green-enabled communications and computing networks, but also communication and computing technologies enabling other green solutions such as smart grids, green buildings and green logistics. -------------------------------------------------- Topics of interest include (but are not limited to): -Energy-efficient protocols and networking -Non-energy based green issues and approaches -Green transmission technologies and network protocols -Novel network concepts and architectures lowering the overall footprint of ICT -Self-organizing green wireless networks -Green traffic shaping and policy implementation -Green optical communications, switching and networking -Use of cognitive principles to reduce energy and/or resource consumption in wireline and/or wireless networks - Power-efficient cooling and air-conditioning systems for communications and computing -Physical layer approaches for green communicommunications and computing -Low cost, energy-efficient antenna and RF designs -Green management of communication networks -Context-based green management & green awareness -Economy and pricing for green communication and services -Green network monitoring -Green sustainable storage and cloud computing -Measurement and profiling of energy consumption -Green scheduling for communications and computing -Power consumption trends and reduction in communications -Modeling and analysis for green communications and computing -Security in green communication networks -Standardization, policy and regulation for green communications and computing -Mitigation of electromagnetic pollution -Experimental test-beds and results for green communications and computing -Communication technologies for transport and logistics efficiency, e.g., applications to road traffic optimization and supply chain management -Communication technologies for industrial processes -Communication technologies for green buildings -Communication technologies for energy harvesting -Architectures and models for Smart Grid communications -Communications networks for the Smart Grid -Quality of service in smart grids -Information security in the Smart Grid -Sensor and actuator networks for smart grid -Advanced metering infrastructure and smart meter technologies -Field trials and deployment experiences ------=_NextPart_000_0287_01CE29AF.685A5850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies fo= r possible multiple copies.

<= o:p> 

CA= LL FOR PAPERS
IEEE GLOBECOM (Global Communications Conference) 2013
S= ymposium on Selected Areas in Communications
Green Communication Systems= and Networks Track

Submissi= on deadline: March 29, 2013 23:59:00 EDT
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Track Chair
Stefano Bregni, Politecnico di Milano, Italy, <= a href=3D"mailto:bregni@elet.polimi.it">bregni@elet.polimi.it

Ne= elesh B. Mehta, Indian Institute of Science (IISc), India, nbmehta@ece.iisc.ernet.in

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
EDAS Submission Link: DİKKAT: İTÜ E-posta G= üvenlik Sistemi tarafından "www.linkedin.com" adresine bir yö= ;nlendirme bulundu. Bu bir sahte yönlendirme (PHISHING) girişimi = olabilir. İçerikte görünen adres: https://www.edas.info= /newPaper.php?c=3D13183&track=3D24871

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Submission Guidelines

Prospective author= s are invited to submit original technical papers. For full details, please= visit the following website:
DİKKAT: İTÜ E-posta Güvenlik Sistemi tarafında= n "www.linkedin.com" adresine bir yönlendirme bulundu. Bu bir sahte y&= #246;nlendirme (PHISHING) girişimi olabilir. İçerikte gö= ;rünen adres: http://www.ieee-globecom.org/2013/submguide.html<= /a>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Scope and Topics of Interest

Green co= mmunications and computing has been increasingly emphasized in recent years= , on the grounds not only of ecological concerns but also of significant ec= onomic drivers (cost saving). The current explosive growth in the number of= devices connected to the Internet and in transmission capacity calls for &= quot;green solutions" to address the challenges in energy efficient an= d/or resource-efficient and/or environmentally-friendly communications and = computing systems.

This track solicits contributions describing curr= ent trends and cutting-edge research in communication and computing systems= and networks that incorporate "green" constraints in their desig= n and operation. It covers a wide range of green communications topics, inc= luding not only green-enabled communications and computing networks, but al= so communication and computing technologies enabling other green solutions = such as smart grids, green buildings and green logistics.

----------= ----------------------------------------
Topics of interest include (but= are not limited to):

-Energy-efficient protocols and networking
= -Non-energy based green issues and approaches
-Green transmission techno= logies and network protocols
-Novel network concepts and architectures l= owering the overall footprint of ICT
-Self-organizing green wireless net= works
-Green traffic shaping and policy implementation
-Green optical= communications, switching and networking
-Use of cognitive principles t= o reduce energy and/or resource consumption in wireline and/or wireless net= works
- Power-efficient cooling and air-conditioning systems for communi= cations and computing
-Physical layer approaches for green communicommun= ications and computing
-Low cost, energy-efficient antenna and RF design= s
-Green management of communication networks
-Context-based green ma= nagement & green awareness
-Economy and pricing for green communicat= ion and services
-Green network monitoring
-Green sustainable storage= and cloud computing
-Measurement and profiling of energy consumption-Green scheduling for communications and computing
-Power consumption t= rends and reduction in communications
-Modeling and analysis for green c= ommunications and computing
-Security in green communication networks-Standardization, policy and regulation for green communications and compu= ting
-Mitigation of electromagnetic pollution
-Experimental test-beds= and results for green communications and computing
-Communication techn= ologies for transport and logistics efficiency, e.g., applications to road = traffic optimization and supply chain management
-Communication technolo= gies for industrial processes
-Communication technologies for green buil= dings
-Communication technologies for energy harvesting
-Architecture= s and models for Smart Grid communications
-Communications networks for = the Smart Grid
-Quality of service in smart grids
-Information securi= ty in the Smart Grid
-Sensor and actuator networks for smart grid
-Ad= vanced metering infrastructure and smart meter technologies
-Field trial= s and deployment experiences

 

 

= ------=_NextPart_000_0287_01CE29AF.685A5850-- From emmanuel.baccelli@inria.fr Thu Mar 28 01:55:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC9121F8FC6 for ; Thu, 28 Mar 2013 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t8kt4AHc+WV for ; Thu, 28 Mar 2013 01:55:48 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id CE11B21F8FE5 for ; Thu, 28 Mar 2013 01:55:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,924,1355094000"; d="scan'208,217";a="9017554" Received: from zmbs1.inria.fr ([128.93.142.14]) by mail3-relais-sop.national.inria.fr with ESMTP; 28 Mar 2013 09:55:42 +0100 Date: Thu, 28 Mar 2013 09:55:42 +0100 (CET) From: Emmanuel Baccelli To: manet@ietf.org Message-ID: <1513188775.8093110.1364460942718.JavaMail.root@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8093109_847992781.1364460942717" X-Originating-IP: [78.52.22.65] X-Mailer: Zimbra 7.2.2_GA_2857 (ZimbraWebClient - SAF3 (Mac)/7.2.2_GA_2852) Subject: [manet] MANIAC Challenge 2013 - Call for Papers/Hacking X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:55:49 -0000 ------=_Part_8093109_847992781.1364460942717 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=20 You like to work on mobile ad hoc networking?=20 You like to code?=20 You like to compete?=20 Join us and consider the following Call for Papers and Hacking!=20 ** Call for Short Papers for the 3rd MANIAC Challenge **=20 Co-located with the 87th IETF meeting in Berlin, Germany=20 July 27 - August 2, 2013=20 http://2013.maniacchallenge. org=20 Sponsored by: Google, ISOC, IETF, IRTF, ANR, and BMBF=20 The MANIAC Challenge is a competition to better understand cooperation and= =20 interoperability in ad hoc networks. Competing teams students/researchers= =20 come together to form a wireless ad hoc network, while simultaneously=20 connected to a backbone of access points. The organizers will generate=20 traffic coming from the backbone, destined to somewhere in the network. A= =20 hop-by-hop bidding contest decides the path of each data packet towards its= =20 destination.=20 Each team usually consists of two to three people. Teams will be judged=20 based on how much of the traffic they relay gets to its destination. To get= =20 their traffic across the network, each team must rely on other teams=20 willingness to forward traffic for them. We have developed software and an= =20 API over Android to allow teams to program their nodes, in particular=20 override forwarding decisions made by the routing protocol and participate= =20 in the hop-by-hop bidding contest.=20 ------------------------------ ------------------=20 Topic of 3rd MANIAC Challenge: Mobile Offloading=20 ------------------------------ ------------------=20 The specific focus of the MANIAC Challenge 2013 is on developing and=20 comparatively evaluating strategies to offload infrastructure access points= =20 via customer ad hoc forwarding using handhelds (e.g., smartphones,=20 tablets). The incentive for customers is discounted monthly fees, and the= =20 incentive for operators is decreased infrastructure costs. The idea is to= =20 demonstrate scenarios/strategies that do not degrade user experience while= =20 offering significant mobile offloading on the infrastructure.=20 Details about the scenario and competition rules are available at=20 http://2013.maniacchallenge. org/rules-setup .=20 ----------=20 Submission=20 ----------=20 We solicit the submission of short papers (max. 2 pages IEEE double-column= =20 format) describing strategies for mobile offloading. After being=20 peer-reviewed, authors of selected submissions will be invited to=20 participate in the MANIAC Challenge and to attend the IETF meeting. We=20 highly encourage authors to continue the development of the offloading=20 strategy during the review time.=20 Please, submit your short paper via email to maniac2013@lists.fu-berlin. de= .=20 -------------=20 Participation=20 -------------=20 Author participation will consist in attending the MANIAC Challenge in=20 Berlin, Germany, July 27 - 28, 2013. Authors are also invited to attend the= =20 IETF/IRTF meeting July 28 - August 2, 2013. Participation in the MANIAC=20 Challenge is free of charge. Registration costs (at full-time student rate)= =20 for the IETF/IRTF meeting are sponsored by ISOC.=20 Authors bring an implementation of the strategy described in the paper=20 submitted by the author, running on the common API and the common hardware= =20 used for the event: the Nexus 7 tablet. The MANIAC API and software will be= =20 released with the notification of acceptance. Hardware will be provided by= =20 the organizers if necessary.=20 Each participant will then concurrently run its strategy during the=20 contest, taking place on July 27th at the Freie Universit=E4t Berlin. The= =20 following day, a workshop will take place at the IETF venue, where we will= =20 summarize and discuss the results of the contest.=20 The winners of the MANIAC Challenge 2013 will be announced during the IRTF= =20 Open Meeting, which is part of the IETF/IRTF week with high visibility. The= =20 IRTF Open Meeting usually will be attended by more than 100 experts from=20 industry and academia working on Internet Engineering.=20 Winners will take home some prizes to be determined with sponsors. Competin= g=20 teams will be provided complimentary IETF registration enabling them to att= end=20 the 87th IETF meeting in Berlin, July 28 - August 2nd.=20 Details about the submission and participation are available at=20 http://2013.maniacchallenge. org/participation/=20 ------------=20 Mailing List=20 ------------=20 If you are interested in the MANIAC Challenge 2013, please subscribe to=20 the mailing list maniac2013-info@lists.fu- berlin.de . We will inform you= =20 about updates.=20 https://lists.fu-berlin.de/ listinfo/maniac2013-info# subscribe=20 ---------------=20 Important Dates=20 ---------------=20 - Deadline for short paper submission: May 5, 2013=20 - Notification of acceptance: May 12, 2013=20 - Release of API and software: May 12, 2013=20 - MANIAC challenge dates: July 27 - 28, 2013=20 - IETF/IRTF meeting: July 28 - August 2, 2013=20 ----------------=20 MANIAC Co-Chairs=20 ----------------=20 - Emmanuel Baccelli (INRIA)=20 - Oliver Hahm (INRIA)=20 - Felix Juraschek (Freie Universit=E4t Berlin)=20 - Thomas Schmidt (HAW Hamburg)=20 - Heiko Will (Freie Universit=E4t Berlin)=20 - Matthias W =E4hlisch (Freie Universit=E4t Berlin)=20 -------=20 Contact=20 -------=20 For questions, please contact maniac2013@lists.fu- berlin.de=20 ------=_Part_8093109_847992781.1364460942717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Folks,

You like to work on mobile ad hoc networking?
You like to code?
Yo= u like to compete?
Join us and consider t= he following Call for Papers and Hacking!

<= br style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, sa= ns-serif; ">        **  Call for Sh= ort Papers for the 3rd MANIAC Challenge  **

         Co-located with the = 87th IETF meeting in Berlin, Germany
&nbs= p;                     Ju= ly 27 - August 2, 2013

 = ;                http://2013.m= aniacchallenge.org

  =        Sponsored by: Google, ISOC, IETF, IRTF, ANR, and= BMBF

The MANIAC Challenge i= s a competition to better understand cooperation and
interoperability in ad hoc networks. Competing teams students/r= esearchers
come together to form a wirele= ss ad hoc network, while simultaneously
c= onnected to a backbone of access points. The organizers will generate
traffic coming from the backbone, destined to = somewhere in the network. A
hop-by-hop bi= dding contest decides the path of each data packet towards its
destination.

Each team usually consists of two to three people. Teams will be jud= ged
based on how much of the traffic they= relay gets to its destination. To get
th= eir traffic across the network, each team must rely on other teamswillingness to forward traffic for them. We have = developed software and an
API over Androi= d to allow teams to program their nodes, in particular
<= span style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, = sans-serif; ">override forwarding decisions made by the routing protocol an= d participate
in the hop-by-hop bidding c= ontest.

--------------------= ----------------------------
Topic of 3rd MANIAC Challenge: Mobile Offloading
------------------------------------------------

<= span style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, = sans-serif; ">The specific focus of the MANIAC Challenge 2013 is on develop= ing and
comparatively evaluating strategi= es to offload infrastructure access points
via customer ad hoc forwarding using handhelds (e.g., smartphones,
tablets). The incentive for customers is disc= ounted monthly fees, and the
incentive fo= r operators is decreased infrastructure costs. The idea is to
demonstrate scenarios/strategies that do not degrade u= ser experience while
offering significant= mobile offloading on the infrastructure.
Details about the scenario and competition rules are available athttp://2013.maniacchallenge.org/rules-setup<= span style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, = sans-serif; ">.

----------
Submission
----------

We solicit th= e submission of short papers (max. 2 pages IEEE double-column
format) describing strategies for mobile offloading. A= fter being
peer-reviewed, authors of sele= cted submissions will be invited to
parti= cipate in the MANIAC Challenge and to attend the IETF meeting. Wehighly encourage authors to continue the developme= nt of the offloading
strategy during the = review time.

Please, submit = your short paper via email to maniac2013@lists.fu-berlin.de.

----= ---------
Participation
-------------

Author participation will consist in attending the MANIAC Challenge in=
Berlin, Germany, July 27 - 28, 2013. Aut= hors are also invited to attend the
IETF/= IRTF meeting July 28 - August 2, 2013. Participation in the MANIACChallenge is free of charge. Registration costs (= at full-time student rate)
for the IETF/I= RTF meeting are sponsored by ISOC.

Authors bring an implementation of the strategy described in the pap= er
submitted by the author, running on th= e common API and the common hardware
used= for the event: the Nexus 7 tablet. The MANIAC API and software will be
released with the notification of acceptance= . Hardware will be provided by
the organi= zers if necessary.

Each part= icipant will then concurrently run its strategy during the
contest, taking place on July 27th at the Freie Universi= t=E4t Berlin. The
following day, a worksh= op will take place at the IETF venue, where we will
summarize and discuss the results of the contest.

The winners of the MANIAC Challenge 2013 w= ill be announced during the IRTF
Open Mee= ting, which is part of the IETF/IRTF week with high visibility. The<= br style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, sa= ns-serif; ">IRTF Open Meeting usually will be attended by mo= re than 100 experts from
industry and aca= demia working on Internet Engineering.

Winners will take home some prizes to be determined with sponsor= s. Competing
teams will be provided compl= imentary IETF registration enabling them to attend
the 87th IETF meeting in Berlin, July 28 - August 2nd.

Details about the submission and parti= cipation are available at
http://2013.maniac= challenge.org/participation/


------------
Mailing List=
------------

If you are interested in the MANIAC Challenge 2013, ple= ase subscribe to
the mailing list maniac2013-info@lists.fu-berlin.de. We = will inform you
about updates.
https://lists.fu-berlin.de/listinf= o/maniac2013-info#subscribe

---------------
Important Dates =
---------------
 -  Deadline for short paper submission: May 5, 2013&nb= sp;
 -  Notification of accepta= nce: May 12, 2013 
 -  Rel= ease of API and software: May 12, 2013
&n= bsp;-  MANIAC challenge dates: July 27 - 28, 2013 
 -  IETF/IRTF meeting: July 28 - August 2, 20= 13

----------------MANIAC Co-Chairs 
----------------

&nb= sp;- Emmanuel Baccelli (INRIA)
 - Ol= iver Hahm (INRIA)
 - Felix Juraschek= (Freie Universit=E4t Berlin)
 - Tho= mas Schmidt (HAW Hamburg)
 - Heiko W= ill (Freie Universit=E4t Berlin)
 - = Matthias W=E4hlisch (Freie Universit=E4t Berlin)

-------
Contact
-------
For questions, please contact maniac2013@l= ists.fu-berlin.de


------=_Part_8093109_847992781.1364460942717-- From ahmed_awamry_86@yahoo.com Sun Mar 31 07:37:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31EF21F8556 for ; Sun, 31 Mar 2013 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=2.297] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1GLGfTbZrT6 for ; Sun, 31 Mar 2013 07:37:38 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id E866221F84E7 for ; Sun, 31 Mar 2013 07:37:37 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UMJO5-0005xF-9l for manet@ietf.org; Sun, 31 Mar 2013 07:37:37 -0700 Date: Sun, 31 Mar 2013 07:37:37 -0700 (PDT) From: "Ahmed A. Elawamry" To: manet@ietf.org Message-ID: <1364740656964-363492.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 14:37:39 -0000 Hello All, I'm new to the MANET working group but i am following the mailing list regarding the LOADng protocol. As mentioned at the LOADng drafts that it is a reactive routing protocol extracted from the AODV; Thus, it has two cycles (topology discovery and data collection cycle). Most of the discussions and results are about the topology discovery cycle but i didn't found the corresponding results at the data collection cycle as you know that the most iterative operation is the data collection cycle not topology discovery. Are there any justification about that?! Thanks, Ahmed A. Elawamry -- View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html Sent from the IETF - manet mailing list archive at Nabble.com. From ahmed_awamry_86@yahoo.com Sun Mar 31 08:04:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E9521F8650 for ; Sun, 31 Mar 2013 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=2.297] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYoiLd1Dui2n for ; Sun, 31 Mar 2013 08:04:57 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6421F84B0 for ; Sun, 31 Mar 2013 08:04:57 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UMJoW-0000UG-Gm for manet@ietf.org; Sun, 31 Mar 2013 08:04:56 -0700 Date: Sun, 31 Mar 2013 08:04:56 -0700 (PDT) From: "Ahmed A. Elawamry" To: manet@ietf.org Message-ID: <1364742296142-363497.post@n7.nabble.com> In-Reply-To: <7130D090-7193-4734-A32D-45908B116644@jiaziyi.com> References: <7130D090-7193-4734-A32D-45908B116644@jiaziyi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [manet] comments for draft-clausen-lln-loadng-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 15:04:58 -0000 Hello, I understood that the mentioned control traffic acts as neighbors refreshment, So, What is the type of this packet is it of RREP format? Also, what after finding a route between Source (originator) and destination (target)? I mean, What is the type of packet that carry the data to be sent to the dest.? Thanks, Ahmed A. Elawamry -- View this message in context: http://ietf.10.n7.nabble.com/comments-for-draft-clausen-lln-loadng-07-txt-tp352731p363497.html Sent from the IETF - manet mailing list archive at Nabble.com.