From nobody Thu Feb 4 16:28:30 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF511B2A75; Thu, 4 Feb 2016 16:28:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160205002829.23168.98780.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 16:28:29 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-18.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:28:29 -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 : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-18.txt Pages : 69 Date : 2016-02-04 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 routing 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: https://tools.ietf.org/html/draft-ietf-manet-dlep-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 4 17:09:09 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C07401B2B9B; Thu, 4 Feb 2016 17:09:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160205010906.23096.68244.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 17:09:06 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-credit-window-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 01:09:06 -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 : Credit Windowing extension for DLEP Author : Stan Ratliff Filename : draft-ietf-manet-credit-window-01.txt Pages : 11 Date : 2016-02-04 Abstract: This draft describes an extension to the DLEP protocol to provide a credit-windowing scheme analogous to that in RFC5578 for destination- specific flow control. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-credit-window/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-credit-window-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-credit-window-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 6 14:22:38 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDF41B3485 for ; Sat, 6 Feb 2016 14:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXqLH3BtTfWZ for ; Sat, 6 Feb 2016 14:22:32 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1211B345D for ; Sat, 6 Feb 2016 14:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8744; q=dns/txt; s=iport; t=1454797352; x=1456006952; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qi/uv3Pg7vUri7v+0Cvn3+8FiKZHuDxqjXZEjtIAfQI=; b=YYqjZ9WjT+ByxDLQkeL4/3zJclbS4SGZLZlrm6LXKgYBswCTBcEDQsxl +PWm/HibgpXiQ6yrpG1vw08BqnNIr7dikqFDnKeH15YB6+PXEgYq/C7kF jhKcZWh87zl4kT+AliqhFDmkhw2ccklh+3NaW0UxJrBla6JMZemGRyIGP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCmcbZW/40NJK1egm5MgT8GiFWud?= =?us-ascii?q?4ITAQ2BZoYNAoElOBQBAQEBAQEBgQqEQgEBBIEJAgEIPwchERQRAgQBEogGAxK?= =?us-ascii?q?5Rw2ETwEBAQEBAQEDAQEBAQEbhhIBhDaCN4FLEQGEWAWNX4UPhAcBi1yBc45zh?= =?us-ascii?q?n2HQAEeAQFCg2RqhyM0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,407,1449532800"; d="scan'208,217";a="235863537" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Feb 2016 22:22:31 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u16MMVAO029598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 6 Feb 2016 22:22:31 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 6 Feb 2016 16:22:30 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Sat, 6 Feb 2016 16:22:30 -0600 From: "Alvaro Retana (aretana)" To: Stan Ratliff , MANET IETF Thread-Topic: [manet] DLEP-18 Security Considerations Thread-Index: AQHRUlOAoKZlMQke1UG/MiPH4VQjRZ8fk4WA Date: Sat, 6 Feb 2016 22:22:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.21.127] Content-Type: multipart/alternative; boundary="_000_D2DBAA6510DB40aretanaciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 22:22:36 -0000 --_000_D2DBAA6510DB40aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" on behalf of ratliffstan@gmail.com> wrote: Stan: Hi! You'll need references for L2 security. The main problem I see with the text below is that it is based on assumptio= ns - even though you do say that "DLEP is restricted to...a single (possibl= y logical) hop at layer 2", it is based on the deployment assumptions. Wha= t happens if it isn't deployed that way? What about confidentiality of the data? What about exposing information ab= out users (privacy)? I know that the assumed deployment model makes it ver= y hard to look at the data in flight between and the physical and L2 securi= ty may well be enough. However, what if DLEP is not used as expected? IMO, you should describe the expected operating environment (or point to th= e assumptions) and any security mechanisms that should be included there (L= 2, physical assumptions), and explain why confidentiality and privacy are n= ot a concern...but then you should also say something like: "if DLEP is use= d in an environment other then the expected one, then xx, yy and zz MUST/SH= OULD be implemented". I think that this way we would be covering the norm= al case, but also providing an answer to what if without making mandatory m= echanisms that may be superfluous. My 2c. Alvaro. Hello WG, As requested in the email thread earlier today, here's a snapshot of what w= e currently have in the upcoming DLEP-18 draft wrt security. We've put an a= dditional paragraph in the Assumptions section (Sec. 2.1) that says: The reliance on MAC addresses by DLEP forces the assumption that participating DLEP peers are on a single segment (either physical or logically, via tunneling protocols) at Layer 2. DLEP further assumes that security of the implementations (e.g., authentication of stations, encryption of traffic, or both) is dealt with by by utilizing Layer 2 security techniques. Additionally, here is the text in the "Security Considerations": 12. Security Considerations The potential security concerns when using DLEP are: 1. An attacker might pretend to be a DLEP peer, either at DLEP session initialization, or by injection of messages once a session has been established, and/or 2. DLEP data items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status. Since DLEP is restricted to operation over a single (possibly logical) hop at layer 2, implementations requiring authentication and/or encryption of traffic MUST take steps to secure the Layer 2 link. To avoid potential denial of service attack, it is RECOMMENDED that implementations using the Peer Discovery mechanism maintain an information base of hosts that persistently fail Session Initialization having provided an acceptable Discovery signal, and ignore Peer Discovery signals from such hosts. This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed. Thoughts? Suggestions? Regards, Stan --_000_D2DBAA6510DB40aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7DD905462127F3469297DFE7F7385752@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <<= a href=3D"mailto:manet-bounces@ietf.org">manet-bounces@ietf.org on beha= lf of ratliffstan@gmail.com> wrot= e:

Stan:

Hi!

You'll need references for L2 security.

The main problem I see with the text below is that it is based on assu= mptions — even though you do say that "DLEP is restricted toR= 30;a single (possibly logical) hop at layer 2", it is based on the dep= loyment assumptions.  What happens if it isn't deployed that way? 

What about confidentiality of the data?  What about exposing info= rmation about users (privacy)?  I know that the assumed deployment mod= el makes it very hard to look at the data in flight between and the physica= l and L2 security may well be enough.  However, what if DLEP is not used as expected?

IMO, you should describe the expected operating environment (or point = to the assumptions) and any security mechanisms that should be included the= re (L2, physical assumptions), and explain why confidentiality and privacy = are not a concern…but then you should also say something like: "if DLEP is used in an environment other the= n the expected one, then xx, yy and zz MUST/SHOULD be implemented". &n= bsp; I think that this way we would be covering the normal case, but also p= roviding an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.

Alvaro.



Hello WG,

As requested in the email thread earlier today, here's a snapshot of what w= e currently have in the upcoming DLEP-18 draft wrt security. We've put an a= dditional paragraph in the Assumptions section (Sec. 2.1) that says:

   The reliance on MAC addresses by DLEP forces the assumption th= at
   participating DLEP peers are on a single segment (either physi= cal or
   logically, via tunneling protocols) at Layer 2.  DLEP fur= ther assumes
   that security of the implementations (e.g., authentication of<= br>    stations, encryption of traffic, or both) is dealt with by by<= br>    utilizing Layer 2 security techniques.


Additionally, here is the text in the "Security Considerations": =

12.  Security Considerations

   The potential security concerns when using DLEP are:

   1.  An attacker might pretend to be a DLEP peer, either a= t DLEP
       session initialization, or by injectio= n of messages once a
       session has been established, and/or
   2.  DLEP data items could be altered by an attacker, caus= ing the
       receiving implementation to inappropri= ately alter its information
       base concerning network status.

   Since DLEP is restricted to operation over a single (possibly<= br>    logical) hop at layer 2, implementations requiring authenticat= ion
   and/or encryption of traffic MUST take steps to secure the Lay= er 2
   link.

   To avoid potential denial of service attack, it is RECOMMENDED= that
   implementations using the Peer Discovery mechanism maintain an=
   information base of hosts that persistently fail Session
   Initialization having provided an acceptable Discovery signal,= and
   ignore Peer Discovery signals from such hosts.

   This specification does not address security of the data plane= , as it
   (the data plane) is not affected, and standard security proced= ures
   can be employed.


Thoughts? Suggestions?

Regards,
Stan
 --_000_D2DBAA6510DB40aretanaciscocom_-- From nobody Sat Feb 6 15:18:50 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ABB1A700F for ; Sat, 6 Feb 2016 15:18:49 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VnmQvc4n3eI for ; Sat, 6 Feb 2016 15:18:47 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D041A7018 for ; Sat, 6 Feb 2016 15:18:46 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id f81so163072972iof.0 for ; Sat, 06 Feb 2016 15:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ne8amiKFbgC+Y5oUmqqGLbj8wqX4xlbrwodXKDuhKXs=; b=0Te0AjOdjSERyTOGUyexgv7rLOkzZ9gxy5B7LNkwgTyG4Bm45XZvSo+lAv+p4DDxqi 0Eg/0BKrD0eOhr1OXLmtgbLYH8ZAaTE7hjdSbZW4Zn086gVXNmrx5Rm3fz1pEDZL1Lzh 4WNChpyFrrwAG7j9fHY2K7ZtI3CUK/Gj/pUm865H8mYZcCRCUqTBVLkDCS4Ta6QVik6B iZfFFya41nJ0KwHE2zmoVAaqJ/fXH+Z9hrT24GjKlmmeam+HF3JC/w+dDvGtH7yr7MtQ yUsT2bMZ6geoETXJ728G5/kPuq7NCChdUuNuLdEbj0CJKsCqpmW5YxclaKrUQ09kYqvD slcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ne8amiKFbgC+Y5oUmqqGLbj8wqX4xlbrwodXKDuhKXs=; b=NGh8KSFl9+R6QjwPo81QIvgkeOkIDuTmAAY/I94W+Dr+l6+hd6SEixlWyCtccZ0BLF 2UAJ3Sjw4gGUP7E5HgyP2wlw5M/Ac/8I5PoHPVQHkdi/O6UQa3qU4XGWkzhfXRYWpQ6R skD3cKZkh7knRloYeCvBgqcPzdEkz/7A1ZEWfQu2n1cRpFUydjocEKb8CrjIiLGAfjZu VPsarog/WSrL5woLZFcNrg9QJTVgFEVOYB/jvIF0PeeJtEN0rfTkDN99AjpAUnRaA5lq Owe/c+M3EEpXbZEvVHI6cfeEQgKCjte6qFcnIPiC116DNQUcs2xwD1rMHspqdAZ64DFL YkZQ== X-Gm-Message-State: AG10YOTNWXIktixkrtvwg3lATgK7bDvvDjpn8gfOgRPeeOy7lxEsB44eyM/QboEtSKZXvWTWXg64NOS59EosRw== MIME-Version: 1.0 X-Received: by 10.107.129.89 with SMTP id c86mr22601064iod.102.1454800726322; Sat, 06 Feb 2016 15:18:46 -0800 (PST) Received: by 10.79.96.1 with HTTP; Sat, 6 Feb 2016 15:18:46 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Feb 2016 18:18:46 -0500 Message-ID: From: Stan Ratliff To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a113f943c82f49b052b22308f Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 23:18:49 -0000 --001a113f943c82f49b052b22308f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alvaro, On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana) wrote: > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" < > manet-bounces@ietf.org on behalf of ratliffstan@gmail.com> wrote: > > Stan: > > Hi! > > You'll need references for L2 security. > OK. Do you have any in mind? > > The main problem I see with the text below is that it is based on > assumptions =E2=80=94 even though you do say that "DLEP is restricted to= =E2=80=A6a single > (possibly logical) hop at layer 2", it is based on the deployment > assumptions. What happens if it isn't deployed that way? > > What about confidentiality of the data? What about exposing information > about users (privacy)? I know that the assumed deployment model makes it > very hard to look at the data in flight between and the physical and L2 > security may well be enough. However, what if DLEP is not used as expect= ed? > I'm confused. We tried to state the DLEP only works over 1 hop. Reliance on MAC addresses forces that. If DLEP isn't used as expected, why would anyone think it would work as expected? Or be secure? A requirement to document use cases outside the document seems to me like a never-ending task - after all, "we don't know what we don't know". We could sit & think about "perverse implementations" almost forever. At the end of the day, if DLEP is not used as expected, all bets are off. Having said that, would the addition of text stating "Using DLEP with multiple network hops between router and modem is out of scope of this document, and results are unpredictable" serve to address your comment? Regards, Stan > > IMO, you should describe the expected operating environment (or point to > the assumptions) and any security mechanisms that should be included ther= e > (L2, physical assumptions), and explain why confidentiality and privacy a= re > not a concern=E2=80=A6but then you should also say something like: "if DL= EP is used > in an environment other then the expected one, then xx, yy and zz > MUST/SHOULD be implemented". I think that this way we would be covering > the normal case, but also providing an answer to what if without making > mandatory mechanisms that may be superfluous. > > My 2c. > > Alvaro. > > > > Hello WG, > > As requested in the email thread earlier today, here's a snapshot of what > we currently have in the upcoming DLEP-18 draft wrt security. We've put a= n > additional paragraph in the Assumptions section (Sec. 2.1) that says: > > The reliance on MAC addresses by DLEP forces the assumption that > participating DLEP peers are on a single segment (either physical or > logically, via tunneling protocols) at Layer 2. DLEP further assumes > that security of the implementations (e.g., authentication of > stations, encryption of traffic, or both) is dealt with by by > utilizing Layer 2 security techniques. > > > Additionally, here is the text in the "Security Considerations": > > 12. Security Considerations > > The potential security concerns when using DLEP are: > > 1. An attacker might pretend to be a DLEP peer, either at DLEP > session initialization, or by injection of messages once a > session has been established, and/or > > 2. DLEP data items could be altered by an attacker, causing the > receiving implementation to inappropriately alter its information > base concerning network status. > > Since DLEP is restricted to operation over a single (possibly > logical) hop at layer 2, implementations requiring authentication > and/or encryption of traffic MUST take steps to secure the Layer 2 > link. > > To avoid potential denial of service attack, it is RECOMMENDED that > implementations using the Peer Discovery mechanism maintain an > information base of hosts that persistently fail Session > Initialization having provided an acceptable Discovery signal, and > ignore Peer Discovery signals from such hosts. > > This specification does not address security of the data plane, as it > (the data plane) is not affected, and standard security procedures > can be employed. > > > Thoughts? Suggestions? > > Regards, > Stan > > --001a113f943c82f49b052b22308f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alvaro,


On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana= ) <aretana@cisco.com> wrote:
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <<= a href=3D"mailto:manet-bounces@ietf.org" target=3D"_blank">manet-bounces@ie= tf.org on behalf of ratliffstan@gmai= l.com> wrote:

Stan:

Hi!

You'll need references for L2 security.

OK. Do you have any in mind?

=C2=A0

The main problem I see with the text below is that it is based on assu= mptions =E2=80=94 even though you do say that "DLEP is restricted to= =E2=80=A6a single (possibly logical) hop at layer 2", it is based on t= he deployment assumptions.=C2=A0 What happens if it isn't deployed that way?=C2=A0

What about confidentiality of the data?=C2=A0 What about exposing info= rmation about users (privacy)?=C2=A0 I know that the assumed deployment mod= el makes it very hard to look at the data in flight between and the physica= l and L2 security may well be enough.=C2=A0 However, what if DLEP is not used as expected?

I'm confused. We tried to state the DLEP only works over 1 hop.= Reliance on MAC addresses forces that. If DLEP isn't used as expected,= why would anyone think it would work as expected? Or be secure? A requirem= ent to document use cases outside the document seems to me like a never-end= ing task - after all, "we don't know what we don't know".= We could sit & think about "perverse implementations" almost= forever. At the end of the day, if DLEP is not used as expected, all bets = are off.

Having said that, would the addition of text st= ating "Using DLEP with multiple network hops between router and modem = is out of scope of this document, and results are unpredictable" serve= to address your comment?


Regards,
Stan=



=C2=A0

IMO, you should describe the expected operating environment (or point = to the assumptions) and any security mechanisms that should be included the= re (L2, physical assumptions), and explain why confidentiality and privacy = are not a concern=E2=80=A6but then you should also say something like: "if DLEP is used in an environment other the= n the expected one, then xx, yy and zz MUST/SHOULD be implemented". = =C2=A0 I think that this way we would be covering the normal case, but also= providing an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.

Alvaro.



Hello WG,

As requested in the email thread earlier today, here's a snapshot of wh= at we currently have in the upcoming DLEP-18 draft wrt security. We've = put an additional paragraph in the Assumptions section (Sec. 2.1) that says= :

=C2=A0=C2=A0 The reliance on MAC addresses by DLEP forces the assumption th= at
=C2=A0=C2=A0 participating DLEP peers are on a single segment (either physi= cal or
=C2=A0=C2=A0 logically, via tunneling protocols) at Layer 2.=C2=A0 DLEP fur= ther assumes
=C2=A0=C2=A0 that security of the implementations (e.g., authentication of<= br> =C2=A0=C2=A0 stations, encryption of traffic, or both) is dealt with by by<= br> =C2=A0=C2=A0 utilizing Layer 2 security techniques.


Additionally, here is the text in the "Security Considerations": =

12.=C2=A0 Security Considerations

=C2=A0=C2=A0 The potential security concerns when using DLEP are:

=C2=A0=C2=A0 1.=C2=A0 An attacker might pretend to be a DLEP peer, either a= t DLEP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 session initialization, or by injectio= n of messages once a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 session has been established, and/or
=C2=A0=C2=A0 2.=C2=A0 DLEP data items could be altered by an attacker, caus= ing the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receiving implementation to inappropri= ately alter its information
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base concerning network status.

=C2=A0=C2=A0 Since DLEP is restricted to operation over a single (possibly<= br> =C2=A0=C2=A0 logical) hop at layer 2, implementations requiring authenticat= ion
=C2=A0=C2=A0 and/or encryption of traffic MUST take steps to secure the Lay= er 2
=C2=A0=C2=A0 link.

=C2=A0=C2=A0 To avoid potential denial of service attack, it is RECOMMENDED= that
=C2=A0=C2=A0 implementations using the Peer Discovery mechanism maintain an=
=C2=A0=C2=A0 information base of hosts that persistently fail Session
=C2=A0=C2=A0 Initialization having provided an acceptable Discovery signal,= and
=C2=A0=C2=A0 ignore Peer Discovery signals from such hosts.

=C2=A0=C2=A0 This specification does not address security of the data plane= , as it
=C2=A0=C2=A0 (the data plane) is not affected, and standard security proced= ures
=C2=A0=C2=A0 can be employed.


Thoughts? Suggestions?

Regards,
Stan

--001a113f943c82f49b052b22308f-- From nobody Sat Feb 6 16:28:21 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D047F1A885D for ; Sat, 6 Feb 2016 16:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKlNfC3w96GW for ; Sat, 6 Feb 2016 16:28:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CDB1A885F for ; Sat, 6 Feb 2016 16:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15647; q=dns/txt; s=iport; t=1454804897; x=1456014497; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+lWkEiqSCm3kbWoqPbf6HX4vyBi9L97YRdlQwv9rVI=; b=F9KPErgMP0yTY6l5tolBAKCC1nY4fpMVdcsxs2WpMLdO9N/3LanxOfQ7 e8Vxg8xqy2ChtXexEFIsAYCblEWbR0X7P6NWtoEwJ+mR2U/Nc2OTAtboq XFNjx67yMvw1hEUuptS6vQAY63BZUUgVARH51Dt1ij1i1AN1i+QhMo1Hp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWBQBIj7ZW/4cNJK1egm5MgT8GiFWud?= =?us-ascii?q?YIhgWaGDQKBIjkTAQEBAQEBAYEKhEIBAQR5EAIBCD8HIREUEQIEDgWIBgMSuTA?= =?us-ascii?q?NhE8BAQEBAQEBAwEBAQEBAQEBAReGEgGENoI3gUsRAYRYBZJuhAcBi1yBc4Fbj?= =?us-ascii?q?RiGfYNvg1EBIgI+ggMZgUhqhyM0fAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,407,1449532800"; d="scan'208,217"; a="70791272" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2016 00:28:16 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u170SGdn025871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 Feb 2016 00:28:16 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 6 Feb 2016 18:28:15 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Sat, 6 Feb 2016 18:28:15 -0600 From: "Alvaro Retana (aretana)" To: Stan Ratliff Thread-Topic: [manet] DLEP-18 Security Considerations Thread-Index: AQHRUlOAoKZlMQke1UG/MiPH4VQjRZ8fk4WAgACV3QD//41EgA== Date: Sun, 7 Feb 2016 00:28:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.21.127] Content-Type: multipart/alternative; boundary="_000_D2DBCB3E10DD58aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 00:28:20 -0000 --_000_D2DBCB3E10DD58aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 2/6/16, 3:18 PM, "Stan Ratliff" > wrote: Stan: Hi! I'm mostly acting as the Devil's Advocate.. Alvaro, On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana) > wrote: On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" on behalf of ratliffstan@gmail.com> wrote: Stan: Hi! You'll need references for L2 security. OK. Do you have any in mind? No, you're the ones writing the spec. ;-) Seriously=85 If you write "MUST take steps to secure the Layer 2", then I = really hope you (authors, WG, etc.) have specifics in mind. That question w= ill come up. The main problem I see with the text below is that it is based on assumptio= ns =97 even though you do say that "DLEP is restricted to=85a single (possi= bly logical) hop at layer 2", it is based on the deployment assumptions. W= hat happens if it isn't deployed that way? What about confidentiality of the data? What about exposing information ab= out users (privacy)? I know that the assumed deployment model makes it ver= y hard to look at the data in flight between and the physical and L2 securi= ty may well be enough. However, what if DLEP is not used as expected? I'm confused. We tried to state the DLEP only works over 1 hop. Reliance on= MAC addresses forces that. If DLEP isn't used as expected, why would anyon= e think it would work as expected? Or be secure? A requirement to document = use cases outside the document seems to me like a never-ending task - after= all, "we don't know what we don't know". We could sit & think about "perve= rse implementations" almost forever. At the end of the day, if DLEP is not = used as expected, all bets are off. Having said that, would the addition of text stating "Using DLEP with multi= ple network hops between router and modem is out of scope of this document,= and results are unpredictable" serve to address your comment? That would make me happy, but it wouldn't address my comment. Note that th= e reliance on MAC addresses is explained as an assumption (not a requiremen= t)=85 I think we all understand when/how DLEP is intended to be used, but it is t= he SecDir/SEC ADs job to ask those "what if" questions. No one can guarant= ee that DLEP won't be used unexpectedly =97 my real intent it to prevent th= e impulse of identifying anything as mandatory if it is not required. I see that the document does include the optional use of TLS =97 I'm assumi= ng most deployments would set the bit to 0. It is not discussed anywhere w= hen it might be set to 1, if at all. If the provision for additional secur= ity is already there, the door is then open for all kinds of scrutiny. Alvaro. Regards, Stan IMO, you should describe the expected operating environment (or point to th= e assumptions) and any security mechanisms that should be included there (L= 2, physical assumptions), and explain why confidentiality and privacy are n= ot a concern=85but then you should also say something like: "if DLEP is use= d in an environment other then the expected one, then xx, yy and zz MUST/SH= OULD be implemented". I think that this way we would be covering the norm= al case, but also providing an answer to what if without making mandatory m= echanisms that may be superfluous. My 2c. Alvaro. Hello WG, As requested in the email thread earlier today, here's a snapshot of what w= e currently have in the upcoming DLEP-18 draft wrt security. We've put an a= dditional paragraph in the Assumptions section (Sec. 2.1) that says: The reliance on MAC addresses by DLEP forces the assumption that participating DLEP peers are on a single segment (either physical or logically, via tunneling protocols) at Layer 2. DLEP further assumes that security of the implementations (e.g., authentication of stations, encryption of traffic, or both) is dealt with by by utilizing Layer 2 security techniques. Additionally, here is the text in the "Security Considerations": 12. Security Considerations The potential security concerns when using DLEP are: 1. An attacker might pretend to be a DLEP peer, either at DLEP session initialization, or by injection of messages once a session has been established, and/or 2. DLEP data items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status. Since DLEP is restricted to operation over a single (possibly logical) hop at layer 2, implementations requiring authentication and/or encryption of traffic MUST take steps to secure the Layer 2 link. To avoid potential denial of service attack, it is RECOMMENDED that implementations using the Peer Discovery mechanism maintain an information base of hosts that persistently fail Session Initialization having provided an acceptable Discovery signal, and ignore Peer Discovery signals from such hosts. This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed. Thoughts? Suggestions? Regards, Stan --_000_D2DBCB3E10DD58aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <07F37725918FF042841B66297F864A81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 2/6/16, 3:18 PM, "Stan Ratliff" <ratliffstan@gmail.com> wrote:

Stan:

Hi!

I'm mostly acting as the Devil's Advocate..

Alvaro,


On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (a= retana) <aretana@cisco.co= m> wrote:
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <<= a href=3D"mailto:manet-bounces@ietf.org" target=3D"_blank">manet-bounces@ie= tf.org on behalf of ratliffstan@gmai= l.com> wrote:

Stan:

Hi!

You'll need references for L2 security.

OK. Do you have any in mind?

No, you're the ones writing the spec. ;-) 

Seriously=85  If you write "MUST take steps to secure the La= yer 2", then I really hope you (authors, WG, etc.) have= specifics in mind. That question will come up.



 

The main problem I see with the text below is that it is based on assu= mptions =97 even though you do say that "DLEP is restricted to=85a sin= gle (possibly logical) hop at layer 2", it is based on the deployment = assumptions.  What happens if it isn't deployed that way? 

What about confidentiality of the data?  What about exposing info= rmation about users (privacy)?  I know that the assumed deployment mod= el makes it very hard to look at the data in flight between and the physica= l and L2 security may well be enough.  However, what if DLEP is not used as expected?

I'm confused. We tried to state the DLEP only works over 1 hop. Relian= ce on MAC addresses forces that. If DLEP isn't used as expected, why would = anyone think it would work as expected? Or be secure? A requirement to docu= ment use cases outside the document seems to me like a never-ending task - after all, "we don't know what= we don't know". We could sit & think about "perverse impleme= ntations" almost forever. At the end of the day, if DLEP is not used a= s expected, all bets are off.

Having said that, would the addition of text stating "Using DLEP = with multiple network hops between router and modem is out of scope of this= document, and results are unpredictable" serve to address your commen= t?

That would make me happy, but it wouldn't address my comment.  No= te that the reliance on MAC addresses is explained as an assumption (not a = requirement)=85

I think we all understand when/how DLEP is intended to be used, but it= is the SecDir/SEC ADs job to ask those "what if" questions. &nbs= p;No one can guarantee that DLEP won't be used unexpectedly =97 my real int= ent it to prevent the impulse of identifying anything as mandatory if it is not required.

I see that the document does include the optional use of TLS =97 I'm a= ssuming most deployments would set the bit to 0.  It is not discussed = anywhere when it might be set to 1, if at all.  If the provision for a= dditional security is already there, the door is then open for all kinds of scrutiny.

Alvaro.




Regards,
Stan



 

IMO, you should describe the expected operating environment (or point = to the assumptions) and any security mechanisms that should be included the= re (L2, physical assumptions), and explain why confidentiality and privacy = are not a concern=85but then you should also say something like: "if DLEP is used in an environment other the= n the expected one, then xx, yy and zz MUST/SHOULD be implemented". &n= bsp; I think that this way we would be covering the normal case, but also p= roviding an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.

Alvaro.



Hello WG,

As requested in the email thread earlier today, here's a snapshot of what w= e currently have in the upcoming DLEP-18 draft wrt security. We've put an a= dditional paragraph in the Assumptions section (Sec. 2.1) that says:

   The reliance on MAC addresses by DLEP forces the assumption th= at
   participating DLEP peers are on a single segment (either physi= cal or
   logically, via tunneling protocols) at Layer 2.  DLEP fur= ther assumes
   that security of the implementations (e.g., authentication of<= br>    stations, encryption of traffic, or both) is dealt with by by<= br>    utilizing Layer 2 security techniques.


Additionally, here is the text in the "Security Considerations": =

12.  Security Considerations

   The potential security concerns when using DLEP are:

   1.  An attacker might pretend to be a DLEP peer, either a= t DLEP
       session initialization, or by injectio= n of messages once a
       session has been established, and/or
   2.  DLEP data items could be altered by an attacker, caus= ing the
       receiving implementation to inappropri= ately alter its information
       base concerning network status.

   Since DLEP is restricted to operation over a single (possibly<= br>    logical) hop at layer 2, implementations requiring authenticat= ion
   and/or encryption of traffic MUST take steps to secure the Lay= er 2
   link.

   To avoid potential denial of service attack, it is RECOMMENDED= that
   implementations using the Peer Discovery mechanism maintain an=
   information base of hosts that persistently fail Session
   Initialization having provided an acceptable Discovery signal,= and
   ignore Peer Discovery signals from such hosts.

   This specification does not address security of the data plane= , as it
   (the data plane) is not affected, and standard security proced= ures
   can be employed.


Thoughts? Suggestions?

Regards,
Stan

 --_000_D2DBCB3E10DD58aretanaciscocom_-- From nobody Sun Feb 7 03:55:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C41B3992 for ; Sun, 7 Feb 2016 03:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8DHr-TkEaNr for ; Sun, 7 Feb 2016 03:55:07 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6391B3993 for ; Sun, 7 Feb 2016 03:55:07 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id j78so81074097lfb.1 for ; Sun, 07 Feb 2016 03:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LsagOi3YhV0R/kVF5wak34210r7hbWX3J2ELUY52aAw=; b=Y/Wr9VktzEwhiZ8D0jNWORhz4RtCHEnsn2xLOrRYMv62Ki6eIXMtCsrq56OzC+D5K0 plrUOQBL4pt/MDtk7ehytPBTeJbgIR0gT61obmKLa0/lR4xsP/7g42buCYef5f/zy37H R2uOQrlRkQxI+T6BU3ibqUkESMRdphswAhO5a8EAC8+CEgy4ns2wdP4UFYnxMKPNP+dJ 5y1k40NR5njaGr5IcVMtcFNUspx7Wh2UiDyZ7A5e6MpfYDySSp8Se/UjSl5URPbZqBJe YQROQTu2nxa1wD8Uuy3Ngmqbjf4Ohgl99rKy6eMjjkxe76zxAGfu/2LXSxFY3SsG+5Qn jmoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=LsagOi3YhV0R/kVF5wak34210r7hbWX3J2ELUY52aAw=; b=ZioWv1EV1sJX3AjVvV4MnhlSNR4Iwnz2gi+5y7/xGsu0U5fkupY/LCx1ENFyeMit5d aBP9Zjn5BhmBLtjvHrMiPqUek3rIHA7zJ64lGPYEaKHfh+d5BekLysJD2uz9+NCYjJzE 2pkxl2mW5yrLwsFxFumnS9mIRxRmm4/AOVacuR1LmvZuH0DdoqQJhv8Q0sNFzfqZtJ8s 1oZvOwD0WGUbYHcvAVuLNrPRQUAf4664uafXTxVr0YAHuD0pRlfEuCpp6f4GNjp1hKyR Sq7VOElKs/1gxZwlsNWcSxtwIFulHGwQJdh7qzNrELfRm6BkSobMOrJrVwrK5zn0qVJ/ 6B4A== X-Gm-Message-State: AG10YOTUzJ9biFWvUt8ybaOE7OWcutp3LWyh9QascQJIAqmtAV5V90fGhO3pGGfzhpnxUG+lsLUpDbC1jS2+tQ== X-Received: by 10.25.169.74 with SMTP id s71mr8450233lfe.128.1454846105304; Sun, 07 Feb 2016 03:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.161.77 with HTTP; Sun, 7 Feb 2016 03:54:35 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Sun, 7 Feb 2016 12:54:35 +0100 Message-ID: To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 11:55:09 -0000 On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana) wrote: > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" > wrote: > > Stan: > > Hi! > > You'll need references for L2 security. > > The main problem I see with the text below is that it is based on > assumptions =E2=80=94 even though you do say that "DLEP is restricted to= =E2=80=A6a single > (possibly logical) hop at layer 2", it is based on the deployment > assumptions. What happens if it isn't deployed that way? It will not work because the user traffic will not reach the destination. DLEP is the model of a "external radio" which acts as a bridge (as in "layer-2 bridge") between the connection to the router and the radio network. If you are more than 1 IP-hop away you will not get the user traffic. > What about confidentiality of the data? What about exposing information > about users (privacy)? if you have one IP-hop between radio and router linklayer/MAC security takes care of this. If not you are outside the specification of the protocol and do something strange to the traffic anyways... so it should not be DLEP's problem. > I know that the assumed deployment model makes it > very hard to look at the data in flight between and the physical and L2 > security may well be enough. However, what if DLEP is not used as expect= ed? If you break the basic assumptions of the protocol, you should not expect its security considerations to be secure in your situation. > IMO, you should describe the expected operating environment (or point to = the > assumptions) and any security mechanisms that should be included there (L= 2, > physical assumptions), and explain why confidentiality and privacy are no= t a > concern=E2=80=A6 http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1 > but then you should also say something like: "if DLEP is used in an > environment other then the expected one, then xx, yy and zz MUST/SHOULD b= e > implemented". I think that this way we would be covering the normal cas= e, > but also providing an answer to what if without making mandatory mechanis= ms > that may be superfluous. There is no guarantee that xx/yy/zz will give you any kind of security in an unspecified environment. Henning Rogge From nobody Sun Feb 7 04:58:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5C41B3A1E for ; Sun, 7 Feb 2016 04:58:09 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Qzvwl2Sody for ; Sun, 7 Feb 2016 04:58:07 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217FD1B3A1F for ; Sun, 7 Feb 2016 04:58:07 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id wb13so126310721obb.1 for ; Sun, 07 Feb 2016 04:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WqDurzLxhHbcFTjibFQalxxNn9OzHemaR8wMkrNmmRg=; b=0fcnaMbKf5LrkbwDskRADT7wesbtvCmBgslQonug+dL+pfI3h+uAQdQv9N6WKREFlr thWzIs/q3KZ+5FH8KZ8Ku+843p84D5hX04wFRHDEpRvzc8H+2G/276bdSEJPXtE+MsiF Pn/lxmZJz2UiWSwl3PnJaognAaa0ATZJaj+5AeyvD/rh2o9FKCiU4mq+jgaISVdNZe/0 5MtDocn1yP1A146c9tsms3nIC8odmDe5EfCppCrLm6NkaYLdU+PkMtZ5jPWtcdzOFURt NqFwU0EfirRScn408EZeV+yxb/rBEEekW0R8xCtvNa5AX/5qzjemB4MIOtErL/uaJMii tj3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WqDurzLxhHbcFTjibFQalxxNn9OzHemaR8wMkrNmmRg=; b=F8hU8OlzZQkXFW4jHL85RI89JorzlBl5puEreYT8trRQoNuH7RZRDEzbQYiDRvs6E4 yrsPF6TBQIrhaeiUfUzuYDUO4GYXfp3lj/Fo9sCTtSHjOnvZ4TjJ7Me6U0P2DsvyE2L6 hX6YTqtkeKoUXtFmUuDkUmZZCLHQzhmP5Nx4DMR05p3CJG0X9Y/4a9VjWZtvokZ/56L8 pGvz/YRjH4JawI3ETSfpsA71wUv5nvPKBJo7T0FHnjnWT6Au/EBTGmJdQp5PVvhqz2vT G/SersBYtUw4FKHccgiipz94gusdwP+SklPDbNKJ3bpZ157XSBQTV5Sqxmkdkdt14eKW ITYQ== X-Gm-Message-State: AG10YOTnWEZ8N8kMAa0iFJLB5TWs7rYGz1M6kpryKpe/3gVUPMfIPEoDUH8/tFvJbCj2tF4Euy8aMaldxgn/ng== MIME-Version: 1.0 X-Received: by 10.60.220.230 with SMTP id pz6mr20172016oec.49.1454849886611; Sun, 07 Feb 2016 04:58:06 -0800 (PST) Received: by 10.76.159.234 with HTTP; Sun, 7 Feb 2016 04:58:06 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Feb 2016 07:58:06 -0500 Message-ID: From: Justin Dean To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11367c2eb1722a052b2da26b Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 12:58:09 -0000 --001a11367c2eb1722a052b2da26b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about the following update? Taken from bits of Hennings' explanation here and Ran's proposed text from quite a while back. Please note the difference in deployment and implement, and the resulting what actually gets used in real deployments.... The potential security concerns when using DLEP are: 1. An attacker might pretend to be a DLEP peer, either at DLEP session initialization, or by injection of messages once a session has been established, and/or 2. DLEP data items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status. DLEP is restricted to operation over a single (possibly logical) hop at layer 2; Deployments other than single-hop are not permitted and outside the scope of this specification. Deployments requiring authentication and/or encryption of traffic MUST take steps to secure the Layer 2 link. All DLEP Implementations either: (a) MUST implement Transport Layer Security (TLS)' [RFC-5246] so TLS is available for use when deployment dictate or (b) MUST restrict the valid IP (both IPv4 and IPv6) unicast addresses for use with DLEP to link-local addresses. To avoid potential denial of service attack, it is RECOMMENDED that implementations using the Peer Discovery mechanism maintain an information base of hosts that persistently fail Session Initialization having provided an acceptable Discovery signal, and ignore Peer Discovery signals from such hosts. This specification does not effect security of the data plane; standard security procedures can be employed for the data plane. On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge wrote: > On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana) > wrote: > > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" > > wrote: > > > > Stan: > > > > Hi! > > > > You'll need references for L2 security. > > > > The main problem I see with the text below is that it is based on > > assumptions =E2=80=94 even though you do say that "DLEP is restricted t= o=E2=80=A6a single > > (possibly logical) hop at layer 2", it is based on the deployment > > assumptions. What happens if it isn't deployed that way? > > It will not work because the user traffic will not reach the > destination. DLEP is the model of a "external radio" which acts as a > bridge (as in "layer-2 bridge") between the connection to the router > and the radio network. > > If you are more than 1 IP-hop away you will not get the user traffic. > > > What about confidentiality of the data? What about exposing informatio= n > > about users (privacy)? > > if you have one IP-hop between radio and router linklayer/MAC security > takes care of this. If not you are outside the specification of the > protocol and do something strange to the traffic anyways... so it > should not be DLEP's problem. > > > I know that the assumed deployment model makes it > > very hard to look at the data in flight between and the physical and L2 > > security may well be enough. However, what if DLEP is not used as > expected? > > If you break the basic assumptions of the protocol, you should not > expect its security considerations to be secure in your situation. > > > IMO, you should describe the expected operating environment (or point t= o > the > > assumptions) and any security mechanisms that should be included there > (L2, > > physical assumptions), and explain why confidentiality and privacy are > not a > > concern=E2=80=A6 > > http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1 > > > but then you should also say something like: "if DLEP is used in an > > environment other then the expected one, then xx, yy and zz MUST/SHOULD > be > > implemented". I think that this way we would be covering the normal > case, > > but also providing an answer to what if without making mandatory > mechanisms > > that may be superfluous. > > There is no guarantee that xx/yy/zz will give you any kind of security > in an unspecified environment. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11367c2eb1722a052b2da26b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about the following update?=C2=A0 Taken from bits= of Hennings' explanation here and Ran's proposed text from quite a= while back.=C2=A0 Please note the difference in deployment and implement, = and the resulting what actually gets used in real deployments....

The potential security concerns when using DLEP are:
=C2=A0 = =C2=A0
1.=C2=A0 An attacker might pretend to be a DLEP peer, eith= er at DLEP
=C2=A0 =C2=A0 session initialization, or by injection = of messages once a
=C2=A0 =C2=A0 session has been established, an= d/or

2.=C2=A0 DLEP data items could be altered by = an attacker, causing the
=C2=A0 =C2=A0 receiving implementation t= o inappropriately alter its information
=C2=A0 =C2=A0 base concer= ning network status.

=C2=A0 =C2=A0DLEP is restrict= ed to operation over a single (possibly
=C2=A0 =C2=A0logical) hop= at layer 2; Deployments other than single-hop are=C2=A0
=C2=A0 = =C2=A0not permitted and outside the scope of this specification.
= =C2=A0 =C2=A0Deployments requiring authentication and/or encryption of traf= fic=C2=A0
=C2=A0 =C2=A0MUST take steps to secure the Layer 2 link= .

All DLEP Implementations either:

(a) MUST implement Transport Layer Sec= urity (TLS)' [RFC-5246]=C2=A0
so TLS is available for use when deployment dictate or= =C2=A0
(b) MUS= T restrict the valid IP (both IPv4 and IPv6) unicast=C2=A0
addresses for use with DLEP t= o link-local addresses.

=C2=A0 =C2=A0To avoid pote= ntial denial of service attack, it is RECOMMENDED that
=C2=A0 =C2= =A0implementations using the Peer Discovery mechanism maintain an
=C2=A0 =C2=A0information base of hosts that persistently fail Session
=C2=A0 =C2=A0Initialization having provided an acceptable Discovery s= ignal, and
=C2=A0 =C2=A0ignore Peer Discovery signals from such h= osts.
=C2=A0 =C2=A0
=C2=A0 =C2=A0This specification doe= s not effect security of the data plane;=C2=A0
=C2=A0 =C2=A0stand= ard security procedures can be employed for the data plane.

On Sun, Feb 7, 2016 a= t 6:54 AM, Henning Rogge <hrogge@gmail.com> wrote:
On Sat, Feb 6, 2016 at 11:22 PM, A= lvaro Retana (aretana)
<aretana@cisco.com> wrote: > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
> <manet-bounces@ietf.org on behalf of ratliffstan@gmail.= com> wrote:
>
> Stan:
>
> Hi!
>
> You'll need references for L2 security.
>
> The main problem I see with the text below is that it is based on
> assumptions =E2=80=94 even though you do say that "DLEP is restri= cted to=E2=80=A6a single
> (possibly logical) hop at layer 2", it is based on the deployment=
> assumptions.=C2=A0 What happens if it isn't deployed that way?

It will not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts a= s a
bridge (as in "layer-2 bridge") between the connection to the rou= ter
and the radio network.

If you are more than 1 IP-hop away you will not get the user traffic.

> What about confidentiality of the data?=C2=A0 What about exposing info= rmation
> about users (privacy)?

if you have one IP-hop between radio and router linklayer/MAC securi= ty
takes care of this. If not you are outside the specification of the
protocol and do something strange to the traffic anyways... so it
should not be DLEP's problem.

>=C2=A0 I know that the assumed deployment model makes it
> very hard to look at the data in flight between and the physical and L= 2
> security may well be enough.=C2=A0 However, what if DLEP is not used a= s expected?

If you break the basic assumptions of the protocol, you should not expect its security considerations to be secure in your situation.

> IMO, you should describe the expected operating environment (or point = to the
> assumptions) and any security mechanisms that should be included there= (L2,
> physical assumptions), and explain why confidentiality and privacy are= not a
> concern=E2=80=A6

http://tools.ietf.org/html/dra= ft-ietf-manet-dlep-18#section-2.1

> but then you should also say something like: "if DLEP is used in = an
> environment other then the expected one, then xx, yy and zz MUST/SHOUL= D be
> implemented".=C2=A0 =C2=A0I think that this way we would be cover= ing the normal case,
> but also providing an answer to what if without making mandatory mecha= nisms
> that may be superfluous.

There is no guarantee that xx/yy/zz will give you any kind of securi= ty
in an unspecified environment.

Henning Rogge

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

--001a11367c2eb1722a052b2da26b-- From nobody Sun Feb 7 06:53:48 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462CC1B3B87 for ; Sun, 7 Feb 2016 06:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7diEzcGZejh for ; Sun, 7 Feb 2016 06:53:45 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id CE6C81B3B7F for ; Sun, 7 Feb 2016 06:53:44 -0800 (PST) Received: (qmail 14953 invoked by uid 0); 7 Feb 2016 14:53:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 7 Feb 2016 14:53:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id FZtZ1s0082SSUrH01ZtcRe; Sun, 07 Feb 2016 14:53:39 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=-NfooI8aBGcA:10 a=kGVakC0ZM5EA:10 a=jFJIQSaiL_oA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=NhSHSWgtGNU5mE0hXpEA:9 a=X4XThmf0Jqt3l_an:21 a=AszAkRxmpE5IgAeX:21 a=QEXdDO2ut3YA:10 a=RhyRCO8XQdqBenyPb78A:9 a=hCvYrBm9cIVzcBop:21 a=A0gmN-fm6FXWsJnl:21 a=GZUm7VqxDOwP0BT3:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=BQG5YBZYbnvkJ/HQJDRAV8o0Cbk5GQEZrDDdBwDkd7k=; b=PvfvT1cdh9IEvQmTtSmV1fB05ytsH2jcXczTOg12dV97n+GjI6WCUCL35mdclsu/H4pE4o0kSyDSLHUGDaAw95lpgOvz73i55EPMJe2yrnU1gi3Dh6Hcmv/gcpcoN0A5; Received: from [172.58.233.18] (port=62008 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aSQiV-0001EU-EF; Sun, 07 Feb 2016 07:53:35 -0700 From: Lou Berger To: Justin Dean , Henning Rogge Date: Sun, 07 Feb 2016 09:53:30 -0500 Message-ID: <152bc392e10.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------152bc3931d01b97281843141d68" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.58.233.18 authed with lberger@labn.net} Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:53:47 -0000 This is a multi-part message in MIME format. ------------152bc3931d01b97281843141d68 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Justin, Two minor suggestions: s/ link-local addresses/a directly attached IP sub-subnet/ And at then end of b Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and 802.1X. Lou On February 7, 2016 7:58:37 AM Justin Dean wrote: > How about the following update? Taken from bits of Hennings' explanation > here and Ran's proposed text from quite a while back. Please note the > difference in deployment and implement, and the resulting what actually > gets used in real deployments.... > > The potential security concerns when using DLEP are: > > 1. An attacker might pretend to be a DLEP peer, either at DLEP > session initialization, or by injection of messages once a > session has been established, and/or > > 2. DLEP data items could be altered by an attacker, causing the > receiving implementation to inappropriately alter its information > base concerning network status. > > DLEP is restricted to operation over a single (possibly > logical) hop at layer 2; Deployments other than single-hop are > not permitted and outside the scope of this specification. > Deployments requiring authentication and/or encryption of traffic > MUST take steps to secure the Layer 2 link. > > All DLEP Implementations either: > > (a) MUST implement Transport Layer Security (TLS)' [RFC-5246] > so TLS is available for use when deployment dictate or > (b) MUST restrict the valid IP (both IPv4 and IPv6) unicast > addresses for use with DLEP to link-local addresses. > > To avoid potential denial of service attack, it is RECOMMENDED that > implementations using the Peer Discovery mechanism maintain an > information base of hosts that persistently fail Session > Initialization having provided an acceptable Discovery signal, and > ignore Peer Discovery signals from such hosts. > > This specification does not effect security of the data plane; > standard security procedures can be employed for the data plane. > > On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge wrote: > >> On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana) >> wrote: >> > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" >> > wrote: >> > >> > Stan: >> > >> > Hi! >> > >> > You'll need references for L2 security. >> > >> > The main problem I see with the text below is that it is based on >> > assumptions — even though you do say that "DLEP is restricted to…a single >> > (possibly logical) hop at layer 2", it is based on the deployment >> > assumptions. What happens if it isn't deployed that way? >> >> It will not work because the user traffic will not reach the >> destination. DLEP is the model of a "external radio" which acts as a >> bridge (as in "layer-2 bridge") between the connection to the router >> and the radio network. >> >> If you are more than 1 IP-hop away you will not get the user traffic. >> >> > What about confidentiality of the data? What about exposing information >> > about users (privacy)? >> >> if you have one IP-hop between radio and router linklayer/MAC security >> takes care of this. If not you are outside the specification of the >> protocol and do something strange to the traffic anyways... so it >> should not be DLEP's problem. >> >> > I know that the assumed deployment model makes it >> > very hard to look at the data in flight between and the physical and L2 >> > security may well be enough. However, what if DLEP is not used as >> expected? >> >> If you break the basic assumptions of the protocol, you should not >> expect its security considerations to be secure in your situation. >> >> > IMO, you should describe the expected operating environment (or point to >> the >> > assumptions) and any security mechanisms that should be included there >> (L2, >> > physical assumptions), and explain why confidentiality and privacy are >> not a >> > concern… >> >> http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1 >> >> > but then you should also say something like: "if DLEP is used in an >> > environment other then the expected one, then xx, yy and zz MUST/SHOULD >> be >> > implemented". I think that this way we would be covering the normal >> case, >> > but also providing an answer to what if without making mandatory >> mechanisms >> > that may be superfluous. >> >> There is no guarantee that xx/yy/zz will give you any kind of security >> in an unspecified environment. >> >> Henning Rogge >> >> _______________________________________________ >> 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 > ------------152bc3931d01b97281843141d68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Justin,

Two minor suggestions:

s/ link-local addresses/a directly attached IP sub-subnet/

And at then end of  b

Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and 802.1X.

Lou

On February 7, 2016 7:58:37 AM Justin Dean <bebemaster@gmail.com> wrote:

How about the following update?  Taken from bits of Hennings' explanation here and Ran's proposed text from quite a while back.  Please note the difference in deployment and implement, and the resulting what actually gets used in real deployments....

The potential security concerns when using DLEP are:
   
1.  An attacker might pretend to be a DLEP peer, either at DLEP
    session initialization, or by injection of messages once a
    session has been established, and/or

2.  DLEP data items could be altered by an attacker, causing the
    receiving implementation to inappropriately alter its information
    base concerning network status.

   DLEP is restricted to operation over a single (possibly
   logical) hop at layer 2; Deployments other than single-hop are 
   not permitted and outside the scope of this specification.
   Deployments requiring authentication and/or encryption of traffic 
   MUST take steps to secure the Layer 2 link.

All DLEP Implementations either:

(a) MUST implement Transport Layer Security (TLS)' [RFC-5246] 
so TLS is available for use when deployment dictate or 
(b) MUST restrict the valid IP (both IPv4 and IPv6) unicast 
addresses for use with DLEP to link-local addresses.

   To avoid potential denial of service attack, it is RECOMMENDED that
   implementations using the Peer Discovery mechanism maintain an
   information base of hosts that persistently fail Session
   Initialization having provided an acceptable Discovery signal, and
   ignore Peer Discovery signals from such hosts.
   
   This specification does not effect security of the data plane; 
   standard security procedures can be employed for the data plane.

On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge <hrogge@gmail.com> wrote:
On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana)
<aretana@cisco.com> wrote:
> On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
> <manet-bounces@ietf.org on behalf of ratliffstan@gmail.com> wrote:
>
> Stan:
>
> Hi!
>
> You'll need references for L2 security.
>
> The main problem I see with the text below is that it is based on
> assumptions — even though you do say that "DLEP is restricted to…a single
> (possibly logical) hop at layer 2", it is based on the deployment
> assumptions.  What happens if it isn't deployed that way?

It will not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts as a
bridge (as in "layer-2 bridge") between the connection to the router
and the radio network.

If you are more than 1 IP-hop away you will not get the user traffic.

> What about confidentiality of the data?  What about exposing information
> about users (privacy)?

if you have one IP-hop between radio and router linklayer/MAC security
takes care of this. If not you are outside the specification of the
protocol and do something strange to the traffic anyways... so it
should not be DLEP's problem.

>  I know that the assumed deployment model makes it
> very hard to look at the data in flight between and the physical and L2
> security may well be enough.  However, what if DLEP is not used as expected?

If you break the basic assumptions of the protocol, you should not
expect its security considerations to be secure in your situation.

> IMO, you should describe the expected operating environment (or point to the
> assumptions) and any security mechanisms that should be included there (L2,
> physical assumptions), and explain why confidentiality and privacy are not a
> concern…

http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1

> but then you should also say something like: "if DLEP is used in an
> environment other then the expected one, then xx, yy and zz MUST/SHOULD be
> implemented".   I think that this way we would be covering the normal case,
> but also providing an answer to what if without making mandatory mechanisms
> that may be superfluous.

There is no guarantee that xx/yy/zz will give you any kind of security
in an unspecified environment.

Henning Rogge

_______________________________________________
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

------------152bc3931d01b97281843141d68-- From nobody Sun Feb 7 08:33:13 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DA21A1AFC for ; Sun, 7 Feb 2016 08:33:12 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp0wa6w5JU_E for ; Sun, 7 Feb 2016 08:33:09 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C0C1A8A80 for ; Sun, 7 Feb 2016 08:33:09 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g73so174503294ioe.3 for ; Sun, 07 Feb 2016 08:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=We7CKeojqItswhNlMatlKjwkQfg1PJDzdthwnI24Rj4=; b=cOsBbwS+ZOXRkU1ad9PVA+VJweg6sMVlcqGM4TDzGTw0f4yRxJ9AtDSHDPtJ/nENDc LR18/DiOFuPkE/gvaRPLgvUpYCF8a/WptRzjbrv9SYZkOOC5txqsRyPqAMwPuOj3Pbrc k+lxNWfH7UW2qQ2hPAY0gTdnYv6NyCRmW61CdhMyKCzCSnIG9D1mpZ7oHULJ+tyTB3l8 G6eODXx/WJ3zA0G157nINn4jQz9nqT6S9ePEIzllE48mNAefdEHT0sXUKh01fNDue+Sd MbQmihiIp79UBmDM73L0yAHct3FKwwecGQtbdX/tIhgS7UKIRgCSJegNml0OGLgm7Fet aktg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=We7CKeojqItswhNlMatlKjwkQfg1PJDzdthwnI24Rj4=; b=V8GQkOyARvgmC6ErqLDOfP7QQF+MRZ9J66B1XqSw3+JK6Q/vuZJkQVTThi1DPVFMPe tBPCOLre2ihqKX2GtnFgz01RiFBlMHELGO8jn+7sb1/jhTtfGa0In7d3w7ZE6uypP1ae 4D3l30Nt1IHIlgDL86ERvFl96dkAPCKAtrQXi6/0b2j1+BXtHKI6bl8kb2wJR15EgJxq YYFDX0stU3yEDYmVzlC+MXWcQN2/Y98C/toeoRQ7HT89DgQaDM2Rf27OInPwH5hxhaKL NGviJSn7wdguWLtpDC6BioQVa4cOlE4tAnsriwmR1XEjVT433pUAa0N7Xm2s4TRDfwpB O+PQ== X-Gm-Message-State: AG10YOT5ZqNbf1UIyUz0hTOMrxMHxA422i/4gFZ29haCQGw4516InlAj/m0UYEAu7PsivvPGUD7wtsaBmkP2Zw== MIME-Version: 1.0 X-Received: by 10.107.3.229 with SMTP id e98mr26781158ioi.182.1454862788405; Sun, 07 Feb 2016 08:33:08 -0800 (PST) Received: by 10.79.96.1 with HTTP; Sun, 7 Feb 2016 08:33:08 -0800 (PST) In-Reply-To: <152bc392e10.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <152bc392e10.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Sun, 7 Feb 2016 11:33:08 -0500 Message-ID: From: Stan Ratliff To: Lou Berger Content-Type: multipart/alternative; boundary=001a113f97beb332b4052b30a3e2 Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 16:33:12 -0000 --001a113f97beb332b4052b30a3e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, I think the critical point here is Alvaro's comment: > The main problem I see with the text below is that it is based on > assumptions =E2=80=94 even though you do say that "DLEP is restricted to= =E2=80=A6a single > (possibly logical) hop at layer 2", it is based on the deployment > assumptions. What happens if it isn't deployed that way? It's NOT an "assumption". We've mis-lableld it as an assumption. It's actually a requirement. Henning's response to the above text is correct: "It will not work because the user traffic will not reach the destination. DLEP is the model of a "external radio" which acts as a bridge (as in "layer-2 bridge") between the connection to the router and the radio network." Anyone attempting multi-hop deployment will immediately bump into the issue of a router issuing packets with a Destination MAC address that's not on the local segment. Traffic won't pass. As Henning states, it simply won't work. I believe we need to move the following text from "Assumptions" to "Requirements": DLEP assumes that the MAC address for delivering data traffic is the MAC address used by DLEP to identify the destination. No manipulation or substitution is performed; the MAC address supplied in all destination messages is used as the OSI Layer 2 Destination MAC address. DLEP also assumes that MAC addresses are unique within the context of a router-modem session. The reliance on MAC addresses by DLEP forces the assumption that participating DLEP peers are on a single segment (either physical or logically, via tunneling protocols) at Layer 2. We also need to take the TLS flag out of the IPv4 and IPv6 Connection Point data items (a clear "miss" on our part). I believe this addresses the concern, in that 1-hop deployment is no longer an "assumption". Regards, Stan On Sun, Feb 7, 2016 at 9:53 AM, Lou Berger wrote: > Justin, > > Two minor suggestions: > > s/ link-local addresses/a directly attached IP sub-subnet/ > > And at then end of b > > Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and > 802.1X. > > Lou > > On February 7, 2016 7:58:37 AM Justin Dean wrote: > >> How about the following update? Taken from bits of Hennings' explanatio= n >> here and Ran's proposed text from quite a while back. Please note the >> difference in deployment and implement, and the resulting what actually >> gets used in real deployments.... >> >> The potential security concerns when using DLEP are: >> >> 1. An attacker might pretend to be a DLEP peer, either at DLEP >> session initialization, or by injection of messages once a >> session has been established, and/or >> >> 2. DLEP data items could be altered by an attacker, causing the >> receiving implementation to inappropriately alter its information >> base concerning network status. >> >> DLEP is restricted to operation over a single (possibly >> logical) hop at layer 2; Deployments other than single-hop are >> not permitted and outside the scope of this specification. >> Deployments requiring authentication and/or encryption of traffic >> MUST take steps to secure the Layer 2 link. >> >> All DLEP Implementations either: >> >> (a) MUST implement Transport Layer Security (TLS)' [RFC-5246] >> so TLS is available for use when deployment dictate or >> (b) MUST restrict the valid IP (both IPv4 and IPv6) unicast >> addresses for use with DLEP to link-local addresses. >> >> To avoid potential denial of service attack, it is RECOMMENDED that >> implementations using the Peer Discovery mechanism maintain an >> information base of hosts that persistently fail Session >> Initialization having provided an acceptable Discovery signal, and >> ignore Peer Discovery signals from such hosts. >> >> This specification does not effect security of the data plane; >> standard security procedures can be employed for the data plane. >> >> On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge wrote: >> >>> On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana) >>> wrote: >>> > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" >>> > wrote: >>> > >>> > Stan: >>> > >>> > Hi! >>> > >>> > You'll need references for L2 security. >>> > >>> > The main problem I see with the text below is that it is based on >>> > assumptions =E2=80=94 even though you do say that "DLEP is restricted= to=E2=80=A6a >>> single >>> > (possibly logical) hop at layer 2", it is based on the deployment >>> > assumptions. What happens if it isn't deployed that way? >>> >>> It will not work because the user traffic will not reach the >>> destination. DLEP is the model of a "external radio" which acts as a >>> bridge (as in "layer-2 bridge") between the connection to the router >>> and the radio network. >>> >>> If you are more than 1 IP-hop away you will not get the user traffic. >>> >>> > What about confidentiality of the data? What about exposing >>> information >>> > about users (privacy)? >>> >>> if you have one IP-hop between radio and router linklayer/MAC security >>> takes care of this. If not you are outside the specification of the >>> protocol and do something strange to the traffic anyways... so it >>> should not be DLEP's problem. >>> >>> > I know that the assumed deployment model makes it >>> > very hard to look at the data in flight between and the physical and = L2 >>> > security may well be enough. However, what if DLEP is not used as >>> expected? >>> >>> If you break the basic assumptions of the protocol, you should not >>> expect its security considerations to be secure in your situation. >>> >>> > IMO, you should describe the expected operating environment (or point >>> to the >>> > assumptions) and any security mechanisms that should be included ther= e >>> (L2, >>> > physical assumptions), and explain why confidentiality and privacy ar= e >>> not a >>> > concern=E2=80=A6 >>> >>> http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1 >>> >>> > but then you should also say something like: "if DLEP is used in an >>> > environment other then the expected one, then xx, yy and zz >>> MUST/SHOULD be >>> > implemented". I think that this way we would be covering the normal >>> case, >>> > but also providing an answer to what if without making mandatory >>> mechanisms >>> > that may be superfluous. >>> >>> There is no guarantee that xx/yy/zz will give you any kind of security >>> in an unspecified environment. >>> >>> Henning Rogge >>> >>> _______________________________________________ >>> 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 > > --001a113f97beb332b4052b30a3e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I think the critical poi= nt here is Alvaro's comment:

> The main problem I see = with the text below is that it is based on
> assumptions =E2=80=94 even though you do say that "DLEP is restri= cted to=E2=80=A6a single
> (possibly logical) hop at layer 2", it is based on the deployment=
> assumptions.=C2=A0 What happens if it isn't deployed that way?

It's NOT an "assumption". We've mi= s-lableld it as an assumption. It's actually a requirement.
Henning= 's response to the above text is correct:

"It will = not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts as a
bridge (as in "layer-2 bridge") between the connection to the router
and the radio network."

Anyone attempting multi-hop = deployment will immediately bump into the issue of a router issuing packets= with a Destination MAC address that's not on the local segment. Traffi= c won't pass. As Henning states, it simply won't work.

I believe we need to move the following text from "Assump= tions" to "Requirements":

=C2=A0=C2=A0 DLEP assumes = that the MAC address for delivering data traffic is the
=C2=A0=C2=A0 MAC= address used by DLEP to identify the destination.=C2=A0 No
=C2=A0=C2=A0= manipulation or substitution is performed; the MAC address supplied
=C2= =A0=C2=A0 in all destination messages is used as the OSI Layer 2 Destinatio= n
=C2=A0=C2=A0 MAC address.=C2=A0 DLEP also assumes that MAC addresses a= re unique within
=C2=A0=C2=A0 the context of a router-modem session.
=
=C2=A0=C2=A0 The reliance on MAC addresses by DLEP forces the assumptio= n that
=C2=A0=C2=A0 participating DLEP peers are on a single segment (ei= ther physical or
=C2=A0=C2=A0 logically, via tunneling protocols) at Lay= er 2.


We also need to take the TLS flag out of the IPv4 and IPv6 C= onnection Point data items (a clear "miss" on our part). I believ= e this addresses the concern, in that 1-hop deployment is no longer an &quo= t;assumption".

Regards,
Stan


On= Sun, Feb 7, 2016 at 9:53 AM, Lou Berger <lberger@labn.net> w= rote:

Justin,

Two minor suggestions:

s/ link-local addresses/a directly attached IP sub-subnet/

And at then end of=C2=A0 b

Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and 802.1X.

Lou

On February 7, 2016 7:58:37 AM Justin Dean <bebemaster@gmail.com> wrote:

How about the following update?=C2=A0 Taken from bits= of Hennings' explanation here and Ran's proposed text from quite a while back.=C2=A0 Please note the difference in deployment and implement, a= nd the resulting what actually gets used in real deployments....

The potential security concerns when using DLEP are:
=C2=A0 =C2=A0
1.=C2=A0 An attacker might pret= end to be a DLEP peer, either at DLEP
=C2=A0 =C2=A0 session initialization, o= r by injection of messages once a
=C2=A0 =C2=A0 session has been estab= lished, and/or

2.=C2=A0 DLEP data items could be altered b= y an attacker, causing the
=C2=A0 =C2=A0 receiving implementation to inappropriately alter its information
=C2=A0 =C2=A0 base concerni= ng network status.

=C2=A0 =C2=A0DLEP is restricted to operati= on over a single (possibly
=C2=A0 =C2=A0logical) hop at layer 2; Deployment= s other than single-hop are=C2=A0
=C2=A0 =C2=A0not permitted and outside = the scope of this specification.
=C2=A0 =C2=A0Deployments requiring authentica= tion and/or encryption of traffic=C2=A0
=C2=A0 =C2=A0MUST take steps t= o secure the Layer 2 link.

All DLEP Implementations either:

(a) MUST implement Transport Layer Security (TLS)' [RFC-5246]=C2=A0
= so TLS is available for use when deployment dictate or=C2=A0
= (b) MUST restrict the valid IP (both IPv4 and IPv6) unicast=C2=A0
addresses for use with DLEP to link-local addresses.

=C2=A0 =C2=A0To avoid potential denial = of service attack, it is RECOMMENDED that
=C2=A0 =C2=A0implementations using= the Peer Discovery mechanism maintain an
=C2=A0 =C2=A0information base of = hosts that persistently fail Session
=C2=A0 =C2=A0Initialization having prov= ided an acceptable Discovery signal, and
=C2=A0 =C2=A0ignore Peer Discove= ry signals from such hosts.
=C2=A0 =C2=A0
=C2=A0 =C2=A0This specif= ication does not effect security of the data plane;=C2=A0
=C2=A0 =C2=A0standard se= curity procedures can be employed for the data plane.

On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge <hrogge@gmail.com> wrote:
On Sat, Feb 6, 2016 at 11:22= PM, Alvaro Retana (aretana)
<aretana@cisco.co= m> wrote:
> On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
> <manet-= bounces@ietf.org on behalf of rat= liffstan@gmail.com> wrote:
>
> Stan:
>
> Hi!
>
> You'll need references for L2 security.
>
> The main problem I see with the text below is that it is based on
> assumptions =E2=80=94 even though you do say that "DLEP is restri= cted to=E2=80=A6a single
> (possibly logical) hop at layer 2", it is based on the deployment=
> assumptions.=C2=A0 What happens if it isn't deployed that way?

It will not work because the user traffic will not reach the
destination. DLEP is the model of a "external radio" which acts as a
bridge (as in "layer-2 bridge") between the connection to the router
and the radio network.

If you are more than 1 IP-hop away you will not get the user traffic.

> What about confidentiality of the data?=C2=A0 What about exposing information
> about users (privacy)?

if you have one IP-hop between radio and router linklayer/MAC security
takes care of this. If not you are outside the specification of the
protocol and do something strange to the traffic anyways... so it
should not be DLEP's problem.

>=C2=A0 I know that the assumed deployment model makes it
> very hard to look at the data in flight between and the physical and L2
> security may well be enough.=C2=A0 However, what if DLEP is not used a= s expected?

If you break the basic assumptions of the protocol, you should not expect its security considerations to be secure in your situation.

> IMO, you should describe the expected operating environment (or point to the
> assumptions) and any security mechanisms that should be included there (L2,
> physical assumptions), and explain why confidentiality and privacy are not a
> concern=E2=80=A6

http://tools.ietf.org/html/dra= ft-ietf-manet-dlep-18#section-2.1

> but then you should also say something like: "if DLEP is used in an
> environment other then the expected one, then xx, yy and zz MUST/SHOULD be
> implemented".=C2=A0 =C2=A0I think that this way we would be cover= ing the normal case,
> but also providing an answer to what if without making mandatory mechanisms
> that may be superfluous.

There is no guarantee that xx/yy/zz will give you any kind of security
in an unspecified environment.

Henning Rogge

_______________________________________________
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


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


--001a113f97beb332b4052b30a3e2-- From nobody Sun Feb 7 09:46:38 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE571A016C for ; Sun, 7 Feb 2016 09:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOU180z_HIaf for ; Sun, 7 Feb 2016 09:46:35 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E351A016B for ; Sun, 7 Feb 2016 09:46:34 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id bc4so72528645lbc.2 for ; Sun, 07 Feb 2016 09:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dQM5XglccYcRSwZ3x4yZKCM93c8DJKTN8quKzRVYwMo=; b=DGm5qBt2YphHSKpz/pL9MOEcTO5zxV/h207c2qD7cXAFNP2BnHvCowbllMFWZuZA2s uxBSag4WTXonFDyIf6qX2wq31lhkw0EhIzRvNw7Uc/jumeMC+yhKD2GwQ0xz9i8T5uQY 6AoKnOsb1N/RcPfxcWdbRruU9L2QOWdvrhGV1Npz0TloBNEd8hirB7iJerOjvDZBs2JZ lwc6hidk/QVg51DUIyHxaaIYWy746g+sQau4n+rN4czupeNCqVpTvwXJlpUZel63IbOr xluTtJG7/87qNggwCVhchbocjh9PTsb+FIinZYJ3a3pYz9JkL/6rxp3Ud3FMGm/NK6Se VGaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dQM5XglccYcRSwZ3x4yZKCM93c8DJKTN8quKzRVYwMo=; b=PS+keQrdML064B7wAJ4ONEXFBU0uMhWq9GdIcBZm7FSuzKaX2wtLxrlJxGaQ66JmZ4 SAgy/MVWbwnUaTcukfSKtpnCRabtUNJfwDIjlrfCIBaQW6lFIkRHneFupkK9vol2CEWE 1/pZFYs75ID3T10unF7Osp0LaK4fq94dvpE77kPydNCbNKngqUUKh+Xow/msUuqflTXa hCzzIg0l6oJorXY3qoJi5XxuWSOTTntOMN7uQ/0tXxdKSWj1xCRjm2io5TAHg7nyUCcG xf5SdF+oW+INVklQoQy6M7RRXmq/nNyROa/3oMoLJ4SzPL3qhE33tFSIcLt9oDYGq8Fx +rAQ== X-Gm-Message-State: AG10YORjB30E1oFWtHPlQB7AHGwfKFypvmtHd8splcRJ1cz6C+vqMgy+gEoiTKBuHyjRTMkth6qhxDB6NN0OGA== X-Received: by 10.112.136.103 with SMTP id pz7mr9789230lbb.3.1454867192806; Sun, 07 Feb 2016 09:46:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.161.77 with HTTP; Sun, 7 Feb 2016 09:46:03 -0800 (PST) In-Reply-To: References: <152bc392e10.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Henning Rogge Date: Sun, 7 Feb 2016 18:46:03 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-18 Security Considerations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 17:46:36 -0000 On Sun, Feb 7, 2016 at 5:33 PM, Stan Ratliff wrote: > All, > > I think the critical point here is Alvaro's comment: > >> The main problem I see with the text below is that it is based on >> assumptions =E2=80=94 even though you do say that "DLEP is restricted to= =E2=80=A6a single >> (possibly logical) hop at layer 2", it is based on the deployment >> assumptions. What happens if it isn't deployed that way? > > It's NOT an "assumption". We've mis-lableld it as an assumption. It's > actually a requirement. Yes. > Henning's response to the above text is correct: > > "It will not work because the user traffic will not reach the > destination. DLEP is the model of a "external radio" which acts as a > bridge (as in "layer-2 bridge") between the connection to the router > and the radio network." > > Anyone attempting multi-hop deployment will immediately bump into the iss= ue > of a router issuing packets with a Destination MAC address that's not on = the > local segment. Traffic won't pass. As Henning states, it simply won't wor= k. > > I believe we need to move the following text from "Assumptions" to > "Requirements": > > DLEP assumes that the MAC address for delivering data traffic is the > MAC address used by DLEP to identify the destination. No > manipulation or substitution is performed; the MAC address supplied > in all destination messages is used as the OSI Layer 2 Destination > MAC address. DLEP also assumes that MAC addresses are unique within > the context of a router-modem session. > > The reliance on MAC addresses by DLEP forces the assumption that > participating DLEP peers are on a single segment (either physical or > logically, via tunneling protocols) at Layer 2. Correct. > We also need to take the TLS flag out of the IPv4 and IPv6 Connection Poi= nt > data items (a clear "miss" on our part). I believe this addresses the > concern, in that 1-hop deployment is no longer an "assumption". If we really want to do TLS we can always add a "TLS Connection Point" TLV in a later extension draft. We could also keep the flags field if we think its useful for later, but I think the TLV format is flexible enough to deal with it when we need a flags field. Henning From nobody Mon Feb 8 12:55:34 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974C31B3312 for ; Mon, 8 Feb 2016 12:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W6r7p_dOVQS for ; Mon, 8 Feb 2016 12:55:32 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3BE1B330B for ; Mon, 8 Feb 2016 12:55:31 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u18KtBQZ006031; Mon, 8 Feb 2016 15:55:11 -0500 From: "Wiggins, David - 0665 - MITLL" To: "manet@ietf.org" , Stan Ratliff Thread-Topic: DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQ== Date: Mon, 8 Feb 2016 20:55:29 +0000 Message-ID: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.147.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-08_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602080352 Archived-At: Subject: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 20:55:33 -0000 Here are some comments on the new Destination Announce/Response messages in= DLEP-18. 1. What are the IPv4/IPv6 data items for? If the MAC address is a multica= st address, are these supposed to be the IP multicast equivalents? 2. Other than canceling a previous status of Not Interested in a destinat= ion (from 3.1. Router-requested Destinations), is there any other case whe= re the router would use a unicast MAC address in a Destination Announce? 3. How does the router cancel (undo) a Destination Announce? Section 10.1= 8 hints that it is Destination Down, but I still have some uncertainty beca= use of the wording. 4. In section C.2, the router is shown as using Destination Up with a mult= icast group. I think this should now be using Destination Announce. 5. I have been assuming that when the router announces interest in a multi= cast group, this effectively causes a multicast join and results in data pl= ane traffic for that group to start flowing to the requesting router. This= is never stated, though, and it's an important side-effect that should be = called out. David From nobody Mon Feb 8 13:22:49 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521CC1B2DAE for ; Mon, 8 Feb 2016 13:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKTDPbC_6TR6 for ; Mon, 8 Feb 2016 13:22:44 -0800 (PST) Received: from smtp1.idirect.net (smtp1.idirect.net [198.180.159.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1641B2D87 for ; Mon, 8 Feb 2016 13:22:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,417,1449550800"; d="scan'208";a="3014202" IronPort-PHdr: =?us-ascii?q?9a23=3Akxb1Eh/h22mVkf9uRHKM819IXTAuvvDOBiVQ1KB8?= =?us-ascii?q?0ukcTK2v8tzYMVDF4r011RmSDdqdsaIP1rSe8/i5HzdfsdDZ6DFKWacPfiFGoP?= =?us-ascii?q?1epxYnDs+BBB+zB9/RRAt+Iv5/UkR49WqwK0lfFZW2TVTTpnqv8WxaQU2nZkJd?= =?us-ascii?q?b974EY/Kjsmxy/v6u9iKO10J13KBZuY4ExS5ogTXrY1erYJ8K6p5j1OR/CUVM6?= =?us-ascii?q?Ee4EJUAXbZ10LQ79mx8Nhc8itfuvQ638pEF6D7Y+I1QaEOSHxsNmkz6dHDtBTf?= =?us-ascii?q?Q02I/HRWGjETmxxFHyDE4Q30GJDrvX2+/tFh0S/SB8TqSbE6V3z29a53TB7mhj?= =?us-ascii?q?wbPjgR/2Tei8g2h6Ve9kGPvRt6lsTuaZ2RNfRwOuvmYdocQWdQFI4FTDZIHoe9?= =?us-ascii?q?YYUnDuYAJ+tTs8/7qkdY/kj2PhWlGO66kmwAvXTxx6Bvlr15SQw=3D?= X-IPAS-Result: =?us-ascii?q?A2DLAQA7BrlW/8r6+gpeDgsBAQEBDwEBAQGESQaIVa58ghM?= =?us-ascii?q?BDYFmhg0CgWcUAQEBAQEBAQGBCYItghQBAQEBAgE6MQYNBwQCAQgRBAEBHwkHI?= =?us-ascii?q?REUCQgBAQQBEgiHfgMKuSINhE8BAQEBAQEEAQEBAQEBGoYUhDWCN4Y1BYdVjxw?= =?us-ascii?q?EAYtcgWyOeoZ9h0EeAQGCRRmBDTtqhxoEOXwBAQE?= From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" , Stan Ratliff Thread-Topic: DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQAB2kSg Date: Mon, 8 Feb 2016 21:20:40 +0000 Message-ID: <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:22:48 -0000 David, = Answers from the perspective of someone who does *not* like Destination Ann= ounce... ;-) = > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David - > 0665 - MITLL > Sent: Monday, February 08, 2016 3:55 PM > To: manet@ietf.org; Stan Ratliff > Subject: [manet] DLEP-18 Destination Announce > = > Here are some comments on the new Destination Announce/Response > messages in DLEP-18. > = > 1. What are the IPv4/IPv6 data items for? If the MAC address is a multi= cast > address, are these supposed to be the IP multicast equivalents? Yes. But while I don't have a specific use-case in mind, I believe the use = of "router-discovered destinations" MAY well extend beyond MCAST. > = > 2. Other than canceling a previous status of Not Interested in a destin= ation > (from 3.1. Router-requested Destinations), is there any other case where > the router would use a unicast MAC address in a Destination Announce? Not currently. But see above - I think a use case may develop. = > = > 3. How does the router cancel (undo) a Destination Announce? Section > 10.18 hints that it is Destination Down, but I still have some uncertainty > because of the wording. > Yes, a Destination Announce is just a router-initiated "Destination Up". Af= ter a destination is available (either via Announce or Up), it can be broug= ht down by either partner. = = > 4. In section C.2, the router is shown as using Destination Up with a mu= lticast > group. I think this should now be using Destination Announce. > = Thanks! We'll put that on the list. = > 5. I have been assuming that when the router announces interest in a > multicast group, this effectively causes a multicast join and results in = data > plane traffic for that group to start flowing to the requesting router. = This is > never stated, though, and it's an important side-effect that should be ca= lled > out. The scheme so far with DLEP is to document (for interoperability) what cros= ses the wire, but *not* to document "what you'd do with this data". I'm not= a multicast expert; I'd rather not get into trying to document what someon= e would do with this message (either on the modem or the router side). For = example, I'd *assume* that a receiving modem would perform tasks (not neces= sarily in sequence) like: = - Modify its MAC listening table to include the MAC address in Destination = Announce (both on the RF and the LAN side) - Do any other allocation (buffers, queues) needed to flow the traffic, = - Determine a set of metrics for the Announced destination (in the MCAST ca= se, does it flow at full data rate? A lesser rate, like 802.11 would? Are t= here different latencies for MCAST? stuff like that). = But having said that, I'd *hate* to get into trying to list all of that - I= think we'd be spinning on DLEP for an eternity (plus 2 weeks). Regards, Stan _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Tue Feb 9 10:11:55 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDC51ACDF4 for ; Tue, 9 Feb 2016 10:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHfjb_lXjiiY for ; Tue, 9 Feb 2016 10:11:52 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 58B161ACDF2 for ; Tue, 9 Feb 2016 10:11:52 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u19IBUd7023523; Tue, 9 Feb 2016 13:11:30 -0500 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , "manet@ietf.org" , Stan Ratliff Thread-Topic: DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQAB2kSgACkzu2A= Date: Tue, 9 Feb 2016 18:11:49 +0000 Message-ID: <051CC8AC48CA52479811BF267278633A13304EBF@LLE2K10-MBX01.mitll.ad.local> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> In-Reply-To: <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-09_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602090314 Archived-At: Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:11:54 -0000 > Stan > > David > > 3. How does the router cancel (undo) a Destination Announce? Section > > 10.18 hints that it is Destination Down, but I still have some > > uncertainty because of the wording. >=20 > Yes, a Destination Announce is just a router-initiated "Destination Up". = After a > destination is available (either via Announce or Up), it can be brought d= own by > either partner. I didn't realize that (either side can Down a destination) until it was not= ed in the latest draft. I'm not sure how to handle the case where a modem declares a destination (l= et's say unicast) up and the router then says no, it's down. In most of th= e implementations I can imagine, the modem is going to know which destinati= ons are up and which are down. So when the router says one of them is down= , this may directly contradict the modem's reality. What's the modem suppo= sed to do? Forcibly take the destination down (may not be possible)? Reme= mber that the router said it's down, and don't send that router any more in= formation about that destination until the router later declares it up agai= n, kind of like a "not interested" status? Similar questions can be raised= about a router declaring a multicast destination up, and the modem then de= claring it down. The router knows which multicast groups it's interested i= n; the modem shouldn't presume to know better. I'd prefer it if the peer that declares a destination up is the only one th= at can declare it down. It's a simpler mental model that avoids the questi= ons above (and probably others). We have the "not interested" status that = lets a peer block information about a destination if so desired; is more th= an that really needed? > > 5. I have been assuming that when the router announces interest in a > > multicast group, this effectively causes a multicast join and results > > in data plane traffic for that group to start flowing to the > > requesting router. This is never stated, though, and it's an > > important side-effect that should be called out. >=20 > The scheme so far with DLEP is to document (for interoperability) what cr= osses > the wire, but *not* to document "what you'd do with this data". I'm not a > multicast expert; I'd rather not get into trying to document what someone > would do with this message (either on the modem or the router side). For > example, I'd *assume* that a receiving modem would perform tasks (not > necessarily in sequence) like: > - Modify its MAC listening table to include the MAC address in Destinatio= n > Announce (both on the RF and the LAN side) > - Do any other allocation (buffers, queues) needed to flow the traffic, > - Determine a set of metrics for the Announced destination (in the MCAST = case, > does it flow at full data rate? A lesser rate, like 802.11 would? Are the= re > different latencies for MCAST? stuff like that). >=20 > But having said that, I'd *hate* to get into trying to list all of that -= I think we'd > be spinning on DLEP for an eternity (plus 2 weeks). Agreed; it shouldn't go into that level of detail. Maybe just add one sent= ence like: "When a router sends a Destination Announce with a multicast destination, t= he modem should interpret this as the router's wish to receive traffic for= that multicast group." At least then the intent is clear, and an implemen= ter will probably know what to do. David From nobody Tue Feb 9 10:30:39 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4995B1ACE2A for ; Tue, 9 Feb 2016 10:30:37 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoPXOQpkTJBI for ; Tue, 9 Feb 2016 10:30:34 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746321ACE33 for ; Tue, 9 Feb 2016 10:30:34 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id ik10so114180310igb.1 for ; Tue, 09 Feb 2016 10:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3GV3VesYohxPLpHnNaweoY5srZNmP6nbF7CLfGfjXI=; b=zza2zoX7NoAD7Sib8b5t7HOXju5VpcjPJ9rMqi3TK4920RTauTXNkhTZvZki7/jq84 N5WgElE8cl/Ur1OZD7ORre+bopo6qaLwhNianUDguDRcjFZO/xovLqL/6gYjNEw3YWGd hE1Fjw0oBm4NTfzUTagiiWj9dKvSub5MgDZcc7TOL3Wwvn7IOpN6K0pVqmMWGn+ewUke 8Z+5aoX5ihNmfn3ewIoiC8PjkCPNWalUitkInqVfEbvWB5FjkSPCPf4GxJRj4VIBh7iK pZkQQ02zmVfmd6QtNsXu6OTNZzYua4kBAng2m+mUDdG4jHYIGWwCzSGcOU3wZeqTfy4G nNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f3GV3VesYohxPLpHnNaweoY5srZNmP6nbF7CLfGfjXI=; b=EowfAz3Hd+U0lAj0vqlZgPjEzRz7NEYJvTyocNZAehj+2TW9mYUTaPbSU9bmW2Xgol +A2ZaR3A1LHYbcr/K3Dt26bOGK4KZWuSWqtkfACyC0uT338ppDFR7FX4k7lYLi8pStiJ pK0gU3Gjc6tQX3Z6J1Q6SHoJnSc/pTGKwFe0kEVIFyx+823/XCX7fFQY1NX+OTsWvSeU w0abmXyECzYwpzCPZkQ0q9ilBwjMTkuV8iG3/Odcgbrz3WOwjIQjvL8uwYmT7joX9gpb RYod10RoevIBebOY7buDwDwiagE7BYps+fS3VQ/Yfg+uSFY7CYqFVIROkxGDjfJldvOs sHbA== X-Gm-Message-State: AG10YORyX+9APIBVFAOYyXstTKu1kWerW3L+tJ5Vgftj9VE9qWZMNrHk4MFkhDJSF+IrVsPjVQusRGVZPWwkYg== MIME-Version: 1.0 X-Received: by 10.50.25.167 with SMTP id d7mr5915967igg.69.1455042633890; Tue, 09 Feb 2016 10:30:33 -0800 (PST) Received: by 10.79.96.1 with HTTP; Tue, 9 Feb 2016 10:30:33 -0800 (PST) In-Reply-To: <051CC8AC48CA52479811BF267278633A13304EBF@LLE2K10-MBX01.mitll.ad.local> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> <051CC8AC48CA52479811BF267278633A13304EBF@LLE2K10-MBX01.mitll.ad.local> Date: Tue, 9 Feb 2016 13:30:33 -0500 Message-ID: From: Stan Ratliff To: "Wiggins, David - 0665 - MITLL" Content-Type: multipart/alternative; boundary=047d7bdc0fd6538436052b5a83ae Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:30:37 -0000 --047d7bdc0fd6538436052b5a83ae Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 1:11 PM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > > Stan > > > David > > > 3. How does the router cancel (undo) a Destination Announce? Section > > > 10.18 hints that it is Destination Down, but I still have some > > > uncertainty because of the wording. > > > > Yes, a Destination Announce is just a router-initiated "Destination Up". > After a > > destination is available (either via Announce or Up), it can be brought > down by > > either partner. > > I didn't realize that (either side can Down a destination) until it was > noted in the latest draft. > > I'm not sure how to handle the case where a modem declares a destination > (let's say unicast) up and the router then says no, it's down. In most of > the implementations I can imagine, the modem is going to know which > destinations are up and which are down. So when the router says one of > them is down, this may directly contradict the modem's reality. What's the > modem supposed to do? Forcibly take the destination down (may not be > possible)? Remember that the router said it's down, and don't send that > router any more information about that destination until the router later > declares it up again, kind of like a "not interested" status? Similar > questions can be raised about a router declaring a multicast destination > up, and the modem then declaring it down. The router knows which multicast > groups it's interested in; the modem shouldn't presume to know better. > It wasn't intended to contradict reality - just update the state of "DLEP Reality". The Destination Down is more of a way to say "I don't want to hear anymore DLEP info on this destination", or "I'm not going to send anymore DLEP information on this destination". There's no reason that data traffic can't continue to flow. > > I'd prefer it if the peer that declares a destination up is the only one > that can declare it down. It's a simpler mental model that avoids the > questions above (and probably others). We have the "not interested" status > that lets a peer block information about a destination if so desired; is > more than that really needed? > It's more state information that has to be carried; more of an opportunity for things to go wrong. In the case where one of the session partners (either router or modem) doesn't want DLEP info for a given destination, sending "Destination Down" is as good a way as any other to say "Stop it". The "Not Interested" status was a way to "NACK" a Dest Up - but when a router initially *is* interested, and then ceases to be? And on the modem side - as an example, I believe some satellites use different transponders/beams for multicast vs. unicast. Therefore, it's possible that multicast could stop, while unicast transmission is still enabled (an operator shut the MCAST transponder down for maintenance, for example). So, what's a poor modem to do, especially in the case where he's already responded to "Destination Announce" for one or more MCAST groups? The model you propose, by necessity, now requires one end to be able to "ask" the other for a Destination Down... > > > > 5. I have been assuming that when the router announces interest in a > > > multicast group, this effectively causes a multicast join and results > > > in data plane traffic for that group to start flowing to the > > > requesting router. This is never stated, though, and it's an > > > important side-effect that should be called out. > > > > The scheme so far with DLEP is to document (for interoperability) what > crosses > > the wire, but *not* to document "what you'd do with this data". I'm not a > > multicast expert; I'd rather not get into trying to document what someone > > would do with this message (either on the modem or the router side). For > > example, I'd *assume* that a receiving modem would perform tasks (not > > necessarily in sequence) like: > > - Modify its MAC listening table to include the MAC address in > Destination > > Announce (both on the RF and the LAN side) > > - Do any other allocation (buffers, queues) needed to flow the traffic, > > - Determine a set of metrics for the Announced destination (in the MCAST > case, > > does it flow at full data rate? A lesser rate, like 802.11 would? Are > there > > different latencies for MCAST? stuff like that). > > > > But having said that, I'd *hate* to get into trying to list all of that > - I think we'd > > be spinning on DLEP for an eternity (plus 2 weeks). > > Agreed; it shouldn't go into that level of detail. Maybe just add one > sentence like: > "When a router sends a Destination Announce with a multicast destination, > the modem should interpret this as the router's wish to receive traffic > for that multicast group." At least then the intent is clear, and an > implementer will probably know what to do. > I'll see what I can work into the text. Regards, Stan --047d7bdc0fd6538436052b5a83ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 9, 2016 at 1:11 PM, Wiggins, David - 0665 - MITLL <= David.Wiggins@ll.mit.edu> wrote:
> Stan
> > David
> > 3.=C2=A0 How does the router cancel (undo) a Destination Announce= ?=C2=A0 Section
> > 10.18 hints that it is Destination Down, but I still have some > > uncertainty because of the wording.
>
> Yes, a Destination Announce is just a router-initiated "Destinati= on Up". After a
> destination is available (either via Announce or Up), it can be brough= t down by
> either partner.

I didn't realize that (either side can Down a destination) until it was= noted in the latest draft.

I'm not sure how to handle the case where a modem declares a destinatio= n (let's say unicast) up and the router then says no, it's down.=C2= =A0 In most of the implementations I can imagine, the modem is going to kno= w which destinations are up and which are down.=C2=A0 So when the router sa= ys one of them is down, this may directly contradict the modem's realit= y.=C2=A0 What's the modem supposed to do?=C2=A0 Forcibly take the desti= nation down (may not be possible)?=C2=A0 Remember that the router said it&#= 39;s down, and don't send that router any more information about that d= estination until the router later declares it up again, kind of like a &quo= t;not interested" status?=C2=A0 Similar questions can be raised about = a router declaring a multicast destination up, and the modem then declaring= it down.=C2=A0 The router knows which multicast groups it's interested= in; the modem shouldn't presume to know better.
<= br>
It wasn't intended to contradict reality - just update th= e state of "DLEP Reality". The Destination Down is more of a way = to say "I don't want to hear anymore DLEP info on this destination= ", or "I'm not going to send anymore DLEP information on this= destination". There's no reason that data traffic can't conti= nue to flow.=C2=A0
=C2=A0

I'd prefer it if the peer that declares a destination up is the only on= e that can declare it down.=C2=A0 It's a simpler mental model that avoi= ds the questions above (and probably others).=C2=A0 We have the "not i= nterested" status that lets a peer block information about a destinati= on if so desired; is more than that really needed?
It's more state information that has to be carried; more of= an opportunity for things to go wrong. In the case where one of the sessio= n partners (either router or modem) doesn't want DLEP info for a given = destination, sending "Destination Down" is as good a way as any o= ther to say "Stop it". The "Not Interested" status was = a way to "NACK" a Dest Up - but when a router initially *is* inte= rested, and then ceases to be?=C2=A0

And on the mo= dem side - as an example, I believe some satellites use different transpond= ers/beams for multicast vs. unicast. Therefore, it's possible that mult= icast could stop, while unicast transmission is still enabled (an operator = shut the MCAST transponder down for maintenance, for example). So, what'= ;s a poor modem to do, especially in the case where he's already respon= ded to "Destination Announce" for one or more MCAST groups? The m= odel you propose, by necessity, now requires one end to be able to "as= k" the other for a Destination Down...=C2=A0
=C2=A0
=C2=A0

> > 5.=C2=A0 I have been assuming that when the router announces inte= rest in a
> > multicast group, this effectively causes a multicast join and res= ults
> > in data plane traffic for that group to start flowing to the
> > requesting router.=C2=A0 This is never stated, though, and it'= ;s an
> > important side-effect that should be called out.
>
> The scheme so far with DLEP is to document (for interoperability) what= crosses
> the wire, but *not* to document "what you'd do with this data= ". I'm not a
> multicast expert; I'd rather not get into trying to document what = someone
> would do with this message (either on the modem or the router side). F= or
> example, I'd *assume* that a receiving modem would perform tasks (= not
> necessarily in sequence) like:
> - Modify its MAC listening table to include the MAC address in Destina= tion
> Announce (both on the RF and the LAN side)
> - Do any other allocation (buffers, queues) needed to flow the traffic= ,
> - Determine a set of metrics for the Announced destination (in the MCA= ST case,
> does it flow at full data rate? A lesser rate, like 802.11 would? Are = there
> different latencies for MCAST? stuff like that).
>
> But having said that, I'd *hate* to get into trying to list all of= that - I think we'd
> be spinning on DLEP for an eternity (plus 2 weeks).

Agreed; it shouldn't go into that level of detail.=C2=A0 Maybe just add= one sentence like:
"When a router sends a Destination Announce with a multicast destinati= on, the modem should interpret this as the=C2=A0 router's wish to recei= ve traffic for that multicast group."=C2=A0 At least then the intent i= s clear, and an implementer will probably know what to do.
=

I'll see what I can work into the text.=C2=A0
=

Regards,
Stan

--047d7bdc0fd6538436052b5a83ae-- From nobody Tue Feb 9 14:30:26 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712F1B2D11 for ; Tue, 9 Feb 2016 14:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwgOVO-nMywJ for ; Tue, 9 Feb 2016 14:30:23 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B3C111B2D03 for ; Tue, 9 Feb 2016 14:30:23 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u19MU1gX005384; Tue, 9 Feb 2016 17:30:01 -0500 From: "Wiggins, David - 0665 - MITLL" To: Stan Ratliff Thread-Topic: DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQAB2kSgACkzu2AADgtkgAAEBeLg Date: Tue, 9 Feb 2016 22:30:21 +0000 Message-ID: <051CC8AC48CA52479811BF267278633A13304F91@LLE2K10-MBX01.mitll.ad.local> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> <051CC8AC48CA52479811BF267278633A13304EBF@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-09_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602090396 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:30:25 -0000 KGFwb2xvZ2llcyBmb3IgdGhlIGZ1bmt5IGF0dHJpYnV0aW9uczsgb3V0bG9vayBtYWRlIGEgbWVz cyBhbmQgSSBjbGVhbmVkIGl0IHVwIGJ5IGhhbmQpDQoNClN0YW4gd3JvdGU6DQpJdCB3YXNuJ3Qg aW50ZW5kZWQgdG8gY29udHJhZGljdCByZWFsaXR5IC0ganVzdCB1cGRhdGUgdGhlIHN0YXRlIG9m ICJETEVQIFJlYWxpdHkiLiBUaGUgRGVzdGluYXRpb24gRG93biBpcyBtb3JlIG9mIGEgd2F5IHRv IHNheSAiSSBkb24ndCB3YW50IHRvIGhlYXIgYW55bW9yZSBETEVQIGluZm8gb24gdGhpcyBkZXN0 aW5hdGlvbiIsIG9yICJJJ20gbm90IGdvaW5nIHRvIHNlbmQgYW55bW9yZSBETEVQIGluZm9ybWF0 aW9uIG9uIHRoaXMgZGVzdGluYXRpb24iLiBUaGVyZSdzIG5vIHJlYXNvbiB0aGF0IGRhdGEgdHJh ZmZpYyBjYW4ndCBjb250aW51ZSB0byBmbG93LsKgDQoNCkRhdmlkOg0KSG93IGFib3V0IHVzaW5n IERlc3RpbmF0aW9uIFVwZGF0ZSB3aXRoIHN0YXR1cz1Ob3QgSW50ZXJlc3RlZMKgdG8gc2F5ICIg SSBkb24ndCB3YW50IHRvIGhlYXIgYW55bW9yZSBETEVQIGluZm8gb24gdGhpcyBkZXN0aW5hdGlv biI/ICAgSGF2aW5nIGp1c3Qgb25lIHdheSB0byBleHByZXNzIHRoaXMgc2VlbXMgYmV0dGVyIHRo YW4gaGF2aW5nIHR3byAoTm90IEludGVyZXN0ZWQgYW5kIERlc3RpbmF0aW9uIERvd24pLg0KDQpG b3IgdGhlICAiSSdtIG5vdCBnb2luZyB0byBzZW5kIGFueSBtb3JlIERMRVAgaW5mb3JtYXRpb24g b24gdGhpcyBkZXN0aW5hdGlvbiIgY2FzZSwgaWYgYSBtb2RlbSBkZWNsYXJlcyBhIGRlc3RpbmF0 aW9uIHVwLCB0aGVuIGRvd24sIGFuZCBkYXRhIHRyYWZmaWMgY29udGludWVzIHRvIGZsb3cgdG8g dGhlIHJvdXRlciBmb3IgdGhhdCBkZXN0aW5hdGlvbiBmb3IgYSBzaWduaWZpY2FudCBhbW91bnQg b2YgdGltZSBhZnRlcndhcmQsIHRoYXQgc2VlbXMgd3JvbmcgdG8gbWUuICBJIGd1ZXNzIGlmIHlv dSB0YWtlIHRoZSB2aWV3IHRoYXQgRExFUCBtZXNzYWdlcyBhcmUgb25seSBtZWFuaW5nZnVsIGlu c2lkZSBETEVQLCBhbmQgaGF2ZSBubyBlZmZlY3Qgb24gdGhlIHdvcmxkIG91dHNpZGUgb2YgRExF UCwgdGhlbiBpdCB3b3Jrcy4gIEEgRExFUCBpc2xhbmQgdGhhdCBkb2Vzbid0IGFmZmVjdCBhbnl0 aGluZyBvdXRzaWRlIGl0c2VsZiwgb3IgYWZmZWN0cyB0aGUgb3V0c2lkZSB3b3JsZCBpbiB1bmRl ZmluZWQgd2F5cywgZG9lc24ndCBzZWVtIHZlcnkgdXNlZnVsLCB0aG91Z2guICBJIHVuZGVyc3Rh bmQgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGdldCBpbnRvIHRoZSBidXNpbmVzcyBvZiBzcGVjaWZ5 aW5nIGluIGdyZWF0IGRldGFpbCB3aGF0IHRoZSBlZmZlY3RzIGFyZSwgYnV0IHN0YXlpbmcgc2ls ZW50IG9uIHRoZXNlIGludGVyYWN0aW9ucyBtZWFucyBkaWZmZXJlbnQgaW1wbGVtZW50ZXJzIGFy ZSBnb2luZyB0byBhc3N1bWUgZGlmZmVyZW50IHRoaW5ncy4gIEkgaG9wZSB0aGVyZSBpcyBhIG1p ZGRsZSBncm91bmQuDQoNClN0YW4gd3JvdGU6DQpBbmQgb24gdGhlIG1vZGVtIHNpZGUgLSBhcyBh biBleGFtcGxlLCBJIGJlbGlldmUgc29tZSBzYXRlbGxpdGVzIHVzZSBkaWZmZXJlbnQgdHJhbnNw b25kZXJzL2JlYW1zIGZvciBtdWx0aWNhc3QgdnMuIHVuaWNhc3QuIFRoZXJlZm9yZSwgaXQncyBw b3NzaWJsZSB0aGF0IG11bHRpY2FzdCBjb3VsZCBzdG9wLCB3aGlsZSB1bmljYXN0IHRyYW5zbWlz c2lvbiBpcyBzdGlsbCBlbmFibGVkIChhbiBvcGVyYXRvciBzaHV0IHRoZSBNQ0FTVCB0cmFuc3Bv bmRlciBkb3duIGZvciBtYWludGVuYW5jZSwgZm9yIGV4YW1wbGUpLiBTbywgd2hhdCdzIGEgcG9v ciBtb2RlbSB0byBkbywgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB3aGVyZSBoZSdzIGFscmVhZHkg cmVzcG9uZGVkIHRvICJEZXN0aW5hdGlvbiBBbm5vdW5jZSIgZm9yIG9uZSBvciBtb3JlIE1DQVNU IGdyb3Vwcz8gVGhlIG1vZGVsIHlvdSBwcm9wb3NlLCBieSBuZWNlc3NpdHksIG5vdyByZXF1aXJl cyBvbmUgZW5kIHRvIGJlIGFibGUgdG8gImFzayIgdGhlIG90aGVyIGZvciBhIERlc3RpbmF0aW9u IERvd24uLi7CoA0KwqANCkRhdmlkOg0KVGhlIG1vZGVtIHdvdWxkIGp1c3QgY29udGludWUgdG8g ZG8gaXRzIGJlc3QgdG8gZGVsaXZlciB0aGUgcmVxdWVzdGVkIHRyYWZmaWMgdG8gdGhlIHJvdXRl ci4gIFNvbWV0aW1lcyBpdCB3b3VsZCBub3QgYmUgYWJsZSB0by4gIEkgd291bGRuJ3QgaGF2ZSBl eHBlY3RlZCBhbnkgRExFUCBtZXNzYWdlcyB3b3VsZCBiZSBuZWVkZWQgaW4gZWl0aGVyIGRpcmVj dGlvbiBmb3IgYSB0cmFmZmljIGludGVycnVwdGlvbi4gIElmIHRoaXMgaXMgZXhwZWN0ZWQsIGl0 IG5lZWRzIHRvIGJlIHNwZWNpZmllZC4NCg0KVGhhbmtzLA0KDQpEYXZpZA0KDQo= From nobody Tue Feb 9 15:34:25 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526891B2E35 for ; Tue, 9 Feb 2016 15:34:24 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUkgq_cWlJoN for ; Tue, 9 Feb 2016 15:34:21 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC611B2E30 for ; Tue, 9 Feb 2016 15:34:21 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id 5so3035549igt.0 for ; Tue, 09 Feb 2016 15:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNRq/4Ewnots/n15UbL/1HXk/xuwkM96QaqfYDuaUF8=; b=QBvNbgOF34uVbNmAEwqm5U7xzgkffHyJDttzr6nRchJJBnoCEX9CKmjhdJLktreW3o hcwAP1tZp3GDR00gCHbGHkSAP2hb8DdtH3kAGVWnmkhyZ1SVZ2BHlY/KRczb3K8oltXg mgxz9NEhOxkHQ4i74S973Toy5gtrT6rz1UizssNDCWgtdpjO4y7Q7kP5tnjJaVeyDGr4 yNnYXoS6uF/V43Sb81/nedbE53YkL4kjYqGZmQ0r/VJXVRjLym+52S8CTbAgEjV6kdDm V0m8L2sx4nOAoFNpw9MMgROZ7jeYtgITWUUGw6Oqq6tInh4l7K6AgrpbpWjQVocXjRGH m7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mNRq/4Ewnots/n15UbL/1HXk/xuwkM96QaqfYDuaUF8=; b=kzjAiEusbMZSybkBal8Xtd3i7XgQVCLbwa8Q+IoxtPqmyDAZbSEpe1acTSaT+mTZm5 ahZmoy3GTOEIQIC8cjUkLz7xIhEf0yczXAo/HAIoCs76CpzBKeyafJrglKQGb+YgVU69 5/8p4l11KZgz453dj8qHl6Mfor2gB7d4RThusBntiabueB3+v02zaTzJv51phOE9T9mC VMprahjzfXs39atWkwPV5TanSG08HmW6cCDSr8HHl1wJRcIkjZQ/vflw8SVXPu9iC909 sg92oGBZLubWMM8DZ60K7Fbzfus7kqE/5KSb4UMm3bCr52zV0gvSOQrxZK2PlUc/4TSN HLAw== X-Gm-Message-State: AG10YOQGXdD4aWwdl+pwf2hAx9T6ilvbHFjaCS4BkWrFe5wpfn5I+/XpvDHjFbX3bJVmADmzhq/ry6xnfLaJvQ== MIME-Version: 1.0 X-Received: by 10.50.80.14 with SMTP id n14mr7154782igx.85.1455060860955; Tue, 09 Feb 2016 15:34:20 -0800 (PST) Received: by 10.79.96.1 with HTTP; Tue, 9 Feb 2016 15:34:20 -0800 (PST) In-Reply-To: <051CC8AC48CA52479811BF267278633A13304F91@LLE2K10-MBX01.mitll.ad.local> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <58d8a6b3b42d40f18b699f20f0f672a7@VAUSDITCHM2.idirect.net> <051CC8AC48CA52479811BF267278633A13304EBF@LLE2K10-MBX01.mitll.ad.local> <051CC8AC48CA52479811BF267278633A13304F91@LLE2K10-MBX01.mitll.ad.local> Date: Tue, 9 Feb 2016 18:34:20 -0500 Message-ID: From: Stan Ratliff To: "Wiggins, David - 0665 - MITLL" Content-Type: multipart/alternative; boundary=089e0149c0c6be7ad5052b5ec10a Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:34:24 -0000 --089e0149c0c6be7ad5052b5ec10a Content-Type: text/plain; charset=UTF-8 David, Sorry about that. I guess I need to stop using Outlook for IETF mails... On Tue, Feb 9, 2016 at 5:30 PM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > (apologies for the funky attributions; outlook made a mess and I cleaned > it up by hand) > > Stan wrote: > It wasn't intended to contradict reality - just update the state of "DLEP > Reality". The Destination Down is more of a way to say "I don't want to > hear anymore DLEP info on this destination", or "I'm not going to send > anymore DLEP information on this destination". There's no reason that data > traffic can't continue to flow. > > David: > How about using Destination Update with status=Not Interested to say " I > don't want to hear anymore DLEP info on this destination"? Having just > one way to express this seems better than having two (Not Interested and > Destination Down). > We absolutely *could* do Destination Update, but I don't think we "should*. In fact, we could've (and perhaps it would have been better) to just NACK the Destination Up instead of providing the "Not Interested" status. To be honest, I don't really look at this as having two ways to do something - the Dest Up needs to be either ACKed or NACKed. Once a DLEP pair understands that a destination is out there, and metrics are presented and processed for it, there has to be a way, for *either* one of the pair, to say "Stop" for some reason. At least for me, this discussion starts to be a circular one, because when asked "What would I do with one of these 'Not Interested' status code on a Destination Update?", my response would be "process it just like you got a Destination Down"... > > For the "I'm not going to send any more DLEP information on this > destination" case, if a modem declares a destination up, then down, and > data traffic continues to flow to the router for that destination for a > significant amount of time afterward, that seems wrong to me. I guess if > you take the view that DLEP messages are only meaningful inside DLEP, and > have no effect on the world outside of DLEP, then it works. A DLEP island > that doesn't affect anything outside itself, or affects the outside world > in undefined ways, doesn't seem very useful, though. I understand that we > don't want to get into the business of specifying in great detail what the > effects are, but staying silent on these interactions means different > implementers are going to assume different things. I hope there is a > middle ground. > I have communicated poorly. Let me take another stab at it: Presentation of a Destination Down effective says that the sender is no longer capable of understanding the state (whether the far end is a member of the RF network or not) of the Destination, and/or is no longer capable of producing or processing metrics for the destination. Does that have impact on the data traffic? I sure hope so. But as to "staying silent on these interactions" - I believe that documenting said impact is well outside the scope of DLEP. I have no idea how to wrap my head around how we'd even begin to do that, and I suspect it would take, at a minimum, another 6 years. From my perspective, it approaches a boiling of the ocean, which I didn't sign on to document, nor do I think this WG should try to document; not to mention that (IMO still) it stifles innovation with the protocol. We can document the protocol such that the DLEP machinery is consistent & interoperable; but I think the broader implications are beyond this one working group. > > Stan wrote: > And on the modem side - as an example, I believe some satellites use > different transponders/beams for multicast vs. unicast. Therefore, it's > possible that multicast could stop, while unicast transmission is still > enabled (an operator shut the MCAST transponder down for maintenance, for > example). So, what's a poor modem to do, especially in the case where he's > already responded to "Destination Announce" for one or more MCAST groups? > The model you propose, by necessity, now requires one end to be able to > "ask" the other for a Destination Down... > > David: > The modem would just continue to do its best to deliver the requested > traffic to the router. Sometimes it would not be able to. I wouldn't have > expected any DLEP messages would be needed in either direction for a > traffic interruption. If this is expected, it needs to be specified. > But in the case I presented, MCAST traffic would *not* be deliverable for an indeterminate amount of time (until the operations staff re-enables the transponder). I don't see how leaving the Destination 'Up' in this case helps anything. Regards, Stan --089e0149c0c6be7ad5052b5ec10a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

Sorry about that. I guess I need= to stop using Outlook for IETF mails...

On Tue, Feb 9, 2016 at 5:30 PM, Wiggins, Da= vid - 0665 - MITLL <David.Wiggins@ll.mit.edu> wrote:<= br>
(apologies for the funky attributions; ou= tlook made a mess and I cleaned it up by hand)

Stan wrote:
It wasn't intended to contradict reality - just update the state of &qu= ot;DLEP Reality". The Destination Down is more of a way to say "I= don't want to hear anymore DLEP info on this destination", or &qu= ot;I'm not going to send anymore DLEP information on this destination&q= uot;. There's no reason that data traffic can't continue to flow.= =C2=A0

David:
How about using Destination Update with status=3DNot Interested=C2=A0to say= " I don't want to hear anymore DLEP info on this destination"= ;?=C2=A0 =C2=A0Having just one way to express this seems better than having= two (Not Interested and Destination Down).

=
We absolutely *could* do Destination Update, but I don't think we = "should*. In fact, we could've (and perhaps it would have been bet= ter) to just NACK the Destination Up instead of providing the "Not Int= erested" status. To be honest, I don't really look at this as havi= ng two ways to do something - the Dest Up needs to be either ACKed or NACKe= d. Once a DLEP pair understands that a destination is out there, and metric= s are presented and processed for it, there has to be a way, for *either* o= ne of the pair, to say "Stop" for some reason. At least for me, t= his discussion starts to be a circular one, because when asked "What w= ould I do with one of these 'Not Interested' status code on a Desti= nation Update?", my response would be "process it just like you g= ot a Destination Down"...
=C2=A0

For the=C2=A0 "I'm not going to send any more DLEP information on = this destination" case, if a modem declares a destination up, then dow= n, and data traffic continues to flow to the router for that destination fo= r a significant amount of time afterward, that seems wrong to me.=C2=A0 I g= uess if you take the view that DLEP messages are only meaningful inside DLE= P, and have no effect on the world outside of DLEP, then it works.=C2=A0 A = DLEP island that doesn't affect anything outside itself, or affects the= outside world in undefined ways, doesn't seem very useful, though.=C2= =A0 I understand that we don't want to get into the business of specify= ing in great detail what the effects are, but staying silent on these inter= actions means different implementers are going to assume different things.= =C2=A0 I hope there is a middle ground.

I have communicated poorly. Let me take another stab at it:=C2=A0=C2=A0 Pr= esentation of a Destination Down effective says that the sender is no longe= r capable of understanding the state (whether the far end is a member of th= e RF network or not) of the Destination, and/or is no longer capable of pro= ducing or processing metrics for the destination. Does that have impact on = the data traffic? I sure hope so.

But as to "staying silent on= these interactions" - I believe that documenting said impact is well = outside the scope of DLEP. I have no idea how to wrap my head around how we= 'd even begin to do that, and I suspect it would take, at a minimum, an= other 6 years. From my perspective, it approaches a boiling of the ocean, w= hich I didn't sign on to document, nor do I think this WG should try to= document; not to mention that (IMO still) it stifles innovation with the p= rotocol. We can document the protocol such that the DLEP machinery is consi= stent & interoperable; but I think the broader implications are beyond = this one working group.=C2=A0
=C2=A0

Stan wrote:
And on the modem side - as an example, I believe some satellites use differ= ent transponders/beams for multicast vs. unicast. Therefore, it's possi= ble that multicast could stop, while unicast transmission is still enabled = (an operator shut the MCAST transponder down for maintenance, for example).= So, what's a poor modem to do, especially in the case where he's a= lready responded to "Destination Announce" for one or more MCAST = groups? The model you propose, by necessity, now requires one end to be abl= e to "ask" the other for a Destination Down...=C2=A0
=C2=A0
David:
The modem would just continue to do its best to deliver the requested traff= ic to the router.=C2=A0 Sometimes it would not be able to.=C2=A0 I wouldn&#= 39;t have expected any DLEP messages would be needed in either direction fo= r a traffic interruption.=C2=A0 If this is expected, it needs to be specifi= ed.

But in the case I presented, MCAST = traffic would *not* be deliverable for an indeterminate amount of time (unt= il the operations staff re-enables the transponder). I don't see how le= aving the Destination 'Up' in this case helps anything.

Regards,
Stan


--089e0149c0c6be7ad5052b5ec10a-- From nobody Tue Feb 9 21:25:33 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE21B3727 for ; Tue, 9 Feb 2016 21:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 350-ga9nlYML for ; Tue, 9 Feb 2016 21:25:29 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0921B3720 for ; Tue, 9 Feb 2016 21:25:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HaKVDFLYIpzrKOllFvZ7A/rxZR5tLvpC1SwO6m9cE7HCOlsHrkKQtAWZ+jzH6ZHr; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.56] (helo=[192.168.1.68]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1aTNHH-0005sq-9J for manet@ietf.org; Wed, 10 Feb 2016 00:25:23 -0500 To: manet References: <241ccb422cb941bda2617d7be275c649@VAUSDITCHM2.idirect.net> <9948DF10-0B9B-404E-BA09-C90CDE209756@thomasclausen.org> From: Charlie Perkins Message-ID: <56BAC9C0.6040301@earthlink.net> Date: Tue, 9 Feb 2016 21:25:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090004050404070408050309" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7664a309081c18092304ff0131b0a6d0a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.56 Archived-At: Subject: Re: [manet] Loops & Specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 05:25:31 -0000 This is a multi-part message in MIME format. --------------090004050404070408050309 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello folks, I read with some interest the paper claiming that sequence numbers do not guarantee loop freedom: > > http://www.cse.unsw.edu.au/~rvg/pub/AODVloop.pdf > It turns out that sequence numbers do guarantee loop freedom after all, contrary to the title of the paper. But it is possible to put bugs in various places that violate the hypotheses of the proof of loop freedom. Getting inconsistent results due to bugs is not shocking news. Since the claimed loop condition pertains to RFC 3561, I should not dive into the details about that. I did check whether there is any impact on AODVv2, and the answer is that it does NOT have any impact. 1. Section 4.4 of AODVv2 clearly forbids storing a stale sequence number in a "self-entry" such as described in the paper 2. Section 7.4.2 of AODVv2 clearly forbids the erroneous interpretation leading to faulty handling of RERR as described in the paper 3. I have reviewed RFC 3561 as part of reading their email, and I believe that some of the interpretations made by the authors are due to possible ambiguities in RFC 3561, combined with interpretations that ignore mandates in RFC 3561, intertwined with some confusion about the ways that a router should keep routes to itself. More information about the discussion related to RFC 3561 is not germane to AODVv2, but available upon request. Regards, Charlie P. --------------090004050404070408050309 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello folks,

I read with some interest the paper claiming that sequence numbers do not guarantee loop freedom:



It turns out that sequence numbers do guarantee loop freedom after all, contrary to the title of the paper. But it is possible to put bugs in various places that violate the hypotheses of the proof of loop freedom. Getting inconsistent results due to bugs is not shocking news.

Since the claimed loop condition pertains to RFC 3561, I should not dive into the details about that. I did check whether there is any impact on AODVv2, and the answer is that it does NOT have any impact.
  1. Section 4.4 of AODVv2 clearly forbids storing a stale sequence number in a "self-entry" such as described in the paper
  2. Section 7.4.2 of AODVv2 clearly forbids the erroneous interpretation leading to faulty handling of RERR as described in the paper
  3. I have reviewed RFC 3561 as part of reading their email, and I believe that some of the interpretations made by the authors are due to possible ambiguities in RFC 3561, combined with interpretations that ignore mandates in RFC 3561, intertwined with some confusion about the ways that a router should keep routes to itself. More information about the discussion related to RFC 3561 is not germane to AODVv2, but available upon request.
Regards,
Charlie P.


--------------090004050404070408050309-- From nobody Wed Feb 10 07:47:22 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2991B2C37 for ; Wed, 10 Feb 2016 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQX2BI7-lDTH for ; Wed, 10 Feb 2016 07:47:18 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2641B2C2F for ; Wed, 10 Feb 2016 07:46:50 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 10 Feb 2016 15:46:17 +0000 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" , Stan Ratliff Thread-Topic: [manet] DLEP-18 Destination Announce Thread-Index: AQHRZBosLbSXQBKICkOVG2wXSUBAow== Date: Wed, 10 Feb 2016 15:46:15 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 15:47:20 -0000 Sorry to fork the thread, but here are some answers from someone who =0A= does like Destination Announce.=0A= =0A= First, thank you David for picking up on Destination Announce, as I =0A= think it is an important change in this draft.=0A= =0A= Some background: I pushed for Destination Announce after I began to =0A= believe that many readers of earlier drafts of DLEP were unaware that =0A= Destination Up and Down messages could flow in *both* directions. That =0A= is from routers to modems as well as the more common modem to router. =0A= In an attempt to clarify, I put in the Destination Announce messages to =0A= replace router-initiated Destination Up messages. Originally they were =0A= called Destination Interest messages, as they are supposed to indicate =0A= that a router is interested in a currently unavailable destination, and =0A= would like the modem to talk about it.=0A= =0A= Comments inline...=0A= =0A= On 08/02/16 20:55, Wiggins, David - 0665 - MITLL wrote:=0A= > Here are some comments on the new Destination Announce/Response messages = in DLEP-18.=0A= >=0A= > 1. What are the IPv4/IPv6 data items for? If the MAC address is a multi= cast address, are these supposed to be the IP multicast equivalents?=0A= =0A= They are there because Destination Announce is inherited from =0A= Destination Up, and I see no reason to remove them. As Stan said, there = =0A= may be future use-cases where they are useful.=0A= =0A= >=0A= > 2. Other than canceling a previous status of Not Interested in a destin= ation (from 3.1. Router-requested Destinations), is there any other case w= here the router would use a unicast MAC address in a Destination Announce?= =0A= =0A= As Stan said before: one day there might be, and I can see no reason to =0A= prevent unicast MAC addresses being used. One potential option for =0A= 'on-demand' unicast destinations is perhaps triggering some proactive =0A= layer-2 routing protocol in the modem, to go find a viable path to the =0A= destination across some meshing radio net?=0A= =0A= >=0A= > 3. How does the router cancel (undo) a Destination Announce? Section 10= .18 hints that it is Destination Down, but I still have some uncertainty be= cause of the wording.=0A= =0A= The wording may well need another pass.=0A= =0A= What I was trying to say was that although Destination Up is no longer =0A= bidirectional, Destination Down may be sent by either peer at any time. =0A= From a modem's perspective, when a Destination 'goes away' it MUST =0A= inform the router via Destination Down, whether the destination was =0A= Announced, or Upped. From a router's perspective, if it no longer wants = =0A= updates concerning a destination, it may send a Destination Down, as a =0A= kind of 'unsubscribe' message.=0A= =0A= If the WG think it would be better to only allow Destination Downs to =0A= flow from modem to router, and to add a new 'Destination Unsubscribe' =0A= message to flow from router to modem instead, now is the time to say!=0A= =0A= >=0A= > 4. In section C.2, the router is shown as using Destination Up with a mu= lticast group. I think this should now be using Destination Announce.=0A= =0A= Yes, I missed that. (I hate editing the appendices).=0A= =0A= >=0A= > 5. I have been assuming that when the router announces interest in a mul= ticast group, this effectively causes a multicast join and results in data = plane traffic for that group to start flowing to the requesting router. Th= is is never stated, though, and it's an important side-effect that should b= e called out.=0A= =0A= My use-case was that the router has detected that a local host has =0A= attempted to join a multicast group, through some out of scope method. =0A= It would then send a Destination Announce message to the modem, =0A= requesting information about the multicast destination. If the modem =0A= can promptly report information about the multicast destination, then it = =0A= response with a positive Destination Announce Response, and the router =0A= can do whatever it needs to do to with the multicast traffic. If the =0A= modem cannot deliver traffic to the multicast destination, then it must =0A= respond with a negative status code, and again, the router can react =0A= appropriately.=0A= =0A= The critical point in my mind is that it is out of scope for DLEP to =0A= define what a Destination Announce message causes the modem to do, it =0A= just describes how a modem should respond, much like Link =0A= Characteristics Request.=0A= =0A= Cheers,=0A= =0A= Rick=0A= From nobody Wed Feb 10 13:01:17 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16941B2FED for ; Wed, 10 Feb 2016 13:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5bQHWl7eFSq for ; Wed, 10 Feb 2016 13:01:08 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61A971B2FEA for ; Wed, 10 Feb 2016 13:01:08 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1AKvU13033580; Wed, 10 Feb 2016 16:00:46 -0500 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , "manet@ietf.org" , Stan Ratliff Thread-Topic: [manet] DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQBmFb8A Date: Wed, 10 Feb 2016 20:58:39 +0000 Message-ID: References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3537964718_1602796" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602100386 Archived-At: Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 21:01:11 -0000 --B_3537964718_1602796 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Rick, Comments below... On 2/10/16, 10:46 AM, "Rick Taylor" wrote: >Some background: I pushed for Destination Announce after I began to >believe that many readers of earlier drafts of DLEP were unaware that >Destination Up and Down messages could flow in *both* directions. That >is from routers to modems as well as the more common modem to router. I think I was aware that these could go in both directions, but I had been assuming that whichever side does the Up for a particular destination is the only side allowed to do the Down for that destination. I'm still not clear on all of the ramifications of allowing either side to do the Down for any destination. > >On 08/02/16 20:55, Wiggins, David - 0665 - MITLL wrote: >> Here are some comments on the new Destination Announce/Response >>messages in DLEP-18. >> >> 1. What are the IPv4/IPv6 data items for? If the MAC address is a >>multicast address, are these supposed to be the IP multicast equivalents? > >They are there because Destination Announce is inherited from >Destination Up, and I see no reason to remove them. As Stan said, there >may be future use-cases where they are useful. Do you agree with "If the MAC address is a multicast address, are these supposed to be the IP multicast equivalents?" If we leave in data items but don't define what they're to be used for, what does that do to future interoperability? >>2. Other than canceling a previous status of Not Interested in a >>destination (from 3.1. Router-requested Destinations), is there any >>other case where the router would use a unicast MAC address in a >>Destination Announce? > >As Stan said before: one day there might be, and I can see no reason to >prevent unicast MAC addresses being used. One potential option for >'on-demand' unicast destinations is perhaps triggering some proactive >layer-2 routing protocol in the modem, to go find a viable path to the >destination across some meshing radio net? OK, I can see that. So for now, when a modem receives a destination announce with a unicast address, the modem should: 1. check to see if the destination is one that it has previously declared Up. If so, send a Destination Up for that destination to the router (actually not sure about that) and resume sending future Destination Updates for that destination to the router. 2. otherwise, ignore the Destination Announce. However, a future enhancement may replace step 2: 2. Start actively probing the network for the given destination. If a router wants this enhanced behavior, how does it know that the modem supports it? Is it going to be advertised by an extension? >If the WG think it would be better to only allow Destination Downs to >flow from modem to router, and to add a new 'Destination Unsubscribe' >message to flow from router to modem instead, now is the time to say! I could go either way, but if we call this Unsubscribe then I'd prefer to rename Announce to Subscribe. >The critical point in my mind is that it is out of scope for DLEP to >define what a Destination Announce message causes the modem to do, it >just describes how a modem should respond, much like Link >Characteristics Request. If "how the modem should respond" includes the equivalent of "give the router traffic for this multicast group" (for a multicast destination) then I agree. > >Cheers, > >Rick David --B_3537964718_1602796 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFF3Ti5ZMdPOKyfum N+4n7yY4fOOSMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDIxMDIwNTgzOFowDQYJKoZIhvcNAQEBBQAEggEAN0DjXLQo/zEwFgouUMGFgIsyDnHLMGzK sTDTcv+Xr0NrxWZOfGpMUnR1QMa2+RDFQ1uevMlyKgaTdtk+MxSTynfJ0u8g8Uun71kJKdtk 6GA3nuC5pGC0n9b3RMaLjzuF0VvwXXn5wuGhhF7jacdHwD35+EGNTD2yteuvPdx9UWVpragR yD9zw0Zq+uR+LAkoaHwyYcXeQJLbwPvieYZlM0wXprDdr4IQoF80Xzib19KI9poEpIBCMqJR lTbx99tl+CgY2algJuqPv5d3Fh90SPH3OP6cOtAc8v4sM2BdMRbUylSEG2/tmCzvCWyLm9VE ZsgZpFp+rLgXtQAa8mkpbQ== --B_3537964718_1602796-- From nobody Wed Feb 10 17:09:47 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14741A879E for ; Wed, 10 Feb 2016 17:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZbLpaQkte7H for ; Wed, 10 Feb 2016 17:09:44 -0800 (PST) Received: from INFPACM005.services.comms.unsw.edu.au (smtp.unsw.edu.au [149.171.193.32]) by ietfa.amsl.com (Postfix) with ESMTP id B974C1A879C for ; Wed, 10 Feb 2016 17:09:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H9DgAF37tWhx/yXoFeFoN2bYYDglihM?= =?us-ascii?q?oEQAQQBjmWBZiGHYhIBAQEBAQEBAw4BAQEnT4I3ODwBAQEBAQEjAhNaAwF/FiE?= =?us-ascii?q?MKB0QiEcIDqIDmkWEKopIg3d6g3sFkluEHIVMiWBKhx93hDiOPycJgWgBCwFAE?= =?us-ascii?q?QiBXFYBAYhRAQEB?= X-IPAS-Result: =?us-ascii?q?A2H9DgAF37tWhx/yXoFeFoN2bYYDglihMoEQAQQBjmWBZiG?= =?us-ascii?q?HYhIBAQEBAQEBAw4BAQEnT4I3ODwBAQEBAQEjAhNaAwF/FiEMKB0QiEcIDqIDm?= =?us-ascii?q?kWEKopIg3d6g3sFkluEHIVMiWBKhx93hDiOPycJgWgBCwFAEQiBXFYBAYhRAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.22,428,1449493200"; d="scan'208";a="258670196" Received: from maillard.orchestra.cse.unsw.edu.au (HELO maillard.cse.unsw.edu.au) ([129.94.242.31]) by INFPACM005.services.comms.unsw.edu.au with ESMTP; 11 Feb 2016 12:09:11 +1100 Received: by maillard.cse.unsw.edu.au (Postfix, from userid 219) id BE5456ECC9; Thu, 11 Feb 2016 12:09:11 +1100 (AEDT) Received: from wagner.orchestra.cse.unsw.EDU.AU (wagner.orchestra.cse.unsw.EDU.AU [129.94.242.19]) by maillard.cse.unsw.edu.au (Postfix) with ESMTP id 9A5666ECC7; Thu, 11 Feb 2016 12:09:11 +1100 (AEDT) Received: From wagner With LocalMail ; Thu, 11 Feb 2016 12:09:11 +1100 From: rvg@cse.unsw.edu.au (rvg) To: manet@ietf.org Date: Thu, 11 Feb 2016 12:09:11 +1100 Message-Id: <1160211010911.12055@cse.unsw.edu.au> Archived-At: Subject: Re: [manet] Loops & Specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 01:09:46 -0000 Dear MANET folks, > I read with some interest the paper claiming that sequence numbers > do not guarantee loop freedom: > > http://www.cse.unsw.edu.au/~rvg/pub/AODVloop.pdf Thanks. As co-author of that publication [1], I'm happy to clarify it further. What it shows, is that an entirely plausible interpretation of the AODV RFC, fully taking into account all mandates stipulated therein, admits routing loops. It also shows that the loops we found can occur in several open-source implementations of AODV. In a companion publication [2], we formally prove that under a different plausible interpretation the protocol is loop free (not counting possible loops due to timing issues). As Charlie already indicated, our findings are the result of ambiguities in the RFC. In fact, in [3] (and summarised in [1]) we carefully examine a long list of ambiguities, contradictions and cases of underspecification in the RFC, analysing in each case the arguments for and against a particular reading. (This is quite different from implementation bugs, which can obviously also cause loops.) Combinatorially, this gave rise to more than 5000 possible interpretations of the RFC, any we classify which ones lead to loops and which ones don't. The take home message of this is not that AODV is a bad protocol. It is also not that the RFC is badly written. In fact I think that, as standards documents go, it is written rather well. Our point is that the methodology of writing protocol specifications in English prose only, unavoidably gives rise to these levels of ambiguity. In our view, each protocol specification should consist of a formalisation in an adequate specification formalism, accompanied by an explanation in English. The choice of a specification formalism is secondary - as long as it eliminates all ambiguity. This message of course pertains to the development of AODVv2 just as well. In our publications we show that formal methods have advanced to such a state that they are now able to capture the full syntax and the full semantics of network protocols. > Since the claimed loop condition pertains to RFC 3561, I should not > dive into the details about that. I did check whether there is any > impact on AODVv2, and the answer is that it does NOT have any impact. Our loops are related to intermediate route reply. As this tricky (although useful) feature has been removed from the draft of AODVv2 (last time I checked; I'm not a regular reader of this list), that problem does not apply any longer. As Charlie mentioned, other shortcomings of the RFC that contributed to the loops we demonstrated have been adequately addressed in AODVv2 as well. Of course, by itself this does not guarantee that AODVv2 is loop free. That requires formal proof, which is only possible on the basis of a formalised specification (resolving all remaining ambiguities). With best regards, Rob van Glabbeek [1] Sequence Numbers Do Not Guarantee Loop Freedom; AODV Can Yield Routing Loops http://theory.stanford.edu/~rvg/abstracts.html#100 MSWiM 2013 [2] A Rigorous Analysis of AODV and its Variants http://theory.stanford.edu/~rvg/abstracts.html#97 MSWiM 2012. [3] A Process Algebra for Wireless Mesh Networks used for Modelling, Verifying and Analysing AODV http://theory.stanford.edu/~rvg/abstracts.html#102 Technical Report 5513, NICTA, 2013. From nobody Wed Feb 10 17:49:45 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01671A8850 for ; Wed, 10 Feb 2016 17:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXvYOJ5YJVmR for ; Wed, 10 Feb 2016 17:49:42 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88E91A8859 for ; Wed, 10 Feb 2016 17:49:41 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id mw1so27123217igb.1 for ; Wed, 10 Feb 2016 17:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cococorp.com; s=google150814; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-type; bh=1ywJDOLgREdvR31KgsK+7NognnD50U0FyWCNT67ccAI=; b=A/Ig+W+yH84w9eC13WNhvKc579x9ySIa99YrEmgGAFSKr6wuhxxUNqads5jIv45iUW 4lCqneu9kxwAGWCAj0Rn3uRDyJtvHJvQQrjgAuTf4xpWq0+/ktJOc8v+/MKD2cniK4P0 vrmqmt8ArH4FE4nbMrXf9fNX23npszH2qyZoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=1ywJDOLgREdvR31KgsK+7NognnD50U0FyWCNT67ccAI=; b=RipRPP3xTKg/wXYfSryuHQ8kCIS/xZRt7cr8ofaJPFhbPDb8H3IJK6KC6m/JyapSUW j42TNloM4nI/4cesH0fULXItGD7vepl7XE/S+9QrFHNvx4vmpRS7/E0owB4XjdLynBdw TDyES8H7NKJwMe/BhSD0enXMA0Yu1PaU57EnM+q8hbp65pxcPumonkDwpP2Zk+jxi+89 WK5s5t0wak8dz6X6cpgwWVeQhl7j5ck6MsyKSi2KYswtbpVM8DjO4eZVgjwrfQuog3W/ zLdRzyoM9XrzUfcnh9fJLNSe9lcnppr2TLa8DP0NYVxnRAOUaKERm730nl2liOypeg1e 3IUQ== X-Gm-Message-State: AG10YOTGJgK3awArD4tzuCO46bKzZ4+oo9igZJxZEtqTB6R0YP78Wm+rI901iiiagSwZk48sUbGO9UbekuFb9v/O X-Received: by 10.50.17.70 with SMTP id m6mr12844995igd.1.1455155381185; Wed, 10 Feb 2016 17:49:41 -0800 (PST) From: "A .Riley Eller" Mime-Version: 1.0 (1.0) References: <1160211010911.12055@cse.unsw.edu.au> In-Reply-To: <1160211010911.12055@cse.unsw.edu.au> Date: Wed, 10 Feb 2016 17:49:40 -0800 Message-ID: <8078666626482199142@unknownmsgid> To: rvg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Loops & Specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 01:49:43 -0000 > In our view, each protocol specification should consist of a > formalisation in an adequate specification formalism, accompanied by > an explanation in English. The choice of a specification formalism is > secondary - as long as it eliminates all ambiguity. Good work. This result further confirms the research done by Meredith Paterson et al (langsec.org) and their denunciation of prosaic parser specifications. Further evidence of this exact problem can be found in various patches submitted to correct loop-admission errors in the Linux kernel's IEEE 802.11(s) implementation. They result from similar ambiguities. It's time to change the protocol specification process. Riley Eller coco communications From nobody Wed Feb 10 18:46:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F9E1A8920 for ; Wed, 10 Feb 2016 18:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2MrRwEAKyz8 for ; Wed, 10 Feb 2016 18:46:52 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 833A61A8923 for ; Wed, 10 Feb 2016 18:46:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LKhiLLfJc2TnNrhaU6xeBBql0gVqavcybyRZZHQg/JPTdzTrs8CtK4N+/RESKJtN; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1aThH9-0002IK-R6; Wed, 10 Feb 2016 21:46:35 -0500 To: rvg , manet@ietf.org References: <1160211010911.12055@cse.unsw.edu.au> From: Charlie Perkins Message-ID: <56BBF609.9060907@earthlink.net> Date: Wed, 10 Feb 2016 18:46:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1160211010911.12055@cse.unsw.edu.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac769e5e9d7e58f9687831bc31e7a2151d8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] Loops & Specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 02:46:56 -0000 Hello Rob, Thanks for your response! It would be much appreciated if we could get a formal analysis of AODVv2, and please let me know if there is anything I can do to help. My experience with formal analytical tools has been positive. We collaborated with a group from University of Pennsylvania after they uncovered an error in an early version of AODV that could arise if certain information were not purged during reboot. There is a specification for intermediate route reply which should rightfully be considered part of AODVv2, but was separated out in accordance with a request during some very unfortunate earlier times. It belongs as part of the protocol because it can reduce the number of network-wide broadcasts, and that is a very desirable goal. Flooding is very expensive and is the main reason that manet routing protocols produce congestion. I still think that the title of the paper is unfortunate, because it wrongly places the blame for routing loops. Sequence numbers do definitely prevent routing loops if used properly. Improper or erroneous use obviously can eliminate that safeguard. It would have been better for the title to emphasize that specification ambiguities (or programming errors) can neutralize the safeguards, instead of giving the impression that the mathematical proof is suspect. Finally, while you are undoubtedly correct that English prose is vulnerable to misinterpretation and ambiguity, on the whole I think it is clear that we have enough experience to avoid most such problems. For instance, we have a pretty large Internet based on such specifications, and overall it seems to work except for a well-known list of problems (e.g., security) arising from initial design decisions. If we have automatic programming systems, then a purely formal specification will be very useful. Imparting knowledge to real-life programmers seems to be a lot more effective using a natural language. Regards, Charlie P. On 2/10/2016 5:09 PM, rvg wrote: > Dear MANET folks, > >> I read with some interest the paper claiming that sequence numbers >> do not guarantee loop freedom: >> >> http://www.cse.unsw.edu.au/~rvg/pub/AODVloop.pdf > Thanks. As co-author of that publication [1], I'm happy to clarify it further. > > What it shows, is that an entirely plausible interpretation of the AODV > RFC, fully taking into account all mandates stipulated therein, admits > routing loops. > > It also shows that the loops we found can occur in several open-source > implementations of AODV. > > In a companion publication [2], we formally prove that under a different > plausible interpretation the protocol is loop free (not counting > possible loops due to timing issues). > > As Charlie already indicated, our findings are the result of > ambiguities in the RFC. In fact, in [3] (and summarised in [1]) we > carefully examine a long list of ambiguities, contradictions and cases > of underspecification in the RFC, analysing in each case the arguments > for and against a particular reading. (This is quite different from > implementation bugs, which can obviously also cause loops.) > Combinatorially, this gave rise to more than 5000 possible > interpretations of the RFC, any we classify which ones lead to loops > and which ones don't. > > The take home message of this is not that AODV is a bad protocol. > It is also not that the RFC is badly written. > In fact I think that, as standards documents go, it is written rather well. > > Our point is that the methodology of writing protocol specifications > in English prose only, unavoidably gives rise to these levels of ambiguity. > In our view, each protocol specification should consist of a > formalisation in an adequate specification formalism, accompanied by > an explanation in English. The choice of a specification formalism is > secondary - as long as it eliminates all ambiguity. > > This message of course pertains to the development of AODVv2 just as well. > > In our publications we show that formal methods have advanced to such a > state that they are now able to capture the full syntax and the full > semantics of network protocols. > >> Since the claimed loop condition pertains to RFC 3561, I should not >> dive into the details about that. I did check whether there is any >> impact on AODVv2, and the answer is that it does NOT have any impact. > Our loops are related to intermediate route reply. As this tricky > (although useful) feature has been removed from the draft of AODVv2 > (last time I checked; I'm not a regular reader of this list), that > problem does not apply any longer. As Charlie mentioned, other > shortcomings of the RFC that contributed to the loops we demonstrated > have been adequately addressed in AODVv2 as well. > > Of course, by itself this does not guarantee that AODVv2 is loop free. > That requires formal proof, which is only possible on the basis of a > formalised specification (resolving all remaining ambiguities). > > With best regards, > Rob van Glabbeek > > [1] Sequence Numbers Do Not Guarantee Loop Freedom; AODV Can Yield Routing Loops > http://theory.stanford.edu/~rvg/abstracts.html#100 > MSWiM 2013 > [2] A Rigorous Analysis of AODV and its Variants > http://theory.stanford.edu/~rvg/abstracts.html#97 > MSWiM 2012. > [3] A Process Algebra for Wireless Mesh Networks used for Modelling, > Verifying and Analysing AODV > http://theory.stanford.edu/~rvg/abstracts.html#102 > Technical Report 5513, NICTA, 2013. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Feb 10 21:55:44 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3971A9051 for ; Wed, 10 Feb 2016 21:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nGY5zYjnJhh for ; Wed, 10 Feb 2016 21:55:41 -0800 (PST) Received: from INFPACM005.services.comms.unsw.edu.au (smtp.unsw.edu.au [149.171.193.32]) by ietfa.amsl.com (Postfix) with ESMTP id B535C1A9056 for ; Wed, 10 Feb 2016 21:55:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HSDAAKIrxWhx/yXoFehAyJSKE0gRUBj?= =?us-ascii?q?maBZh2FcIFvEgEBAQEBAQEDDgEBASdPgjdIAQEBAQEBAQEBTAITWgQzAQo8BRY?= =?us-ascii?q?hNB0QKwQZBYd6CLxRhAABKYpIg3eEdQWWd4VNiWFKg3mDJoUvjj8nB4I3EQiBX?= =?us-ascii?q?okpAQEB?= X-IPAS-Result: =?us-ascii?q?A2HSDAAKIrxWhx/yXoFehAyJSKE0gRUBjmaBZh2FcIFvEgE?= =?us-ascii?q?BAQEBAQEDDgEBASdPgjdIAQEBAQEBAQEBTAITWgQzAQo8BRYhNB0QKwQZBYd6C?= =?us-ascii?q?LxRhAABKYpIg3eEdQWWd4VNiWFKg3mDJoUvjj8nB4I3EQiBXokpAQEB?= X-IronPort-AV: E=Sophos;i="5.22,429,1449493200"; d="scan'208";a="258753969" Received: from maillard.orchestra.cse.unsw.edu.au (HELO maillard.cse.unsw.edu.au) ([129.94.242.31]) by INFPACM005.services.comms.unsw.edu.au with ESMTP; 11 Feb 2016 16:55:15 +1100 Received: by maillard.cse.unsw.edu.au (Postfix, from userid 219) id 1BC0B6ECC9; Thu, 11 Feb 2016 16:55:15 +1100 (AEDT) Received: from weill.orchestra.cse.unsw.EDU.AU (weill.orchestra.cse.unsw.EDU.AU [129.94.242.49]) by maillard.cse.unsw.edu.au (Postfix) with ESMTP id DFB2D6ECC7; Thu, 11 Feb 2016 16:55:14 +1100 (AEDT) Received: From weill With LocalMail ; Thu, 11 Feb 2016 16:55:14 +1100 From: rvg@cse.unsw.edu.au (rvg) To: manet@ietf.org Date: Thu, 11 Feb 2016 16:55:14 +1100 Message-Id: <1160211055514.7802@cse.unsw.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: Wee Lum Tan Subject: Re: [manet] Loops & Specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:55:43 -0000 Hi Charlie, > It would be much appreciated if we could get a formal analysis of > AODVv2, and please let me know if there is anything I can do to help. We have already applied our experience in modelling (RFC-) AODV to an earlier version of AODVv2 (Internet-Draft 22, March 12, 2012). See [4] below. A small problem for us, however, is that the AODVv2 is a quickly moving target. A formal analysis takes some time, and by the time it is ready, the proposed new standard has already moved on, so that the work is no longer fully applicable. I would be interested to work (or put a student on) transferring our study to the current AODVv2, specially when you think there is a version that is somewhat stable. Our (perhaps far-fetched) ideal would be that formal specifications (of which a small snippet is shown at the top of page 3 of [4], for instance) can be read by the people that make proposals on how to further change the AODVv2 spec., so that a proposal could have the form "change line 13 of Process 4 into [ ip = dip ]". > There is a specification for intermediate route reply which should > rightfully be considered part of AODVv2, but was separated out in > accordance with a request during some very unfortunate earlier times. > It belongs as part of the protocol because it can reduce the number of > network-wide broadcasts, and that is a very desirable goal. Flooding is > very expensive and is the main reason that manet routing protocols > produce congestion. I agree with that, even though one has to be very careful with intermediate route reply. Is that separated proposal relatively stable by now? (And where do I find it? Sorry for now being up to date in this regard.) > I still think that the title of the paper is unfortunate, because it > wrongly places the blame for routing loops. Sequence numbers do > definitely prevent routing loops if used properly. What we wanted to say is that the "used properly" cannot be taken for granted (as we felt it too easily was). I hope the abstract and conclusion of the paper do make that clear. Although the formal-methods community likes our work, it is hard to get traction in the networks community; the choice of a rather controversial paper title did help in this regard (eventually) :^) > Finally, while you are undoubtedly correct that English prose is > vulnerable to misinterpretation and ambiguity, on the whole I think it > is clear that we have enough experience to avoid most such problems. > For instance, we have a pretty large Internet based on such > specifications, and overall it seems to work except for a well-known > list of problems (e.g., security) arising from initial design > decisions. If we have automatic programming systems, then a purely > formal specification will be very useful. Imparting knowledge to > real-life programmers seems to be a lot more effective using a natural > language. I agree that for widely used internet protocols people appear to have reached consensus on how to read the specifications. However, for thinks like AODV this is only partially the case. I for instance don't believe that AODV routers from different vendors could work together very well, because they are based on subtly different readings on the workings of the protocol. Cheers, Rob [4] Peter Hfner and Sarah Edenhofer Towards a rigorous analysis of AODVv2 (DYMO) 2nd International Workshop on Rigorous Protocol Engineering (WRiPE 2012), pp. 1-6, Austin, Texas, October, 2012 http://nicta.com.au/pub?id=6169 From nobody Thu Feb 11 11:25:42 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5811B3967 for ; Thu, 11 Feb 2016 11:25:41 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yomj9_D9OBWu for ; Thu, 11 Feb 2016 11:25:38 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8544A1B3962 for ; Thu, 11 Feb 2016 11:25:38 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id ik10so18032926igb.1 for ; Thu, 11 Feb 2016 11:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlmQgnUI6+RQId/EiVlp/YLVQDulXCjYmEiu1Up3NWk=; b=WdWig4/et6QEkhEepLjSL77UsJ7L6fOXLTZwVzP2K2kRBNM5jY1M2OZ7Gs4QmQjUm7 y7WhjCHY6mXn6GdIBDfGENbRhA0+neey+ESLoSNQwNb4q06LMTMGS8v6iF6pECx/Z2Ry a0WpI4PhwSDcGlvxDxexccPD/ui7wsVqoJOFMrmevCAEVJPhA9gSZqTu/IuoGAMH2VS3 NlAOI3KmR2mMXXhjwQ4Sh6yPE/3UpSi9WX1TjcsgV8uA8EqzUMEMQ3wQvLBVhBwYRlLB In6q91AlXwG0vh0Syhbm65nPh/m3yGCN8ZYqf1XVXdS8s8WaY2yHZCgMjR49ufTQ45lN 0Gig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qlmQgnUI6+RQId/EiVlp/YLVQDulXCjYmEiu1Up3NWk=; b=lKedLkPIxDVa2Usoi7e0YYItsdzAu04n8XQVZYNs3Y7JefajGsNSFbJNugZXwbBm2n OWkxuRJb+b5adyOfbVz2TX5rX5Hf/2f4l76+lKIocU4Q3yaU1YxMyRYlOAn+gusAYbZw o0/YSUjretdglUpt7/c9BxWmhsIKeJr5Zs84vFym5geamU1Py+iL9Phi/A0UuU3Ns/AM B7WjismQ1EUE0nGw9QsSAgmxsd2nCbC6VDEeNKB3SWqfgeo2bbkR49cOEAyNwvo7vUP3 D1ODI9tgam2ojAn9x3O+U+HcLqLRJFlWwFP9lmD9V7cT924dAV1ICAU4hFMtb9ONnxvR AU4Q== X-Gm-Message-State: AG10YOR9zSRI5eUob76ssrscAA5Thgp28wtjiD5mT4VqvlwLwAuvAvTeHCn7RPilt83jfx40cnQ3rxJJUl7o/w== MIME-Version: 1.0 X-Received: by 10.50.138.76 with SMTP id qo12mr130779igb.85.1455218738034; Thu, 11 Feb 2016 11:25:38 -0800 (PST) Received: by 10.79.96.1 with HTTP; Thu, 11 Feb 2016 11:25:37 -0800 (PST) In-Reply-To: References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> Date: Thu, 11 Feb 2016 14:25:37 -0500 Message-ID: From: Stan Ratliff To: "Wiggins, David - 0665 - MITLL" Content-Type: multipart/alternative; boundary=001a1134b964f382e0052b838321 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:25:41 -0000 --001a1134b964f382e0052b838321 Content-Type: text/plain; charset=UTF-8 David, Some comments inline. On Wed, Feb 10, 2016 at 3:58 PM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > Hi Rick, > > Comments below... > > On 2/10/16, 10:46 AM, "Rick Taylor" > wrote: > > >Some background: I pushed for Destination Announce after I began to > >believe that many readers of earlier drafts of DLEP were unaware that > >Destination Up and Down messages could flow in *both* directions. That > >is from routers to modems as well as the more common modem to router. > > I think I was aware that these could go in both directions, but I had been > assuming that whichever side does the Up for a particular destination is > the only side allowed to do the Down for that destination. I'm still not > clear on all of the ramifications of allowing either side to do the Down > for any destination. > > > > >On 08/02/16 20:55, Wiggins, David - 0665 - MITLL wrote: > >> Here are some comments on the new Destination Announce/Response > >>messages in DLEP-18. > >> > >> 1. What are the IPv4/IPv6 data items for? If the MAC address is a > >>multicast address, are these supposed to be the IP multicast equivalents? > > > >They are there because Destination Announce is inherited from > >Destination Up, and I see no reason to remove them. As Stan said, there > >may be future use-cases where they are useful. > > Do you agree with "If the MAC address is a multicast address, are these > supposed to be the IP multicast equivalents?" > Yes, I agree with this. However, I don't see a need to explicitly state it in the draft. A developer of a DLEP implementation is free to check the consistency of the received data. If the MAC address doesn't "match" the supplied IP address (or addresses), then issue Announce Response with non-zero Status. > > If we leave in data items but don't define what they're to be used for, > what does that do to future interoperability? > > >>2. Other than canceling a previous status of Not Interested in a > >>destination (from 3.1. Router-requested Destinations), is there any > >>other case where the router would use a unicast MAC address in a > >>Destination Announce? > > > >As Stan said before: one day there might be, and I can see no reason to > >prevent unicast MAC addresses being used. One potential option for > >'on-demand' unicast destinations is perhaps triggering some proactive > >layer-2 routing protocol in the modem, to go find a viable path to the > >destination across some meshing radio net? > > OK, I can see that. So for now, when a modem receives a destination > announce with a unicast address, the modem should: > 1. check to see if the destination is one that it has previously declared > Up. If so, send a Destination Up for that destination to the router > (actually not sure about that) and resume sending future Destination > Updates for that destination to the router. > 2. otherwise, ignore the Destination Announce. > Why would you ignore the Destination Announce in this case? Why not send Destination Announce Response with a non-zero status code, indicating that the Announce failed? > > However, a future enhancement may replace step 2: > 2. Start actively probing the network for the given destination. > > If a router wants this enhanced behavior, how does it know that the modem > supports it? Is it going to be advertised by an extension? > I don't see why this would necessarily be an extension. It's an implementation "detail". What, specifically goes into a modem's support of Destination Announce? Up to the modem developer. Regards, Stan > > >If the WG think it would be better to only allow Destination Downs to > >flow from modem to router, and to add a new 'Destination Unsubscribe' > >message to flow from router to modem instead, now is the time to say! > > I could go either way, but if we call this Unsubscribe then I'd prefer to > rename Announce to Subscribe. > > >The critical point in my mind is that it is out of scope for DLEP to > >define what a Destination Announce message causes the modem to do, it > >just describes how a modem should respond, much like Link > >Characteristics Request. > > If "how the modem should respond" includes the equivalent of "give the > router traffic for this multicast group" (for a multicast destination) > then I agree. > > > > >Cheers, > > > >Rick > > David > --001a1134b964f382e0052b838321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,=C2=A0

Some comments inline.
<= div class=3D"gmail_extra">
On Wed, Feb 10, 20= 16 at 3:58 PM, Wiggins, David - 0665 - MITLL <David.Wiggins@ll.mit= .edu> wrote:
Hi Rick,

Comments below...

On 2/10/16, 10:46 AM, "Rick Taylor" <rick@tropicalstormsoftware.com> wrote:

>Some background:=C2=A0 I pushed for Destination Announce after I began = to
>believe that many readers of earlier drafts of DLEP were unaware that >Destination Up and Down messages could flow in *both* directions. That<= br> >is from routers to modems as well as the more common modem to router.
I think I was aware that these could go in both directions, but I had been<= br> assuming that whichever side=C2=A0 does the Up for a particular destination= is
the only side allowed to do the Down for that destination. I'm still no= t
clear on all of the ramifications of allowing either side to do the Down for any destination.

>
>On 08/02/16 20:55, Wiggins, David - 0665 - MITLL wrote:
>> Here are some comments on the new Destination Announce/Response >>messages in DLEP-18.
>>
>> 1.=C2=A0 What are the IPv4/IPv6 data items for?=C2=A0 If the MAC a= ddress is a
>>multicast address, are these supposed to be the IP multicast equiva= lents?
>
>They are there because Destination Announce is inherited from
>Destination Up, and I see no reason to remove them.=C2=A0 As Stan said,= there
>may be future use-cases where they are useful.

Do you agree with "If the MAC address is a multicast address, are thes= e
supposed to be the IP multicast equivalents?"
Yes, I agree with this. However, I don't see a need to expl= icitly state it in the draft. A developer of a DLEP implementation is free = to check the consistency of the received data. If the MAC address doesn'= ;t "match" the supplied IP address (or addresses), then issue Ann= ounce Response with non-zero Status.=C2=A0
=C2=A0

If we leave in data items but don't define what they're to be used = for,
what does that do to future interoperability?

>>2.=C2=A0 Other than canceling a previous status of Not Interested= =C2=A0 in a
>>destination (from 3.1.=C2=A0 Router-requested Destinations), is the= re any
>>other case where the router would use a unicast MAC address in a >>Destination Announce?
>
>As Stan said before: one day there might be, and I can see no reason to=
>prevent unicast MAC addresses being used. One potential option for
>'on-demand' unicast destinations is perhaps triggering some pro= active
>layer-2 routing protocol in the modem, to go find a viable path to the<= br> >destination across some meshing radio net?

OK, I can see that.=C2=A0 So for now, when a modem receives a destination announce with a unicast address, the modem should:
1. check to see if the destination is one that it has previously declared Up.=C2=A0 If so, send a Destination Up for that destination to the router (actually not sure about that) and resume sending future Destination
Updates for that destination to the router.
2. otherwise, ignore the Destination Announce.

Why would you ignore the Destination Announce in this case? Why not= send Destination Announce Response with a non-zero status code, indicating= that the Announce failed?=C2=A0
=C2=A0

However, a future enhancement may replace step 2:
2. Start actively probing the network for the given destination.

If a router wants this enhanced behavior, how does it know that the modem supports it?=C2=A0 Is it going to be advertised by an extension?

I don't see why this would necessarily be an = extension. It's an implementation "detail". What, specificall= y goes into a modem's support of Destination Announce? Up to the modem = developer.

Regards,
Stan=C2=A0
=C2=A0

>If the WG think it would be better to only allow Destination Downs to >flow from modem to router, and to add a new 'Destination Unsubscrib= e'
>message to flow from router to modem instead, now is the time to say!
I could go either way, but if we call this Unsubscribe then I'd prefer = to
rename Announce to Subscribe.

>The critical point in my mind is that it is out of scope for DLEP to >define what a Destination Announce message causes the modem to do, it >just describes how a modem should respond, much like Link
>Characteristics Request.

If "how the modem should respond" includes the equivalent of &quo= t;give the
router traffic for this multicast group" (for a multicast destination)=
then I agree.

>
>Cheers,
>
>Rick

David

--001a1134b964f382e0052b838321-- From nobody Fri Feb 12 11:50:38 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7FA1A8948 for ; Fri, 12 Feb 2016 11:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj__5D-odgFq for ; Fri, 12 Feb 2016 11:50:35 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB61A8949 for ; Fri, 12 Feb 2016 11:50:34 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1CJo9b4030259; Fri, 12 Feb 2016 14:50:09 -0500 From: "Wiggins, David - 0665 - MITLL" To: Stan Ratliff Thread-Topic: [manet] DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQBmFb8AADmFLoAAKK64gA== Date: Fri, 12 Feb 2016 19:50:30 +0000 Message-ID: References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538133429_11724394" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602120308 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:50:37 -0000 --B_3538133429_11724394 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit >> >>2. Other than canceling a previous status of Not Interested in a >>destination (from 3.1. Router-requested Destinations), is there any >>other case where the router would use a unicast MAC address in a >>Destination Announce? > >As Stan said before: one day there might be, and I can see no reason to >prevent unicast MAC addresses being used. One potential option for >'on-demand' unicast destinations is perhaps triggering some proactive >layer-2 routing protocol in the modem, to go find a viable path to the >destination across some meshing radio net? OK, I can see that. So for now, when a modem receives a destination announce with a unicast address, the modem should: 1. check to see if the destination is one that it has previously declared Up. If so, send a Destination Up for that destination to the router (actually not sure about that) and resume sending future Destination Updates for that destination to the router. 2. otherwise, ignore the Destination Announce. Stan asked: Why would you ignore the Destination Announce in this case? Why not send Destination Announce Response with a non-zero status code, indicating that the Announce failed? In general, if a data item is allowed on a message/signal, and is is well-formed (length matches the expected length for this data item, any restrictions on allowed values are met, etc.), and there isn't a specifically called-out protocol reason to reject it, then our implementation accepts it, even if it has no use for it. ("Be liberal in what you accept...") If we definitely want every implementation to reject a Destination Announce for a unicast address if it doesn't know what to do with it, then I would expect that to be stated in the draft. If we want to leave this case up to implementations, then the draft doesn't have to say anything about this, and some implementations will accept it and some won't. I didn't intend for this to get bogged down in minutiae; the bigger point is that I'm not sure all of the protocol interactions between Announce/Down from the router and Up/Down from the modem are sufficiently spelled out, and I was just picking one example above of such an interaction. David --B_3538133429_11724394 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFJH/9C4wkLeZGaGx owG4c+g8Z61HMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDIxMjE5NTAyOVowDQYJKoZIhvcNAQEBBQAEggEAbrS2FRCTaXWMgtI6mIPE2sEKd/I53s+9 qN+J8QykSrjahC46R4V1nV9Dwfa5v1qDwhX3wZ77jngR1aCv6bk6ssa5iVP+x+5hMTLWXdEg clGl9bvOg/vpIWajR/FWtINdQJQbLp3yjCU8KqSq0W5c+0Fj2I614/b46ZABzRJzDs2XnnWE k3uA4uTH6UqZvvPpHZwZP4+k0PMTScb9ilcBA3Jbt1aD29JZ9/D3ZixwQtGdGL+e7WkcA0hB g2il/lvJK6oXMoEFndj3/GEkkh580DIVeDUuXbo3yUDzRrXfX41aLrWNHmC19zRfOlcIjclV dV/JUKi1KluDlij9/STlRA== --B_3538133429_11724394-- From nobody Sun Feb 14 14:42:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064461A1B6D for ; Sun, 14 Feb 2016 14:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWSok4jpZLpH for ; Sun, 14 Feb 2016 14:42:01 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA6B1A1AC1 for ; Sun, 14 Feb 2016 14:42:01 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id ik10so42939849igb.1 for ; Sun, 14 Feb 2016 14:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p3+Kl2peflDMSuh/szfH1TeIT2ZIucgkpVdVEz09iEw=; b=lPH1ZyubOA7f0nYdoVCn2cjF+ON+CUffE3QD6SGpWZo2+2xiX7I7P4RSX9BUcQfDDe BQu7qr9brJj0fI3859I5R8YrgGVVVAEOCINLOfbxuaLu1kYQkpIGI3AyCc2Ee846Sk8j PZR+SOTyDIZYRP9QZb7N9azt0Cqpwiwl2rZcB40SmA6OGuxfrqjv/71fAFECibkbPyuU WsixVL8KGsWtdcyuU6hJOwtS79nrhTaMVwr98OVNaB235oLLLAwZAeMFMtNDfzPk6ZzS +mAmh46lLB9NywtCBvyEy/VgG4f5K2FtSZ6cQ83uClSU4kXlab66iHQkbjSRASMc2zfq wavA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p3+Kl2peflDMSuh/szfH1TeIT2ZIucgkpVdVEz09iEw=; b=KcbnESzEmmlYgT+Z0RViJebi60uPt6153t5dtSs1fRI/ELWMM9+HDCSIEo99t+w7Li keTVUZGMU74JwcD2UfNnzDE6wEFPKcCGSuoz2j6Ga0l7TqOcpF4uuRb7UoX2ij8+dMvQ Z74O4h3kU7ZV8elAmVS4MASaI98asSEfyaMdKyheVJG/P8TALMIIiX6D+edkK4mBeOdm tNXOEajYr+u9NG9qvNETkTPK0qsujrzzqXJvH8QA9Bsel3T7Qwzstf+UA5uolWGdZXB6 WXLQMP74jRISp5mdVUOnHUgFOMedUMzFqVzPb6DfZa+muhoa4wt0UjyP3JAar0iarfci hoPw== X-Gm-Message-State: AG10YOSZyARMW+qY4SG9EIXfX/3zIuHoAjO+razAkoR0V8574jqYokqRaG9EXW4fJJ4qFjETnAFpO7VGCDP1NA== MIME-Version: 1.0 X-Received: by 10.50.30.134 with SMTP id s6mr8824635igh.36.1455489721177; Sun, 14 Feb 2016 14:42:01 -0800 (PST) Received: by 10.79.96.1 with HTTP; Sun, 14 Feb 2016 14:42:01 -0800 (PST) In-Reply-To: References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> Date: Sun, 14 Feb 2016 17:42:01 -0500 Message-ID: From: Stan Ratliff To: "Wiggins, David - 0665 - MITLL" Content-Type: multipart/alternative; boundary=047d7bdc184ace2276052bc29b7b Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 22:42:03 -0000 --047d7bdc184ace2276052bc29b7b Content-Type: text/plain; charset=UTF-8 David, On Fri, Feb 12, 2016 at 2:50 PM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > I didn't intend for this to get bogged down in minutiae; the bigger point > is that I'm not sure all of the protocol interactions between > Announce/Down from the router and Up/Down from the modem are sufficiently > spelled out, and I was just picking one example above of such an > interaction. > > I'm not sure where we go from here. If there are recommendations for improving the draft, then please let me know. Otherwise, we'll press forward with DLEP-18. Regards, Stan --047d7bdc184ace2276052bc29b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

On Fri, Feb 12, 2016 at 2:50 PM, Wiggins, David - 0665 - M= ITLL <David.Wiggins@ll.mit.edu> wrote:
I didn't intend for this to get bogged down in minu= tiae; the bigger point
is that I'm not sure all of the protocol interactions between
Announce/Down from the router and Up/Down from the modem are sufficiently spelled out, and I was just picking one example above of such an
interaction.

=C2=A0
I'm not sure where we go from here. If the= re are recommendations for improving the draft, then please let me know. Ot= herwise, we'll press forward with DLEP-18.

Regards,<= br>
Stan

--047d7bdc184ace2276052bc29b7b-- From nobody Mon Feb 15 05:59:36 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1041B3417; Mon, 15 Feb 2016 05:59:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215135934.4971.10442.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 05:59:34 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-sec-threats-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 13:59:35 -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 of the IETF. Title : Security Threats for Simplified Multicast Forwarding (SMF) Authors : Jiazi Yi Thomas Heide Clausen Ulrich Herberg Filename : draft-ietf-manet-smf-sec-threats-04.txt Pages : 15 Date : 2016-02-15 Abstract: This document analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-smf-sec-threats-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-sec-threats-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 17 00:55:30 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4A1B3554 for ; Wed, 17 Feb 2016 00:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S-d4ZT_CZVB for ; Wed, 17 Feb 2016 00:55:25 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0251B34C5 for ; Wed, 17 Feb 2016 00:55:25 -0800 (PST) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by outbox.sics.se (Postfix) with ESMTPS id 57938828 for ; Wed, 17 Feb 2016 09:55:23 +0100 (CET) Received: from [193.10.66.141] (marco-desktop.sics.se [193.10.66.141]) by norm.sics.se (Postfix) with ESMTPSA id 4C12C259 for ; Wed, 17 Feb 2016 09:55:23 +0100 (CET) Message-ID: <56C4357B.4010202@sics.se> Date: Wed, 17 Feb 2016 09:55:23 +0100 From: Marco Tiloca User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: manet@ietf.org Content-Type: multipart/alternative; boundary="------------030309060908070003090006" Archived-At: Subject: [manet] SMARTCOMP 2016 | Call for WiP/Demo Papers - Deadline: March 7, 2016 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 08:55:29 -0000 This is a multi-part message in MIME format. --------------030309060908070003090006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [Apologies for possible multiple copies] ------------------------------------------------------------------------ Call for WORK-IN-PROGRESS papers and DEMOs SMARTCOMP 2016 Second IEEE International Conference on Smart Computing http://www.smart-comp.org/ May 18-20, 2016 St. Louis, Missouri, USA ******* WIP/DEMO PAPER SUBMISSION DEADLINE: March 7, 2016 ******* Conference Proceedings in IEEE Xplore ------------------------------------------------------------------------ The 2nd IEEE International Conference on Smart Computing (SMARTCOMP 2016) draws upon many application disciplines such as transportation, energy, environmental protection, resource management, healthcare, security, banking, entertainment, and social media. In addition to full-length technical papers, SMARTCOMP welcomes Work in Progress (WIP) papers and technical demonstrations(DEMOs)showing innovative and original research in the areas of smart computing. Submissions from both industry and academia are strongly encouraged. WIP papers are expected to report on early or ongoing research activities, while DEMO papers are expected to present innovative applications and tools. The WIP and DEMO sessions will provide a forum to discuss novel ideas and emerging results, presenting innovative applications and tools, and bring about novel research questions, approaches, and directions. =20 TOPICS: Submissions should be targeted to one of the following major areas: - Smart Cyber-Physical Environments and Energy/Water/Agriculture/Transportation/Healthcare/Banking Infrastructure= - Security, Privacy, and Economics in Smart Environments - Smart Computing Technologies - Future Smart Computing Paradigms - Smart Human Environments, Health, Entertainment, and Social Activities - Smart Energy Management and Analytics SUBMISSION GUIDELINES: =20 WIP and Demo papers may be no more than 3 pages in length, including figures, tables, and references. WIP papers are expected to present early or ongoing research activities. Novel approaches and preliminary results are especially appreciated. Demo papers should explicitly state what will be demonstrated to the audience, and how the attendees will be able to interact, enjoy, and experiment. =20 The submitted manuscripts will be reviewed by members of the SMARTCOMP 2016 Technical Program Committee. All the accepted papers will be presented as posters and included in the conference proceedings. At least one author of each accepted paper must register and attend the conference to present the work. The accepted papers will be published in the conference proceedings by IEEE, and will be included in the Digital Library. Authors are requested to submit original, unpublished manuscripts in standard IEEE proceedings format in PDF. All submissions must be typeset in double-column IEEE format using 10pt fonts on US letter paper, with all fonts embedded. Submitted papers must include the contact information of all the authors. Please make sure you use the latest version of the templates to prepare your submissions. Due to the short interval between the notification of acceptance and the camera-ready deadline, we strongly encourage authors to follow the camera-ready formatting guidelines as close as possible even for the initial abstract submission. The IEEE LaTeX and Microsoft Word templates for conferences can be found at IEEE Manuscript Templates for Conference Proceedings at http://www.ieee.org/conferences_events/conferences/publishing/templates.h= tml Further information for authors may be found at the IEEE Computer Society Information for Authors for Conference Publishing Services: http://www.computer.org/web/cs-cps/authors Submissions must be made via EasyChair: https://easychair.org/conferences/?conf=3Dsmartcomp2016 When submitting, please select the appropriate Track for your paper (i.e., WIP or Demo). IMPORTANT DATES: =20 Paper submissions: March 7, 2016 Notification of acceptance: March 30, 2016 Camera-ready copy due: April 15, 2016 Conference date: May 18-20, 2016 WIP/DEMO CO-CHAIRS: Hassan Ghasemzadeh (hassan@eecs.wsu.edu), Washington State University, US= A Sejun Song (songsej@umkc.edu), University of Missouri-Kansas City, USA --------------030309060908070003090006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
[Apologies for possible multiple copies]

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

               Call for WORK-IN-PROGRESS papers and DEMOs

                             SMARTCOMP 2016
                  Second IEEE International Conference on
               Smart Computing

                      http://www.smart-comp.org/

                            May 18-20, 2016
                        St. Louis, Missouri, USA


*******    WIP/DEMO PAPER SUBMISSION DEADLINE: March 7, 2016    *******

                 Conference Proceedings in IEEE Xplore

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


The 2nd IEEE International Conference on Smart Computing (SMARTCOMP
2016) draws upon many application disciplines such as transportation,
energy, environmental protection, resource management, healthcare,
security, banking, entertainment, and social media. In addition to
full-length technical papers, SMARTCOMP welcomes Work in Progress (WIP)
papers and technical demonstrations(DEMOs)showing innovative and
original research in the areas of smart computing. Submissions from both
industry and academia are strongly encouraged.

WIP papers are expected to report on early or ongoing research
activities, while DEMO papers are expected to present innovative
applications and tools.

The WIP and DEMO sessions will provide a forum to discuss novel ideas
and emerging results, presenting innovative applications and tools, and
bring about novel research questions, approaches, and directions.
 

TOPICS:
Submissions should be targeted to one of the following major areas:

- Smart Cyber-Physical Environments and
Energy/Water/Agriculture/Transportation/Healthcare/Banking Infrastructure
- Security, Privacy, and Economics in Smart Environments
- Smart Computing Technologies
- Future Smart Computing Paradigms
- Smart Human Environments, Health, Entertainment, and Social Activities
- Smart Energy Management and Analytics



SUBMISSION GUIDELINES:
 
WIP and Demo papers may be no more than 3 pages in length, including
figures, tables, and references.

WIP papers are expected to present early or ongoing research activities.
Novel approaches and preliminary results are especially appreciated.

Demo papers should explicitly state what will be demonstrated to the
audience, and how the attendees will be able to interact, enjoy, and
experiment.
 
The submitted manuscripts will be reviewed by members of the SMARTCOMP
2016 Technical Program Committee. All the accepted papers will be
presented as posters and included in the conference proceedings. At
least one author of each accepted paper must register and attend the
conference to present the work. The accepted papers will be published in
the conference proceedings by IEEE, and will be included in the Digital
Library.

Authors are requested to submit original, unpublished manuscripts in
standard IEEE proceedings format in PDF. All submissions must be typeset
in double-column IEEE format using 10pt fonts on US letter paper, with
all fonts embedded. Submitted papers must include the contact
information of all the authors. Please make sure you use the latest
version of the templates to prepare your submissions. Due to the short
interval between the notification of acceptance and the camera-ready
deadline, we strongly encourage authors to follow the camera-ready
formatting guidelines as close as possible even for the initial abstract
submission.


The IEEE LaTeX and Microsoft Word templates for conferences can be found
at IEEE Manuscript Templates for Conference Proceedings at
http://www.ieee.org/conferences_events/conferences/publishing/templates.html

Further information for authors may be found at the IEEE Computer
Society Information for Authors for Conference Publishing Services:
http://www.computer.org/web/cs-cps/authors

Submissions must be made via EasyChair:
https://easychair.org/conferences/?conf=smartcomp2016
When submitting, please select the appropriate Track for your paper
(i.e., WIP or Demo).


IMPORTANT DATES:
 
Paper submissions:              March 7, 2016
Notification of acceptance:     March 30, 2016
Camera-ready copy due:          April 15, 2016
Conference date:             May 18-20, 2016


WIP/DEMO CO-CHAIRS:
Hassan Ghasemzadeh (hassan@eecs.wsu.edu), Washington State University, USA
Sejun Song (songsej@umkc.edu), University of Missouri-Kansas City, USA
--------------030309060908070003090006-- From nobody Wed Feb 17 03:03:54 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8091B38B6 for ; Wed, 17 Feb 2016 03:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr0YRv0wW9Wd for ; Wed, 17 Feb 2016 03:03:47 -0800 (PST) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F26B1B38B1 for ; Wed, 17 Feb 2016 03:03:46 -0800 (PST) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id C5349C0A8D for ; Wed, 17 Feb 2016 12:03:33 +0100 (CET) Date: Wed, 17 Feb 2016 12:32:01 +0100 From: Antonino Masaracchia To: manet@ietf.org Message-ID: <56c45a31.WPfoYPU8aDCQi5ys%aoc2016_publicity@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [manet] AOC 2016: IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 11:03:52 -0000 Please accept our apologies if you receive multiple copies of this CFP. -----------------------------------------------------------------------= --------- CALL FOR PAPERS = =09 =09Tenth IEEE WoWMoM Workshop on = =09 =09Autonomic and Opportunistic Communications (AOC 2016) = =09 =09 June 21, 2016 - Coimbra, Portugal =20 =09 http://cnd.iit.cnr.it/aoc2016 =09=09 in conjunction with IEEE WoWMoM, 2016 =20 http://wowmom2016.uc.pt/ =09 =20 =09**** Submission Deadline --- March 10, 2016 **** = =09 -----------------------------------------------------------------------= --------- SCOPE AND OVERVIEW The recent proliferation of sensor-rich portable devices is enabling no= vel communication paradigms for users and contributing to the implement= ation of the ubiquitous computing and networking vision. Opportunistic = networking represents a key communication paradigm for this vision. Eit= her as a standalone communication mode or as a complement to infrastruc= ture-based communication, opportunistic networking leverages the mobili= ty of end users to enhance their ability to communicate in the absence = of reliable end-to-end connectivity. Opportunistic networking opens up = many possibilities but also poses countless new challenges. The goal of= the AOC 2016 workshop is to serve as a forum for researchers, professi= onals, application developers, and other experts from both academia and= industry to exchange new ideas, discuss new solutions, and share their= experiences. As with previous editions, this year's workshop is partic= ularly interested in novel research directions, such as service composi= tion techniques, co-existence with infrastructure networks such solutio= ns based on fog or edge computing, and insights from complex network an= alysis applied to autonomic and opportunistic communications. The workshop will solicit original papers addressing theoretical and pr= actical aspects of autonomic and opportunistic communications as well a= s papers describing prototype implementations and deployments. Topics of interest for AOC 2016 include, but are not limited to: - Techniques for data dissemination and replication - Context and social awareness mechanisms and algorithms - Autonomous and self-adaptive systems for smart cities - Autonomous solutions for IoT and cyber-physical systems - Solutions based on fog or edge computing - Big data for autonomic and opportunistic systems - Mobile social networking algorithms and applications - Co-existence of opportunistic networks with infrastructure mobile wir= eless networks - Mobility models and statistical analysis of mobility traces - Service composition in autonomic and opportunistic networks - Cognition-driven information processing and decision making - Performance modelling, scaling laws, and fundamental limits for auton= omic and opportunistic communications - Participatory and urban sensing in autonomic and opportunistic networ= ks - Game-theoretic insights to the operation of autonomic and opportunist= ic networks - Trust, security, and reputation - Autonomic and opportunistic communication testbeds and prototypes, me= asurement data from real experiments - Socio-economic models for autonomic and opportunistic communications - SNA and graph modeling for autonomic and opportunistic networks - Autonomic and opportunistic solutions for mobile cloud applications - Applications and middleware support - Routing, transport, and reliability issues =20 PAPER SUBMISSION AND PUBLICATION -------------------------------- Submission will be managed electronically through EDAS (https://edas.in= fo/newPaper.php?c=3D21826). =20 Papers should neither have been published elsewhere nor being currently= under review by another conference or journal. Manuscripts are limited= to 6 pages, single spacing, double column, and must strictly adhere to= the template format. Accepted papers will appear in the symposium proceedings published by I= EEE. There will be no separate workshop registration, as one single reg= istration will cover both conference and workshops participation. At le= ast one author of each accepted paper must register to the workshop and= present his/her work. =20 =20 IMPORTANT DATES --------------- Full papers due:=09March 10, 2016 Notification:=09=09April 15, 2016 Camera-ready:=09=09April 29, 2016 Workshop:=09=09June 21, 2016 ORGANISING COMMITTEE -------------------- Workshop Co-Chairs=20 Michela Papandrea, SUPSI, Switzerland Matteo Zignani, University of Milan, Italy Valerio Arnaboldi, IIT, CNR, Italy Publicity Chair Antonino Masaracchia, IIT, CNR, Italy PROGRAM COMMITTEE Alan Ferrari, SUSPSI, Switzerland Anna Forster, University of Bremen, Germany Chiara Boldrini, IIT-CNR, Italy Christian Rohner, Uppsala University, Sweden Eiko Yoneki, University of Cambridge, UK Elena Pagani, Universita' di Milano, Italy Franck Legendre, ETH, Switzerland Hongyi Wu, University of Louisiana at Lafayette, USA Jorg Ott, Technische Universitat Munchen Kamini Garg, SUPSI, Switzerland Kyunghan Lee, UNIST, Korea Lorenzo Valerio, IIT-CNR, Italy Matteo Mordacchini, IIT-CNR, Italy Nicholas Lane, Bell Labs, UK Pavlos Sermpezis, FORTH, Greece Roger Whitaker, University of Cardiff, UK Sabrina Gaito, Universita' degli Studi di Milano, Italy Sebastian Zander, Swinbourne University of Technology, Australia Serge Fdida, UPMC Sorbonne Universites, France Thrasyvoulos Spyropoulos, EURECOM, France Tristan Henderson, University of St Andrews, United Kingdom Vania Conan, Thales Communication and Security, France Waldir Moreira, COPELABS/University Lusofona, Portugal For further information, please contact the workshop chairs at aoc2016 = at iit.cnr.it From nobody Wed Feb 17 14:18:33 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D331B3043 for ; Wed, 17 Feb 2016 14:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuI53laHuZNz for ; Wed, 17 Feb 2016 14:18:24 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 079191B3034 for ; Wed, 17 Feb 2016 14:18:03 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1HMHZiq029206; Wed, 17 Feb 2016 17:17:35 -0500 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , "manet@ietf.org" , Stan Ratliff Thread-Topic: [manet] DLEP-18 Destination Announce Thread-Index: AdFirXlDvIMyvOMcS1GkvL9VrHVOAQBmFb8AAWLPq4A= Date: Wed, 17 Feb 2016 22:18:00 +0000 Message-ID: References: <051CC8AC48CA52479811BF267278633A13304D34@LLE2K10-MBX01.mitll.ad.local> <38A5475DE83986499AEACD2CFAFC3F9801C37C6CD7@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538574279_38179066" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-17_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602170350 Archived-At: Subject: Re: [manet] DLEP-18 Destination Announce X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 22:18:31 -0000 --B_3538574279_38179066 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 2/10/16, 3:58 PM, "Wiggins, David - 0665 - MITLL" wrote: >On 2/10/16, 10:46 AM, "Rick Taylor" >wrote: > >>Some background: I pushed for Destination Announce after I began to >>believe that many readers of earlier drafts of DLEP were unaware that >>Destination Up and Down messages could flow in *both* directions. That >>is from routers to modems as well as the more common modem to router. > >I think I was aware that these could go in both directions, but I had been >assuming that whichever side does the Up for a particular destination is >the only side allowed to do the Down for that destination. I'm still not >clear on all of the ramifications of allowing either side to do the Down >for any destination. The addition in the latest draft of the sentence "It should be noted that both modem and router may send a Destination Down message to its peer" is helpful. I suggest further clarification, maybe adding ", regardless of which peer initially announced or declared the destination to be up." If the modem declares a destination to be up, and the router responds Success, then later the router says destination down, I believe what is intended is that the modem stop sending *any* messages regarding that destination to the router. It is as if the router had responded Not Interested to the initial Up. To the modem, though, that destination is still up, and it will continue to tell other peers about it. If that is all correct, then I think the description of Destination Down should cover this. Currently it just says "A DLEP participant MUST send a Destination Down message to report when a destination (a remote node or a multicast group) is no longer reachable." In this case, it's not that the destination isn't reachable, it's that the router doesn't want to hear about it any more. One way to do this might be to split the description of Destination Down in two, one part addressing what happens when the peer that initiated the Up/Announce does the Down, and the other part addressing when the non-initiating peer does the Down. Having a new message to cancel an Announce (instead of reusing Down), an idea that Rick floated, might also help to clarify these cases. David --B_3538574279_38179066 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFHoZVIPG3xw08diI y2FrsSvNHBUJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDIxNzIyMTc1OVowDQYJKoZIhvcNAQEBBQAEggEAT14fYYjjBJjKdygwV5vl5qIjoztGuCzL mprizYk5gAV7OEi/BvUeUiI8k6lBuZUqt4+CgMP2UhqdcXWIZjav0f6mCUt29ELqYFpZHbmr jHlpQQ7GKC/o4UcuuBR2xW0Rldp25NRn2Mz8wluPYbN87ctVXsJjquHY6cR6YbBAxU7hIkHt x4CIBI6qp5nBjt56MtWRjkp2wFch8lAyXd3UOKV1Ix9nUUh0pLI+6alQGzA02OsQ7z7wMUS+ 3XZU2DVSEXmAQNRC1jeDMgoVqmofpuI838bbU1zXHlbnAc8spU1q/VPDlLuqhLXal2vwWTg8 rXDMYke5mapenIkbv8wm8A== --B_3538574279_38179066-- From nobody Wed Feb 17 21:00:45 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6261A00DA; Wed, 17 Feb 2016 19:46:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218034621.9883.44158.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 19:46:21 -0800 Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 21:00:43 -0800 Cc: manet@ietf.org, manet-chairs@ietf.org Subject: [manet] manet - New Meeting Session Request for IETF 95 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 03:46:21 -0000 A new meeting session request has just been submitted by Stan Ratliff, a Chair of the manet working group. --------------------------------------------------------- Working Group Name: Mobile Ad-hoc Networks Area Name: Routing Area Session Requester: Stan Ratliff Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: rtgarea Second Priority: roll Third Priority: lisp Special Requests: --------------------------------------------------------- From nobody Thu Feb 18 08:19:38 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0B1B2E2E for ; Thu, 18 Feb 2016 08:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.373 X-Spam-Level: X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJwqgnOXhM31 for ; Thu, 18 Feb 2016 08:19:34 -0800 (PST) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C971B2E20 for ; Thu, 18 Feb 2016 08:19:33 -0800 (PST) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id E07AEC0AAF for ; Thu, 18 Feb 2016 17:19:28 +0100 (CET) Date: Thu, 18 Feb 2016 17:48:01 +0100 From: Mattia Campana To: manet@ietf.org Message-ID: <56c5f5c1.+zP1e+aXHXJD/OUA%mattia.campana@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] One Week to Paper Registration: IoP-W 2016 The first IFIP Internet of People Workshop (co-located with Networking 2016) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: iopw2016-publicity@iit.cnr.it List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:19:37 -0000 -------------------------------------------------------------------------------- IFIP IoP-W 2016 - First IFIP Internet of People Workshop co-located with IFIP Networking 2016 20 May 2016, Vienna, Austria http://cnd.iit.cnr.it/iopw2016/ ONE WEEK TO THE PAPER REGISTRATION DEADLINE ******** Abstract Submission Deadline: 23 February 2016 ******** ******** Paper Submission Deadline: 1 March 2016 ******** -------------------------------------------------------------------------------- ****** Paper publication in both ****** ****** IFIP DL http://dl.ifip.org/ ****** ****** IEEE Xplore http://ieeexplore.ieee.org/ ****** SCOPE AND OVERVIEW ---------------------------------------- The massive penetration of Internet connectivity and devices with networking and computing capabilities (such as "things" and personal users' devices) is pushing a tighter and tighter convergence between the cyber world - of Internet protocols, services and Apps - and the physical world, with continuous interactions and mutual impact between these two worlds. According to an "anti-Copernican" view, humans are put back at the centre of the "Internet universe", whenever they are in the loop of cyber-world services. Applications, middlewares, but even Internet services and network protocols are more and more designed incorporating Human Individual and Social Behavioural (HISB) models. This is particularly the case when users' personal devices are themselves the network, or provide services to each other such as in mobile self-organising networks, because devices become the "proxies" of their users in the cyber world. Interestingly, similar approaches are also explored in Internet technologies in developing scenarios, where users' participation is often exploited as another resource for networking services. This vision, that we call "the Internet of People" (IoP) generalises emerging concepts and technologies such as IoT, which put the emphasis on the communication between "machines", and adapt to the users' behaviour only as an afterthought. Designing IoP protocols, services and applications thus requires a profound inter-disciplinary approach, where "non-ICT disciplines" such as social sciences, cognitive sciences, economics, complex network sciences, impact the way Internet algorithms are conceived and defined. Note that other types of inter-disciplinary design patterns i.e., bio-inspired approaches where non-human natural behaviours are used as inspiration for network protocols and services, are out of scope. This workshop aims to stimulate research following this view, and aggregate an inter-disciplinary community of researchers around the concept of the Internet of People. Specifically, we seek papers presenting IoP approaches, addressing any layer of the canonical Internet stack or cross-layer combinations thereof, where the human behaviour is at the centre of the design. Also, we welcome submissions that analyse how the human behaviour is affected (and possibly modified) by the use of Internet systems, and how the latter can be improved or re-designed accordingly. The workshop will accept papers where quantitative evidence is available or quantitative approaches are applied. Therefore, purely methodological papers or qualitative analyses will be considered out of scope. Papers proposing novel, thought provoking ideas, possibly presenting preliminary results and analyses are also welcome. However, we do not call for position papers. Topics of interest include, but are not limited to, the following - Networking IoP protocols based on HISB models - Information-centric IoP protocols based on HISB models - IoP services, service-composition and middleware solutions based on HISB models - Online Social Network services based on HISB models - Analysis and modelling of human behaviours in massively diffused Internet services, such as Online Social Networks - Complex network approaches to IoP - IoP protocols and services in developing regions - Privacy, security and trust mechanisms for IoP based on HISB models - QoE aspects in IoP - Human-centric, inter-disciplinary IoP solutions for IoT scenarios - Crowdsourcing, crowdsensing, pervasive sensing in IoP - Test and experimental results with IoP solutions - Architecture, design and implementation of IoP protocols - Modelling, analysis and characterisation of IoP solutions For any additional information please visit the workshop website at http://cnd.iit.cnr.it/iopw2016/, or contact the workshop chairs at iopw2016 iit cnr it BEST PAPER AWARD ---------------- IoP-W 2016 will grant a Best Paper Award sponsored by IFIP TC6. PAPER FORMAT AND SUBMISSION INSTRUCTIONS ---------------------------------------- Papers should neither have been published elsewhere nor being currently under review by another conference or journal. Submitted papers must be no more than 6 pages (IEEE two-column format, 10pt). Papers will be reviewed single blind. Please follow the submission link at: https://easychair.org/conferences/?conf=ifipiopw2016 Detailed submission information is available at http://cnd.iit.cnr.it/iopw2016/submission.html IoP-W papers will be available in the IFIP Digital Library (http://dl.ifip.org/). IoP-W adopts the IFIP TC Open Access policy. The IFIP DL is Open Access. IFIP holds papers copyright, and releases it freely to authors for any use. Thanks to this model, papers will also be available in and indexed by IEEE Xplore, while copyright will still remain available to authors. At least one author of each accepted paper is required to register and present his/her work at the workshop. EDITORIAL FOLLOW-UPS ---------------------------------------- Extended versions of the selected workshop papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier), in a special section on Internet of People. IMPORTANT DATES ---------------------------------------- Abstract Registration: 23 February 2016 Submission Deadline: 1 March 2016 Authors Notification: 8 April 2016 Camera Ready Due: 22 April 2016 Workshop: 20 May 2016 WORKSHOP CO-CHAIRS ---------------------------------------- Isabelle Chrisment, TELECOM Nancy, Universite de Lorraine, France Andrea Passarella, IIT-CNR, Italy Ana Pont-Sanjuan, Polytechnic University of Valencia, Spain PUBLICITY CO-CHAIRS ---------------------------------------- Mattia Campana, IIT-CNR, Italy Yang Chen, Fudan University, China PROGRAM COMMITTEE ---------------------------------------- Jussara M. Almeida, Universidade Federal de Minas Gerais, Brazil Valerio Arnaboldi, IIT-CNR, Italy Guido Caldarelli, IMT of Lucca, Italy Yang Chen, Fudan University, China Marco Conti, IIT-CNR, Italy Sajal K. Das, University of Missouri, USA Jordi Domingo-Pascual, Universitat Politecnica de Catalunya, Spain Falko Dressler, University of Paderborn, Germany Xiaoming Fu, University of Goettingen, Germany Sabrina Gaito, University of Milan, Italy Ahmed Helmy, University of Florida, USA Pan Hui, The Hong Kong University of Science and Technology, Hong Kong Tobias Hossfeld, University of Duisburg-Essen, Germany Adriana Iamnitchi, University of South Florida, USA Teemu Karkkainen, TUM, Germany Claudia-Lavinia Ignat, Inria, France Winfried Lamersdorf, University of Hamburg, Germany Yong Li, Tsinghua University, China William Liu, Auckland University of Technology (AUT), New Zealand Renato Lo Cigno, University of Trento, Italy Paul Lukowicz, DFKI, Germany Marco Mamei, University of Modena e Reggio Emilia, Italy Matteo Mordacchini, IIT-CNR, Italy Melek Onen, EURECOM, France Joerg Ott, TUM, Germany Dino Pedreschi, University of Pisa, Italy Dario Pompili, Rutgers University, USA Peter Reichl, University of Vienna, Austria George Roussos, University of London, UK Alessandra Sala, Bell Labs, Ireland Nishanth Sastry, Kings College London, UK Arjuna Sathiaseelan, University of Cambridge, UK Siraj Shaikh, University of Coventry, UK Valerie Shalin, Wright State University, USA Burkhard Stiller, University of Zurich, Switzerland Thorsten Strufe, University of Dresden, Germany Martin Varela, VTT, Finland Roger Whitaker, Cardiff University, UK From nobody Thu Feb 18 16:26:35 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763B1A00FA; Thu, 18 Feb 2016 16:26:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219002634.8593.96916.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 16:26:34 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 00:26:34 -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 of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-19.txt Pages : 70 Date : 2016-02-18 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 routing 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: https://tools.ietf.org/html/draft-ietf-manet-dlep-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 19 07:05:59 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C611B30A5 for ; Fri, 19 Feb 2016 07:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grRsAfrApDmp for ; Fri, 19 Feb 2016 07:05:52 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE2C1B3111 for ; Fri, 19 Feb 2016 07:05:51 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWmcw-0047nh-90>; Fri, 19 Feb 2016 16:05:50 +0100 Received: from dhcp-wlcd147006.zim.uni-duisburg-essen.de ([134.91.147.6]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES128-SHA:128) (envelope-from ) id <1aWmcv-001qt7-Nt>; Fri, 19 Feb 2016 16:05:50 +0100 From: Lotte Steenbrink Content-Type: multipart/mixed; boundary="Apple-Mail=_593D08F9-6B72-41AC-9F7A-4034FBA88859" Date: Fri, 19 Feb 2016 16:05:54 +0100 To: manet@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 134.91.147.6 X-ZEDAT-Hint: A Archived-At: Subject: [manet] AODVv2: Security considerations update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:05:58 -0000 --Apple-Mail=_593D08F9-6B72-41AC-9F7A-4034FBA88859 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, in the interest of transparency, we (the AODVv2 author team) want to = send out more updates on what we've been doing, and this is the first of = these e-mails. We've restructured (and sometimes rewritten) our security = considerations a bit and added a subsection about the Trust Model, and = we'd love to hear your opinions on those changes. You can find the = result and a diff to the current considerations in the attachments. (the = formatting was done manually, so it might be a bit wonky) Some notes: * This is all work in progress, so please poke holes into it where you = can! * While (afaik) the Availability/Confidentiality/Integrity model may be = considered a bit dated, I thought it might be a good starting point. * I was wondering if =93Encryption will not only protect against = unauthorized devices obtaining information about network topology=94 isn't a tad too short and bold=96= maybe we could add a clarification along the lines of: Encryption will not only make it more difficult for unauthorized = devices to obtain information about network topology but will also ensure that only = trusted routers participate in routing operations: When messages are = encrypted, a malicious observer would have to monitor the entire network to = understand its topology and traffic flow. And even then, due to the hop by hop nature of the protocol and the fact that messages are regenerated = rather=20 than forwarded (resulting in a different payload every time), following the path of a message would be hard if its transmission is = not the only encrypted traffic produced by the network. Regards, Lotte --Apple-Mail=_593D08F9-6B72-41AC-9F7A-4034FBA88859 Content-Disposition: attachment; filename="13. Security Considerations-from-_current.diff.html" Content-Type: text/html; name="13. Security Considerations-from-_current.diff.html" Content-Transfer-Encoding: 7bit Diff: 13. Security Considerations_current - 13. Security Considerations
 13. Security Considerations_current   13. Security Considerations 
13. Security Considerations 13. Security Considerations
This section describes various security considerations and potential This section describes various security considerations and potential
avenues to secure AODVv2 routing. The objective of the AODVv2 avenues to secure AODVv2 routing. The main objective of the AODVv2
protocol is for each router to communicate reachability information protocol is for each router to communicate reachability information
about addresses for which it is responsible, and for routes it has about addresses for which it is responsible, and for routes it has
learned from other AODVv2 routers. Positive routing information learned from other AODVv2 routers.
(i.e. a route exists) is distributed via RREQ and RREP messages.
AODVv2 routers store the information contained in these messages in
order to properly forward IP packets, and they generally provide this
information to other AODVv2 routers. Negative routing information
(i.e. a route does not exist) is distributed via RERR messages.
AODVv2 routers process these messages and remove routes, and forward
this information to other AODVv2 routers.
Networks using AODVv2 to maintain connectivity and establish routes Networks using AODVv2 to maintain connectivity and establish routes
on demand may be vulnerable to certain well-known types of threats. on demand may be vulnerable to certain well-known types of threats,
which will be detailed in the following. Some of the threats described
can be mitigated or eliminated. Tools to do so will be described also.
13.1 Availability
Flooding attacks using RREQ amount to a denial of service for route Flooding attacks using RREQ amount to a denial of service for route
discovery. Valid route table entries can be replaced by maliciously discovery: By issuing RREQ mesages for targets that don't exist, an
constructed RREQ and RREP messages. Links could be erroneously attacker can flood the network, blocking resources and drowning out
treated as bidirectional if malicious unsolicited RREP or RREP_Ack legitimate traffic.
messages were to be accepted. Replay attacks using RERR messages
could, in some circumstances, be used to disrupt active routes.
Passive inspection of AODVv2 control messages could enable
unauthorized devices to gain information about the network topology,
since exchanging such information is the main purpose of AODVv2.
The on-demand nature of AODVv2 route discovery reduces the Valid route table entries can be replaced or modified by maliciously
vulnerability to route disruption. Since control traffic for constructed RREQ and RREP messages, destroying existing routes and the
network's integrity.
Links could be erroneously treated as bidirectional if malicious unsolicited
or spoofed RREP and RREP_Ack messages were to be accepted.
Maliciously crafted or replayed RERR messages can be used to disrupt active routes.
However, The on-demand nature of AODVv2 route discovery automatically reduces
the vulnerability to route disruption. Since control traffic for
updating route tables is diminished, there is less opportunity for updating route tables is diminished, there is less opportunity for
failure. Processing requirements for AODVv2 are typically quite attacks and failure.
Processing requirements for AODVv2 are typically quite
small, and would typically be dominated by calculations to verify small, and would typically be dominated by calculations to verify
integrity. This has the effect of reducing (but by no means integrity. This has the effect of reducing (but by no means
eliminating) AODVv2's vulnerability to denial of service attacks. eliminating) AODVv2's vulnerability to denial of service attacks.
13.2 Confidentiality
Passive inspection of AODVv2 control messages could enable
unauthorized devices to gain information about the network topology,
since exchanging such information is the main purpose of AODVv2.
13.3 Integrity
Out of the box, AODVv2 provides no integrity protection. Any participating
router may pose as another router by sending RREQ, RREP, RREP_Ack and RERR
messages in its name. Replaying of (old) RREQ or RREP messages, however,
would be of less use to an attacker, since they would be dropped immediately
due to their stale sequence number.
Encryption MAY be used for AODVv2 messages. If the routers share a Encryption MAY be used for AODVv2 messages. If the routers share a
packet-level security association, the message data can be encrypted packet-level security association, the message data can be encrypted
prior to message transmission. The establishment of such security prior to message transmission. The establishment of such security
associations is outside the scope of this specification. Encryption associations is outside the scope of this specification. Encryption
will not only protect against unauthorized devices obtaining will not only protect against unauthorized devices obtaining
information about network topology but will ensure that only trusted information about network topology but will ensure that only trusted
routers participate in routing operations. routers participate in routing operations.
Message integrity checking is enabled by the Integrity Check Value The data contained in AODVv2 routing protocol messages SHOULD be verified using
mechanisms defined in [RFC7182]. The data contained in AODVv2 Cryptographic Integrity Check Values (ICVs)values, to
routing protocol messages SHOULD be verified using ICV values, to avoid the use of message data if the message has been tampered with.
avoid the use of message data if the message has been tampered with Replay attacks SHOULD be prevented by adding timestamps to the messages.
or replayed. Otherwise, it would be possible to disrupt While the generation of these ICVs and timestamps is out of scope for
communications by injecting nonexistent or malicious routes into the this document, they MUST be represented as defined in [RFC7182].
route tables of routers within the ad hoc network. This can result
in loss of data or message processing by unauthorized devices.
The remainder of this section provides specific recommendations for 13.3.1 Recommendations for ICV and timestamp generation
This section provides specific recommendations for
the use of the integrity checking and timestamp functions defined in the use of the integrity checking and timestamp functions defined in
[RFC7182] to ensure the integrity of each AODVv2 message. The [RFC7182] to ensure the integrity of each AODVv2 message. The
calculation used for the Integrity Check Value will depend on the calculation used for the Integrity Check Value will depend on the
message type. Sequence numbers can be used as timestamps to protect message type. Sequence numbers can be used as timestamps to protect
against replay, since they are known to be strictly increasing. against replay, since they are known to be strictly increasing.
When more than one message is included in an RFC5444 packet, using a
single ICV Packet TLV and a single TIMESTAMP Packet TLV is more efficient
than including an ICV Message TLV and TIMESTAMP Message TLV in each
message created. In this case, the RFC5444 multiplexer must be instructed
to include the ICV and TIMESTAMP Packet TLVs in packets containing AODVv2
messages, or must be selected because it always performs these additions.
If the multiplexer is not capable of adding these Packet TLVs, they SHOULD
be included in each AODVv2 message.
RREQ messages advertise a route to OrigAddr, and impose very little RREQ messages advertise a route to OrigAddr, and impose very little
processing requirement for receivers. The main threat presented by processing requirement for receivers. The main threat presented by
sending an RREQ message with false information is that traffic to sending an RREQ message with false information is that traffic to
OrigAddr could be disrupted. Since RREQ is multicast and likely to OrigAddr could be disrupted. Since RREQ is multicast and likely to
be received by all routers in the ad hoc network, this threat could be received by all routers in the ad hoc network, this threat could
have serious impact on applications communicating by way of OrigAddr. have serious impact on applications communicating by way of OrigAddr.
The actual threat to disrupt routes to OrigAddr is reduced by the The actual threat to disrupt routes to OrigAddr is reduced by the
AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed" AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed"
until the link to the next hop is confirmed. If AODVv2 routers until the link to the next hop is confirmed. If AODVv2 routers
always verify the integrity of the RREQ message data, then the threat verify the integrity of the RREQ message data with the help of ICVs,
of disruption is minimized. The ICV mechanisms offered in [RFC7182] then the threat of disruption is minimized. Since OrigAddr is included in the
are sufficient for this purpose. Since OrigAddr is included in the
RREQ, the ICV can be calculated and verified using message contents. RREQ, the ICV can be calculated and verified using message contents.
The ICV SHOULD be verified at every step along the dispersal path of The ICV SHOULD be verified at every step along the dispersal path of
the RREQ to mitigate the threat. Since RREQ_Gen's sequence number is the RREQ to mitigate the threat. Since RREQ_Gen's sequence number is
incremented for each new RREQ, replay protection is already afforded incremented for each new RREQ, replay protection is already afforded
and no extra timestamp mechanism is required. and no extra timestamp mechanism is required.
RREP messages advertise a route to TargAddr, and impose very little RREP messages advertise a route to TargAddr, and impose very little
processing requirement for receivers. The main threat presented by processing requirement for receivers. The main threat presented by
sending an RREP message with false information is that traffic to sending an RREP message with false information is that traffic to
TargAddr could be disrupted. Since RREP is unicast, this threat is TargAddr could be disrupted. Since RREP is unicast, this threat is
restricted to receivers along the path from OrigAddr to TargAddr. If restricted to receivers along the path from OrigAddr to TargAddr. If
AODVv2 routers always verify the integrity of the RREP message data, AODVv2 routers always verify the integrity of the RREP message data with the help of ICVs,
then this threat is minimized. This facility is offered by the ICV then this threat is minimized. Since TargAddr is included as a Data
mechanisms in [RFC7182]. Since TargAddr is included as a Data
Element of the RREP, the ICV can be calculated and verified using Element of the RREP, the ICV can be calculated and verified using
message contents. The ICV SHOULD be verified at every step along the message contents. The ICV SHOULD be verified at every step along the
unicast path of the RREP. Since RREP_Gen's sequence number is unicast path of the RREP. Since RREP_Gen's sequence number is
incremented for each new RREP, replay protection is afforded and no incremented for each new RREP, replay protection is afforded and no
extra timestamp mechanism is required. extra timestamp mechanism is required.
RREP_Ack messages are intended to verify bidirectional neighbor RREP_Ack messages are intended to verify bidirectional neighbor
connectivity, and impose very little processing requirement for connectivity, and impose very little processing requirement for
receivers. The main threat presented by sending an RREP_Ack message receivers. The main threat presented by sending an RREP_Ack message
with false information is that the route advertised to a target with false information is that the route advertised to a target
address in an RREP might be erroneously accepted even though the address in an RREP might be erroneously accepted even though the
route would contain a unidirectional link and thus not be suitable route would contain a unidirectional link and thus not be suitable
for most traffic. Since RREP_Ack is unicast, this threat is strictly for most traffic. Since RREP_Ack is unicast, this threat is strictly
local to the RREP transmitter expecting the acknowledgement. A local to the RREP transmitter expecting the acknowledgement. A
malicious router could also attempt to send an unsolicited RREP_Ack malicious router could also attempt to send an unsolicited RREP_Ack
to convince another router that a bidirectional link exists and to convince another router that a bidirectional link exists and
subsequently use further messages to divert traffic along a route subsequently use further messages to divert traffic along a route
which is not valid. If AODVv2 routers always verify the integrity of which is not valid. If AODVv2 routers always verify the integrity of
the RREP_Ack message data, then this threat is minimized. This the RREP_Ack message data, then this threat is minimized.
facility is offered by the ICV mechanisms in [RFC7182]. The RREP_Gen The RREP_Gen SHOULD use the source IP address of the RREP_Ack to identify the
SHOULD use the source IP address of the RREP_Ack to identify the
sender, and so the ICV SHOULD be calculated using the message sender, and so the ICV SHOULD be calculated using the message
contents and the IP source address. The message must also include contents and the IP source address. The message must also include
the Timestamp defined in [RFC7182] to protect against replay attacks, a timestamp to protect against replay attacks, using TargSeqNum from the RREP
using TargSeqNum from the RREP as the value in the TIMESTAMP TLV. as the value in the TIMESTAMP TLV.
RERR messages remove routes, and impose very little processing RERR messages remove routes, and impose very little processing
requirement for receivers. The main threat presented by sending an requirement for receivers. The main threat presented by sending an
RERR message with false information is that traffic to the advertised RERR message with false information is that traffic to the advertised
destinations could be disrupted. Since RERR is multicast and can be destinations could be disrupted. Since RERR is multicast and can be
received by many routers in the ad hoc network, this threat could received by many routers in the ad hoc network, this threat could
have serious impact on applications communicating by way of the have serious impact on applications communicating by way of the
sender of the RERR message. However, since the sender of the RERR sender of the RERR message. However, since the sender of the RERR
message with erroneous information MAY be presumed to be either message with erroneous information MAY be presumed to be either
malicious or broken, it is better that such routes not be used malicious or broken, it is better that such routes not be used
anyway. Another threat is that a malicious RERR message MAY be sent anyway. Another threat is that a malicious RERR message MAY be sent
with a PktSource included, to disrupt PktSource's ability to send to with a PktSource included, to disrupt PktSource's ability to send to
the addresses contained in the RERR. If AODVv2 routers always verify the addresses contained in the RERR. If AODVv2 routers always verify
the integrity of the RERR message data, then this threat is reduced. the integrity of the RERR message data with the help of ICVs, this threat is reduced.
This facility is offered by the ICV mechanisms in [RFC7182]. The The receiver of the RERR SHOULD use the source IP address of the RERR to
receiver of the RERR SHOULD use the source IP address of the RERR to identify the sender. The message must also include a timestamp to protect
identify the sender. The message must also include the Timestamp against replay attacks, using SeqNum from RERR_Gen as the value in the TIMESTAMP TLV.
defined in [RFC7182] to protect against replay attacks, using SeqNum
from RERR_Gen as the value in the TIMESTAMP TLV. 13.4 Trust Model
Since routing information is distributed to neighbours on a hop-by-hop basis,
and route messages are regenerated at each router, AODVv2 assumes a security
model of transitive trust. The sender of a message must be trusted in order
for receiving one-hop neighbours to store the routing information it
provides and regenerate the message to their own one-hop neighbours.
Routes are installed based on information received from trusted neighbours.
Therefore a chain of trust back to the originator of a message is assumed
by any router using the routing information received.
Since messages are regenerated rather than forwarded, the message concepts
known as RREQ, RREP and RERR do not travel as a single unchanged entity
between source and destination, and therefore message integrity cannot be
assured end-to-end. Using ICVs and timestamps, messages can be protected
on a hop-by-hop basis, allowing only those routers with knowledge of a
shared secret key to participate in routing information exchanges, and
protecting against replay attacks.
 End of changes. 17 change blocks. 
47 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail=_593D08F9-6B72-41AC-9F7A-4034FBA88859 Content-Disposition: attachment; filename="13. Security Considerations.txt" Content-Type: text/plain; name="13. Security Considerations.txt" Content-Transfer-Encoding: quoted-printable 13. Security Considerations This section describes various security considerations and potential avenues to secure AODVv2 routing. The main objective of the AODVv2 protocol is for each router to communicate reachability information about addresses for which it is responsible, and for routes it has learned from other AODVv2 routers. Networks using AODVv2 to maintain connectivity and establish routes on demand may be vulnerable to certain well-known types of threats, which will be detailed in the following. Some of the threats = described can be mitigated or eliminated. Tools to do so will be described = also. 13.1 Availability Flooding attacks using RREQ amount to a denial of service for route discovery: By issuing RREQ mesages for targets that don't exist, an attacker can flood the network, blocking resources and drowning out legitimate traffic. Valid route table entries can be replaced or modified by maliciously constructed RREQ and RREP messages, destroying existing routes and = the network's integrity. Links could be erroneously treated as bidirectional if malicious = unsolicited or spoofed RREP and RREP_Ack messages were to be accepted. Maliciously crafted or replayed RERR messages can be used to disrupt = active routes. However, The on-demand nature of AODVv2 route discovery automatically = reduces the vulnerability to route disruption. Since control traffic for updating route tables is diminished, there is less opportunity for attacks and failure. Processing requirements for AODVv2 are typically quite small, and would typically be dominated by calculations to verify integrity. This has the effect of reducing (but by no means eliminating) AODVv2's vulnerability to denial of service attacks. 13.2 Confidentiality Passive inspection of AODVv2 control messages could enable unauthorized devices to gain information about the network topology, since exchanging such information is the main purpose of AODVv2. 13.3 Integrity Out of the box, AODVv2 provides no integrity protection. Any = participating router may pose as another router by sending RREQ, RREP, RREP_Ack and = RERR messages in its name. Replaying of (old) RREQ or RREP messages, = however, would be of less use to an attacker, since they would be dropped = immediately due to their stale sequence number. Encryption MAY be used for AODVv2 messages. If the routers share a packet-level security association, the message data can be encrypted prior to message transmission. The establishment of such security associations is outside the scope of this specification. Encryption will not only protect against unauthorized devices obtaining information about network topology but will ensure that only trusted routers participate in routing operations. The data contained in AODVv2 routing protocol messages SHOULD be = verified using Cryptographic Integrity Check Values (ICVs)values, to avoid the use of message data if the message has been tampered with. Replay attacks SHOULD be prevented by adding timestamps to the = messages. While the generation of these ICVs and timestamps is out of scope for this document, they MUST be represented as defined in [RFC7182]. 13.3.1 Recommendations for ICV and timestamp generation This section provides specific recommendations for the use of the integrity checking and timestamp functions defined in [RFC7182] to ensure the integrity of each AODVv2 message. The calculation used for the Integrity Check Value will depend on the message type. Sequence numbers can be used as timestamps to protect against replay, since they are known to be strictly increasing. When more than one message is included in an RFC5444 packet, using a single ICV Packet TLV and a single TIMESTAMP Packet TLV is more = efficient than including an ICV Message TLV and TIMESTAMP Message TLV in each message created. In this case, the RFC5444 multiplexer must be = instructed to include the ICV and TIMESTAMP Packet TLVs in packets containing = AODVv2 messages, or must be selected because it always performs these = additions. If the multiplexer is not capable of adding these Packet TLVs, they = SHOULD be included in each AODVv2 message. RREQ messages advertise a route to OrigAddr, and impose very little processing requirement for receivers. The main threat presented by sending an RREQ message with false information is that traffic to OrigAddr could be disrupted. Since RREQ is multicast and likely to be received by all routers in the ad hoc network, this threat could have serious impact on applications communicating by way of OrigAddr. The actual threat to disrupt routes to OrigAddr is reduced by the AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed" until the link to the next hop is confirmed. If AODVv2 routers verify the integrity of the RREQ message data with the help of ICVs, then the threat of disruption is minimized. Since OrigAddr is = included in the RREQ, the ICV can be calculated and verified using message contents. The ICV SHOULD be verified at every step along the dispersal path of the RREQ to mitigate the threat. Since RREQ_Gen's sequence number is incremented for each new RREQ, replay protection is already afforded and no extra timestamp mechanism is required. RREP messages advertise a route to TargAddr, and impose very little processing requirement for receivers. The main threat presented by sending an RREP message with false information is that traffic to TargAddr could be disrupted. Since RREP is unicast, this threat is restricted to receivers along the path from OrigAddr to TargAddr. If AODVv2 routers always verify the integrity of the RREP message data = with the help of ICVs, then this threat is minimized. Since TargAddr is included as a Data Element of the RREP, the ICV can be calculated and verified using message contents. The ICV SHOULD be verified at every step along the unicast path of the RREP. Since RREP_Gen's sequence number is incremented for each new RREP, replay protection is afforded and no extra timestamp mechanism is required. RREP_Ack messages are intended to verify bidirectional neighbor connectivity, and impose very little processing requirement for receivers. The main threat presented by sending an RREP_Ack message with false information is that the route advertised to a target address in an RREP might be erroneously accepted even though the route would contain a unidirectional link and thus not be suitable for most traffic. Since RREP_Ack is unicast, this threat is strictly local to the RREP transmitter expecting the acknowledgement. A malicious router could also attempt to send an unsolicited RREP_Ack to convince another router that a bidirectional link exists and subsequently use further messages to divert traffic along a route which is not valid. If AODVv2 routers always verify the integrity of the RREP_Ack message data, then this threat is minimized. The RREP_Gen SHOULD use the source IP address of the RREP_Ack to = identify the sender, and so the ICV SHOULD be calculated using the message contents and the IP source address. The message must also include a timestamp to protect against replay attacks, using TargSeqNum from = the RREP as the value in the TIMESTAMP TLV. RERR messages remove routes, and impose very little processing requirement for receivers. The main threat presented by sending an RERR message with false information is that traffic to the advertised destinations could be disrupted. Since RERR is multicast and can be received by many routers in the ad hoc network, this threat could have serious impact on applications communicating by way of the sender of the RERR message. However, since the sender of the RERR message with erroneous information MAY be presumed to be either malicious or broken, it is better that such routes not be used anyway. Another threat is that a malicious RERR message MAY be sent with a PktSource included, to disrupt PktSource's ability to send to the addresses contained in the RERR. If AODVv2 routers always verify the integrity of the RERR message data with the help of ICVs, this = threat is reduced. The receiver of the RERR SHOULD use the source IP address of the RERR = to identify the sender. The message must also include a timestamp to = protect against replay attacks, using SeqNum from RERR_Gen as the value in = the TIMESTAMP TLV. 13.4 Trust Model Since routing information is distributed to neighbours on a = hop-by-hop basis, and route messages are regenerated at each router, AODVv2 assumes a = security model of transitive trust. The sender of a message must be trusted in = order for receiving one-hop neighbours to store the routing information it provides and regenerate the message to their own one-hop neighbours. Routes are installed based on information received from trusted = neighbours. Therefore a chain of trust back to the originator of a message is = assumed by any router using the routing information received. Since messages are regenerated rather than forwarded, the message = concepts known as RREQ, RREP and RERR do not travel as a single unchanged = entity between source and destination, and therefore message integrity = cannot be assured end-to-end. Using ICVs and timestamps, messages can be = protected on a hop-by-hop basis, allowing only those routers with knowledge of = a shared secret key to participate in routing information exchanges, = and protecting against replay attacks. --Apple-Mail=_593D08F9-6B72-41AC-9F7A-4034FBA88859-- From nobody Fri Feb 19 07:52:19 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994CB1AD080 for ; Fri, 19 Feb 2016 07:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF5X1Oj7kQX8 for ; Fri, 19 Feb 2016 07:52:13 -0800 (PST) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8DE1A9023 for ; Fri, 19 Feb 2016 07:52:12 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,471,1449532800"; d="scan'208,217"; a="31342411" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 19 Feb 2016 15:52:10 +0000 X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208,217";a="106944019" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 19 Feb 2016 15:52:10 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.89]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 15:52:11 +0000 From: "Dearlove, Christopher (UK)" To: Lotte Steenbrink , "manet@ietf.org" Thread-Topic: [manet] AODVv2: Security considerations update Thread-Index: AQHRaycSXu8ve8QZcUyQTthv3yKKT58zgQlw Date: Fri, 19 Feb 2016 15:52:09 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8BFFFB72GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] AODVv2: Security considerations update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:52:17 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8BFFFB72GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSB3b3VsZCBzYXkgdGhhdCBpbiB0aGUgaW50ZXJlc3RzIG9mIHRyYW5zcGFyZW5jeSwgYSBsb3Qg bW9yZSBzaG91bGQgYXBwZWFyIG9uIGxpc3QuIE9mIGNvdXJzZSB0aGVyZeKAmXMgbm8gbmVlZCAt IHVudGlsIGxhdGVyIHN0YWdlcyAtIHRvIGRpc2N1c3MgZXZlcnkgZWRpdG9yaWFsIG5pdCBvbiBs aXN0LCBidXQgYmFzaWMgZGVjaXNpb25zIHNob3VsZCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGhlcmUg YmVmb3JlIG5vdywgYW5kIHJlc3BvbnNlcyB0byBjb21tZW50cyByZWNlaXZlZCAoSeKAmXZlIG5l dmVyIGhhZCByZXNwb25zZXMgdG8gYWxsIG15IGNvbW1lbnRzKS4NCg0KT24gdGhpcyBwb3N0aW5n LCBpdOKAmXMgbm90IGV4YWN0bHkgdHJ1ZSB0aGF0DQoNCiAgIEVuY3J5cHRpb24gd2lsbCBub3Qg b25seSBtYWtlIGl0IG1vcmUgZGlmZmljdWx0IGZvciB1bmF1dGhvcml6ZWQgZGV2aWNlcyB0byBv YnRhaW4NCiAgIGluZm9ybWF0aW9uIGFib3V0IG5ldHdvcmsgdG9wb2xvZ3kgYnV0IHdpbGwgYWxz byBlbnN1cmUgdGhhdCBvbmx5IHRydXN0ZWQNCiAgIHJvdXRlcnMgcGFydGljaXBhdGUgaW4gcm91 dGluZyBvcGVyYXRpb25zOg0KDQpXaGF0IGVuc3VyZSB0aGUgbGF0dGVyIGlzIG5vdCBlbmNyeXB0 aW9uLCBidXQgYXV0aGVudGljYXRpb24uIEl0IGlzIHRydWUgdGhhdCBvbmUgc2hvdWxkIGdlbmVy YWxseSBub3QgdXNlIGVuY3J5cHRpb24gd2l0aG91dCBhdXRoZW50aWNhdGlvbiwgYW5kIHRoZXJl IGFyZSBzb21lIGFsZ29yaXRobXMgdGhhdCBkbyBib3RoIHRvZ2V0aGVyLiBOZXZlcnRoZWxlc3Mg SSB0aGluayBpdOKAmXMgYm90aCB1c2VmdWwgYW5kIGltcG9ydGFudCB0byBhc3NpZ24gdGhlIHJp Z2h0IHByb3BlcnRpZXMgdG8gZWFjaC4NCg0KVGhlcmXigJlzIHRoZW4gdGhlIHByYWN0aWNhbCBp c3N1ZSB0aGF0IHdpdGggYSBzaGFyZWQgc2VjcmV0IGtleSwgZW5jcnlwdGlvbiBhbmQgYXV0aGVu dGljYXRpb24gYXJlIGJvdGggKHJlbGF0aXZlbHkpIGVhc3kuIEJ1dCBpZiB5b3Ugd2FudCBhIHNv bHV0aW9uIHRoYXQgaXNu4oCZdCB0aGF0IChiZWNhdXNlIHRoYXQgaGFzIHZhcmlvdXMgZHJhd2Jh Y2tzKSB0aGVuIGF1dGhlbnRpY2F0aW9uIGlzIG1vcmUgbWFuYWdlYWJsZSB0aGFuIGVuY3J5cHRp b24uIEZvciBleGFtcGxlIGRyYWZ0LWlldGYtbWFuZXQtaWJzIGhhcyBhIHNjaGVtZSAobm90IG9m IGNvdXJzZSB0aGUgb25seSBwb3NzaWJsZSBvbmUpIGZvciBhdXRoZW50aWNhdGlvbi4gVGhlIGVx dWl2YWxlbnQgZm9yIGVuY3J5cHRpb24gdGhhdCBhY3R1YWxseSBjb25jZWFscyBuZXR3b3JrIHRv cG9sb2d5IGlzIGhhcmQgKGp1c3QgcmV2ZWFsaW5nIGFsbCBhZGRyZXNzZXMgZ2l2ZXMgYXdheSBx dWl0ZSBhIGxvdCkuDQoNCihGb2xsb3dpbmcgdGhlIHBhdGggb2YgYSBzaWduYWxsaW5nIG1lc3Nh Z2UgaXMgcHJvYmFibHkgZWFzaWVyIGluIGEgcmVhY3RpdmUgbmV0d29yaywgYmVjYXVzZSBvZiB0 aGUgZGlyZWN0IHJlYWN0aW9uLikNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv cmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwg IEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN MiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJl eSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5l dCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3R0ZSBTdGVl bmJyaW5rDQpTZW50OiAxOSBGZWJydWFyeSAyMDE2IDE1OjA2DQpUbzogbWFuZXRAaWV0Zi5vcmcN ClN1YmplY3Q6IFttYW5ldF0gQU9EVnYyOiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyB1cGRhdGUN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LA0KZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4N CkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55DQpsaW5r cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3Vz cGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycw0KZm9yIGluc3RydWN0aW9ucyBvbiBy ZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCioqKiBXQVJOSU5HICoqKg0K RVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbml6YXRpb24uDQoNCg0KSGkgYWxsLA0KaW4gdGhlIGludGVyZXN0IG9mIHRyYW5zcGFy ZW5jeSwgd2UgKHRoZSBBT0RWdjIgYXV0aG9yIHRlYW0pIHdhbnQgdG8gc2VuZCBvdXQgbW9yZSB1 cGRhdGVzIG9uIHdoYXQgd2UndmUgYmVlbiBkb2luZywgYW5kIHRoaXMgaXMgdGhlIGZpcnN0IG9m IHRoZXNlIGUtbWFpbHMuIFdlJ3ZlIHJlc3RydWN0dXJlZCAoYW5kIHNvbWV0aW1lcyByZXdyaXR0 ZW4pIG91ciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhIGJpdCBhbmQgYWRkZWQgYSBzdWJzZWN0 aW9uIGFib3V0IHRoZSBUcnVzdCBNb2RlbCwgYW5kIHdlJ2QgbG92ZSB0byBoZWFyIHlvdXIgb3Bp bmlvbnMgb24gdGhvc2UgY2hhbmdlcy4gWW91IGNhbiBmaW5kIHRoZSByZXN1bHQgYW5kIGEgZGlm ZiB0byB0aGUgY3VycmVudCBjb25zaWRlcmF0aW9ucyBpbiB0aGUgYXR0YWNobWVudHMuICh0aGUg Zm9ybWF0dGluZyB3YXMgZG9uZSBtYW51YWxseSwgc28gaXQgbWlnaHQgYmUgYSBiaXQgd29ua3kp DQoNClNvbWUgbm90ZXM6DQoqIFRoaXMgaXMgYWxsIHdvcmsgaW4gcHJvZ3Jlc3MsIHNvIHBsZWFz ZSBwb2tlIGhvbGVzIGludG8gaXQgd2hlcmUgeW91IGNhbiENCiogV2hpbGUgKGFmYWlrKSB0aGUg QXZhaWxhYmlsaXR5L0NvbmZpZGVudGlhbGl0eS9JbnRlZ3JpdHkgbW9kZWwgbWF5IGJlIGNvbnNp ZGVyZWQgYSBiaXQgZGF0ZWQsIEkgdGhvdWdodCBpdCBtaWdodCBiZSBhIGdvb2Qgc3RhcnRpbmcg cG9pbnQuDQoqIEkgd2FzIHdvbmRlcmluZyBpZiDigJxFbmNyeXB0aW9uIHdpbGwgbm90IG9ubHkg cHJvdGVjdCBhZ2FpbnN0IHVuYXV0aG9yaXplZCBkZXZpY2VzIG9idGFpbmluZw0KICAgaW5mb3Jt YXRpb24gYWJvdXQgbmV0d29yayB0b3BvbG9neeKAnSBpc24ndCBhIHRhZCB0b28gc2hvcnQgYW5k IGJvbGTigJMgbWF5YmUgd2UgY291bGQgYWRkIGEgY2xhcmlmaWNhdGlvbiBhbG9uZyB0aGUgbGlu ZXMgb2Y6DQoNCiAgIEVuY3J5cHRpb24gd2lsbCBub3Qgb25seSBtYWtlIGl0IG1vcmUgZGlmZmlj dWx0IGZvciB1bmF1dGhvcml6ZWQgZGV2aWNlcyB0byBvYnRhaW4NCiAgIGluZm9ybWF0aW9uIGFi b3V0IG5ldHdvcmsgdG9wb2xvZ3kgYnV0IHdpbGwgYWxzbyBlbnN1cmUgdGhhdCBvbmx5IHRydXN0 ZWQNCiAgIHJvdXRlcnMgcGFydGljaXBhdGUgaW4gcm91dGluZyBvcGVyYXRpb25zOiBXaGVuIG1l c3NhZ2VzIGFyZSBlbmNyeXB0ZWQsDQogICBhIG1hbGljaW91cyBvYnNlcnZlciB3b3VsZCBoYXZl IHRvIG1vbml0b3IgdGhlIGVudGlyZSBuZXR3b3JrIHRvIHVuZGVyc3RhbmQNCiAgIGl0cyB0b3Bv bG9neSBhbmQgdHJhZmZpYyBmbG93LiBBbmQgZXZlbiB0aGVuLCBkdWUgdG8gdGhlIGhvcCBieSBo b3ANCiAgIG5hdHVyZSBvZiB0aGUgcHJvdG9jb2wgYW5kIHRoZSBmYWN0IHRoYXQgbWVzc2FnZXMg YXJlIHJlZ2VuZXJhdGVkIHJhdGhlcg0KICAgdGhhbiBmb3J3YXJkZWQgKHJlc3VsdGluZyBpbiBh IGRpZmZlcmVudCBwYXlsb2FkIGV2ZXJ5IHRpbWUpLA0KICAgZm9sbG93aW5nIHRoZSBwYXRoIG9m IGEgbWVzc2FnZSB3b3VsZCBiZSBoYXJkIGlmIGl0cyB0cmFuc21pc3Npb24gaXMgbm90DQogICB0 aGUgb25seSBlbmNyeXB0ZWQgdHJhZmZpYyBwcm9kdWNlZCBieSB0aGUgbmV0d29yay4NCg0KUmVn YXJkcywNCkxvdHRlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQg b3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8BFFFB72GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgc2F5IHRoYXQgaW4gdGhlIGlu dGVyZXN0cyBvZiB0cmFuc3BhcmVuY3ksIGEgbG90IG1vcmUgc2hvdWxkIGFwcGVhciBvbiBsaXN0 LiBPZiBjb3Vyc2UgdGhlcmXigJlzIG5vIG5lZWQgLSB1bnRpbCBsYXRlciBzdGFnZXMgLSB0byBk aXNjdXNzIGV2ZXJ5IGVkaXRvcmlhbA0KIG5pdCBvbiBsaXN0LCBidXQgYmFzaWMgZGVjaXNpb25z IHNob3VsZCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGhlcmUgYmVmb3JlIG5vdywgYW5kIHJlc3BvbnNl cyB0byBjb21tZW50cyByZWNlaXZlZCAoSeKAmXZlIG5ldmVyIGhhZCByZXNwb25zZXMgdG8gYWxs IG15IGNvbW1lbnRzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uIHRoaXMgcG9zdGluZywgaXTigJlzIG5vdCBleGFj dGx5IHRydWUgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IEVuY3J5cHRpb24gd2lsbCBub3Qgb25seSBtYWtlIGl0 IG1vcmUgZGlmZmljdWx0IGZvciB1bmF1dGhvcml6ZWQgZGV2aWNlcyB0byBvYnRhaW48YnI+DQom bmJzcDsmbmJzcDsgaW5mb3JtYXRpb24gYWJvdXQgbmV0d29yayB0b3BvbG9neSBidXQgd2lsbCBh bHNvIGVuc3VyZSB0aGF0IG9ubHkgdHJ1c3RlZDxicj4NCiZuYnNwOyZuYnNwOyByb3V0ZXJzIHBh cnRpY2lwYXRlIGluIHJvdXRpbmcgb3BlcmF0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgZW5zdXJlIHRoZSBsYXR0ZXIgaXMg bm90IGVuY3J5cHRpb24sIGJ1dCBhdXRoZW50aWNhdGlvbi4gSXQgaXMgdHJ1ZSB0aGF0IG9uZSBz aG91bGQgZ2VuZXJhbGx5IG5vdCB1c2UgZW5jcnlwdGlvbiB3aXRob3V0IGF1dGhlbnRpY2F0aW9u LCBhbmQgdGhlcmUgYXJlDQogc29tZSBhbGdvcml0aG1zIHRoYXQgZG8gYm90aCB0b2dldGhlci4g TmV2ZXJ0aGVsZXNzIEkgdGhpbmsgaXTigJlzIGJvdGggdXNlZnVsIGFuZCBpbXBvcnRhbnQgdG8g YXNzaWduIHRoZSByaWdodCBwcm9wZXJ0aWVzIHRvIGVhY2guPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZeKAmXMg dGhlbiB0aGUgcHJhY3RpY2FsIGlzc3VlIHRoYXQgd2l0aCBhIHNoYXJlZCBzZWNyZXQga2V5LCBl bmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBhcmUgYm90aCAocmVsYXRpdmVseSkgZWFzeS4g QnV0IGlmIHlvdSB3YW50IGEgc29sdXRpb24gdGhhdCBpc27igJl0DQogdGhhdCAoYmVjYXVzZSB0 aGF0IGhhcyB2YXJpb3VzIGRyYXdiYWNrcykgdGhlbiBhdXRoZW50aWNhdGlvbiBpcyBtb3JlIG1h bmFnZWFibGUgdGhhbiBlbmNyeXB0aW9uLiBGb3IgZXhhbXBsZSBkcmFmdC1pZXRmLW1hbmV0LWli cyBoYXMgYSBzY2hlbWUgKG5vdCBvZiBjb3Vyc2UgdGhlIG9ubHkgcG9zc2libGUgb25lKSBmb3Ig YXV0aGVudGljYXRpb24uIFRoZSBlcXVpdmFsZW50IGZvciBlbmNyeXB0aW9uIHRoYXQgYWN0dWFs bHkgY29uY2VhbHMgbmV0d29yaw0KIHRvcG9sb2d5IGlzIGhhcmQgKGp1c3QgcmV2ZWFsaW5nIGFs bCBhZGRyZXNzZXMgZ2l2ZXMgYXdheSBxdWl0ZSBhIGxvdCkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oRm9sbG93aW5n IHRoZSBwYXRoIG9mIGEgc2lnbmFsbGluZyBtZXNzYWdlIGlzIHByb2JhYmx5IGVhc2llciBpbiBh IHJlYWN0aXZlIG5ldHdvcmssIGJlY2F1c2Ugb2YgdGhlIGRpcmVjdCByZWFjdGlvbi4pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hy aXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw MDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3 RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+ OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48 YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI Ti48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHls ZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGlt aXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5S ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5 LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+TG90dGUgU3RlZW5icmluazxicj4NCjxiPlNlbnQ6PC9iPiAxOSBGZWJydWFyeSAy MDE2IDE1OjA2PGJyPg0KPGI+VG86PC9iPiBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbbWFuZXRdIEFPRFZ2MjogU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdXBkYXRlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0 aW9uLDxicj4NCmVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50 ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgPGJyPg0KbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZv bGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzPGJy Pg0KZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdl cy48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCjxicj4NCioqKiBXQVJOSU5HICoqKjxicj4NCkVYVEVSTkFMIEVNQUlMIC0t IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLjxi cj4NCjxicj4NCjxicj4NCkhpIGFsbCw8YnI+DQppbiB0aGUgaW50ZXJlc3Qgb2YgdHJhbnNwYXJl bmN5LCB3ZSAodGhlIEFPRFZ2MiBhdXRob3IgdGVhbSkgd2FudCB0byBzZW5kIG91dCBtb3JlIHVw ZGF0ZXMgb24gd2hhdCB3ZSd2ZSBiZWVuIGRvaW5nLCBhbmQgdGhpcyBpcyB0aGUgZmlyc3Qgb2Yg dGhlc2UgZS1tYWlscy4gV2UndmUgcmVzdHJ1Y3R1cmVkIChhbmQgc29tZXRpbWVzIHJld3JpdHRl bikgb3VyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGEgYml0IGFuZCBhZGRlZCBhIHN1YnNlY3Rp b24NCiBhYm91dCB0aGUgVHJ1c3QgTW9kZWwsIGFuZCB3ZSdkIGxvdmUgdG8gaGVhciB5b3VyIG9w aW5pb25zIG9uIHRob3NlIGNoYW5nZXMuIFlvdSBjYW4gZmluZCB0aGUgcmVzdWx0IGFuZCBhIGRp ZmYgdG8gdGhlIGN1cnJlbnQgY29uc2lkZXJhdGlvbnMgaW4gdGhlIGF0dGFjaG1lbnRzLiAodGhl IGZvcm1hdHRpbmcgd2FzIGRvbmUgbWFudWFsbHksIHNvIGl0IG1pZ2h0IGJlIGEgYml0IHdvbmt5 KTxicj4NCjxicj4NClNvbWUgbm90ZXM6PGJyPg0KKiBUaGlzIGlzIGFsbCB3b3JrIGluIHByb2dy ZXNzLCBzbyBwbGVhc2UgcG9rZSBob2xlcyBpbnRvIGl0IHdoZXJlIHlvdSBjYW4hPGJyPg0KKiBX aGlsZSAoYWZhaWspIHRoZSBBdmFpbGFiaWxpdHkvQ29uZmlkZW50aWFsaXR5L0ludGVncml0eSBt b2RlbCBtYXkgYmUgY29uc2lkZXJlZCBhIGJpdCBkYXRlZCwgSSB0aG91Z2h0IGl0IG1pZ2h0IGJl IGEgZ29vZCBzdGFydGluZyBwb2ludC48YnI+DQoqIEkgd2FzIHdvbmRlcmluZyBpZiDigJxFbmNy eXB0aW9uIHdpbGwgbm90IG9ubHkgcHJvdGVjdCBhZ2FpbnN0IHVuYXV0aG9yaXplZCBkZXZpY2Vz IG9idGFpbmluZzxicj4NCiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBhYm91dCBuZXR3b3JrIHRv cG9sb2d54oCdIGlzbid0IGEgdGFkIHRvbyBzaG9ydCBhbmQgYm9sZOKAkyBtYXliZSB3ZSBjb3Vs ZCBhZGQgYSBjbGFyaWZpY2F0aW9uIGFsb25nIHRoZSBsaW5lcyBvZjo8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsgRW5jcnlwdGlvbiB3aWxsIG5vdCBvbmx5IG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQg Zm9yIHVuYXV0aG9yaXplZCBkZXZpY2VzIHRvIG9idGFpbjxicj4NCiZuYnNwOyZuYnNwOyBpbmZv cm1hdGlvbiBhYm91dCBuZXR3b3JrIHRvcG9sb2d5IGJ1dCB3aWxsIGFsc28gZW5zdXJlIHRoYXQg b25seSB0cnVzdGVkPGJyPg0KJm5ic3A7Jm5ic3A7IHJvdXRlcnMgcGFydGljaXBhdGUgaW4gcm91 dGluZyBvcGVyYXRpb25zOiBXaGVuIG1lc3NhZ2VzIGFyZSBlbmNyeXB0ZWQsPGJyPg0KJm5ic3A7 Jm5ic3A7IGEgbWFsaWNpb3VzIG9ic2VydmVyIHdvdWxkIGhhdmUgdG8gbW9uaXRvciB0aGUgZW50 aXJlIG5ldHdvcmsgdG8gdW5kZXJzdGFuZDxicj4NCiZuYnNwOyZuYnNwOyBpdHMgdG9wb2xvZ3kg YW5kIHRyYWZmaWMgZmxvdy4gQW5kIGV2ZW4gdGhlbiwgZHVlIHRvIHRoZSBob3AgYnkgaG9wPGJy Pg0KJm5ic3A7Jm5ic3A7IG5hdHVyZSBvZiB0aGUgcHJvdG9jb2wgYW5kIHRoZSBmYWN0IHRoYXQg bWVzc2FnZXMgYXJlIHJlZ2VuZXJhdGVkIHJhdGhlciA8YnI+DQombmJzcDsmbmJzcDsgdGhhbiBm b3J3YXJkZWQgKHJlc3VsdGluZyBpbiBhIGRpZmZlcmVudCBwYXlsb2FkIGV2ZXJ5IHRpbWUpLDxi cj4NCiZuYnNwOyZuYnNwOyBmb2xsb3dpbmcgdGhlIHBhdGggb2YgYSBtZXNzYWdlIHdvdWxkIGJl IGhhcmQgaWYgaXRzIHRyYW5zbWlzc2lvbiBpcyBub3Q8YnI+DQombmJzcDsmbmJzcDsgdGhlIG9u bHkgZW5jcnlwdGVkIHRyYWZmaWMgcHJvZHVjZWQgYnkgdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0K UmVnYXJkcyw8YnI+DQpMb3R0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRm Lm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBh bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ug bm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLjxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8BFFFB72GLKXM0002VGREEN_-- From nobody Fri Feb 19 13:36:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37661ACD85 for ; Fri, 19 Feb 2016 13:36:08 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHow3mBGYRwL for ; Fri, 19 Feb 2016 13:36:07 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0D81A1B86 for ; Fri, 19 Feb 2016 13:36:07 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id j125so21294589oih.0 for ; Fri, 19 Feb 2016 13:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IyEIxi45A4NsmM0pdBrNHlyIxBmdTAHb6hmwd4NV77w=; b=UY+f7iPONG6kEavg+BRtiq0YJd6GIJ4n5PAitd4EeuOafmZ3MLfHLEISm0sk9JTAQO QP3SLqgiSdwBivVvMGq0PjlvJ6pxfPicgQ+sBB0gWoYtqJKSbWZbjcDQgM89mluitYJV TtxCfZGlxMJv2YYNjv+Q96AuRRVkjlMDgkenH0vE8mTVcVZAaufF5OMp5X2d/KZE3+VY R/5kwnv9+w5XmbhnlvsssJD8DAlW3B6JtkaL+8AvAr2x7o/iXBIBQdy1++TWUH2wl/fu pWYufZ7USliM7By7/jSGE8kdgItcmjcJk4zjZvkv0iAounfJk9nGxxevtbFjd8pHp4C+ MiHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IyEIxi45A4NsmM0pdBrNHlyIxBmdTAHb6hmwd4NV77w=; b=hFldF5HeQD6LtEzcUzDdh7+o4W/ohiFEyzVVXjbTgbQBe1xVihmWAo9EUDe8xq7zAm J9iU/J7A/NgQUO7feZWHZIB5bwHL7GpNf/EEDtrCW8JbK1JHczR9nwWqoEj/xCel3hhw bkJDuXqVNWHmrdZW3VBXDsql8HS07uB2RoH4+hyc27XCOIEaS6QXs3vPxD5JkueGdDuN MTeFz+qiTWX1s7gPgkWHMyyyBF/9YkK+QYceLua5nXMpN1H/Pw/7gxKT6ONtjl59SY6A 402+6bw6t3R8APFblJT9B2sLixBbWnFufwmHrqjd1tahPuGdsVT+i2lKTdZw+Oesr4f2 X0Uw== X-Gm-Message-State: AG10YOSgV/o/J0+9CiU2QTokUsrMHSOOxbdmBco1+88G+9B4kM3Id0emJl1mN9jg9fO1aIxVN2+FHefVrfjwlw== MIME-Version: 1.0 X-Received: by 10.202.193.10 with SMTP id r10mr13354170oif.126.1455917766703; Fri, 19 Feb 2016 13:36:06 -0800 (PST) Received: by 10.76.45.102 with HTTP; Fri, 19 Feb 2016 13:36:06 -0800 (PST) Date: Fri, 19 Feb 2016 16:36:06 -0500 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a113dc36e4e84cd052c264570 Archived-At: Subject: [manet] News X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 21:36:09 -0000 --001a113dc36e4e84cd052c264570 Content-Type: text/plain; charset=UTF-8 The working group chairs (Stan and Justin) and the AD (Alvaro) just concluded a conference call. There are some significant developments which were decided during the talk: 1. There will be NO MANET meeting in Buenos Aries. Informal meetings, as always within the IETF would continue as normal. The reason for not having a meeting, apparent lack of progress on DLEP and AODVv2. 2. A new version of DLEP was published last night and will be last called shortly so start your reading/reviews now. 3. AODVv2: A new version of AODVv2 has been released, but hasn't had much official on-list feedback regarding the changes and or remaining issues. I've tasked myself to doing a thorough review, to get a better understanding of were things stand (with regard to appropriateness of a last call.) If a last call is not reasonable within a very short timeframe (within 3 weeks) with rough consensus of the working group, it will be abandoned. 3b. I've asked the authors to be more active on the list so that the progress and effort they have been making is apparent to everyone. I believe they have taken my suggestion to heart. We as a working group also have a responsibility to be constructive in our feedback. 4. A recharter will happen before the next MANET meeting but that discussion will be postponed until both DLEP and AODVv2 have been dealt with. Justin Dean --001a113dc36e4e84cd052c264570 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The working group chairs (= Stan and Justin) and the AD (Alvaro) just concluded a conference call.=C2= =A0 There are some significant developments which were decided during the t= alk:

1.=C2=A0 There will be NO MANET meeting in Buenos Aries.=C2=A0 = Informal meetings, as always within the IETF would continue as normal.=C2= =A0 The reason for not having a meeting, apparent lack of progress on DLEP = and AODVv2.

2.=C2=A0 A new versi= on of DLEP was published last night and will be last called shortly so star= t your reading/reviews now.=C2=A0

3.=C2=A0 AO= DVv2: A new version of AODVv2 has been released, but hasn't had much of= ficial on-list feedback regarding the changes and or remaining issues.=C2= =A0 I've tasked myself to doing a thorough review, to get a better unde= rstanding of were things stand (with=C2=A0regard=C2=A0to appropriateness of= a last call.) =C2=A0If a last call is not reasonable within a very short t= imeframe (within 3 weeks) with rough consensus of the working group, it wil= l be abandoned.
=C2=A0 3b= . I've asked the authors to be more active on the list so that the prog= ress and effort they have been making is apparent to everyone.=C2=A0 I beli= eve they have taken my suggestion to heart. We as a working group also have= a responsibility to be constructive in our feedback. =C2=A0

=
4.=C2=A0 A recharter will happe= n before the next MANET meeting but that discussion will be postponed until= both DLEP and AODVv2 have been dealt with.

Justin Dean
=
--001a113dc36e4e84cd052c264570-- From nobody Sat Feb 20 08:41:22 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376881A0155 for ; Sat, 20 Feb 2016 08:41:22 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdY8yqFKl6t0 for ; Sat, 20 Feb 2016 08:41:20 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE601A007A for ; Sat, 20 Feb 2016 08:41:20 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so99063023vkh.2 for ; Sat, 20 Feb 2016 08:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HtGVm9BzoYpGwk0IwLyOVd/75xOVwBHIscB5sxqc+mw=; b=ju8lT/XmtlXwZYYXi1JDJ5OfYYTp6hqov0jcop6/7sBpCuGtfanEhNvkAeOV5JzAH3 2vzNFHF5HFMoopwxHWi+aM/cFRdNTIofwQ2Qrm8lr1ozdy59sCLAIEH8mTZKlXZCY3N5 bsZasmMEZwNMmDTDp3pYDwNV2RMQfCDvicyWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HtGVm9BzoYpGwk0IwLyOVd/75xOVwBHIscB5sxqc+mw=; b=h10rQOVDLekWFrT3BNaO4Pc3NJX3SNDGDA5qdo8F7inARwesn2jQAEo8yoMTzj+cER pFyPz8XbvAS7XrD2eLyiI2D/5i28W5iEQMhEDjHGc3Qwt7Ixjt4EMdGDrQIEgBwdOOfb zMQ2i9vQis4BFuHBNV9YqrHgIYw2B6Syds5/UROhsst797Z/BzBtm4XTTva6adcb6cb+ UUcz4R/wLJcdYdcfr6GM/cBDziANglFeW0lRpJfTkvQO0jSO9YpJMsxYSTB8NLe0Aw/9 NY0d3mVM7uW0KC50uN7ynMoN9N39a6jKopXWfNALNWjoiqWWYkJZxgbfu5BNoLWcaI/w yjSg== X-Gm-Message-State: AG10YOQovJGZOe9Hz3C3/+39NEreuIDgG+iRP+tI2E/Z5k6A2XfCthONshhsqLSwG1YQgfxP3sCoZgMtYaVwaA== MIME-Version: 1.0 X-Received: by 10.31.58.193 with SMTP id h184mr16233154vka.111.1455986478907; Sat, 20 Feb 2016 08:41:18 -0800 (PST) Received: by 10.31.97.65 with HTTP; Sat, 20 Feb 2016 08:41:18 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 08:41:18 -0800 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AODVv2: Security considerations update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 16:41:22 -0000 Hi Lotte, I agree with what Chris said. Can you clarify what you mean in your email by: "[...] (afaik) the Availability/Confidentiality/Integrity model may be considered a bit dated [...]"? I have a few concerns with the proposed security considerations section: - BCP72 specifies: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled. " =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I don't think all of the above MUSTs are addressed in the proposed text (see also below). - I think the chain-of-trust model that doesn't allow end-to-end integrity protection is problematic in an entirely distributed and untrusted network environment. It's a bit like saying that you trust that an email sent to someone else is integrity protected because the step-wise SMTP between various mail servers along the path uses TLS. This brings me to the deeper issue of why messages are regenerated instead of forwarded. I have not understood why this is necessary in the first place (and I argued this in an email to the list at https://www.ietf.org/mail-archive/web/manet/current/msg18081.html) - The text in section 13.3.1 is hard to interpret as implementer, since it mixes a security evaluation with the actual specifications of how to protect the messages. I think it would be better to have separate sections for these two parts. Also, as a stylistic recommendation, I always had a hard time reading the continuous text as opposed to bullet points as we applied in OLSRv2. - I have some doubts that the Security ADs will agree with the terms "recommendations" in the title of the section together with a lot of SHOULDs and MAYs in the text, which seems to imply that usage of the integrity protection is not mandatory. When specifying OLSRv2, we were clearly told that we require a "MUST-implement/SHOULD use until you have something more better". - The Sec ADs required us for OLSRv2 to argue (in the spec) why we don't need to specify automatic key management as per BCP107. I don't see a similar section in AODVv2. Have you confirmed with the Sec ADs that their requirements have been relaxed? - The biggest issue I have with the proposed security consideration text is that there is no detailed specification of how to sign and validate messages, similar to what we were required to do by the Sec ADs in RFC7183. I doubt that two AODVv2 implementations by different programmers would be interoperable just using the current text. You mention the functions specified in RFC7182; but really these are just the containers for the actual information. RFC7182 does not mandate how to use them (such as we do in RFC7183). Best regards Ulrich On Fri, Feb 19, 2016 at 7:52 AM, Dearlove, Christopher (UK) wrote: > I would say that in the interests of transparency, a lot more should appe= ar > on list. Of course there=E2=80=99s no need - until later stages - to disc= uss every > editorial nit on list, but basic decisions should have been discussed her= e > before now, and responses to comments received (I=E2=80=99ve never had re= sponses to > all my comments). > > > > On this posting, it=E2=80=99s not exactly true that > > > > Encryption will not only make it more difficult for unauthorized devic= es > to obtain > information about network topology but will also ensure that only trus= ted > routers participate in routing operations: > > > > What ensure the latter is not encryption, but authentication. It is true > that one should generally not use encryption without authentication, and > there are some algorithms that do both together. Nevertheless I think it= =E2=80=99s > both useful and important to assign the right properties to each. > > > > There=E2=80=99s then the practical issue that with a shared secret key, e= ncryption > and authentication are both (relatively) easy. But if you want a solution > that isn=E2=80=99t that (because that has various drawbacks) then authent= ication is > more manageable than encryption. For example draft-ietf-manet-ibs has a > scheme (not of course the only possible one) for authentication. The > equivalent for encryption that actually conceals network topology is hard > (just revealing all addresses gives away quite a lot). > > > > (Following the path of a signalling message is probably easier in a react= ive > network, because of the direct reaction.) > > > > -- > > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > _________________________________________________________________________= _ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, > Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte Steenbrink > Sent: 19 February 2016 15:06 > To: manet@ietf.org > Subject: [manet] AODVv2: Security considerations update > > > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Consider carefully whether you should click on any > links, open any attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > > Hi all, > in the interest of transparency, we (the AODVv2 author team) want to send > out more updates on what we've been doing, and this is the first of these > e-mails. We've restructured (and sometimes rewritten) our security > considerations a bit and added a subsection about the Trust Model, and we= 'd > love to hear your opinions on those changes. You can find the result and = a > diff to the current considerations in the attachments. (the formatting wa= s > done manually, so it might be a bit wonky) > > Some notes: > * This is all work in progress, so please poke holes into it where you ca= n! > * While (afaik) the Availability/Confidentiality/Integrity model may be > considered a bit dated, I thought it might be a good starting point. > * I was wondering if =E2=80=9CEncryption will not only protect against un= authorized > devices obtaining > information about network topology=E2=80=9D isn't a tad too short and = bold=E2=80=93 maybe > we could add a clarification along the lines of: > > Encryption will not only make it more difficult for unauthorized devic= es > to obtain > information about network topology but will also ensure that only trus= ted > routers participate in routing operations: When messages are encrypted= , > a malicious observer would have to monitor the entire network to > understand > its topology and traffic flow. And even then, due to the hop by hop > nature of the protocol and the fact that messages are regenerated rath= er > than forwarded (resulting in a different payload every time), > following the path of a message would be hard if its transmission is n= ot > the only encrypted traffic produced by the network. > > Regards, > Lotte > > _______________________________________________ > 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. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Sat Feb 20 10:52:40 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF77B1ACEAD for ; Sat, 20 Feb 2016 10:52:38 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPo_ONhfq5cA for ; Sat, 20 Feb 2016 10:52:36 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6145C1ACEA9 for ; Sat, 20 Feb 2016 10:52:36 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id y89so85508861qge.2 for ; Sat, 20 Feb 2016 10:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/qptivpZ7PNIRIZyM5szxKdr7mqljtsea6MN519GOc=; b=bCsGArqXfRuafdNoCk2EVUofzZsVz19vpWYloHvgUp2ihwIQEQg9ZrB00Ke8LQ2ilr nPwqsWbWKuj2iU2yJHOi7/7jEyCtrX192nzQH7WmUHbJp2+F2Jtp7lcxenxoU1tFlQ3k xp+HLiP2zO5Il5/0EN2BdInQkr/v1dUxBWrnRbRhb2XAafeY65F73rgRkGrpzOj2/sIC xWKIm8kq9XqH0T9vlKuqaUP9sQE/cc/cVEl7OHBi9yRuR2hvZ2xZXI+eZ/0JPMIH7yfk LRY1BRFV1Meze285FvgDb3T18N27Q+a+fnPNh0GMDvlB0mY7m+1ovcYCe2KQ7eSKTKw+ T22w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J/qptivpZ7PNIRIZyM5szxKdr7mqljtsea6MN519GOc=; b=l6So0lrrjutXBw24aVI95abVYQQ9Lo43wZwDygpUT3efQ3cKYRLAYP9N8ZxDSMy1NC jje03HlNKZEUYWhGnyi64p+Z2+0DZATU7/XlWU2yi03GL4HYx7wilnZeQ2t/MqMqhPwo ELmlkxZxqlPAkezNKsB6tun5ul3IN4MQETo4T2VEuFcv9D7Nl6AFB3/6uJA17awGie3D 0GqGlj18DJpKFCI7gRY00NTNWVjmVxcyizedPmuSNIbgdH1O1JfL2gqE2GJKbnzM8Fp8 9XmCoG001lCcM7X20NSJpBn6TnGPieJecqewoQnQnX0867KBjhKn6PW4YqibllS8xrl8 lS0A== X-Gm-Message-State: AG10YOTzZep/Ym1y7TrNy4RM6Y381rC+QBWQXSGuW1jpr01OsMwkbcb+tqtzDDk7OVnHVdlGEiIlrBC9kscDpw== MIME-Version: 1.0 X-Received: by 10.141.7.9 with SMTP id j9mr25835269qhd.71.1455994355604; Sat, 20 Feb 2016 10:52:35 -0800 (PST) Received: by 10.140.99.86 with HTTP; Sat, 20 Feb 2016 10:52:35 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 20:52:35 +0200 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: multipart/alternative; boundary=001a1137452a5c6330052c381a8e Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] News X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 18:52:39 -0000 --001a1137452a5c6330052c381a8e Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 11:36 PM, Justin Dean wrote: > The working group chairs (Stan and Justin) and the AD (Alvaro) just > concluded a conference call. There are some significant developments which > were decided during the talk: > > 1. There will be NO MANET meeting in Buenos Aries. Informal meetings, as > always within the IETF would continue as normal. The reason for not having > a meeting, apparent lack of progress on DLEP and AODVv2. > I am sorry to add that I think the no progress is because the WG chairs are busy or not active on the list. For examples when I go to other WGs I see that the Chair is always moving the ideas and following up with drafts/authors/responses/issues per week/day. I am sorry to see that this WG-list is not having much push from the chair ( or even the AD). I think solving the no progress will need another decision, I suggest that the WG chairs should get an addition new chair that follows up only with those both drafts. > > 2. A new version of DLEP was published last night and will be last called > shortly so start your reading/reviews now. > > 3. AODVv2: A new version of AODVv2 has been released, but hasn't had much > official on-list feedback regarding the changes and or remaining issues. > I've tasked myself to doing a thorough review, to get a better > understanding of were things stand (with regard to appropriateness of a > last call.) If a last call is not reasonable within a very short timeframe > (within 3 weeks) with rough consensus of the working group, it will be > abandoned. > I don't agree until management defines the problem/issue, also your decision is not understood is it based on procedure or on other known-reason. Please respond/help. I think the problem is a management problem and hope that IETF looks into such problem so that it does not appear again. > 3b. I've asked the authors to be more active on the list so that the > progress and effort they have been making is apparent to everyone. I > believe they have taken my suggestion to heart. We as a working group also > have a responsibility to be constructive in our feedback. > I agree. > > 4. A recharter will happen before the next MANET meeting but that > discussion will be postponed until both DLEP and AODVv2 have been dealt > with. > I agree that issuing many new drafts can slow progress. I asked (before many months) the WG that we need to focus on these two drafts, before issuing new wg drafts or other issues. Yes I think if we just focus on these two we will have alot of work and we can finish quickly, then we get progress for WG. > > > Justin Dean > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1137452a5c6330052c381a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 11:36 PM, Justin Dean <bebemas= ter@gmail.com> wrote:
The working group chairs (Stan and Justin) an= d the AD (Alvaro) just concluded a conference call.=C2=A0 There are some si= gnificant developments which were decided during the talk:

1.=C2=A0 = There will be NO MANET meeting in Buenos Aries.=C2=A0 Informal meetings, as= always within the IETF would continue as normal.=C2=A0 The reason for not = having a meeting, apparent lack of progress on DLEP and AODVv2.

I am sorry to add that I think the no = progress is because the WG chairs are busy or not active on the list. For e= xamples when I go to other WGs I see that the Chair is always moving the id= eas and following=C2=A0up with drafts/authors/responses/issues per week/day= .=C2=A0 I am sorry to see that this WG-list is not having much push from th= e chair ( or even the AD). I think solving the no progress will need anothe= r decision, I suggest that the WG chairs should get an addition new chair t= hat follows up only=C2=A0with=C2=A0those both drafts.
=C2=A0

<= span style=3D"font-size:12.8px">2.=C2=A0 A new version of DLEP was publishe= d last night and will be last called shortly so start your reading/reviews = now.=C2=A0

3.=C2=A0 AODVv2: A new version of = AODVv2 has been released, but hasn't had much official on-list feedback= regarding the changes and or remaining issues.=C2=A0 I've tasked mysel= f to doing a thorough review, to get a better understanding of were things = stand (with=C2=A0regard=C2=A0to appropriateness of a last call.) =C2=A0If a= last call is not reasonable within a very short timeframe (within 3 weeks)= with rough consensus of the working group, it will be abandoned.

I don't agree until=C2=A0mana= gement defines=C2=A0the problem/issue, also your decision is not understood= is it based on procedure or on other known-reason. Please respond/help. I = think the problem is a management problem and hope that IETF looks into suc= h problem so that it does not appear again.
=C2=A0
=C2=A0 3b. I= 've asked the authors to be more active on the list so that the progres= s and effort they have been making is apparent to everyone.=C2=A0 I believe= they have taken my suggestion to heart. We as a working group also have a = responsibility to be constructive in our feedback. =C2=A0
<= /div>

I agree.=C2=A0
=

4.=C2=A0 A recharter will happen before = the next MANET meeting but that discussion will be postponed until both DLE= P and AODVv2 have been dealt with.

=
I agree that issuing many new drafts can slow progress. I=C2=A0a= sked (before many months) the WG that we need to focus on these two drafts,= before issuing new wg drafts or other issues. Yes I think if we just focus= on these two we will have=C2=A0alot of work and we can finish quickly, the= n we get progress for WG.
=

Justin Dean

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


--001a1137452a5c6330052c381a8e-- From nobody Sat Feb 20 11:12:29 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030371ACDD7 for ; Sat, 20 Feb 2016 11:12:28 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4OwBo3uMmsy for ; Sat, 20 Feb 2016 11:12:26 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322331ACE8D for ; Sat, 20 Feb 2016 11:12:26 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id b35so85570576qge.0 for ; Sat, 20 Feb 2016 11:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PwEO9DWv3IahDwluIAbLrPFaMztnkZaYSRrW0rgY1wY=; b=WoQRwB3DnxdpFZ1BUYpKXnWAOJWjgnujSh3MkUxjoODwFMcAFSpEm5waUgtBQZEAQ6 zpO/7zFVYYfg0+CQz5+bXwsH+jKT4jy46YGIPWwMHaX9M1K/S6Wo8IXsX7ArwOlX7wrL Mgfy20N+bkcCXqyKuOmDpPpcWk0OeJ8nQxNlKWQXnjTVjn3abbvViW5zX/PoowanBWMV UM0LksMNQvcuJ3v+oED0cnsJ16ZIjc44bTriP6xsufe1oTlK8tshZQ3XkKYsfHqshESc VQFXXtbr7YawSnVq2F/nZ0kTQB3jpBd+szTQdxHS3aSeV0XgyR73uppe9affFDnnzB4E OuhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PwEO9DWv3IahDwluIAbLrPFaMztnkZaYSRrW0rgY1wY=; b=A7LxTsSL25fHQ3aImKVc4Qj6/61ibxy4HD0yjFsBAPVxdhTSIE9PGJnZsn2q77wTnz IgXKXXJvgcAdqZvbwrl0WsXWaytkYcli32Ai3jVC8QFr8TayRW3VrRahboEZgUbjPdL3 /PxuG2PVfh70HinSxtxE9/EvcOG8MqlXleDbsW/iXIoY3md6AbOC29U5dY4/f9M17fPX jz40mxANhiRTB8VsccMsDRO08PK/YeQQHdQ48j8bg2awVpok+Mr+a4E5JMExrc0A/kHD DpeBD4bWhd2hfZE4Y60PErqzazBLrBUp8oilY93D+XehgWREH3h3u3ii3UFFUcuN5WkM bUig== X-Gm-Message-State: AG10YORBc2xu/3gXCWowWFiftuf9f1bM3vGPyBq30MNOk8LvZPWjG9fxFemdwtn2dqe0WGGgV6DmkJ29ebf0wQ== MIME-Version: 1.0 X-Received: by 10.141.7.9 with SMTP id j9mr25930458qhd.71.1455995545443; Sat, 20 Feb 2016 11:12:25 -0800 (PST) Received: by 10.140.99.86 with HTTP; Sat, 20 Feb 2016 11:12:25 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 21:12:25 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1137452a47e4e5052c386158 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AODVv2: Security considerations update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 19:12:28 -0000 --001a1137452a47e4e5052c386158 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2016 at 5:52 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I would say that in the interests of transparency, a lot more should > appear on list. Of course there=E2=80=99s no need - until later stages - = to discuss > every editorial nit on list, but basic decisions should have been discuss= ed > here before now, and responses to comments received (I=E2=80=99ve never h= ad > responses to all my comments). > I agree. We need to get all comments together and responded to. For me it is easier to make feedback on list if the chair is active but if not, then I suggest we use the ticket-tracker to make it easy to the authors to track the issues. I see the tickets about 20 (I think some were submitted for chris and other participants). http://trac.tools.ietf.org/wg/manet/trac/query?status=3D!closed&component= =3Daodvv2 > > > > > > --001a1137452a47e4e5052c386158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 5:52 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

I would say that in = the interests of transparency, a lot more should appear on list. Of course = there=E2=80=99s no need - until later stages - to discuss every editorial nit on list, but basic decisions should have been discussed here before no= w, and responses to comments received (I=E2=80=99ve never had responses to = all my comments).


I= =C2=A0agree. We need to get all comments together and responded to. For me = it is easier to make feedback on list=C2=A0if the chair is active but if no= t, then=C2=A0I suggest we use the ticket-tracker to=C2=A0make it easy to th= e authors to track the issues.=C2=A0I see the tickets about 20 (I think som= e were submitted for chris and other participants).

http://trac.tools.ietf.org/wg/manet/trac/query?st= atus=3D!closed&component=3Daodvv2

=C2=A0=


=C2=A0=

=C2=A0=

--001a1137452a47e4e5052c386158-- From nobody Sat Feb 20 12:23:37 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8544E1AD049; Sat, 20 Feb 2016 12:23:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160220202336.23154.91298.idtracker@ietfa.amsl.com> Date: Sat, 20 Feb 2016 12:23:36 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6779bis-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 20:23:36 -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 of the IETF. Title : Definition of Managed Objects for the Neighborhood Discovery Protocol Authors : Ulrich Herberg Robert G. Cole Ian D Chakeres Thomas Heide Clausen Filename : draft-ietf-manet-rfc6779bis-04.txt Pages : 71 Date : 2016-02-20 Abstract: This document revises, extends, and replaces RFC 6779. It 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 parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6779bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 21 13:37:37 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571AE1ACE3C for ; Sun, 21 Feb 2016 13:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ7nXel6fPY8 for ; Sun, 21 Feb 2016 13:37:35 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3021ACE01 for ; Sun, 21 Feb 2016 13:37:34 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g62so146663447wme.1 for ; Sun, 21 Feb 2016 13:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=i/upwyc2xswdNjLjZ3YWZ9wdJbFP0aY1bJ6L2cThKn4=; b=rbyAnoPIkvVLwsN2KdOJXYDGLDIbOcHwjHD1o+KBQ38dyMtfoab8eMo55go8LSMvZ0 w26P2Yr6e2itPkNnAJ3/JNByjLuws4iXZ/OK1edywj2qa23+F8tTDCM8OkOliYmXzIot hb+9FdHz6zBHZwCi7djKR4uiYHl+C5Nud//yPhC1X50b9GXlFHcAvFFt/NWVDHhoeNIf r8LKRgOgkKBmb7aM1KXaIGu18YF2R086bDftPcQ+g++qTyMa5UIdu1whYeyElwNJEkVl /z1Bi+9Zci0KbHpsMUtJ+JtSOD2We5VzvMTHsum2vCf2UdEZ+yTfqDbAKvGNSDdM1r1A Dfgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=i/upwyc2xswdNjLjZ3YWZ9wdJbFP0aY1bJ6L2cThKn4=; b=gaSoxspSqYtCPXTGv46T+9H8e1ZyJmOIevL2y3lTNdEz11rJI5eoQtUv4Y0leAF0Rc YfKwNCFX7Mmvvpd1ldKFXOptDAmk+euzKaxLEr8f0h4Nbo3Jqar6IjEj/r5ZyG78hITh 4+LTXwFf/C3mOXdTOlSvjV2OGOmBHiaHCGoGNraQNaXHWI/a8sqC2wBuuM7knYH3aaX9 3Df6FhaOyMl4+XvMMQWpthG466VKTEfLT9rcvmvRnJw38DWgjRnUoetIpJZSG8CWWWxQ PVSkBQ6oQRbzbop91XFqxvRDExGYf0fQvluoqM1WmFY3FvolIbXdivER75vIA298w8D1 4NTg== X-Gm-Message-State: AG10YOSjVoTEwGpvLKz/SHH5pwFMSr8No2L61v6Dm07vk5Ki15QPSA2gYJsBCSnZ3dZCOtjiCJb/QACu9H2ryA== MIME-Version: 1.0 X-Received: by 10.28.98.84 with SMTP id w81mr8377297wmb.57.1456090653461; Sun, 21 Feb 2016 13:37:33 -0800 (PST) Sender: yi.jiazi@gmail.com Received: by 10.194.246.201 with HTTP; Sun, 21 Feb 2016 13:37:33 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 22:37:33 +0100 X-Google-Sender-Auth: H_J6MP1b2QBZvLNdP6gjLDHlhyI Message-ID: From: Jiazi YI To: Lotte Steenbrink Content-Type: multipart/alternative; boundary=001a1148e078291607052c4e8612 Archived-At: Cc: manet Subject: Re: [manet] AODVv2: Security considerations update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:37:37 -0000 --001a1148e078291607052c4e8612 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Regarding the trust model: 13.4 Trust Model > Since routing information is distributed to neighbours on a hop-by-hop > basis, > and route messages are regenerated at each router, AODVv2 assumes a > security > model of transitive trust. "information distributed on hop-by-hop basis" applies to almost all multi-hop networks. "route messages are regenerated at each router" is questionable and has been discussed in previous sessions. I couldn't remember that it was accepted by the WG. Especially, the reasons justifying this trust model seems to be more because of the limitation of a protocol design, rather than the requirements from real applications. > The sender of a message must be trusted in order > for receiving one-hop neighbours to store the routing information it > provides and regenerate the message to their own one-hop neighbours. Routes are installed based on information received from trusted > neighbours. > Therefore a chain of trust back to the originator of a message is > assumed > by any router using the routing information received. In ad hoc networks, it's hard to avoid having compromised routers, especially in adverse environments (which is an important application scenario of MANETs). For AODV, the RREQ/RREP messages are designed to be end-to-end. Especially, RREQ is to be disseminated to the whole networks. Using the transit trust model means, if there is a single compromised router, the whole network is compromised. Even worse, there is no way (like identity based signature) can be used as countermeasures because of the limitation of the trust model. best Jiazi On Fri, Feb 19, 2016 at 4:05 PM, Lotte Steenbrink < lotte.steenbrink@fu-berlin.de> wrote: > Hi all, > in the interest of transparency, we (the AODVv2 author team) want to send > out more updates on what we've been doing, and this is the first of these > e-mails. We've restructured (and sometimes rewritten) our security > considerations a bit and added a subsection about the Trust Model, and we= 'd > love to hear your opinions on those changes. You can find the result and = a > diff to the current considerations in the attachments. (the formatting wa= s > done manually, so it might be a bit wonky) > > Some notes: > * This is all work in progress, so please poke holes into it where you ca= n! > * While (afaik) the Availability/Confidentiality/Integrity model may be > considered a bit dated, I thought it might be a good starting point. > * I was wondering if =E2=80=9CEncryption will not only protect against > unauthorized devices obtaining > information about network topology=E2=80=9D isn't a tad too short and = bold=E2=80=93 > maybe we could add a clarification along the lines of: > > Encryption will not only make it more difficult for unauthorized > devices to obtain > information about network topology but will also ensure that only > trusted > routers participate in routing operations: When messages are encrypted= , > a malicious observer would have to monitor the entire network to > understand > its topology and traffic flow. And even then, due to the hop by hop > nature of the protocol and the fact that messages are regenerated rath= er > than forwarded (resulting in a different payload every time), > following the path of a message would be hard if its transmission is n= ot > the only encrypted traffic produced by the network. > > Regards, > Lotte > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1148e078291607052c4e8612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Regarding the trust model:

13.4 Trust Model
=C2=A0 =C2=A0Sinc= e routing information is distributed to neighbours on a hop-by-hop basis,=C2=A0 =C2=A0and route messages are regenerated at each router, AODVv2 as= sumes a security
=C2=A0 =C2=A0model of transitive trust.

"information distributed on hop-by-hop basis" a= pplies to almost all multi-hop networks.=C2=A0

&qu= ot;route messages are regenerated at each router" is questionable and = has been discussed in previous sessions. I couldn't remember that it wa= s accepted by the WG.=C2=A0

Especially, the reason= s justifying this trust model seems to be more because of the limitation of= a protocol design, rather than the requirements from real applications.=C2= =A0

=C2=A0
The sender of a m= essage must be trusted in order
=C2=A0 =C2=A0for receiving one-hop neigh= bours to store the routing information it
=C2=A0 =C2=A0provides and rege= nerate the message to their own one-hop neighbours.=C2=A0
=C2=A0 =C2=A0Routes are installed based on information received= from trusted neighbours.
=C2=A0 =C2=A0Therefore a chain of trust back t= o the originator of a message is assumed
=C2=A0 =C2=A0by any router usin= g the routing information received.


In ad hoc networks, it's hard to avoid having compromised route= rs, especially in adverse environments (which is an important application s= cenario of MANETs).

For AODV, the RREQ/RREP messag= es are designed to be end-to-end. Especially, RREQ is to be disseminated to= the whole networks. Using the transit trust model means, if there is a sin= gle compromised router, the whole network is compromised. Even worse, there= is no way (like identity based signature) can be used as countermeasures b= ecause of the limitation of the trust model.=C2=A0

best

Jiazi
=C2=A0=C2=A0
=

On Fr= i, Feb 19, 2016 at 4:05 PM, Lotte Steenbrink <lotte.steenbrin= k@fu-berlin.de> wrote:
Hi a= ll,
in the interest of transparency, we (the AODVv2 author team) want to send o= ut more updates on what we've been doing, and this is the first of thes= e e-mails. We've restructured (and sometimes rewritten) our security co= nsiderations a bit and added a subsection about the Trust Model, and we'= ;d love to hear your opinions on those changes. You can find the result and= a diff to the current considerations in the attachments. (the formatting w= as done manually, so it might be a bit wonky)

Some notes:
* This is all work in progress, so please poke holes into it where you can!=
* While (afaik) the Availability/Confidentiality/Integrity model may be con= sidered a bit dated, I thought it might be a good starting point.
* I was wondering if =E2=80=9CEncryption will not only protect against unau= thorized devices obtaining
=C2=A0 =C2=A0information about network topology=E2=80=9D isn't a tad to= o short and bold=E2=80=93 maybe we could add a clarification along the line= s of:

=C2=A0 =C2=A0Encryption will not only make it more difficult for unauthoriz= ed devices to obtain
=C2=A0 =C2=A0information about network topology but will also ensure that o= nly trusted
=C2=A0 =C2=A0routers participate in routing operations: When messages are e= ncrypted,
=C2=A0 =C2=A0a malicious observer would have to monitor the entire network = to understand
=C2=A0 =C2=A0its topology and traffic flow. And even then, due to the hop b= y hop
=C2=A0 =C2=A0nature of the protocol and the fact that messages are regenera= ted rather
=C2=A0 =C2=A0than forwarded (resulting in a different payload every time),<= br> =C2=A0 =C2=A0following the path of a message would be hard if its transmiss= ion is not
=C2=A0 =C2=A0the only encrypted traffic produced by the network.

Regards,
Lotte


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


--001a1148e078291607052c4e8612-- From nobody Thu Feb 25 01:29:58 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FB51A888B for ; Thu, 25 Feb 2016 01:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utOT01RIe-MY for ; Thu, 25 Feb 2016 01:29:53 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0151A8885 for ; Thu, 25 Feb 2016 01:29:53 -0800 (PST) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by outbox.sics.se (Postfix) with ESMTPS id 3D4AC179A for ; Thu, 25 Feb 2016 10:29:52 +0100 (CET) Received: from [130.229.185.144] (n185-p144.kthopen.kth.se [130.229.185.144]) by norm.sics.se (Postfix) with ESMTPSA id 29B29247 for ; Thu, 25 Feb 2016 10:29:52 +0100 (CET) To: manet@ietf.org From: Marco Tiloca Message-ID: <56CEC98E.6030000@sics.se> Date: Thu, 25 Feb 2016 10:29:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] SMARTCOMP 2016 | Call for WiP/Demo Papers - Deadline: March 7, 2016 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 09:29:56 -0000 [Apologies for possible multiple copies] ------------------------------------------------------------------------ Call for WORK-IN-PROGRESS papers and DEMOs SMARTCOMP 2016 Second IEEE International Conference on Smart Computing http://www.smart-comp.org/ May 18-20, 2016 St. Louis, Missouri, USA ******* WIP/DEMO PAPER SUBMISSION DEADLINE: March 7, 2016 ******* Conference Proceedings in IEEE Xplore ------------------------------------------------------------------------ The 2nd IEEE International Conference on Smart Computing (SMARTCOMP 2016) draws upon many application disciplines such as transportation, energy, environmental protection, resource management, healthcare, security, banking, entertainment, and social media. In addition to full-length technical papers, SMARTCOMP welcomes Work in Progress (WIP) papers and technical demonstrations(DEMOs)showing innovative and original research in the areas of smart computing. Submissions from both industry and academia are strongly encouraged. WIP papers are expected to report on early or ongoing research activities, while DEMO papers are expected to present innovative applications and tools. The WIP and DEMO sessions will provide a forum to discuss novel ideas and emerging results, presenting innovative applications and tools, and bring about novel research questions, approaches, and directions. TOPICS: Submissions should be targeted to one of the following major areas: - Smart Cyber-Physical Environments and Energy/Water/Agriculture/Transportation/Healthcare/Banking Infrastructure - Security, Privacy, and Economics in Smart Environments - Smart Computing Technologies - Future Smart Computing Paradigms - Smart Human Environments, Health, Entertainment, and Social Activities - Smart Energy Management and Analytics SUBMISSION GUIDELINES: WIP and Demo papers may be no more than 3 pages in length, including figures, tables, and references. WIP papers are expected to present early or ongoing research activities. Novel approaches and preliminary results are especially appreciated. Demo papers should explicitly state what will be demonstrated to the audience, and how the attendees will be able to interact, enjoy, and experiment. The submitted manuscripts will be reviewed by members of the SMARTCOMP 2016 Technical Program Committee. All the accepted papers will be presented as posters and included in the conference proceedings. At least one author of each accepted paper must register and attend the conference to present the work. The accepted papers will be published in the conference proceedings by IEEE, and will be included in the Digital Library. Authors are requested to submit original, unpublished manuscripts in standard IEEE proceedings format in PDF. All submissions must be typeset in double-column IEEE format using 10pt fonts on US letter paper, with all fonts embedded. Submitted papers must include the contact information of all the authors. Please make sure you use the latest version of the templates to prepare your submissions. Due to the short interval between the notification of acceptance and the camera-ready deadline, we strongly encourage authors to follow the camera-ready formatting guidelines as close as possible even for the initial abstract submission. The IEEE LaTeX and Microsoft Word templates for conferences can be found at IEEE Manuscript Templates for Conference Proceedings at http://www.ieee.org/conferences_events/conferences/publishing/templates.html Further information for authors may be found at the IEEE Computer Society Information for Authors for Conference Publishing Services: http://www.computer.org/web/cs-cps/authors Submissions must be made via EasyChair: https://easychair.org/conferences/?conf=smartcomp2016 When submitting, please select the appropriate Track for your paper (i.e., WIP or Demo). IMPORTANT DATES: Paper submissions: March 7, 2016 Notification of acceptance: March 30, 2016 Camera-ready copy due: April 15, 2016 Conference date: May 18-20, 2016 WIP/DEMO CO-CHAIRS: Hassan Ghasemzadeh (hassan@eecs.wsu.edu), Washington State University, USA Sejun Song (songsej@umkc.edu), University of Missouri-Kansas City, USA From nobody Thu Feb 25 06:47:12 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99581AD17F for ; Thu, 25 Feb 2016 06:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.373 X-Spam-Level: X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSBDbM_36fEc for ; Thu, 25 Feb 2016 06:47:06 -0800 (PST) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6661D1AD0CB for ; Thu, 25 Feb 2016 06:47:06 -0800 (PST) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id 1F389C0A48 for ; Thu, 25 Feb 2016 15:47:02 +0100 (CET) Date: Thu, 25 Feb 2016 16:16:01 +0100 From: Mattia Campana To: manet@ietf.org Message-ID: <56cf1ab1./JEZuCl/eGWLurPw%mattia.campana@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] Deadline extension: IoP-W 2016 The first IFIP Internet of People Workshop (co-located with Networking 2016) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: iopw2016-publicity@iit.cnr.it List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 14:47:10 -0000 -------------------------------------------------------------------------------- IFIP IoP-W 2016 - First IFIP Internet of People Workshop co-located with IFIP Networking 2016 20 May 2016, Vienna, Austria http://cnd.iit.cnr.it/iopw2016/ SUBMISSION DEADLINES EXTENDED ******** EXTENDED Abstract Submission Deadline: 3 March 2016 ******** ******** EXTENDED Paper Submission Deadline: 10 March 2016 ******** -------------------------------------------------------------------------------- ****** Paper publication in both ****** ****** IFIP DL http://dl.ifip.org/ ****** ****** IEEE Xplore http://ieeexplore.ieee.org/ ****** SCOPE AND OVERVIEW ---------------------------------------- The massive penetration of Internet connectivity and devices with networking and computing capabilities (such as "things" and personal users' devices) is pushing a tighter and tighter convergence between the cyber world - of Internet protocols, services and Apps - and the physical world, with continuous interactions and mutual impact between these two worlds. According to an "anti-Copernican" view, humans are put back at the centre of the "Internet universe", whenever they are in the loop of cyber-world services. Applications, middlewares, but even Internet services and network protocols are more and more designed incorporating Human Individual and Social Behavioural (HISB) models. This is particularly the case when users' personal devices are themselves the network, or provide services to each other such as in mobile self-organising networks, because devices become the "proxies" of their users in the cyber world. Interestingly, similar approaches are also explored in Internet technologies in developing scenarios, where users' participation is often exploited as another resource for networking services. This vision, that we call "the Internet of People" (IoP) generalises emerging concepts and technologies such as IoT, which put the emphasis on the communication between "machines", and adapt to the users' behaviour only as an afterthought. Designing IoP protocols, services and applications thus requires a profound inter-disciplinary approach, where "non-ICT disciplines" such as social sciences, cognitive sciences, economics, complex network sciences, impact the way Internet algorithms are conceived and defined. Note that other types of inter-disciplinary design patterns i.e., bio-inspired approaches where non-human natural behaviours are used as inspiration for network protocols and services, are out of scope. This workshop aims to stimulate research following this view, and aggregate an inter-disciplinary community of researchers around the concept of the Internet of People. Specifically, we seek papers presenting IoP approaches, addressing any layer of the canonical Internet stack or cross-layer combinations thereof, where the human behaviour is at the centre of the design. Also, we welcome submissions that analyse how the human behaviour is affected (and possibly modified) by the use of Internet systems, and how the latter can be improved or re-designed accordingly. The workshop will accept papers where quantitative evidence is available or quantitative approaches are applied. Therefore, purely methodological papers or qualitative analyses will be considered out of scope. Papers proposing novel, thought provoking ideas, possibly presenting preliminary results and analyses are also welcome. However, we do not call for position papers. Topics of interest include, but are not limited to, the following - Networking IoP protocols based on HISB models - Information-centric IoP protocols based on HISB models - IoP services, service-composition and middleware solutions based on HISB models - Online Social Network services based on HISB models - Analysis and modelling of human behaviours in massively diffused Internet services, such as Online Social Networks - Complex network approaches to IoP - IoP protocols and services in developing regions - Privacy, security and trust mechanisms for IoP based on HISB models - QoE aspects in IoP - Human-centric, inter-disciplinary IoP solutions for IoT scenarios - Crowdsourcing, crowdsensing, pervasive sensing in IoP - Test and experimental results with IoP solutions - Architecture, design and implementation of IoP protocols - Modelling, analysis and characterisation of IoP solutions For any additional information please visit the workshop website at http://cnd.iit.cnr.it/iopw2016/, or contact the workshop chairs at iopw2016 iit cnr it BEST PAPER AWARD ---------------- IoP-W 2016 will grant a Best Paper Award sponsored by IFIP TC6. PAPER FORMAT AND SUBMISSION INSTRUCTIONS ---------------------------------------- Papers should neither have been published elsewhere nor being currently under review by another conference or journal. Submitted papers must be no more than 6 pages (IEEE two-column format, 10pt). Papers will be reviewed single blind. Please follow the submission link at: https://easychair.org/conferences/?conf=ifipiopw2016 Detailed submission information is available at http://cnd.iit.cnr.it/iopw2016/submission.html IoP-W papers will be available in the IFIP Digital Library (http://dl.ifip.org/). IoP-W adopts the IFIP TC Open Access policy. The IFIP DL is Open Access. IFIP holds papers copyright, and releases it freely to authors for any use. Thanks to this model, papers will also be available in and indexed by IEEE Xplore, while copyright will still remain available to authors. At least one author of each accepted paper is required to register and present his/her work at the workshop. EDITORIAL FOLLOW-UPS ---------------------------------------- Extended versions of the selected workshop papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier), in a special section on Internet of People. IMPORTANT DATES ---------------------------------------- (EXTENDED) Abstract Registration: 3 March 2016 (EXTENDED) Submission Deadline: 10 March 2016 Authors Notification: 8 April 2016 Camera Ready Due: 22 April 2016 Workshop: 20 May 2016 WORKSHOP CO-CHAIRS ---------------------------------------- Isabelle Chrisment, TELECOM Nancy, Universite' de Lorraine, France Andrea Passarella, IIT-CNR, Italy Ana Pont-Sanjuan, Polytechnic University of Valencia, Spain PUBLICITY CO-CHAIRS ---------------------------------------- Mattia Campana, IIT-CNR, Italy Yang Chen, Fudan University, China PROGRAM COMMITTEE ---------------------------------------- Jussara M. Almeida, Universidade Federal de Minas Gerais, Brazil Valerio Arnaboldi, IIT-CNR, Italy Guido Caldarelli, IMT of Lucca, Italy Yang Chen, Fudan University, China Marco Conti, IIT-CNR, Italy Sajal K. Das, University of Missouri, USA Jordi Domingo-Pascual, Universitat Politecnica de Catalunya, Spain Falko Dressler, University of Paderborn, Germany Xiaoming Fu, University of Goettingen, Germany Sabrina Gaito, University of Milan, Italy Ahmed Helmy, University of Florida, USA Pan Hui, The Hong Kong University of Science and Technology, Hong Kong Tobias Hossfeld, University of Duisburg-Essen, Germany Adriana Iamnitchi, University of South Florida, USA Teemu Karkkainen, TUM, Germany Claudia-Lavinia Ignat, Inria, France Winfried Lamersdorf, University of Hamburg, Germany Yong Li, Tsinghua University, China William Liu, Auckland University of Technology (AUT), New Zealand Renato Lo Cigno, University of Trento, Italy Paul Lukowicz, DFKI, Germany Marco Mamei, University of Modena e Reggio Emilia, Italy Matteo Mordacchini, IIT-CNR, Italy Melek Onen, EURECOM, France Joerg Ott, TUM, Germany Dino Pedreschi, University of Pisa, Italy Dario Pompili, Rutgers University, USA Peter Reichl, University of Vienna, Austria George Roussos, University of London, UK Alessandra Sala, Bell Labs, Ireland Nishanth Sastry, Kings College London, UK Arjuna Sathiaseelan, University of Cambridge, UK Siraj Shaikh, University of Coventry, UK Valerie Shalin, Wright State University, USA Burkhard Stiller, University of Zurich, Switzerland Thorsten Strufe, University of Dresden, Germany Martin Varela, VTT, Finland Roger Whitaker, Cardiff University, UK From nobody Fri Feb 26 13:18:19 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21191B308B for ; Fri, 26 Feb 2016 13:18:17 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn4aFShQXyFU for ; Fri, 26 Feb 2016 13:18:15 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F51B1B307F for ; Fri, 26 Feb 2016 13:18:15 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id s6so39066144obg.3 for ; Fri, 26 Feb 2016 13:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=QpojJeEcExbDzK7UijBHOBnllTWNn7dJ8UEyeHKJT70=; b=yBDOJj3ez1Rx10baJSgLNSML+NxT6omhGp97RN0DDy9xsCy+LP5Iq51qbJRhmWDmCq t18oibqv4OUim/AmbMPj4ZCNtaEwxenKTDe/2A7v0tSu1ewavqroRJgaKR8yoGPtaRY6 sUa25Oa0NhdroQViT/jKjbh2Eny3SlvT6focDvetSFLrM09kipt1publyz/8ToLXq2pM fnCbWHqUZoX2hLhB4XsYb99+yCQ7ywYNGAunOjsZBKuubTpMz0wOsKl7IpgDWHY9wj8f 6f+WtliQeTLyBtf/DYe7YrBFj+qL9Q5E40lwW2LFz+6uCHabLIPoX7iHUPRlt4MWokBt zvEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=QpojJeEcExbDzK7UijBHOBnllTWNn7dJ8UEyeHKJT70=; b=g6vrXLCppakiW2UV9k00xMmAIgDUhi38eWLluWSfoXYyWycwUUBIXtqOaaO+4fQ42o l9CRJWMFvLHjHZ52A+E3Arizlymrye7iexawNghNcIBm3d8B6tX8dC/3SWrspm3uTV/o 62Vswlp68BMA8GBKgckB1FPUlUlDCojfrutHwtp4mO/R4dIhWRgc9sbStdKwKJ7dmZ+r 3UfNCq//V/gTCYWyVwy9Xnqgyk/sGpK3fqnAEjgatOWEF81P+IoRmezoZLb6zpwVRrfu VtA0oJWeDz6c2902HiGqMeAKEQEgyT4f8IlgFowq1VvD6x88jJufFnGGzMMjjXGIO+AI uKVQ== X-Gm-Message-State: AD7BkJJeHUkza0QjU1yTdwd33V6SPP2r6VN3RrfFc/RTKIRX3okg1ZlbMiZ0hFUwqlTP6auKsATSFiXhR5PQ0g== MIME-Version: 1.0 X-Received: by 10.60.59.37 with SMTP id w5mr2874472oeq.44.1456521494912; Fri, 26 Feb 2016 13:18:14 -0800 (PST) Received: by 10.76.45.102 with HTTP; Fri, 26 Feb 2016 13:18:14 -0800 (PST) Date: Fri, 26 Feb 2016 16:18:14 -0500 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0149d1864fe9ba052cb2d687 Archived-At: Subject: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:18:17 -0000 --089e0149d1864fe9ba052cb2d687 Content-Type: text/plain; charset=UTF-8 Last week I mentioned that DLEP was going to be last called soon. That time has come (again) and with no list objections (in the rough or otherwise). Since everyone has had plenty of time to review the document this last call will last 2 weeks. Both the core DLEP specification and the credit windowing extension draft are in last call. Justin Dean --089e0149d1864fe9ba052cb2d687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Last week I mentioned that DLEP was going to be last = called soon.=C2=A0 That time has come (again) and with no list objections (= in the rough or otherwise).=C2=A0 Since everyone has had plenty of time to = review the document this last call will last 2 weeks.=C2=A0 Both the core D= LEP specification and the credit windowing extension draft are in last call= .

Justin Dean
--089e0149d1864fe9ba052cb2d687-- From nobody Fri Feb 26 13:20:42 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4F21B308D for ; Fri, 26 Feb 2016 13:20:41 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UApX-gTRWnRK for ; Fri, 26 Feb 2016 13:20:38 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F051B3095 for ; Fri, 26 Feb 2016 13:20:35 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id j125so71296315oih.0 for ; Fri, 26 Feb 2016 13:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=6yrjCdLGj7cDizsLyZwmEDsb7J80fal8dKZIn5eKJag=; b=bCuBQN9dcyn4Ds7Bul9qw+ca1WPl1KEmWOvdSNWAmWCZ+UysfLZlFT8DZM9XX6yUxl 2r9hIVC24HU0R/VvAtFWqVooFw+NZeZHpuMqJR9ElIGBH4PlbozRxKkzsSWyNcFxGxBs u5aWrOg49dJNNjjdB2URBl8UCtPIsf7gN3NhJqp3RKvNNa4P+eTeDxj9+IKV8H8eebar GymPEu7m9wz+UEk87VmKenr7Xf37GkINY3ZU6yuvakLmTZ8Bu+zr6dt25+W5M5vUukI8 1tpgVoqq0uHBfvcGwZGIbmqf8bqZuT5DQidEvajJwMvxXgh0zFJOl0lzCC3W9BQigi9g ULqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=6yrjCdLGj7cDizsLyZwmEDsb7J80fal8dKZIn5eKJag=; b=UQPkXtQOxnavtKbTzM+Xm4xk7JA6ZPSGk/2+dIAS4BKq1IbrElocBKJw6SiRWSJrQt 3N8zJwPhOIAvIPQQLtXFL4fyWO6Cy354YZ57PeVcLGugeUFYEsL3dK6Mm+vuzOK0H611 o/0my0rsnD13htWVnhlmIeXWn+5CvoPYL6VJORknKhSZ4Vo5Be3guAVZqGdmSgV0n/0j J6xDGM+NAZ0mEmw7uX79TbcGxTOZofweBLhVAdk0lRlAE33hB6uOl3yMZZ3mvfG47rN6 DEm+Z7jigoHRdqJ5Yvh5XU7EMNAxCxEnd3DVB/5/VQlFRLD/P0H9/VFStUAhZUVteDkt Xw7w== X-Gm-Message-State: AD7BkJJfQ0ft/k43Mi4MoyWiKp3zMCk1S7BLiOj6oAhVM0WoH84SNRRBleDu200LdIpX46U56DaYrvTsVr+xEQ== MIME-Version: 1.0 X-Received: by 10.202.229.134 with SMTP id c128mr2779267oih.115.1456521634908; Fri, 26 Feb 2016 13:20:34 -0800 (PST) Received: by 10.76.45.102 with HTTP; Fri, 26 Feb 2016 13:20:34 -0800 (PST) Date: Fri, 26 Feb 2016 16:20:34 -0500 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a1141c1cca80f97052cb2deb7 Archived-At: Subject: [manet] AODVv2 status X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:20:41 -0000 --001a1141c1cca80f97052cb2deb7 Content-Type: text/plain; charset=UTF-8 I'm still in the middle of my thorough review. I'll post that review along with my recommendation to the working group regarding last call or removal as soon as possible. Justin Dea --001a1141c1cca80f97052cb2deb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm still in the middle of my thorough review.=C2= =A0 I'll post that review along with my recommendation to the working g= roup regarding last call or removal as soon as possible.

Justi= n Dea
--001a1141c1cca80f97052cb2deb7-- From nobody Mon Feb 29 02:12:41 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADCD1B2F68 for ; Mon, 29 Feb 2016 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw8pVDcFIAsS for ; Mon, 29 Feb 2016 02:12:37 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268511B2F69 for ; Mon, 29 Feb 2016 02:12:37 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,520,1449532800"; d="scan'208,217"; a="47612353" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 29 Feb 2016 10:12:35 +0000 X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208,217";a="108096636" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 29 Feb 2016 10:12:35 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.67]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 10:12:35 +0000 From: "Dearlove, Christopher (UK)" To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in Last call Thread-Index: AQHRcNs76FmCKa+Xo06YeoNdrdDiOp9C0Edg Date: Mon, 29 Feb 2016 10:12:34 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C017297GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 10:12:40 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C017297GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBnYXZlIGEgc3Vic3RhbnRpYWwgcmV2aWV3IG9mIGEgcmVjZW50IGRyYWZ0LCBidXQgSSB3b3Vs ZG7igJl0IHNheSBJ4oCZdmUgaGFkIHBsZW50eSBvZiB0aW1lIG9uIHRoZSBsYXRlc3QgKGFuZCBJ 4oCZbSBub3Qgc3VyZSBpZiBJ4oCZbSBvbmUgb3IgdHdvIHZlcnNpb25zIGJlaGluZCkuDQoNCklu IHBhcnRpY3VsYXIsIHRoZSDigJxoZXJl4oCZcyBhIG5ldyBkcmFmdCwgd2XigJl2ZSBjb25zaWRl cmVkIHlvdXIgY29tbWVudHPigJ0gaXMgbm90IHNhdGlzZmFjdG9yeS4gSeKAmWQgbGlrZSBub3Qg dG8gaGF2ZSB0byBkbyB0aGUgd29yayBvZiB3b3JraW5nIG91dCB3aGF0IGhhcyBhbmQgaGFzIG5v dCBiZWVuIGRvbmUsIGJvdGggZnJvbSBteSByZXZpZXcgYW5kIGluIHRoZSBkcmFmdCBnZW5lcmFs bHkuIFdpdGhvdXQgdGhhdCwgSSBkb27igJl0IHJlZ2FyZCB0d28gd2Vla3MgYXMgc3VmZmljaWVu dC4NCg0KVGhlIGNyZWRpdCB3aW5kb3dpbmcgZHJhZnQgSeKAmXZlIG5vdCBldmVuIGxvb2tlZCBh dC4gSGFzIGFueW9uZSBwb3N0ZWQgYW55IHJldmlldyBjb21tZW50cyBvbiBpdD8gSeKAmXZlIHNh aWQgYmVmb3JlIHRoYXQgSSB0aGluayBtYWtpbmcgRExFUCBkZXBlbmRlbnQgb24gdGhlIFNXIGRy YWZ0IGlzIGFuIGVycm9yLCBhbmQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGxldCBDVyBnbyB0aHJv dWdoIHNlcGFyYXRlbHkuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5j aXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y aWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3Jk IFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhO Lg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVu Z2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVz ZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNl bnQ6IDI2IEZlYnJ1YXJ5IDIwMTYgMjE6MTgNClRvOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDog W21hbmV0XSBETEVQIGluIExhc3QgY2FsbA0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5 b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBp cyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQu ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50 cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5H ICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz aWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkxhc3Qgd2VlayBJIG1lbnRpb25lZCB0aGF0IERMRVAg d2FzIGdvaW5nIHRvIGJlIGxhc3QgY2FsbGVkIHNvb24uICBUaGF0IHRpbWUgaGFzIGNvbWUgKGFn YWluKSBhbmQgd2l0aCBubyBsaXN0IG9iamVjdGlvbnMgKGluIHRoZSByb3VnaCBvciBvdGhlcndp c2UpLiAgU2luY2UgZXZlcnlvbmUgaGFzIGhhZCBwbGVudHkgb2YgdGltZSB0byByZXZpZXcgdGhl IGRvY3VtZW50IHRoaXMgbGFzdCBjYWxsIHdpbGwgbGFzdCAyIHdlZWtzLiAgQm90aCB0aGUgY29y ZSBETEVQIHNwZWNpZmljYXRpb24gYW5kIHRoZSBjcmVkaXQgd2luZG93aW5nIGV4dGVuc2lvbiBk cmFmdCBhcmUgaW4gbGFzdCBjYWxsLg0KSnVzdGluIERlYW4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApy ZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBu b3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C017297GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZ2F2ZSBhIHN1YnN0YW50aWFsIHJldmlldyBvZiBhIHJl Y2VudCBkcmFmdCwgYnV0IEkgd291bGRu4oCZdCBzYXkgSeKAmXZlIGhhZCBwbGVudHkgb2YgdGlt ZSBvbiB0aGUgbGF0ZXN0IChhbmQgSeKAmW0gbm90IHN1cmUgaWYgSeKAmW0gb25lIG9yIHR3byB2 ZXJzaW9ucyBiZWhpbmQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gcGFydGljdWxhciwgdGhlIOKAnGhlcmXigJlz IGEgbmV3IGRyYWZ0LCB3ZeKAmXZlIGNvbnNpZGVyZWQgeW91ciBjb21tZW50c+KAnSBpcyBub3Qg c2F0aXNmYWN0b3J5LiBJ4oCZZCBsaWtlIG5vdCB0byBoYXZlIHRvIGRvIHRoZSB3b3JrIG9mIHdv cmtpbmcgb3V0IHdoYXQgaGFzIGFuZA0KIGhhcyBub3QgYmVlbiBkb25lLCBib3RoIGZyb20gbXkg cmV2aWV3IGFuZCBpbiB0aGUgZHJhZnQgZ2VuZXJhbGx5LiBXaXRob3V0IHRoYXQsIEkgZG9u4oCZ dCByZWdhcmQgdHdvIHdlZWtzIGFzIHN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY3JlZGl0IHdp bmRvd2luZyBkcmFmdCBJ4oCZdmUgbm90IGV2ZW4gbG9va2VkIGF0LiBIYXMgYW55b25lIHBvc3Rl ZCBhbnkgcmV2aWV3IGNvbW1lbnRzIG9uIGl0PyBJ4oCZdmUgc2FpZCBiZWZvcmUgdGhhdCBJIHRo aW5rIG1ha2luZyBETEVQIGRlcGVuZGVudCBvbiB0aGUNCiBTVyBkcmFmdCBpcyBhbiBlcnJvciwg YW5kIGl0IHdvdWxkIGJlIGJldHRlciB0byBsZXQgQ1cgZ28gdGhyb3VnaCBzZXBhcmF0ZWx5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0 b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3 RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdE Ij5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAm bmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBo cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48 YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0i Y29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIERlYW48YnI+DQo8Yj5TZW50OjwvYj4gMjYgRmVi cnVhcnkgMjAxNiAyMToxODxicj4NCjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW21hbmV0XSBETEVQIGluIExhc3QgY2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWdu OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNo b3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwv c3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8 L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3Ug ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+ DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ KioqPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2Fn ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5MYXN0 IHdlZWsgSSBtZW50aW9uZWQgdGhhdCBETEVQIHdhcyBnb2luZyB0byBiZSBsYXN0IGNhbGxlZCBz b29uLiZuYnNwOyBUaGF0IHRpbWUgaGFzIGNvbWUgKGFnYWluKSBhbmQgd2l0aCBubyBsaXN0IG9i amVjdGlvbnMgKGluIHRoZSByb3VnaCBvciBvdGhlcndpc2UpLiZuYnNwOyBTaW5jZSBldmVyeW9u ZSBoYXMgaGFkIHBsZW50eSBvZiB0aW1lIHRvIHJldmlldyB0aGUgZG9jdW1lbnQNCiB0aGlzIGxh c3QgY2FsbCB3aWxsIGxhc3QgMiB3ZWVrcy4mbmJzcDsgQm90aCB0aGUgY29yZSBETEVQIHNwZWNp ZmljYXRpb24gYW5kIHRoZSBjcmVkaXQgd2luZG93aW5nIGV4dGVuc2lvbiBkcmFmdCBhcmUgaW4g bGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K dXN0aW4gRGVhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0 aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90 IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRp c3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C017297GLKXM0002VGREEN_-- From nobody Mon Feb 29 02:46:56 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EB21B2FE4 for ; Mon, 29 Feb 2016 02:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kohgv__lJdF5 for ; Mon, 29 Feb 2016 02:46:53 -0800 (PST) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF431B2FC3 for ; Mon, 29 Feb 2016 02:46:52 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,520,1449532800"; d="scan'208,217"; a="31645116" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 29 Feb 2016 10:46:51 +0000 X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208,217";a="108108115" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 29 Feb 2016 10:46:46 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.67]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 10:46:46 +0000 From: "Dearlove, Christopher (UK)" To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in Last call Thread-Index: AQHRcNs76FmCKa+Xo06YeoNdrdDiOp9C0EdggAAKUyA= Date: Mon, 29 Feb 2016 10:46:45 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0182C6GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 10:46:55 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0182C6GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va2luZyBhdCB3aGF0IEkgd3JvdGUsIEkgZmFpbGVkIHRvIG5vdGUgdGhhdCBJIHRoaW5rIERM RVAgaXMgaW4gcHJldHR5IGdvb2Qgc2hhcGUsIGFuZCB3aWxsIGJlIHJlYWR5IGZvciBXR0xDIHNv b24sIGJ1dCB0aGVyZSBoYXZlIGJlZW4gc29tZSByZWNlbnQgY2hhbmdlcywgYW5kIEnigJltIGp1 c3Qgc2F5aW5nIEnigJlkIGxpa2Ugc29tZSBtYXRlcmlhbCBvbiB0aG9zZSBjaGFuZ2VzLCBpbmNs dWRpbmcgcmVzcG9uc2VzIHRvIHJldmlld3MsIGZyb20gdGhlIGF1dGhvcnMgYW5kIHRoZW4gcGVy aGFwcyB0d28gd2Vla3MuIE9yIGEgYml0IG1vcmUgdGhhbiB0d28gd2Vla3MuDQoNCi0tDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpU OiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNClNlbnQ6IDI5IEZlYnJ1 YXJ5IDIwMTYgMTA6MTMNClRvOiBKdXN0aW4gRGVhbjsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbWFuZXRdIERMRVAgaW4gTGFzdCBjYWxsDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0 aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVy ZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVt YWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdB Uk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t IG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KSSBnYXZlIGEgc3Vic3RhbnRpYWwgcmV2aWV3 IG9mIGEgcmVjZW50IGRyYWZ0LCBidXQgSSB3b3VsZG7igJl0IHNheSBJ4oCZdmUgaGFkIHBsZW50 eSBvZiB0aW1lIG9uIHRoZSBsYXRlc3QgKGFuZCBJ4oCZbSBub3Qgc3VyZSBpZiBJ4oCZbSBvbmUg b3IgdHdvIHZlcnNpb25zIGJlaGluZCkuDQoNCkluIHBhcnRpY3VsYXIsIHRoZSDigJxoZXJl4oCZ cyBhIG5ldyBkcmFmdCwgd2XigJl2ZSBjb25zaWRlcmVkIHlvdXIgY29tbWVudHPigJ0gaXMgbm90 IHNhdGlzZmFjdG9yeS4gSeKAmWQgbGlrZSBub3QgdG8gaGF2ZSB0byBkbyB0aGUgd29yayBvZiB3 b3JraW5nIG91dCB3aGF0IGhhcyBhbmQgaGFzIG5vdCBiZWVuIGRvbmUsIGJvdGggZnJvbSBteSBy ZXZpZXcgYW5kIGluIHRoZSBkcmFmdCBnZW5lcmFsbHkuIFdpdGhvdXQgdGhhdCwgSSBkb27igJl0 IHJlZ2FyZCB0d28gd2Vla3MgYXMgc3VmZmljaWVudC4NCg0KVGhlIGNyZWRpdCB3aW5kb3dpbmcg ZHJhZnQgSeKAmXZlIG5vdCBldmVuIGxvb2tlZCBhdC4gSGFzIGFueW9uZSBwb3N0ZWQgYW55IHJl dmlldyBjb21tZW50cyBvbiBpdD8gSeKAmXZlIHNhaWQgYmVmb3JlIHRoYXQgSSB0aGluayBtYWtp bmcgRExFUCBkZXBlbmRlbnQgb24gdGhlIFNXIGRyYWZ0IGlzIGFuIGVycm9yLCBhbmQgaXQgd291 bGQgYmUgYmV0dGVyIHRvIGxldCBDVyBnbyB0aHJvdWdoIHNlcGFyYXRlbHkuDQoNCi0tDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpU OiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDI2IEZlYnJ1YXJ5IDIwMTYgMjE6MTgN ClRvOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFu ZXRdIERMRVAgaW4gTGFzdCBjYWxsDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hl dGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMg b3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBj YW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1 c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQu YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0Rl YWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioq DQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXphdGlvbi4NCg0KTGFzdCB3ZWVrIEkgbWVudGlvbmVkIHRoYXQgRExFUCB3YXMg Z29pbmcgdG8gYmUgbGFzdCBjYWxsZWQgc29vbi4gIFRoYXQgdGltZSBoYXMgY29tZSAoYWdhaW4p IGFuZCB3aXRoIG5vIGxpc3Qgb2JqZWN0aW9ucyAoaW4gdGhlIHJvdWdoIG9yIG90aGVyd2lzZSku ICBTaW5jZSBldmVyeW9uZSBoYXMgaGFkIHBsZW50eSBvZiB0aW1lIHRvIHJldmlldyB0aGUgZG9j dW1lbnQgdGhpcyBsYXN0IGNhbGwgd2lsbCBsYXN0IDIgd2Vla3MuICBCb3RoIHRoZSBjb3JlIERM RVAgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIGNyZWRpdCB3aW5kb3dpbmcgZXh0ZW5zaW9uIGRyYWZ0 IGFyZSBpbiBsYXN0IGNhbGwuDQpKdXN0aW4gRGVhbg0KDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpy ZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQg bm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0182C6GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5M b29raW5nIGF0IHdoYXQgSSB3cm90ZSwgSSBmYWlsZWQgdG8gbm90ZSB0aGF0IEkgdGhpbmsgRExF UCBpcyBpbiBwcmV0dHkgZ29vZCBzaGFwZSwgYW5kIHdpbGwgYmUgcmVhZHkgZm9yIFdHTEMgc29v biwgYnV0IHRoZXJlIGhhdmUgYmVlbiBzb21lIHJlY2VudCBjaGFuZ2VzLA0KIGFuZCBJ4oCZbSBq dXN0IHNheWluZyBJ4oCZZCBsaWtlIHNvbWUgbWF0ZXJpYWwgb24gdGhvc2UgY2hhbmdlcywgaW5j bHVkaW5nIHJlc3BvbnNlcyB0byByZXZpZXdzLCBmcm9tIHRoZSBhdXRob3JzIGFuZCB0aGVuIHBl cmhhcHMgdHdvIHdlZWtzLiBPciBhIGJpdCBtb3JlIHRoYW4gdHdvIHdlZWtzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9w aGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0Ui Pjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+ VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5i c3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJl Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8 YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0 ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy IDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+U2VudDo8L2I+IDI5IEZlYnJ1 YXJ5IDIwMTYgMTA6MTM8YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBEZWFuOyBtYW5ldEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBETEVQIGluIExhc3QgY2FsbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBw dDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3Nh Z2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20g YW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNv bnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBv cGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxz dHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwv c3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0K IGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJl PC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lv dXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBX aXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+ PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8L3NwYW4+PC9zdHJvbmc+ PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V0FSTklORw0KPC9zcGFu Pjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5F WFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy IG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgZ2F2ZSBhIHN1YnN0YW50aWFsIHJldmlldyBvZiBhIHJlY2VudCBk cmFmdCwgYnV0IEkgd291bGRu4oCZdCBzYXkgSeKAmXZlIGhhZCBwbGVudHkgb2YgdGltZSBvbiB0 aGUgbGF0ZXN0IChhbmQgSeKAmW0gbm90IHN1cmUgaWYgSeKAmW0gb25lIG9yIHR3byB2ZXJzaW9u cyBiZWhpbmQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gcGFydGljdWxhciwgdGhlIOKAnGhlcmXigJlzIGEgbmV3 IGRyYWZ0LCB3ZeKAmXZlIGNvbnNpZGVyZWQgeW91ciBjb21tZW50c+KAnSBpcyBub3Qgc2F0aXNm YWN0b3J5LiBJ4oCZZCBsaWtlIG5vdCB0byBoYXZlIHRvIGRvIHRoZSB3b3JrIG9mIHdvcmtpbmcg b3V0IHdoYXQgaGFzIGFuZA0KIGhhcyBub3QgYmVlbiBkb25lLCBib3RoIGZyb20gbXkgcmV2aWV3 IGFuZCBpbiB0aGUgZHJhZnQgZ2VuZXJhbGx5LiBXaXRob3V0IHRoYXQsIEkgZG9u4oCZdCByZWdh cmQgdHdvIHdlZWtzIGFzIHN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY3JlZGl0IHdpbmRvd2lu ZyBkcmFmdCBJ4oCZdmUgbm90IGV2ZW4gbG9va2VkIGF0LiBIYXMgYW55b25lIHBvc3RlZCBhbnkg cmV2aWV3IGNvbW1lbnRzIG9uIGl0PyBJ4oCZdmUgc2FpZCBiZWZvcmUgdGhhdCBJIHRoaW5rIG1h a2luZyBETEVQIGRlcGVuZGVudCBvbiB0aGUNCiBTVyBkcmFmdCBpcyBhbiBlcnJvciwgYW5kIGl0 IHdvdWxkIGJlIGJldHRlciB0byBsZXQgQ1cgZ28gdGhyb3VnaCBzZXBhcmF0ZWx5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIg RGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsm IzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4 QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9s b2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8 YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6 IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4N ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVk IE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IG1hbmV0IFs8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5KdXN0aW4gRGVhbjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBGZWJydWFyeSAyMDE2IDIxOjE4PGJy Pg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIERMRVAgaW4gTGFzdCBjYWxsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBw dCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4q KiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg ZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBh cnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ry b25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlv dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwv ZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9s bG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwv aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48L3N0cm9uZz48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1B SUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRp b248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkxhc3Qgd2VlayBJIG1lbnRpb25lZCB0aGF0IERMRVAgd2FzIGdvaW5nIHRv IGJlIGxhc3QgY2FsbGVkIHNvb24uJm5ic3A7IFRoYXQgdGltZSBoYXMgY29tZSAoYWdhaW4pIGFu ZCB3aXRoIG5vIGxpc3Qgb2JqZWN0aW9ucyAoaW4gdGhlIHJvdWdoIG9yIG90aGVyd2lzZSkuJm5i c3A7IFNpbmNlIGV2ZXJ5b25lIGhhcyBoYWQgcGxlbnR5IG9mIHRpbWUgdG8gcmV2aWV3IHRoZSBk b2N1bWVudA0KIHRoaXMgbGFzdCBjYWxsIHdpbGwgbGFzdCAyIHdlZWtzLiZuYnNwOyBCb3RoIHRo ZSBjb3JlIERMRVAgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIGNyZWRpdCB3aW5kb3dpbmcgZXh0ZW5z aW9uIGRyYWZ0IGFyZSBpbiBsYXN0IGNhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkp1c3RpbiBEZWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNl IGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZ b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns b3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48 YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C0182C6GLKXM0002VGREEN_-- From nobody Mon Feb 29 04:07:31 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 494951B3116; Mon, 29 Feb 2016 04:07:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229120729.10077.14656.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 04:07:29 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 12:07:29 -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 of the IETF. Title : Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ Message Format Authors : Thomas Clausen Christopher Dearlove Ulrich Herberg Henning Rogge Filename : draft-ietf-manet-rfc5444-usage-02.txt Pages : 20 Date : 2016-02-29 Abstract: This document updates the generalized MANET packet/message format, specified in RFC 5444, by providing rules and recommendations for how protocols can use that packet/message format. In particular, the mandatory rules prohibit a number of uses of RFC 5444 that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use generic RFC 5444 parsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc5444-usage-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 29 04:43:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D41A8742; Mon, 29 Feb 2016 04:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTaodDqJ35Ly; Mon, 29 Feb 2016 04:43:01 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B551A8741; Mon, 29 Feb 2016 04:43:00 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,520,1449532800"; d="scan'208,217"; a="47668788" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 29 Feb 2016 12:14:00 +0000 X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208,217";a="108130822" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 29 Feb 2016 12:14:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.67]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 12:14:00 +0000 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: RFC 5444 usage Thread-Index: AdFy6iaSvJ96kg9xRru0S9qAIiKR4w== Date: Mon, 29 Feb 2016 12:13:58 +0000 Message-ID: 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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C018366GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet-chairs@ietf.org" Subject: [manet] RFC 5444 usage X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 12:43:03 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C018366GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable We have created a -02, of this draft-ietf-manet-rfc5444-usage, which is mos= tly just tidying up -01, in particular making it clearer what the rules it = specifies are (and are not). We think it's ready for WGLC, at whatever length within the usual range the= chairs feel appropriate, and would thus like to request that. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C018366GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

We have created a -02, of this draft-ietf-manet-rfc5= 444-usage, which is mostly just tidying up -01, in particular making it cle= arer what the rules it specifies are (and are not).

 

We think it’s ready for WGLC, at whatever leng= th within the usual range the chairs feel appropriate, and would thus like = to request that.

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________= ________________________________________________

T:  +44 (0)1245 24= 2194  |  E: chris.dearlove@baesystems.com

BAE Systems Appli= ed Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse= x CM2 8HN.
www.= baesystems.com/ai

B= AE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guil= dford, Surrey, GU2 7YP

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C018366GLKXM0002VGREEN_-- From nobody Mon Feb 29 06:10:26 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137061B31E5 for ; Mon, 29 Feb 2016 06:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px_K70FWhVIE for ; Mon, 29 Feb 2016 06:10:23 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 63A361B31E0 for ; Mon, 29 Feb 2016 06:10:22 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1TE9gCx039933; Mon, 29 Feb 2016 09:09:42 -0500 From: "Wiggins, David - 0665 - MITLL" To: "manet@ietf.org" , "Ratliff, Stanley" Thread-Topic: credit-wIndow-01 comments Thread-Index: AQHRcvrsYXx+qbb21EKt7Hk7gYKLxQ== Date: Mon, 29 Feb 2016 14:10:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3539581819_98633396" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602290277 Archived-At: Subject: [manet] credit-wIndow-01 comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 14:10:25 -0000 --B_3539581819_98633396 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Here are a few commemts on draft-ietf-manet-credit-window-01. Sorry I didn't get this out earlier. The draft talks about Destination Up and Response, but not Destination Announce and Response. A strict reading would only allow modems to request credit windowing on their destinations, since only they can send Destination Up (as of DLEP-18). I *think* the intention was to allow either side to request credit windowing. If so, then Destination Announce and Response need to be added. In most cases it is probably sufficient to change "Destination Up" to "Destination Up or Destination Announce" and likewise for Response. The code points for the new data items and the extension code are still listed as TBD. Do specific values need to be chosen, as was done in the DLEP draft? DLEP-19 says that the Credit Windowing extension has code = 1, so at least that should be consistent. Ideally it would not be specified in two places. In section 7.2, "the implementation detecting the mismatch MUST terminate the session by issuing a Peer Termination message with a status code of 'XXXX'" What is XXXX? In section 9, "In these environments, implementations MUST employ [TLS]" TLS was dropped from DLEP, so this should be replaced with a different mitigation strategy. Thanks, David --B_3539581819_98633396 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFNAsAarrdQbMxQ4R 30AYlvWzZQ2aMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDIyOTE0MTAxOVowDQYJKoZIhvcNAQEBBQAEggEAZBw8yrwNXrrvygQJbyeO+k8ufjDdk3+c lF12Oumm3rlWLttah2XXw13T9IwsQElJB590aea/hSPebYlq4Px7iF38ChRRuJNdYeD63ps9 MPvnNrUWEOtCgAGTLoetnpW6s45lt/6RfATn6lqK2EjWbiexQoO0Nh3bAVXtmdg03bcmV3qj OFETpf0mIbmoPVKm+gZ8T/VCL1QUaLoYI2ADzSmPYUBdgxzSD3Cd7XVu1OqSgP+q5uNtarG8 xPIrKyov11dUfSqUJaFuANhp6CQoOQ1kQFRg8iS524o708oYBE9h9vFoB9lm2nT8FsMSnMcX 8jPFhUGgCpRKy9aeKEeNxw== --B_3539581819_98633396-- From nobody Mon Feb 29 07:11:53 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507B91B3327 for ; Mon, 29 Feb 2016 07:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1RWNwtABk2I for ; Mon, 29 Feb 2016 07:11:49 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id A93681B3324 for ; Mon, 29 Feb 2016 07:11:49 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u1TFAwM9032559 for ; Mon, 29 Feb 2016 10:11:09 -0500 From: "Wiggins, David - 0665 - MITLL" To: "manet@ietf.org" Thread-Topic: DLEP and credit windowing normative references Thread-Index: AQHRcwN99pxegM+bmUWQk/mYZ/0ruQ== Date: Mon, 29 Feb 2016 15:11:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3539585498_98891167" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602290295 Archived-At: Subject: [manet] DLEP and credit windowing normative references X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:11:51 -0000 --B_3539585498_98891167 Content-type: multipart/alternative; boundary="B_3539585498_98853232" --B_3539585498_98853232 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Just noticed these nits: DLEP-19 cites credit-window-00 as a normative reference, but that is out of date by one revision. credit-window-01 cites DLEP-18 as a normative reference. Same problem. David --B_3539585498_98853232 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Just noticed these nits:

DLEP-19 cites credit-window-00 as a normative reference= , but that is out of date by one revision.

credit-w= indow-01 cites DLEP-18 as a normative reference.  Same problem.

David

--B_3539585498_98853232-- --B_3539585498_98891167 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFKSwDw2xsRbdUq+Z q3DnmkZBnHddMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDIyOTE1MTEzOFowDQYJKoZIhvcNAQEBBQAEggEAiFVZ3KbT3nOCmGra4jPRiolssz43v8C0 XqrmX6aA9frsuZUr3MUcstnCGWDxv8wYH2QH8cW2CpgHfRCwdjHMo6IQp/j1LFgFJLa4cGVC 67RIjANsIoEs+Vwcina/QofJKhN9G8TIUe2iRDixJ/XwzxMgBg4Cs8zyBcD5q17dT7VAIIE3 uLEoZqVwCkwX38V8hvQVdcy2m0fkzajax1glxdnHjb7Qm8c5j0s+zhtuqchqdfHDSzRnD5WW iCPS5tnT/zIcBTaR6ZXEzVjsKqpbuebNOiWjLHiCsHFMFjL6zMj8mh9cVxaViM/Q/XniOyLB qCZhZHpp3SRkkpqz6trpFw== --B_3539585498_98891167-- From nobody Mon Feb 29 07:17:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB91B3369 for ; Mon, 29 Feb 2016 07:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ANT-BFWuMcQ for ; Mon, 29 Feb 2016 07:16:49 -0800 (PST) Received: from smtp1.idirect.net (smtp1.idirect.net [198.180.159.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E291B3352 for ; Mon, 29 Feb 2016 07:16:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,521,1449550800"; d="scan'208";a="3677227" IronPort-PHdr: =?us-ascii?q?9a23=3AYzWRlhXlojbeBXh9cWqr6CN5EDjV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZhOCt8tkgFKBZ4jH8fUM07OQ6PC/HzJQqsnZ+DBaKdoXCE9D0Z?= =?us-ascii?q?1X1yUbQ+e7SmTDZMbwaCI7GMkQHHRExFqcdXZvJcDlelfJqWez5zNBUj/2NA5y?= =?us-ascii?q?O/inUtWK15f//6mI9pbSewRFgiamKfM3dU3u7FaZis5Dy7RjJakwzACN6ldBZe?= =?us-ascii?q?VajSYgfQzNwl65ruKRwLpHuWwEl/s/9sIGbqT1cKU+VpRcCHIjMnxz6cH2412L?= =?us-ascii?q?Bw6G4HYAemQbjhQOBBLKplmuW573vzfSt+dh1m+dJ8KgHp4uXjH3pZ1iVBvphi?= =?us-ascii?q?lDfwUl+WfTh906xPZAuhu9ox1xzabVbICPOfFiOKXQYYVJFiJ6Qs9NWnkZUcuH?= =?us-ascii?q?ZIwVAr9EZL4Aog=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2DKAQCUX9RW/8n6+gpeDgsBAQEBDwEBAQGESQa6ZQENgWe?= =?us-ascii?q?GEwKBaxQBAQEBAQEBAYEKgi2CFAEBAQEDOksEAgEIEQQBAR8JBzIUCQgCBAESC?= =?us-ascii?q?McOAQEBAQEBBAEBAQEBAQEZhhOEOYhvBZcIBAGNWo57jkoeAQGDaztqAYdEfgE?= =?us-ascii?q?BAQ?= From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" Thread-Topic: credit-wIndow-01 comments Thread-Index: AQHRcvrsYXx+qbb21EKt7Hk7gYKLxZ9DIkPw Date: Mon, 29 Feb 2016 15:16:46 +0000 Message-ID: <4418c743d7d94db9a65adcce6b6df065@VAUSDITCHM2.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] credit-wIndow-01 comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:16:51 -0000 David, = Thanks for the input. I'll try to get to this, and the references you menti= oned, tonight. = Regards, Stan > -----Original Message----- > From: Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] > Sent: Monday, February 29, 2016 9:10 AM > To: manet@ietf.org; Ratliff, Stanley > Subject: credit-wIndow-01 comments > = > Here are a few commemts on draft-ietf-manet-credit-window-01. Sorry I > didn't get this out earlier. > = > The draft talks about Destination Up and Response, but not Destination > Announce and Response. A strict reading would only allow modems to > request credit windowing on their destinations, since only they can send > Destination Up (as of DLEP-18). I *think* the intention was to allow > either side to request credit windowing. If so, then Destination Announce > and Response need to be added. In most cases it is probably sufficient to > change "Destination Up" to "Destination Up or Destination Announce" and > likewise for Response. > = > The code points for the new data items and the extension code are still > listed as TBD. Do specific values need to be chosen, as was done in the > DLEP draft? DLEP-19 says that the Credit Windowing extension has code = =3D > 1, so at least that should be consistent. Ideally it would not be > specified in two places. > = > In section 7.2, "the implementation detecting the mismatch MUST terminate > the session by issuing a Peer Termination message with a status code of > 'XXXX'" > What is XXXX? > = > = > In section 9, "In these environments, implementations MUST employ [TLS]" > TLS was dropped from DLEP, so this should be replaced with a different > mitigation strategy. > = > = > Thanks, > = > David _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Feb 29 07:19:22 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30DB1B335F for ; Mon, 29 Feb 2016 07:19:19 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aELJG9bF6O1 for ; Mon, 29 Feb 2016 07:19:18 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF331B3364 for ; Mon, 29 Feb 2016 07:19:18 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id xx9so24075984obc.2 for ; Mon, 29 Feb 2016 07:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KuH/E7VWjWoaMfgHWVueaEu13W7l8X5GoNdBh3wm8tA=; b=hA1sNbFqw4Rjaffl/zM8BsMLIon/UWWQq/+SF/UhAUPuuEkrzT7r7yxuI+l91JH1TV 2Bs7gw6JDyKBBWd0eCXV8NshXD2L4pA+m54udSgf4DNIDww3zD/Bs9kcp5SyvUWM8vJu OPDFPJ6B8ockwkdu6qY7OiEqwwWaH0sxfy939jj7VYXz2jBH3b1nNsO4OF3a9zmTDmHa ImtNGMH2CWciwcHgJ9xMxJlMPB5ML2dtw5oWARHQNgfyCa0LkVUjxBLTjCQ4Rbztn/lu 7wnRqNKMrlqH7iZFdsBTy4+3ZA73g3L3K8g9pWzIqjoOMJbTrpjWPnKfw8lf7xgMgxug eEhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KuH/E7VWjWoaMfgHWVueaEu13W7l8X5GoNdBh3wm8tA=; b=FJ44b0JjTdGcUDCbJuhWRO/uNDTQGfdgHw9P3sHakztT1xQFzbkoCCzpNqr/WtBS4C sfMMtVn/Lc96X1yyUyPixG6cBOBwCFNb48r3/ZXdkxwi+VwkA8nlcrH1pyatU7cE2eFw oqqs4QW4xghk4HdyevBRL21kB7hnt/U6I+7FW+fj2YOtEiohApRufEGPfVfiKu7m78rd pC/CdYsB8tIGA0v5qHUuT7NmpMyZ94ceHdvqWAVfRMksty9FLrhOw/q20BvH3qEA+CU4 6BpljSv2b4A7p5arLtJEBnmW23lsRjgK20dyefCKcdL0mwk1kykpv0RC0adZCj64At1Q /Zdg== X-Gm-Message-State: AD7BkJJshXjkWmm9mpyLhTDykFvQJJ7iRvHIUwAtWNgTl46D/P1+pVs9/XitPigYlZDugY9EGfUBDpGaWGo/bw== MIME-Version: 1.0 X-Received: by 10.182.135.230 with SMTP id pv6mr11839582obb.61.1456759158018; Mon, 29 Feb 2016 07:19:18 -0800 (PST) Received: by 10.76.45.102 with HTTP; Mon, 29 Feb 2016 07:19:17 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 10:19:17 -0500 Message-ID: From: Justin Dean To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=089e0112c5cc231d76052cea2cd1 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:19:20 -0000 --089e0112c5cc231d76052cea2cd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DLEP is currently in WGLC. You note regarding recent changes including responses to recent reviews is valid and the document will not be sent up without resolution of comments (in the rough or otherwise). Justin On Mon, Feb 29, 2016 at 5:46 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Looking at what I wrote, I failed to note that I think DLEP is in pretty > good shape, and will be ready for WGLC soon, but there have been some > recent changes, and I=E2=80=99m just saying I=E2=80=99d like some materia= l on those > changes, including responses to reviews, from the authors and then perhap= s > two weeks. Or a bit more than two weeks. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > --089e0112c5cc231d76052cea2cd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
DLEP is currently in WGLC.=C2=A0 You note regarding r= ecent changes including responses to recent reviews is valid and the docume= nt will not be sent up without resolution of comments (in the rough or othe= rwise).

Justin

On Mon, Feb 29, 2016 at 5:46 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:<= br>

Looking at what I wrote, = I failed to note that I think DLEP is in pretty good shape, and will be rea= dy for WGLC soon, but there have been some recent changes, and I=E2=80=99m just saying I=E2=80=99d like some material on those change= s, including responses to reviews, from the authors and then perhaps two we= eks. Or a bit more than two weeks.

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

=

--089e0112c5cc231d76052cea2cd1-- From nobody Mon Feb 29 07:22:28 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FB1B3399 for ; Mon, 29 Feb 2016 07:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1x9JRUlqFzM for ; Mon, 29 Feb 2016 07:22:25 -0800 (PST) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCCC1B3393 for ; Mon, 29 Feb 2016 07:22:24 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,521,1449532800"; d="scan'208,217"; a="31662926" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 29 Feb 2016 15:22:22 +0000 X-IronPort-AV: E=Sophos;i="5.22,521,1449532800"; d="scan'208,217";a="108175049" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 29 Feb 2016 15:22:22 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.67]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 15:22:22 +0000 From: "Dearlove, Christopher (UK)" To: Justin Dean Thread-Topic: [manet] DLEP in Last call Thread-Index: AQHRcNs76FmCKa+Xo06YeoNdrdDiOp9C0EdggAAKUyCAAEzLgIAAADBQ Date: Mon, 29 Feb 2016 15:22:21 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C01A4D1GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:22:27 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C01A4D1GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Qnkg4oCccmVzb2x1dGlvbiBvZiBjb21tZW50c+KAnSwgZG8geW91IG1lYW4gdGhhdCB0aGUgYXV0 aG9ycyBzaG91bGQgcHJvdmlkZSBzb21lIHJldmlldyByZXNwb25zZXMgYW5kIGNvbW1lbnRzIG9u IHdoYXTigJlzIGRvbmUgYmV5b25kIGp1c3QgaGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24/DQoN Ci0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMu Y29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzog MDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm b3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogSnVzdGluIERlYW4gW21haWx0bzpiZWJlbWFz dGVyQGdtYWlsLmNvbV0NClNlbnQ6IDI5IEZlYnJ1YXJ5IDIwMTYgMTU6MTkNClRvOiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21h bmV0XSBETEVQIGluIExhc3QgY2FsbA0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdl IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFu IGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdo ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz IG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3Ug Y2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBz dXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50 LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9E ZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkRMRVAgaXMgY3VycmVu dGx5IGluIFdHTEMuICBZb3Ugbm90ZSByZWdhcmRpbmcgcmVjZW50IGNoYW5nZXMgaW5jbHVkaW5n IHJlc3BvbnNlcyB0byByZWNlbnQgcmV2aWV3cyBpcyB2YWxpZCBhbmQgdGhlIGRvY3VtZW50IHdp bGwgbm90IGJlIHNlbnQgdXAgd2l0aG91dCByZXNvbHV0aW9uIG9mIGNvbW1lbnRzIChpbiB0aGUg cm91Z2ggb3Igb3RoZXJ3aXNlKS4NCkp1c3Rpbg0KDQpPbiBNb24sIEZlYiAyOSwgMjAxNiBhdCA1 OjQ2IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpM b29raW5nIGF0IHdoYXQgSSB3cm90ZSwgSSBmYWlsZWQgdG8gbm90ZSB0aGF0IEkgdGhpbmsgRExF UCBpcyBpbiBwcmV0dHkgZ29vZCBzaGFwZSwgYW5kIHdpbGwgYmUgcmVhZHkgZm9yIFdHTEMgc29v biwgYnV0IHRoZXJlIGhhdmUgYmVlbiBzb21lIHJlY2VudCBjaGFuZ2VzLCBhbmQgSeKAmW0ganVz dCBzYXlpbmcgSeKAmWQgbGlrZSBzb21lIG1hdGVyaWFsIG9uIHRob3NlIGNoYW5nZXMsIGluY2x1 ZGluZyByZXNwb25zZXMgdG8gcmV2aWV3cywgZnJvbSB0aGUgYXV0aG9ycyBhbmQgdGhlbiBwZXJo YXBzIHR3byB3ZWVrcy4gT3IgYSBiaXQgbW9yZSB0aGFuIHR3byB3ZWVrcy4NCg0KLS0NCkNocmlz dG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0 cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C01A4D1GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ5IOKAnHJlc29sdXRpb24gb2YgY29tbWVudHPigJ0sIGRv IHlvdSBtZWFuIHRoYXQgdGhlIGF1dGhvcnMgc2hvdWxkIHByb3ZpZGUgc29tZSByZXZpZXcgcmVz cG9uc2VzIGFuZCBjb21tZW50cyBvbiB3aGF04oCZcyBkb25lIGJleW9uZCBqdXN0IGhlcmUgaXMg dGhlIGxhdGVzdCB2ZXJzaW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3 RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y aWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNC RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wg Jm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMu Y29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2Fp PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmss IEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBEZWFuIFttYWls dG86YmViZW1hc3RlckBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjkgRmVicnVhcnkg MjAxNiAxNToxOTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+ DQo8Yj5DYzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFu ZXRdIERMRVAgaW4gTGFzdCBjYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg YmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2Vt PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0K PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9z cGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5S ZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3Ug cmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w ZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBp cyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50 LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9E ZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2Vzczwv YT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ RExFUCBpcyBjdXJyZW50bHkgaW4gV0dMQy4mbmJzcDsgWW91IG5vdGUgcmVnYXJkaW5nIHJlY2Vu dCBjaGFuZ2VzIGluY2x1ZGluZyByZXNwb25zZXMgdG8gcmVjZW50IHJldmlld3MgaXMgdmFsaWQg YW5kIHRoZSBkb2N1bWVudCB3aWxsIG5vdCBiZSBzZW50IHVwIHdpdGhvdXQgcmVzb2x1dGlvbiBv ZiBjb21tZW50cyAoaW4gdGhlIHJvdWdoIG9yIG90aGVyd2lzZSkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMjksIDIwMTYgYXQgNTo0 NiBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkxvb2tpbmcgYXQgd2hhdCBJIHdyb3RlLCBJIGZhaWxlZCB0byBub3RlIHRo YXQgSSB0aGluayBETEVQIGlzIGluIHByZXR0eSBnb29kIHNoYXBlLCBhbmQgd2lsbCBiZQ0KIHJl YWR5IGZvciBXR0xDIHNvb24sIGJ1dCB0aGVyZSBoYXZlIGJlZW4gc29tZSByZWNlbnQgY2hhbmdl cywgYW5kIEnigJltIGp1c3Qgc2F5aW5nIEnigJlkIGxpa2Ugc29tZSBtYXRlcmlhbCBvbiB0aG9z ZSBjaGFuZ2VzLCBpbmNsdWRpbmcgcmVzcG9uc2VzIHRvIHJldmlld3MsIGZyb20gdGhlIGF1dGhv cnMgYW5kIHRoZW4gcGVyaGFwcyB0d28gd2Vla3MuIE9yIGEgYml0IG1vcmUgdGhhbiB0d28gd2Vl a3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5D aHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+ PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4K VGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGlu dGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5 IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmli dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3A+ PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D8C01A4D1GLKXM0002VGREEN_-- From nobody Mon Feb 29 07:37:00 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25521B3418 for ; Mon, 29 Feb 2016 07:36:57 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBxsbrVGnmnt for ; Mon, 29 Feb 2016 07:36:56 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C701B33B8 for ; Mon, 29 Feb 2016 07:36:55 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id ts10so137664416obc.1 for ; Mon, 29 Feb 2016 07:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=Ez69BhjrH1+srDV2eLsJCwEud4/WQqx5JVNcbiKJPz0=; b=nWkzFZ6Iv2gEsrgS4Q0gEUtn2bb24rf/oLKsSswAWS6UzrCvejz7WTQ5E6qgOe6Cqd 6rYD+Zcs8l/mH7iQPmSm2O/Gnahfmlx76N4rOyWuiUNvDXiRzd48h7FGNkuyF6FkD+a5 W6lQmyR9ZlLa02OiE7dB3mua/DO5oo4pC6FNKZ/5dXaEq0CTvMHEA5kSq44R4Xkutj0n YR5PUV4z2MfrrXupipg/5tFl2E2Xi2JUqDhqrRfvazBrWju0LOacwCx24Qihn+wL9YqS KOw8Gzi7xbwqIncahC+0lDDqSoaRzCUxpBuXL5vAKnAJDWzMWi9E8RYYCxBtqKRy238P koIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=Ez69BhjrH1+srDV2eLsJCwEud4/WQqx5JVNcbiKJPz0=; b=KxLTmy66zdS1Z0UE0QudwPvc5F6KPw1ZxNuEmNzoV/6WQutcp2nW7VUYee8cz2UZuv cp8ZYLHHTk2JRYRCxXqoZypSYezDBtAm6Avx703Any6ZlvG+dzYnNXVMxIcJJ+P27Qm7 2Z7IruK7/pLyiLIBD5n4G9Kb+rGLAfOXbFO3h90Ay0nSjN5d9yyCFimDZWA8oZubiBUP JRS6debNVmj3ETwX7jntSiQ548oaMmrwSdOqWVOYXQ16V3OVPqSIWoWwC/P5EnR9sk4u CZREXSae+KOWB4cneBqlTPs3WZzKdE4i0LQdHsrUHBRBxSimBxoh/+qmt5o4TMsaOXv8 1YnQ== X-Gm-Message-State: AD7BkJKOOqY6K7Oc4aQ4TPH8LbuWXT7RrOILfksVmvmNzI6rBL4QETUZiXEqeEhEa9w8Py6bwYMEx7eqa1CVqg== MIME-Version: 1.0 X-Received: by 10.182.56.161 with SMTP id b1mr12068283obq.14.1456760215049; Mon, 29 Feb 2016 07:36:55 -0800 (PST) Received: by 10.76.45.102 with HTTP; Mon, 29 Feb 2016 07:36:54 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 10:36:54 -0500 Message-ID: From: Justin Dean To: "Dearlove, Christopher (UK)" , "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2d760241e48052cea6b13 Archived-At: Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:36:58 -0000 --001a11c2d760241e48052cea6b13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 10:22 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > By =E2=80=9Cresolution of comments=E2=80=9D, do you mean that the authors= should provide > some review responses and comments on what=E2=80=99s done beyond just her= e is the > latest version? > > > Yes that is exactly what I mean. There should be an author response of including review comments and resolution, be it a change in the document or we thought about it but decided against and here is why. Justin --001a11c2d760241e48052cea6b13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 29, 2016 at 10:22 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

By =E2=80=9Cresolution of= comments=E2=80=9D, do you mean that the authors should provide some review= responses and comments on what=E2=80=99s done beyond just here is the late= st version?


Yes that is exactly what I mean.=C2=A0 There should be= an author response of including review comments and resolution, be it a ch= ange in the document or we thought about it but decided against and here is= why.

Justin
--001a11c2d760241e48052cea6b13-- From nobody Mon Feb 29 07:40:28 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8451B345D for ; Mon, 29 Feb 2016 07:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z24dFO8xuQIH for ; Mon, 29 Feb 2016 07:40:25 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EED1B3456 for ; Mon, 29 Feb 2016 07:40:24 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Mon, 29 Feb 2016 15:39:59 +0000 From: Rick Taylor To: Justin Dean , "Dearlove, Christopher (UK)" , "manet@ietf.org" Thread-Topic: [manet] DLEP in Last call Thread-Index: AQHRcNs6mE88eV2i0E6iCg5ulw+oiQ== Date: Mon, 29 Feb 2016 15:39:58 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C37E4C02@tss-server1.home.tropicalstormsoftware.com> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP in Last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:40:27 -0000 I'm looking at my git history right now...=0A= =0A= Rick=0A= =0A= On 29/02/16 15:37, Justin Dean wrote:=0A= >=0A= >=0A= > On Mon, Feb 29, 2016 at 10:22 AM, Dearlove, Christopher (UK)=0A= > >=0A= > wrote:=0A= >=0A= > By =93resolution of comments=94, do you mean that the authors should= =0A= > provide some review responses and comments on what=92s done beyond=0A= > just here is the latest version?____=0A= >=0A= >=0A= > Yes that is exactly what I mean. There should be an author response of= =0A= > including review comments and resolution, be it a change in the document= =0A= > or we thought about it but decided against and here is why.=0A= >=0A= > Justin=0A= =0A= From nobody Mon Feb 29 17:09:08 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3372F1A8745 for ; Mon, 29 Feb 2016 17:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GOavGRF3YnK for ; Mon, 29 Feb 2016 17:08:52 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id DDBE71A8738 for ; Mon, 29 Feb 2016 17:08:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QQLUnn8Ftn5FjvS96yC3LORX3zcHarNeKq7iKdjDUEO6EtZGWqFFdig4Df02xRvD; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1aaYnQ-0004he-C4; Mon, 29 Feb 2016 20:08:17 -0500 To: "Dearlove, Christopher (UK)" , manet References: From: Charlie Perkins Message-ID: <56D4EB7D.4010002@earthlink.net> Date: Mon, 29 Feb 2016 17:08:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010904070009090401000809" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac79c6031831070e5de14c6310a67a6303d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] AODVv2 responses to recent comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 01:09:06 -0000 This is a multi-part message in MIME format. --------------010904070009090401000809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Chris, On 1/19/2016 5:37 AM, Dearlove, Christopher (UK) wrote: > > And outside those 31, that we’re at this position with a suggestion > there’s possible looping (about which I have no idea) isn’t that > comforting. > I hope your concerns have been resolved on this matter. The paper mentioned on the mailing list pointed out various ambiguities in RFC 3561 described how the ambiguities might be construed to install self-routes and, combined with possible inconsistent choices for sequence number, loops could result. But the email to the list several weeks ago indicated that these ambiguities do not exist in AODVv2. The authors of that paper have expressed interest in doing a similar analysis on AODVv2. Other discussion about routing loops has not identified routing loop problems in the existing specification. Use of unconfirmed or invalid routes for routing might lead to errors, but that doesn't carry over to produce loops in the route table. I'm looking for any other open issues outside of the Security Considerations which is being reworked according to recent comments but should be submitted soon. Regards, Charlie P. > There’s also a lot of document to review. Which of course I haven’t > done at this time. But my attention did alight on the IANA > considerations section, and I noted there that: > > - Not sure why the jump to 10 for message types, though I’m not opposed. > > - The PATH_METRIC TLV can’t be type 10, that’s already taken. See IANA > register. > > - We previously pointed out that CONT_SEQ_NUM (COMPLETE) already > exists and does the job that SEQ_NUM is doing, so why allocate another > TLV? (You could avoid the necessity of repeating (COMPLETE) by simply > commenting once and thereafter omitting.) > > - Why the suggested skipping of types 12 to 14? > > *-- * > > *Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > **__________________________________________________________________________ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Victoria > Mercieca > *Sent:* 18 January 2016 21:45 > *To:* manet > *Subject:* [manet] AODVv2 responses to recent comments > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Consider carefully whether you should click on any links, open any > attachments or reply./ > /For information regarding //*/Red Flags/*/that you can look out for > in emails you receive, click here > .// > /If you feel the email is suspicious, please follow this process > .// > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > Hi all, > > We have just released the newest AODVv2 draft. The major update is the > separation of the AODVv2 route set from the RIB. > > Here are also responses to the comments received before Christmas. > This should include all the points from Thomas Clausen regarding > versions 11 and 12, and also a couple of other points which have been > brought up since. Apologies for the huge email. For issues that need > further discussion, I have tried to include the main points of the > discussion so far. Please feel free to create a separate thread for > any further discussion. > > We are still looking into the loop conditions recently reported for > AODV, also still working on the text about security, and use of > msg-hop-limit. > > Kind regards, > > Victoria. > > > 1. End-to-end / hop-by-hop acks - issue when a route is marked as > confirmed and valid when the link to the next hop is confirmed as > bidirectional (but the links downstream have not yet been verified as > bidirectional). > > AODVv2: The authors believe this is an issue which would not occur > frequently, and would right itself. > > This only occurs for the route to OrigAddr. What needs to happen for > this to occur is that an intermediate node that takes part in the > route discovery between OrigAddr and TargAddr coincidentally has > packets to send to OrigAddr in the time between confirming the link to > its own next hop toward OrigAddr is bidirectional, and the time taken > for all other routers on the path to confirm their next hops too. If > the route is used to forward packets before every other link in the > path is confirmed as bidirectional, and the data packets are forwarded > faster than the RREP and any RREP_Acks, then yes they could be > delivered to a router without a valid route to OrigAddr. Alternatively > if one of the links turns out to be unidirectional then the data > packets will also arrive at a router without a valid route. In these > cases, RERR messages will be generated toward the source of the > traffic, the route to OrigAddr will be deleted at routers back toward > TargAddr, but if data packets are still flowing from any source to > OrigAddr, the route will be re-requested by the router responsible for > discovering routes for the source of the data. > > The changes required to make acknowledgements end-to-end would require > a lot more control traffic and be necessary for every route discovery > and in almost all cases would be unnecessary. > > Text has been added to the draft in “Local Route State Changes” to > describe this. > > 2. Buffering > Thomas: > “It would seem that buffering, as specified, does not accomplish what > it states that it accomplishes: packets are (as you describe) still being > sent while no route is available, and therefore will be dropped later. > => Consequently, it seems that buffering is a futile exercise?” > > AODVv2: Packets are buffered before a route exists. A router only > begins sending them when it deems the route to be valid. In general, > buffering is not futile. > > True, there is this case outlined above where the router could deem > the route valid before the bidirectionality check has happened for > each and every hop. If the links chosen for the route are not all > bidirectional, then yes, any data packets forwarded along this route > will end up being dropped at some point on that path. > This case is caused by the RREP_Ack being hop-by-hop, and not caused > by buffering. > > Thomas:  > “Buffers have huge impacts on TCP performance, and I doubt if the > issues on e.g. TCP are well enough understood by this WG (Bufferbloat > was an example of where people got it wrong, despite having extensive > experience).” > > AODVv2: Packets will only be buffered while a route is requested. The > TCP packets buffered will be packets for session initialisation. The > authors believe that buffering these will have a positive effect. Some > references have been suggested, listed here, the first of which has > been included in the draft: > http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf > Mobile Internetworking with IPv6: Concepts, Principles and Practices > {Koodli, Perkins} > disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt > > Analysis of TCP performance over mobile ad hoc networks > http://dl.acm.org/citation.cfm?id=313540 > > Alternatively, we could remove the mention of TCP, and instead state > that buffering MAY be used for packets awaiting a route, but that > implementation and implications of this are out of scope for AODVv2. > > > 3. Use of msg-hop-limit and msg-hop-count: > Thomas: > But, either way, as according to your model messages are never > forwarded, but always are intended for receipt by a router which is a > direct neighbor, then a >1 (which applies to the > message) seems inappropriate. > Actually, according to that model, I would even say that receipt of a > message with a >1 should be interpreted as a malfunction. > As you refer to RFC5444 appendix B, do note that Appendix B of RFC5444 > (and, note the errata 4003) talks about: > field, if present, contains the number of hops > on which the message is allowed to travel before being discarded by a > MANET router. The is set by the message originator > and is used to prevent messages from endlessly circulating in a MANET. > Specifically “set by the message originator” and “number of hops on > which the message is allowed to travel” — with your control messages > traveling just one hop, I believe that setting = 1 is > correct. > > AODVv2: Discussion is still needed here. We wonder if these fields are > necessary at all for AODVv2. We were using them to limit the number of > regenerations of a RREQ. However, the hop limit value needs to be > large enough to allow a RREQ from one side of the network to another. > It might be the case that using the hop limit, almost every router in > the network would receive that RREQ anyway, and by using the > redundancy check, we already stop RREQs from circulating endlessly. > > 4. Abstract > Thomas: > “I made the following comment, which still applies: > “This is a little over-stating the applicability: these statements may > be true in some scenarios (for example, when there are few concurrent > traffic flows, and therefore few routes to repair, and therefore few > flooding operations to contend for channel access). As a general > statement, this last sentence is incorrect”” > > AODVv2: The text has been removed and the abstract now states: “ The > Ad Hoc On-demand Distance Vector Version 2 (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.” > > 5,9,12,13,20. Router Client > Thomas: > “I made a comment previously that “Router client” is a poorly chosen > term, and have proposed alternatives. I’ve seen some attempts on the > list at rather than change the term, explain it — some of which is in > this document. The “Overview” still talks about “a router…one of its > clients” - which is no less confusing than last time Iw went through it. > I reiterate, why not use “Local Attached Network Set”, which is the > term used by other documents from this WG?” > > AODVv2: We already answered this suggestion on the MANET list and > asked for comments and suggestions, and no responses were received. We > have defined what we mean by Router Client, and the terminology has so > far not changed. However, some alternatives have been suggested, so if > you feel any of these are more effective, please let us know: > • Advertised IP Address: puts the emphasis on advertisement rather > than topological connection > • Accessible IP Address: puts the emphasis on accessibility through > the particular router – not bad > • Reduced Function Device [RFD]: doesn’t roll off the tongue, but > this is terminology used for L2R in IEEE 802 Wireless for a similar > situation > • Accessible Device Address: adds some emphasis for the device as > well as the address > • Stably Connected IP Address: nothing is permanent, of course, > but the router client set is thought to be relatively stable > • Topologically Connected IP address: ... suggests that a > "topological connection" is stable compared to wireless > • Administratively Assigned IP address: ... somehow does not > connote the "otherness" of the router client devices. > > 6. Overview - adjacency > Thomas: > The term “confirming adjacency” is gone, and is now replaced by > “confirming bidirectionality” - which, alas, still sounds like there > is some active monitoring (HELLO message exchange) going on. Unless > that is the case, then please be more specific here. > I note that the term adjacency is used through and through the > document, btw. > > AODVv2: The text has been updated to avoid the word adjacency. We do > not believe the text implies active monitoring through HELLO messages. > > 7. Overview - forwarding plane > Thomas: I suggested in my last review: The overview must also include > a paragraph on the intersections between this protocol and the > forwarding plane — this, as it is different (and more invasive) from > that which is typically seen in routing protocols. > Specifically, as a reactive protocol, it is required (at least) that > the forwarding plane is modified : > 1) A “miss” when looking up a next hop for a data packet to be > forwarded, is signalled to the AODVv2 process so as to permit that > route discovery be launched; > 2) A “miss” when attempting to deliver a data packet to a next hop, > which was recorded in the routing table, is signalled to the AODVv2 > process so as to permit that a route repair be initiated and/or a > Route Error be generated. > 3) A “hit” when looking up a next hop for a data packet to be > forwarded to a destination is signalled to the AODVv2 process so as to > permit maintenance of “active route” Route State, timers and such. > Note that these things are necessary to call out in the “overview” and > in the “applicability statement”, both: it is not that they are > negatives per se, but that they are important factors governing the > applicability of this protocol: will a given platform permit such > access to the forwarding plane, for example? Important to understand > if for that platform this protocol is apple > I see that this was not addressed in the overview, nor in the > applicability other than by a forward reference to section 6.4. While > it is positive that there is a section 6.4, this does not exonerate > the overview and the applicability statement for being honest about > the requirements (notably to the platform/os) that this protocol has > for being applicable > > AODVv2: The Overview and the Applicability Statement now refer to > these basic requirements for the interaction with the forwarding > plane. The Applicability Statement also contains the reference to the > later section which describes this in more detail. > > 8. 7182 and security > > Thomas: I suggested in my last review: It is important to do more than > this: 7182 does only provide “containers” for ICVs and timestamps, and > does not specify how to use them to obtain specific security > properties. RFC7182 may be a tool that can be used, but how* that tool > is used is what determines the security properties. > Therefore, saying that “security is dealt with by using RFC7182” is > either an incomplete statement, or is indicative of insufficient > security considerations.” > The actual sentence in the I-D has been changed, now it explicitly > names the two TLVs from 7182 that it uses. That is, alas, still not > sufficient. > Making the aside that was discussed recently on the list, that (i) > control messages are not forwarded, and that (ii) they are modified in > transit, the security/trust model is somewhat different from that of > 7181 and consequently for what 7182 was initially written for. I think > that calling out the trust model, and how 7182 actually is used here, > might be what is called for. > Continuing with the aside, this *especially* as the applicability > statement says: "Providing security for a reactive routing protocol > can be difficult” > > Thomas: > OK, so assume that I understand regeneration as per my previous > email, as meaning “generate a new message and send to my neighbors, > based on what I learned when processing a received message” — just > like any distance vector protocol does. > In that model, what you write makes sense: each originator of a > control message (i.e., whoever generates or regenerates it) is free to > include the information it desires, such as the 4 points you list > above. No issues with that. > However, and this joins what I pointed out in a previous email, you > write in the applicability statement: "Providing security for a > reactive routing protocol can be difficult." > While we can discuss if the nature of “reactive routing protocol” > generates particular difficulties, we certainly can agree that this > protocol has the same “difficulties” as a distance vector protocol: > routing topology information (by definition) not being exchanged > end-to-end, but between neighbors (who do calculations and generate > their own announcements — regeneration, as you call it). > This means that a specific security model of transitive trust must be > assumed, no? I trust Victoria, therefore when Victoria says “Stan told > me” then I trust that she actually verified that "it was indeed Stan > who told her …” — and either way, I have no way of verifying? > I did not see the trust model / trust assumption discussed in the > specification (specifically not in applicability and in section 13, > both of where it should be called out), but I think that this is > actually a crucial point to get right, in order to approach developing > the MTI security mechanisms. > Anyways, that observation actually contrasts strongly with what the > applicability statement then goes on to say, namely: > AODVv2 provides for message integrity and security against replay > attacks by using integrity check values, timestamps and sequence > numbers, as described in Section 13. > This is true only in as much as messages are indeed exchanged between > neighbors: when you “regenerate” a message, i.e., generate a > new message in response to receipt of a message, you generate brand > new payload (but possibly including some of the data from the received > message, of course): thus, any ICVs “from farther away than the > neighbor” will be useless (or, if you zero out the parts that you > change, these parts will not be protected). > The above sentence, quoted from the applicability statement, and that > which transpires from section 13, seems - certainly, absent the trust > model assumed - to suggest that end-to-end protection/validation is > provided. But, this is not the case. > Finally to the applicability statement, a question: > If security associations can be established, encryption can be used > for AODVv2 messages to ensure that only trusted routers participate in > routing operations. > What you want to say here is that “if all trusted routers have a > shared secret, then we’re able to use that shared secret to ignore > non-trusted routers”, right? > While “security associations” that do not pass through a shared secret > probably can be thought up, it’s not trivial and I did not find any > discussion of that in the document? > Having, on the topic of security, re-read Section 13, which starts: > This section describes various security considerations and potential > avenues to secure AODVv2 routing. > While this is an honest description of what follows, I remain > convinced that this is not sufficient. So let me ask as precisely as I > can: > o what is the MTI security mechanism that a conformant implementation > must provide? Specifically: - which are the processing steps (for > example in section 7.2.1 and section 7.2.2 for RREP - and similarly > for the other message types) that define that security mechanism > o what protection is offered by that MTI security mechanism? And what > remains vulnerable. > If this specification targets std.track, then it should include > (reasonably solid, but definitely well specified) MTI security. > > Chris Dearlove: > There are two potential choices: > > - RREQ has an integrity check value to indicate that someone trusted > created it, if not necessarily the destination. That someone might be > identifiable or not. > - RREQ has a signature that indicates that the destination created it. > > Unfortunately, an RREQ that changes as it is forwarded (aggregating > data of any sort) makes the second option tricky, unless there’s some > sort of aggregating signature as it is forwarded. But I’m not an > expert on the latter. > > The most trivial case of the former is simply that everyone trusted > has a single shared key. That has obvious issues – although it was > good enough that embodied as RFC 7183 we could get 7181 through the > system (as a “must implement, do not need to use” minimal case). > Alternatively something identity-based (e.g. draft-ietf-manet-ibs) > could be used, so you know who created the message you received, but > you are relying on a chain of trust, hop by hop. At which point you > might as well just sign packets (see RFC 7182). > > But in even the weakest case (the single shared key used hop by hop) > there has to be a failure for things to go wrong - either loss of key > (in which case all bets are off) or suborning one router (who can do > quite a lot of damage). > > I haven't read the latest AODVv2 draft yet, but this sort of thing > should be described in its security considerations - the previous > draft though didn't discuss this as far as I recall. > > Chris Dearlove: > If you go down this route of assuming transitive trust, then you > might as well use 7182’s packet ICV and timestamp rather than message > ICV and timestamp. > > There is a complication (mostly one of presentation) that the 5444 > multiplexer (rather than AODVv2) needs to do this, at least for > packets containing AODVv2 messages (but at which point, probably all > 5444 packets). So you either, depending on your point of view, need to > request it to do that, or (administratively) decline to operate except > over a 5444 multiplexer that is doing this. > > The advantage is one of saved space and time when packets contain more > than one message. Plus slightly better protection (hop count and limit > are covered) but which probably doesn’t matter here. > > If messages are changed/replaced on a one-to-one basis as forwarded, > then the only solutions I can see are hop by hop transitive trust > (packets or messages per hop), or something complicated involving > aggregation and knowledge of changes. But the latter would be a > research task to develop, so let’s not try that. > > Jiazi Yi: > I agree with Chris and Thomas on their concerns on the hop-by-hop > security issue. > This is very different from classical DV protocol, in which the vector > information is designed to be exchanged between neighbours. > In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple > hops. A router can sign a message that isn't actually initialised by > itself -- this is, at least, against intuition. > This can be an issue if we have compromised routers in the network. Of > course, a compromised router is a problem for every protocol, like > OLSRv2. But in OLSRv2, a compromised router can only speak on behalf > of itself -- however, in AODVv2, a compromised/mis-configured router > can pretend to be any other router (for example, generate RREQ > messages using another address as OrigAddr). The consequence will be > much more serious if that happens. > > AODVv2: This is not yet addressed. > > 9. Terminology - host, routers, router clients: > > Thomas: My last review suggested: > “This has been brought up on the list several times in the past, > without having been addressed. > There are “hosts” and there are “routers” — whose roles are well > defined. Node” not so much — which is clear from looking at the > definition here: “either AODVv2 routers or router clients” (with > “router clients” being defined as “an AODVv2 router is also its own > router client”). > > This is very much related to the use of “Router Client”, and both that > term, and “node” indicative that some clarity is needed here. > > All a router cares about is “an address”. If that address is of a > network, or a router, or an interface (and, if said interface is > installed in a router or a host) doesn’t matter. > > So, “an address” is something that the routing protocol should care > about finding paths to. Which means that each address that should be > made reachable by the routing protocol should be advertised by (at > least) one router in the network. > > One way of doing that would be to simply talk about “Attached > Networks” as is done in RFC7181, wherein an address included in the > “Attached Network Set” is advertised by an OLSRv2 router....in this > case, the equivalent would be “for each address in the Attached > Network Set of an AODVv2 router the router MUST respond > authoritatively to a RREQ, and MUST maintain the corresponding > sequence number”. > The text, as it currently is, is really hard to read, and a re-edit > along these lines would go a long way.” > > I note that the terms “Node” and “Router Client” are still used, in > their original form, and that other than some slight wordsmithing this > comment has not been addressed in the document. > > I reiterate that the need to use router, host, node, and router client > in and by itself should be an indicator that tightening up of > terminology is required. > > AODVv2: See 5. The use of “node” has been addressed. > > 10. Terminology and elsewhere - address > Thomas: I made the following comment to Routable Unicast IP Address: > “Are there any technical reason why not simply *any* address could be > considered by the routing protocol? > My understanding, but correct me if I am wrong, is that all that is > required is that all interfaces in a given AODVv2 routing domain has > an unique address. > That some of these addresses (by an IP addressing architecture > document) has special semantics associated (such as are link locals, > or are for private use, or are for example use only, or are for > multicast) is out of scope here? > I see nothing has changed on the above, so let me be more explicit: > the routing protocol itself probably) should not care about what kind > of addresses are filled into it. Is an 192.16./16 address appropriate? > Not across the internet, but it may be in somebody’s private > deployments. Should the routing protocol be “address police” and is > implementation of a “I refuse to route these addresses…” a requirement > for claiming conformance? Suggest simply stating what the requirements > are under which the routing protocol will work — and leave “address > assignment politics” aside. > > AODVv2: We ask for clarification on this issue. We use the phrase > “routable and unicast” in the draft with respect to OrigAddr and > TargAddr. We dont mean to exclude addresses from the private address > ranges. But we dont want to request routes for multicast, > indeterminate, link-local, or loopback addresses. This is not about > router interface addresses which are used for AODVv2. > > 11. Multiple interfaces with the same IP address, 6621 implications > > Thomas: I also continued: > Now, with that being said also, the WG wanted that RFC7181 supports > not just multiple interfaces, but also the same address used on > multiple interfaces of the same router. There were good reasons for > that, and while it was not trivial to implement, it turned out to be > the right thing to support. If there are technical reasons why this is > not supported in AODVv2 (for example, if this cannot be made work > because of ) then that should be called out in the > applicability statement also? > Conversely, if it is possible in AODVv2, then I do not believe that it > is clearly specified how (at least, in the “naive” on paper examples I > drew up, something ended up not working). So either the protocol as-is > does not support it (but could be made to?) or it is supported (but > just need to be spelled out), or is not possible (and need to be > disclaimed in the applicability statement). > Stan Ratliff was a driving force in holding the WG’s collective feet > to the fire in getting this support included in RFC7181, and would > likely be the right person to consult on this matter? > I actually have not seen changes, or comments, on this. In OLSRv2, the > WG was making it a strong requirement that it should be possible to > use the same IP address on different interfaces of a router. It was > somewhat tedious to design around, but it was worked out, and the > conditions under which that was possible were defined and documented. > I would like to see the same done for this protocol. > I also note that this is not unrelated to RFC6621-discussions. For > example, when selecting S-MPRs on a multi-interface and > multi-address-per-interface router, care must be taken least things > won’t work. So, if (and this links back to previous mails) RFC6621 is > a requirement or desire for this protocol, then there are some > considerations required here. > > AODVv2: We have removed references to RFC 6621. > Initial thoughts on this topic of multiple interfaces using the same > IP address, is that this wouldn’t cause a problem, if the router has > only one sequence number. However, this is up for further discussion. > > 12. Interfaces configured as router clients > > Thomas: I see that the definition of “Router Client” has changed to be > “An address or address range…the AODVv2 router’s interface addresses > are also configured as router clients” > Better than before, but still missing the target. The term “Router > Client” is, as I indicated numerous times before, odd. > But the second part of the sentence, does that mean (what it says) > that the interfaces must be configured specially, so as to be able to > be “router clients”? That can’t be true. > What you likely mean is: > An AODVv2 router is configured so as to consider its own interfaces as > part of the locally attached network set” ? > You configure the router, right? No special “interface configuration > properties” are required for an interface to be announcable by an > AODVv2 router? (And, getting rid of node would actually make the > definition shorter and nicer) > > AODVv2: The wording we use says: "The IP Addresses of the router's > interfaces will appear in the Router Client Table." and in the > Terminology: "The AODVv2 router's interface addresses are also > configured as Router Clients." Both statements say that ‘interface > addresses are configured as router clients’ ...we are not sure why > this is misunderstood. We have a router client list, and the AODVv2 > router’s interface addresses are included in this list. The interface > itself doesn’t have special “interface configuration properties”. > > 13 - more on router clients > Thomas: Now, snipping out from the applicability statement: > "Multi-homing of an IP address is not supported by AODVv2, and > therefore a Router Client, i.e. an IP Address, … " > …evidence to there being some redundant terminology here to weed away. > > AODVv2: That was there as a reminder that a router client is based on > IP address, even though the device with that IP address may have other > IP addresses too. It’s the IP address that is the router client, not > the device as a whole with its entire collection of configured IP > addresses. One IP address of that device might be configured as a > router client on one router, and a different IP address of that device > could be configured as a router client on another router. The IP > addresses would seem to AODVv2 to be on different devices. > > > 14. data elements > > Thomas: The below is a little bit of a meta-comment, I am not quite > sure what I think here. The definitions for Target Node and such were > confusing before. They still are, somewhat. > I think that it may be because the definitions now used are simply > copy-pasted out from the tables in the previous version, for example: > “An AODVv2 Data Element containing the destination address of the > IP packet triggering route discovery.” > OK, I can trace back and see that a Data Element is something that > exists inside a protocol message. To me, however, that’s not really > general terminology as such, but part of the specification of a packet > format - or rather, it is the notation that you use when describing an > algorithm. By the way, why are some notations in CamelCase whereas > others have a space in them, e.g. “Target Node” and “TargMetric”, both > of which are Data Elements? Would be good with a consistent approach here. > I *think* that it would be better to take all those “Data Element” > bits and move to a separate section (or subsection) to the > terminology, and then keep all the “other stuff” (Neighbor, …) in its > own section. > > AODVv2: Your comment from draft 11 where we already had data elements > in a separate table, says: > "Also suggest abolishing this table and folding the definitions in > with the other definitions in the terminology section." > We have updated to not refer so heavily to the term Data Element. All > the terms are described in the Terminology section. Those in CamelCase > are used as message fields. > > > 15. Route “to a specific address” > Thomas: > I made a comment: Second, should “valid route” not be qualified by “to > a specific address”?” > Which was not addressed. > > AODVv2: Every route is to a specific address...the address is > specified by Route.Address and Route.PrefixLength. > Do you mean that routes are to the address TargAddr or OrigAddr and > therefore to a specific host address rather than to a network prefix? > This is not the case. Prefix Length is included in AODVv2 messages so > that the route learned from the message represents the prefix which > OrigAddr or TargAddr resides on (if the router client entry > corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is > configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the > corresponding router client entry at RREQ_Gen could be 10.0.0.0/8 > . So when constructing the RREQ you include a > prefix length of 8, and when receiving the RREQ and learning the route > to OrigAddr, you can install a route to 10.0.0.0/8 > . Text has been updated to make this more obvious. > > 16. unreachable address > > Thomas: I also made a comment on "Unreachable Address” - I am glad I > did, because I apparently had a different understanding than what was > intended. I now see that an Unreachable Address by definition is an > address listed in a RERR message, and not the same as an address to > which no route has yet been discovered? If yes, then please use a > different term, such as FormerlyReachableAddress” or something of the > sort? > > AODVv2: "Formerly reachable" is inaccurate... we send a RERR if > another router forwards a packet via us, and we dont have a route, not > just when we lose a route. We might never have had a route, or might > never have had a valid route, so the address may not have been > "formerly reachable". Also, I think "FormerlyReachableAddress" is a > really ugly term. Unreachable means "we don’t have a route and we > aren’t going to request one" or "we lost this route" (depending on why > the RERR is being sent). It doesn’t mean "we didn’t request one yet", > and it would be wrong to class an address as unreachable because we > hadn’t requested a route for it yet, that is, assuming it’s configured > as a router client. > > If a better term is suggested we could consider changing but at the > moment we have kept “Unreachable Address”. > > > 17. Applicability - multiple interfaces same address, 6621 again > > Thomas: Applicability statement: First, I would like to recognize the > efforts made to improve this since last review. Thanks > Second, the document states: "AODVv2 supports routers with multiple > interfaces, as long as each interface configured for AODVv2 has a > unicast IP address. A router may use the same IP address on multiple > interfaces. Address assignment procedures are out of scope for AODVv2.” > Is that true? Granted, I have not worked this through in detail, but I > can present a counter-example: the use of RFC6621 means that there > certainly are some constraints that must be respected least various > flooding optimizations may not work. > Secondly, if the multiple-interfaces-with-same-address are on the same > L2, and this is what I have not worked through, are there any > situations that will not work? > The immediately previous version of this specification read: > "AODVv2 supports routers with multiple interfaces, as long as each > interface configured for AODVv2 has its own unicast routable IP address" > So what changed that means that each interface no longer needs its > *own* unicast address? > > AODVv2: Well, based on previous questions on this, we talked it > through and decided there shouldn’t be an issue if different > interfaces of a router used the same IP address. Note that we changed > AODVv2 so that there is one sequence number per router. No longer can > a router use different sequence numbers on different interfaces. If an > RREQ went out of two interfaces using the same address, we worked it > through and decided the request would be processed correctly. > Also, text referring to RFC 6621 has been removed. > > 18. Applicability and appendix - multihoming > > Thomas: I pointed out to the Applicability Statement: > I think that appendix B needs to be removed. Essentially, it makes > claims that it is possible to do multi-homing — but neither specifies > how it is done, nor gives pointers to documents that justify the claim. > AODVv2 does not support multi-homing — that’s clear, and it is fine > that it is called out here. Thank you for that. > Now, with that being said, I am torn between being satisfied that it > is called out on one hand, and wanting to have “multi homing” on the > other hand. RFC7181 supports multi-homing, FWIW. > I believe that this also would merit some explicit discussion by the > WG, in order to understand if this design decision is acceptable? > I see that Appendix B still is in the document, and I do not recall > having seen this discussed on the mailing list. Simply removing the > reference from the Applicability Statement to Appendix B does not > address the issue that I raised in my previous review. > > AODVv2: Appendix has been removed and may appear in a future > informational document. > > 19. interfaces list - use of “SHOULD” > > Thomas: To 4.1, I made the following comment: > "Is this a should, or a SHOULD? If the latter, should it be a MUST? > In general, there are a lot of such “maybe normative language” through > the document, and I would much like to see an editorial pass — > essentially all may/should/ must and friends carefully evaluated as if > they should become 2119-terms, and ... more importantly (it has been > called out before, fwiw) quite a bit of should/SHOULD which ought to > be transformed into MUST. > Generally, aiming for a very a low number of SHOULD is a good design > metric for a document” > Aside from the general comment on 2119-language, why is this a SHOULD? > > AODVv2: We changed this instance to a MUST and will be checking for > “maybe normative language”. > > > 20. Router client - Local Attached Network Set > > Thomas: To 4.2, I made the following comment: > As indicated earlier, I believe that the term “Router Client” is ill > chosen. I believe that it is more appropriately an “Attached Network > Set” since — as indicated previously — the term “Router Client” is > ambiguous. I am pleased to see, though, that this “Router Client List” > in reality is an “Attached Network Set” and so that change should be > (relatively) easy. > The above comment still is applicable to this revision, > > AODVv2: See 5,9,12,13. > > > 21. Subnet > Thomas: To 4.2, I made the following comment: > Also, I recommend to not say “subnet” — how about rephrasing to “If a > prefix is included in the attached network set of an AODVv2 router, > then that AODVv2 router MUST provide connectivity for, i.e. answer to > RREQs and maintain sequence numbers for, all addresses from within > that prefix.” > I note that while the term has been removed from section 4, there’re 4 > lingering instances of this term in the document, that could easily be > removed. > > AODVv2: All mentions of "subnet" were in the ENAR section. They have > been updated to say network, or "networks attached to the routers" > > > 22. relocating router client > > Thomas: I Also made a comment about Appendix B in my previous review, > which is referenced here. That comment still applies. > > AODVv2: Moved into main draft. > > > 23. Neighbor Monitoring > > Thomas: To Section 4.3, I noticed: > Does section 6.2 describe how to monitor an established adjacency > only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, > I see > “Not every pair of neighboring routers will necessarily form an > adjacency,” — so it likely isn’t 6.2 that tells me how to maintain > this table? > In short, “A neighbour table MUST be maintained” — where can I find > information on how to do this? > Section 6.2 states: > “The default approach for monitoring bidirectional connectivity to the > next hop toward OrigAddr is to request acknowledgement of Route Reply > messages.” > That certainly will tell me if a link over which an RREP is sent is > bi-directional, but will not maintain a “neighbor table”. > So how is this done? Or, is the “Neighbor Table” not supposed to > contain the complete set of neighbours? What information “...MUST be > maintained” then, in this table? > This is very unclear, I would not know how to implement a mechanism > that populates this “Neighbor Table” with the needed information here. > I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this > comment has not been addressed > > AODVv2: A new section was added to show how to update the neighbour > table. There have also been updates to this entire section since > version 12. > > 24. pseudo-code > > Thomas: > I am throwing this in here, as I am sure that I commented on that in > the previous review, but I do not see that addressed: is Appendix C > normative, or not? It represents “ a second specification of the > protocol, in a different language” from the main part of the > specification. I have not walked through and made 200% sure that both > are perfectly aligned and that there are no ambiguities, but having > two different specifications of a protocol is a recipe for disaster. > Please either make 2000% sure that they are specifying the same thing > without ambiguities, or remove one. > > AODVv2: Removed - maybe to include in an informational document in future. > > > 25. seqnum as 16 bit unsigned integer > > Thomas: To section 4.4, I wrote: > "would like to nit-pick that: the router can maintain this sequence > number in whatever format it pleases — but, when it includes it in > control messages, it must be representable in a specified format, > respecting certain rules.” > I see that there were no changes following this comment. > > AODVv2: Why store it as anything other than what it needs to be when > it goes into a message? However, we now state "MUST report its own > sequence number as a 16 bit....whenever it creates a RREQ or RREP > message". > > > 26. multiple seqnums? > > Thomas: > To section 4.4 I asked for clarification as to if sequence numbers > were per interface or per router, as the specification was unclear on > that. The words has changed, but it still is unclear: how many > sequence numbers does a router maintain? One? One per interface? > > AODVv2: We tried to start discussion on that point, and in the > meantime we reverted to having 1 seqnum per router. We think the text > is clear... we refer to "the routers sequence number" or "its sequence > number" - never hinting that there could be multiple seqnums per > router (as far as I'm aware). > > > 27. sets/lists/tables > > Thomas: > In my previous review, I expressed that it would be preferential to > use “a notation of Sets” rather than tables. I see that this has not > changed. > > AODVv2: You preferred sets rather than lists in your previous > review...and explained our reasoning for this in responses to the > MANET list, and we did not receive further comments. > > > 28. use of “node” > > Thomas: > I made a comment on node and address, let me pick this up again. The > following: > RteMsg.OrigAddr > An IP address of the node which requires the route, i.e., the source > address of the IP packet triggering the route request. > would be more compact and clear if getting rid of the term “node” and > said: > RteMsg.OrigAddr > The source address of the IP packet triggering the route request. > > AODVv2: Change made as suggested. > > 29. route table/rib/routing set > > Thomas: To section 4.6, and I (and others) have commented on this before: > All AODVv2 routers MUST maintain a route table. The route table entry > is a conceptual data structure. Implementations MAY use any internal > representation but MUST contain the following information: > In order to avoid confusion, rename this to “Routing Information Base” > or “Routing Set” — a Routing Table is an operating system construct, > whereon operations directly influence packet forwarding. What you are > defining here is a RIB/an RS. > > AODVv2: Done in version 13. > > > 30. rreq for prefix, use of “ip address” and “address" > > Thomas: > The confusion that I pointed out in my previous review on “IP address” > and “Address” being used a bit haphazardly persists, fwiw. It makes me > think, can a router send an RREQ for a prefix? > > AODVv2: See also #15. RREQ_Gen can include the prefix associated with > OrigAddr by adding a prefix length to the message, the prefix length > associated with the router client entry corresponding to OrigAddr. So > all routers which receive it can learn a route to the prefix on which > OrigAddr resides. But for TargAddr... the RREQ only has one target IP > address - the destination IP address of the packet requiring the > route... so what prefix length would it use? The RREQ requests a route > to a single IP address. However, when the RREP is created, RREP_Gen > should include the prefix length associated with the router client > entry for TargAddr. So all routers which receive this RREP learn a > route to the prefix TargAddr is part of (if the router client entry is > configured with a prefix length). The text has been updated to make > this more obvious. > > > 31. next hop ip address wording > > Thomas: > I also called this out in my previous review as incorrect, and despite > wordsmithing it still is: > > Route.NextHop > The source IP address of the message advertising the > route to > Route.Address, i.e. an IP address of the AODVv2 router > used for > the next hop on the path toward Route.Address. > > If that “message” is an RFC5444 entity, then it does to have a “source > IP Address” — the encapsulating IP datagram containing the packet > containing the message does. And the message MAY have an Originator > Address > > AODVv2: Updated to say “the source IP address of the IP packet > containing the message advertising...” > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------010904070009090401000809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Chris,

On 1/19/2016 5:37 AM, Dearlove, Christopher (UK) wrote:

And outside those 31, that we’re at this position with a suggestion there’s possible looping (about which I have no idea) isn’t that comforting.


I hope your concerns have been resolved on this matter.  The paper mentioned on the mailing list pointed out various ambiguities in RFC 3561 described how the ambiguities might be construed to install self-routes and, combined with possible inconsistent choices for sequence number, loops could result.  But the email to the list several weeks ago indicated that these ambiguities do not exist in AODVv2.  The authors of that paper have expressed interest in doing a similar analysis on AODVv2.

Other discussion about routing loops has not identified routing loop problems in the existing specification.  Use of unconfirmed or invalid routes for routing might lead to errors, but that doesn't carry over to produce loops in the route table.

I'm looking for any other open issues outside of the Security Considerations which is being reworked according to recent comments but should be submitted soon.

Regards,
Charlie P.


 

There’s also a lot of document to review. Which of course I haven’t done at this time. But my attention did alight on the IANA considerations section, and I noted there that:

- Not sure why the jump to 10 for message types, though I’m not opposed.

- The PATH_METRIC TLV can’t be type 10, that’s already taken. See IANA register.

- We previously pointed out that CONT_SEQ_NUM (COMPLETE) already exists and does the job that SEQ_NUM is doing, so why allocate another TLV? (You could avoid the necessity of repeating (COMPLETE) by simply commenting once and thereafter omitting.)

- Why the suggested skipping of types 12 to 14?

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Victoria Mercieca
Sent: 18 January 2016 21:45
To: manet
Subject: [manet] AODVv2 responses to recent comments

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

 

Hi all,

We have just released the newest AODVv2 draft. The major update is the separation of the AODVv2 route set from the RIB.

Here are also responses to the comments received before Christmas. This should include all the points from Thomas Clausen regarding versions 11 and 12, and also a couple of other points which have been brought up since. Apologies for the huge email. For issues that need further discussion, I have tried to include the main points of the discussion so far. Please feel free to create a separate thread for any further discussion.

We are still looking into the loop conditions recently reported for AODV, also still working on the text about security, and use of msg-hop-limit.

Kind regards,

Victoria.

 


1. End-to-end / hop-by-hop acks - issue when a route is marked as confirmed and valid when the link to the next hop is confirmed as bidirectional (but the links downstream have not yet been verified as bidirectional).

AODVv2: The authors believe this is an issue which would not occur frequently, and would right itself.

This only occurs for the route to OrigAddr. What needs to happen for this to occur is that an intermediate node that takes part in the route discovery between OrigAddr and TargAddr coincidentally has packets to send to OrigAddr in the time between confirming the link to its own next hop toward OrigAddr is bidirectional, and the time taken for all other routers on the path to confirm their next hops too. If the route is used to forward packets before every other link in the path is confirmed as bidirectional, and the data packets are forwarded faster than the RREP and any RREP_Acks, then yes they could be delivered to a router without a valid route to OrigAddr. Alternatively if one of the links turns out to be unidirectional then the data packets will also arrive at a router without a valid route. In these cases, RERR messages will be generated toward the source of the traffic, the route to OrigAddr will be deleted at routers back toward TargAddr, but if data packets are still flowing from any source to OrigAddr, the route will be re-requested by the router responsible for discovering routes for the source of the data.

The changes required to make acknowledgements end-to-end would require a lot more control traffic and be necessary for every route discovery and in almost all cases would be unnecessary.

Text has been added to the draft in “Local Route State Changes” to describe this.

2. Buffering
Thomas:
“It would seem that buffering, as specified, does not accomplish what
it states that it accomplishes: packets are (as you describe) still being
sent while no route is available, and therefore will be dropped later.
=> Consequently, it seems that buffering is a futile exercise?”

AODVv2: Packets are buffered before a route exists. A router only begins sending them when it deems the route to be valid. In general, buffering is not futile.

True, there is this case outlined above where the router could deem the route valid before the bidirectionality check has happened for each and every hop. If the links chosen for the route are not all bidirectional, then yes, any data packets forwarded along this route will end up being dropped at some point on that path.
This case is caused by the RREP_Ack being hop-by-hop, and not caused by buffering.

Thomas: 
“Buffers have huge impacts on TCP performance, and I doubt if the issues on e.g. TCP are well enough understood by this WG (Bufferbloat was an example of where people got it wrong, despite having extensive experience).”

AODVv2: Packets will only be buffered while a route is requested. The TCP packets buffered will be packets for session initialisation. The authors believe that buffering these will have a positive effect. Some references have been suggested, listed here, the first of which has been included in the draft:
http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf
Mobile Internetworking with IPv6: Concepts, Principles and Practices {Koodli, Perkins}
disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt
Analysis of TCP performance over mobile ad hoc networks http://dl.acm.org/citation.cfm?id=313540
Alternatively, we could remove the mention of TCP, and instead state that buffering MAY be used for packets awaiting a route, but that implementation and implications of this are out of scope for AODVv2.


3. Use of msg-hop-limit and msg-hop-count:
Thomas:
But, either way, as according to your model messages are never forwarded, but always are intended for receipt by a router which is a direct neighbor, then a <msg-hop-limit> >1 (which applies to the message) seems inappropriate.
Actually, according to that model, I would even say that receipt of a message with a <msg-hop-count> >1 should be interpreted as a malfunction.
As you refer to RFC5444 appendix B, do note that Appendix B of RFC5444 (and, note the errata 4003) talks about:
      <msg-hop-limit> field, if present, contains the number of hops on which the message is allowed to travel before being discarded by a MANET router.  The <msg-hop-limit> is set by the message originator and is used to prevent messages from endlessly circulating in a MANET.
Specifically “set by the message originator” and “number of hops on which the message is allowed to travel” — with your control messages traveling just one hop, I believe that setting <msg-hop-limit> = 1 is correct.

AODVv2: Discussion is still needed here. We wonder if these fields are necessary at all for AODVv2. We were using them to limit the number of regenerations of a RREQ. However, the hop limit value needs to be large enough to allow a RREQ from one side of the network to another. It might be the case that using the hop limit, almost every router in the network would receive that RREQ anyway, and by using the redundancy check, we already stop RREQs from circulating endlessly.

4. Abstract
Thomas:
“I made the following comment, which still applies:
“This is a little over-stating the applicability: these statements may be true in some scenarios (for example, when there are few concurrent traffic flows, and therefore few routes to repair, and therefore few flooding operations to contend for channel access). As a general statement, this last sentence is incorrect””

AODVv2: The text has been removed and the abstract now states: “ The Ad Hoc On-demand Distance Vector Version 2 (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.”

5,9,12,13,20. Router Client
Thomas:
“I made a comment previously that “Router client” is a poorly chosen term, and have proposed alternatives. I’ve seen some attempts on the list at rather than change the term, explain it — some of which is in this document. The “Overview” still talks about “a router…one of its clients” - which is no less confusing than last time Iw went through it.
I reiterate, why not use “Local Attached Network Set”, which is the term used by other documents from this WG?”

AODVv2: We already answered this suggestion on the MANET list and asked for comments and suggestions, and no responses were received. We have defined what we mean by Router Client, and the terminology has so far not changed. However, some alternatives have been suggested, so if you feel any of these are more effective, please let us know:
•    Advertised IP Address: puts the emphasis on advertisement rather than topological connection
•    Accessible IP Address: puts the emphasis on accessibility through the particular router – not bad
•    Reduced Function Device [RFD]: doesn’t roll off the tongue, but this is terminology used for L2R in IEEE 802 Wireless for a similar situation
•    Accessible Device Address: adds some emphasis for the device as well as the address
•    Stably Connected IP Address: nothing is permanent, of course, but the router client set is thought to be relatively stable
•    Topologically Connected IP address: ... suggests that a "topological connection" is stable compared to wireless
•    Administratively Assigned IP address: ... somehow does not connote the "otherness" of the router client devices.

6. Overview - adjacency
Thomas:
The term “confirming adjacency” is gone, and is now replaced by “confirming bidirectionality” - which, alas, still sounds like there is some active monitoring (HELLO message exchange) going on. Unless that is the case, then please be more specific here.
I note that the term adjacency is used through and through the document, btw.

AODVv2: The text has been updated to avoid the word adjacency. We do not believe the text implies active monitoring through HELLO messages.

7. Overview - forwarding plane
Thomas: I suggested in my last review: The overview must also include a paragraph on the intersections between this protocol and the forwarding plane — this, as it is different (and more invasive) from that which is typically seen in routing protocols.
Specifically, as a reactive protocol, it is required (at least) that the forwarding plane is modified :
1) A “miss” when looking up a next hop for a data packet to be forwarded, is signalled to the AODVv2 process so as to permit that route discovery be launched;
2) A “miss” when attempting to deliver a data packet to a next hop, which was recorded in the routing table, is signalled to the AODVv2 process so as to permit that a route repair be initiated and/or a Route Error be generated.
3) A “hit” when looking up a next hop for a data packet to be forwarded to a destination is signalled to the AODVv2 process so as to permit maintenance of “active route” Route State, timers and such.
Note that these things are necessary to call out in the “overview” and in the “applicability statement”, both: it is not that they are negatives per se, but that they are important factors governing the applicability of this protocol: will a given platform permit such access to the forwarding plane, for example? Important to understand if for that platform this protocol is apple
I see that this was not addressed in the overview, nor in the applicability other than by a forward reference to section 6.4. While it is positive that there is a section 6.4, this does not exonerate the overview and the applicability statement for being honest about the requirements (notably to the platform/os) that this protocol has for being applicable

AODVv2: The Overview and the Applicability Statement now refer to these basic requirements for the interaction with the forwarding plane. The Applicability Statement also contains the reference to the later section which describes this in more detail.

8. 7182 and security

Thomas: I suggested in my last review: It is important to do more than this: 7182 does only provide “containers” for ICVs and timestamps, and does not specify how to use them to obtain specific security properties. RFC7182 may be a tool that can be used, but how* that tool is used is what determines the security properties.
Therefore, saying that “security is dealt with by using RFC7182” is either an incomplete statement, or is indicative of insufficient security considerations.”
The actual sentence in the I-D has been changed, now it explicitly names the two TLVs from 7182 that it uses. That is, alas, still not sufficient.
Making the aside that was discussed recently on the list, that (i) control messages are not forwarded, and that (ii) they are modified in transit, the security/trust model is somewhat different from that of 7181 and consequently for what 7182 was initially written for. I think that  calling out the trust model, and how 7182 actually is used here, might be what is called for.
Continuing with the aside, this *especially* as the applicability statement says: "Providing security for a reactive routing protocol can be difficult”

Thomas:
OK, so assume that I understand regeneration as per my previous email, as meaning “generate a new message and send to my neighbors, based on what I learned when processing a received message” — just like any distance vector protocol does.
In that model, what you write makes sense: each originator of a control message (i.e., whoever generates or regenerates it) is free to include the information it desires, such as the 4 points you list above. No issues with that.
However, and this joins what I pointed out in a previous email, you write in the applicability statement: "Providing security for a reactive routing protocol can be difficult."
While we can discuss if the nature of “reactive routing protocol” generates particular difficulties, we certainly can agree that this protocol has the same “difficulties” as a distance vector protocol: routing topology information (by definition) not being exchanged end-to-end, but between neighbors (who do calculations and generate their own announcements — regeneration, as you call it).
This means that a specific security model of transitive trust must be assumed, no? I trust Victoria, therefore when Victoria says “Stan told me” then I trust that she actually verified that "it was indeed Stan who told her …” — and either way, I have no way of verifying?
I did not see the trust model / trust assumption discussed in the specification (specifically not in applicability and in section 13, both of where it should be called out), but I think that this is actually a crucial point to get right, in order to approach developing the MTI security mechanisms.
Anyways, that observation actually contrasts strongly with what the applicability statement then goes on to say, namely:
   AODVv2 provides for message integrity and security against replay
   attacks by using integrity check values, timestamps and sequence
   numbers, as described in Section 13.
This is true only in as much as messages are indeed exchanged between neighbors: when you “regenerate” a message, i.e., generate a new message in response to receipt of a message, you generate brand new payload (but possibly including some of the data from the received message, of course): thus, any ICVs “from farther away than the neighbor” will be useless (or, if you zero out the parts that you change, these parts will not be protected).
The above sentence, quoted from the applicability statement, and that which transpires from section 13, seems - certainly, absent the trust model assumed - to suggest that end-to-end protection/validation is provided. But, this is not the case.
Finally to the applicability statement, a question:
If security associations can be established, encryption can be used for AODVv2 messages to ensure that only trusted routers participate in routing operations.
What you want to say here is that “if all trusted routers have a shared secret, then we’re able to use that shared secret to ignore non-trusted routers”, right?
While “security associations” that do not pass through a shared secret probably can be thought up, it’s not trivial and I did not find any discussion of that in the document?
Having, on the topic of security, re-read Section 13, which starts:
   This section describes various security considerations and potential
   avenues to secure AODVv2 routing. 
While this is an honest description of what follows, I remain convinced that this is not sufficient. So let me ask as precisely as I can:
o what is the MTI security mechanism that a conformant implementation must provide? Specifically: - which are the processing steps (for example in section 7.2.1 and section 7.2.2 for RREP - and similarly for the other message types) that define that security mechanism
o what protection is offered by that MTI security mechanism? And what remains vulnerable.
If this specification targets std.track, then it should include (reasonably solid, but definitely well specified) MTI security.

Chris Dearlove:
There are two potential choices:

- RREQ has an integrity check value to indicate that someone trusted created it, if not necessarily the destination. That someone might be identifiable or not.
- RREQ has a signature that indicates that the destination created it.

Unfortunately, an RREQ that changes as it is forwarded (aggregating data of any sort) makes the second option tricky, unless there’s some sort of aggregating signature as it is forwarded. But I’m not an expert on the latter.

The most trivial case of the former is simply that everyone trusted has a single shared key. That has obvious issues – although it was good enough that embodied as RFC 7183 we could get 7181 through the system (as a “must implement, do not need to use” minimal case). Alternatively something identity-based (e.g. draft-ietf-manet-ibs) could be used, so you know who created the message you received, but you are relying on a chain of trust, hop by hop. At which point you might as well just sign packets (see RFC 7182).

But in even the weakest case (the single shared key used hop by hop) there has to be a failure for things to go wrong - either loss of key (in which case all bets are off) or suborning one router (who can do quite a lot of damage).

I haven't read the latest AODVv2 draft yet, but this sort of thing should be described in its security considerations - the previous draft though didn't discuss this as far as I recall.

Chris Dearlove:
If you go down this route of assuming transitive trust, then you might as well use 7182’s packet ICV and timestamp rather than message ICV and timestamp.
 
There is a complication (mostly one of presentation) that the 5444 multiplexer (rather than AODVv2) needs to do this, at least for packets containing AODVv2 messages (but at which point, probably all 5444 packets). So you either, depending on your point of view, need to request it to do that, or (administratively) decline to operate except over a 5444 multiplexer that is doing this.
 
The advantage is one of saved space and time when packets contain more than one message. Plus slightly better protection (hop count and limit are covered) but which probably doesn’t matter here.
 
If messages are changed/replaced on a one-to-one basis as forwarded, then the only solutions I can see are hop by hop transitive trust (packets or messages per hop), or something complicated involving aggregation and knowledge of changes. But the latter would be a research task to develop, so let’s not try that.

Jiazi Yi:
I agree with Chris and Thomas on their concerns on the hop-by-hop security issue.
This is very different from classical DV protocol, in which the vector information is designed to be exchanged between neighbours.
In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A router can sign a message that isn't actually initialised by itself -- this is, at least, against intuition.
This can be an issue if we have compromised routers in the network. Of course, a compromised router is a problem for every protocol, like OLSRv2. But in OLSRv2, a compromised router can only speak on behalf of itself -- however, in AODVv2, a compromised/mis-configured router can pretend to be any other router (for example, generate RREQ messages using another address as OrigAddr).  The consequence will be much more serious if that happens.

AODVv2: This is not yet addressed.

9. Terminology - host, routers, router clients:

Thomas: My last review suggested:
“This has been brought up on the list several times in the past, without having been addressed.
There are “hosts” and there are “routers” — whose roles are well defined. Node” not so much — which is clear from looking at the definition here: “either AODVv2 routers or router clients” (with “router clients” being defined as “an AODVv2 router is also its own router client”).

This is very much related to the use of “Router Client”, and both that term, and “node” indicative that some clarity is needed here.

All a router cares about is “an address”. If that address is of a network, or a router, or an interface (and, if said interface is installed in a router or a host) doesn’t matter.

So, “an address” is something that the routing protocol should care about finding paths to. Which means that each address that should be made reachable by the routing protocol should be advertised by (at least) one router in the network.

One way of doing that would be to simply talk about “Attached Networks” as is done in RFC7181, wherein an address included in the “Attached Network Set” is advertised by an OLSRv2 router....in this case, the equivalent would be “for each address in the Attached Network Set of an AODVv2 router the router MUST respond authoritatively to a RREQ, and MUST maintain the corresponding sequence number”.
The text, as it currently is, is really hard to read, and a re-edit along these lines would go a long way.”

I note that the terms “Node” and “Router Client” are still used, in their original form, and that other than some slight wordsmithing this comment has not been addressed in the document.

I reiterate that the need to use router, host, node, and router client in and by itself should be an indicator that tightening up of terminology is required.

AODVv2: See 5. The use of “node” has been addressed.

10. Terminology and elsewhere - address
Thomas: I made the following comment to Routable Unicast IP Address:
“Are there any technical reason why not simply *any* address could be considered by the routing protocol?
My understanding, but correct me if I am wrong, is that all that is required is that all interfaces in a given AODVv2 routing domain has an unique address.
That some of these addresses (by an IP addressing architecture document) has special semantics associated (such as are link locals, or are for private use, or are for example use only, or are for multicast) is out of scope here?
I see nothing has changed on the above, so let me be more explicit: the routing protocol itself probably) should not care about what kind of addresses are filled into it. Is an 192.16./16 address appropriate? Not across the internet, but it may be in somebody’s private deployments. Should the routing protocol be “address police” and is implementation of a “I refuse to route these addresses…” a requirement for claiming conformance? Suggest simply stating what the requirements are under which the routing protocol will work — and leave “address assignment politics” aside.

AODVv2: We ask for clarification on this issue. We use the phrase “routable and unicast” in the draft with respect to OrigAddr and TargAddr. We dont mean to exclude addresses from the private address ranges. But we dont want to request routes for multicast, indeterminate, link-local, or loopback addresses. This is not about router interface addresses which are used for AODVv2.

11. Multiple interfaces with the same IP address, 6621 implications

Thomas: I also continued:
Now, with that being said also, the WG wanted that RFC7181 supports not just multiple interfaces, but also the same address used on multiple interfaces of the same router. There were good reasons for that, and while it was not trivial to implement, it turned out to be the right thing to support. If there are technical reasons why this is not supported in AODVv2 (for example, if this cannot be made work because of <reason>) then that should be called out in the applicability statement also?
Conversely, if it is possible in AODVv2, then I do not believe that it is clearly specified how (at least, in the “naive” on paper examples I drew up, something ended up not working). So either the protocol as-is does not support it (but could be made to?) or it is supported (but just need to be spelled out), or is not possible (and need to be disclaimed in the applicability statement).
Stan Ratliff was a driving force in holding the WG’s collective feet to the fire in getting this support included in RFC7181, and would likely be the right person to consult on this matter?
I actually have not seen changes, or comments, on this. In OLSRv2, the WG was making it a strong requirement that it should be possible to use the same IP address on different interfaces of a router. It was somewhat tedious to design around, but it was worked out, and the conditions under which that was possible were defined and documented.
I would like to see the same done for this protocol.
I also note that this is not unrelated to RFC6621-discussions. For example, when selecting S-MPRs on a multi-interface and multi-address-per-interface router, care must be taken least things won’t work. So, if (and this links back to previous mails) RFC6621 is a requirement or desire for this protocol, then there are some considerations required here.

AODVv2: We have removed references to RFC 6621.
Initial thoughts on this topic of multiple interfaces using the same IP address, is that this wouldn’t cause a problem, if the router has only one sequence number. However, this is up for further discussion.

12. Interfaces configured as router clients

Thomas: I see that the definition of “Router Client” has changed to be
“An address or address range…the AODVv2 router’s interface addresses are also configured as router clients”
Better than before, but still missing the target. The term “Router Client” is, as I indicated numerous times before, odd.
But the second part of the sentence, does that mean (what it says) that the interfaces must be configured specially, so as to be able to be “router clients”? That can’t be true.
What you likely mean is:
An AODVv2 router is configured so as to consider its own interfaces as part of the locally attached network set” ?
You configure the router, right? No special “interface configuration properties” are required for an interface to be announcable by  an AODVv2 router? (And, getting rid of node would actually make the definition shorter and nicer)

AODVv2: The wording we use says: "The IP Addresses of the router's interfaces will appear in the Router Client Table." and in the Terminology: "The AODVv2 router's interface addresses are also configured as Router Clients." Both statements say that ‘interface addresses are configured as router clients’ ...we are not sure why this is misunderstood. We have a router client list, and the AODVv2 router’s interface addresses are included in this list. The interface itself doesn’t have special “interface configuration properties”.

13 - more on router clients
Thomas: Now, snipping out from the applicability statement:
"Multi-homing of an IP address is not supported by AODVv2, and therefore a Router Client, i.e. an IP Address,  … "
…evidence to there being some redundant terminology here to weed away.

AODVv2: That was there as a reminder that a router client is based on IP address, even though the device with that IP address may have other IP addresses too. It’s the IP address that is the router client, not the device as a whole with its entire collection of configured IP addresses. One IP address of that device might be configured as a router client on one router, and a different IP address of that device could be configured as a router client on another router. The IP addresses would seem to AODVv2 to be on different devices.


14. data elements

Thomas: The below is a little bit of a meta-comment, I am not quite sure what I think here. The definitions for Target Node and such were confusing before. They still are, somewhat.
I think that it may be because the definitions now used are simply copy-pasted out from the tables in the previous version, for example:
   “An AODVv2 Data Element containing the destination address of the IP packet triggering route discovery.”
OK, I can trace back and see that a Data Element is something that exists inside a protocol message. To me, however, that’s not really general terminology as such, but part of the specification of a packet format - or rather, it is the notation that you use when describing an algorithm. By the way, why are some notations in CamelCase whereas others have a space in them, e.g. “Target Node” and “TargMetric”, both of which are Data Elements? Would be good with a consistent approach here.
I *think* that it would be better to take all those “Data Element” bits and move to a separate section (or subsection) to the terminology, and then keep all the “other stuff” (Neighbor, …) in its own section.

AODVv2: Your comment from draft 11 where we already had data elements in a separate table, says:
"Also suggest abolishing this table and folding the definitions in with the other definitions in the terminology section."
We have updated to not refer so heavily to the term Data Element. All the terms are described in the Terminology section. Those in CamelCase are used as message fields.


15. Route “to a specific address”
Thomas:
I made a comment: Second, should “valid route” not be qualified by “to a specific address”?”
Which was not addressed.

AODVv2: Every route is to a specific address...the address is specified by Route.Address and Route.PrefixLength.
Do you mean that routes are to the address TargAddr or OrigAddr and therefore to a specific host address rather than to a network prefix? This is not the case. Prefix Length is included in AODVv2 messages so that the route learned from the message represents the prefix which OrigAddr or TargAddr resides on (if the router client entry corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the corresponding router client entry at RREQ_Gen could be 10.0.0.0/8. So when constructing the RREQ you include a prefix length of 8, and when receiving the RREQ and learning the route to OrigAddr, you can install a route to 10.0.0.0/8.  Text has been updated to make this more obvious.

16. unreachable address

Thomas: I also made a comment on "Unreachable Address” - I am glad I did, because I apparently had a different understanding than what was intended. I now see that an Unreachable Address by definition is an address listed in a RERR message, and not the same as an address to which no route has yet  been discovered? If yes, then please use a different term, such as FormerlyReachableAddress” or something of the sort?

AODVv2: "Formerly reachable" is inaccurate... we send a RERR if another router forwards a packet via us, and we dont have a route, not just when we lose a route. We might never have had a route, or might never have had a valid route, so the address may not have been "formerly reachable". Also, I think "FormerlyReachableAddress" is a really ugly term. Unreachable means "we don’t have a route and we aren’t going to request one" or "we lost this route" (depending on why the RERR is being sent). It doesn’t mean "we didn’t request one yet", and it would be wrong to class an address as unreachable because we hadn’t requested a route for it yet, that is, assuming it’s configured as a router client.

If a better term is suggested we could consider changing but at the moment we have kept “Unreachable Address”.


17. Applicability - multiple interfaces same address, 6621 again

Thomas: Applicability statement: First, I would like to recognize the efforts made to improve this since last review. Thanks
Second, the document states: "AODVv2 supports routers with multiple interfaces, as long as each interface configured for AODVv2 has a unicast IP address.  A router may use the same IP address on multiple interfaces.  Address assignment procedures are out of scope for AODVv2.”
Is that true? Granted, I have not worked this through in detail, but I can present a counter-example: the use of RFC6621 means that there certainly are some constraints that must be respected least various flooding optimizations may not work.
Secondly, if the multiple-interfaces-with-same-address are on the same L2, and this is what I have not worked through, are there any situations that will not work?
The immediately previous version of this specification read:
"AODVv2 supports routers with multiple interfaces, as long as each interface configured for AODVv2 has its own unicast routable IP address"
So what changed that means that each interface no longer needs its *own* unicast address?

AODVv2: Well, based on previous questions on this, we talked it through and decided there shouldn’t be an issue if different interfaces of a router used the same IP address. Note that we changed AODVv2 so that there is one sequence number per router. No longer can a router use different sequence numbers on different interfaces. If an RREQ went out of two interfaces using the same address, we worked it through and decided the request would be processed correctly.
Also, text referring to RFC 6621 has been removed.

18. Applicability and appendix - multihoming

Thomas: I pointed out to the Applicability Statement:
I think that appendix B needs to be removed. Essentially, it makes claims that it is possible to do multi-homing — but neither specifies how it is done, nor gives pointers to documents that justify the claim.
AODVv2 does not support multi-homing — that’s clear, and it is fine that it is called out here. Thank you for that.
Now, with that being said, I am torn between being satisfied that it is called out on one hand, and wanting to have “multi homing” on the other hand. RFC7181 supports multi-homing, FWIW.
I believe that this also would merit some explicit discussion by the WG, in order to understand if this design decision is acceptable?
I see that Appendix B still is in the document, and I do not recall having seen this discussed on the mailing list. Simply removing the reference from the Applicability Statement to Appendix B does not address the issue that I raised in my previous review.

AODVv2: Appendix has been removed and may appear in a future informational document.

19. interfaces list - use of “SHOULD”

Thomas: To 4.1, I made the following comment:
"Is this a should, or a SHOULD? If the latter, should it be a MUST?
In general, there are a lot of such “maybe normative language” through the document, and I would much like to see an editorial pass — essentially all may/should/ must and friends carefully evaluated as if they should become 2119-terms, and ... more importantly (it has been called out before, fwiw) quite a bit of should/SHOULD which ought to be transformed into MUST.
Generally, aiming for a very a low number of SHOULD is a good design metric for a document”
Aside from the general comment on 2119-language, why is this a SHOULD?

AODVv2: We changed this instance to a MUST and will be checking for “maybe normative language”.


20. Router client - Local Attached Network Set

Thomas: To 4.2, I made the following comment:
As indicated earlier, I believe that the term “Router Client” is ill chosen. I believe that it is more appropriately an “Attached Network Set” since — as indicated previously — the term “Router Client” is ambiguous. I am pleased to see, though, that this “Router Client List” in reality is an “Attached Network Set” and so that change should be (relatively) easy.
The above comment still is applicable to this revision,

AODVv2: See 5,9,12,13.


21. Subnet
Thomas: To 4.2, I made the following comment:
Also, I recommend to not say “subnet” — how about rephrasing to “If a prefix is included in the attached network set of an AODVv2 router, then that AODVv2 router MUST provide connectivity for, i.e. answer to RREQs and maintain sequence numbers for, all addresses from within that prefix.”
I note that while the term has been removed from section 4, there’re 4 lingering instances of this term in the document, that could easily be removed.

AODVv2: All mentions of "subnet" were in the ENAR section. They have been updated to say network, or "networks attached to the routers"


22. relocating router client

Thomas: I Also made a comment about Appendix B in my previous review, which is referenced here. That comment still applies.

AODVv2: Moved into main draft.


23. Neighbor Monitoring

Thomas: To Section 4.3, I noticed:
Does section 6.2 describe how to monitor an established adjacency only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, I see
“Not every pair of neighboring routers will necessarily form an adjacency,” — so it likely isn’t 6.2 that tells me how to maintain this table?
In short, “A neighbour table MUST be maintained” — where can I find information on how to do this?
Section 6.2 states:
“The default approach for monitoring bidirectional connectivity to the next hop toward OrigAddr is to request acknowledgement of Route Reply messages.”
That certainly will tell me if a link over which an RREP is sent is bi-directional, but will not maintain a “neighbor table”.
So how is this done? Or, is the “Neighbor Table” not supposed to contain the complete set of neighbours? What information “...MUST be maintained” then, in this table?
This is very unclear, I would not know how to implement a mechanism that populates this “Neighbor Table” with the needed information here.
I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this comment has not been addressed

AODVv2: A new section was added to show how to update the neighbour table. There have also been updates to this entire section since version 12.

24.     pseudo-code

Thomas:
I am throwing this in here, as I am sure that I commented on that in the previous review, but I do not see that addressed: is Appendix C normative, or not? It represents “ a second specification of the protocol, in a different language” from the main part of the specification. I have not walked through and made 200% sure that both are perfectly aligned and that there are no ambiguities, but having two different specifications of a protocol is a recipe for disaster.  Please either make 2000% sure that they are specifying the same thing without ambiguities, or remove one.

AODVv2: Removed - maybe to include in an informational document in future.


25. seqnum as 16 bit unsigned integer

Thomas: To section 4.4, I wrote:
"would like to nit-pick that: the router can maintain this sequence number in whatever format it pleases — but, when it includes it in control messages, it must be representable in a specified format, respecting certain rules.”
I see that there were no changes following this comment.

AODVv2: Why store it as anything other than what it needs to be when it goes into a message? However, we now state "MUST report its own sequence number as a 16 bit....whenever it creates a RREQ or RREP message".


26. multiple seqnums?

Thomas:
To section 4.4 I asked for clarification as to if sequence numbers were per interface or per router, as the specification was unclear on that. The words has changed, but it still is unclear: how many sequence numbers does a router maintain? One? One per interface?

AODVv2: We tried to start discussion on that point, and in the meantime we reverted to having 1 seqnum per router. We think the text is clear... we refer to "the routers sequence number" or "its sequence number" - never hinting that there could be multiple seqnums per router (as far as I'm aware).


27. sets/lists/tables

Thomas:
In my previous review, I expressed that it would be preferential to use “a notation of Sets” rather than tables. I see that this has not changed.

AODVv2: You preferred sets rather than lists in your previous review...and explained our reasoning for this in responses to the MANET list, and we did not receive further comments.


28. use of “node”

Thomas:
I made a comment on node and address, let me pick this up again. The following:
RteMsg.OrigAddr
An IP address of the node which requires the route, i.e., the source address of the IP packet triggering the route request.
would be more compact and clear if getting rid of the term “node” and said:
RteMsg.OrigAddr
The source address of the IP packet triggering the route request.

AODVv2: Change made as suggested.

29. route table/rib/routing set

Thomas: To section 4.6, and I (and others) have commented on this before:
All AODVv2 routers MUST maintain a route table.  The route table entry is a conceptual data structure.  Implementations MAY use any internal representation but MUST contain the following information:
In order to avoid confusion, rename this to “Routing Information Base” or “Routing Set” — a Routing Table is an operating system construct, whereon operations directly influence packet forwarding. What you are defining here is a RIB/an RS.

AODVv2: Done in version 13.


30. rreq for prefix, use of “ip address” and “address"

Thomas:
The confusion that I pointed out in my previous review on “IP address” and “Address” being used a bit haphazardly persists, fwiw. It makes me think, can a router send an RREQ for a prefix?

AODVv2: See also #15. RREQ_Gen can include the prefix associated with OrigAddr by adding a prefix length to the message, the prefix length associated with the router client entry corresponding to OrigAddr. So all routers which receive it can learn a route to the prefix on which OrigAddr resides. But for TargAddr... the RREQ only has one target IP address - the destination IP address of the packet requiring the route... so what prefix length would it use? The RREQ requests a route to a single IP address. However, when the RREP is created, RREP_Gen should include the prefix length associated with the router client entry for TargAddr. So all routers which receive this RREP learn a route to the prefix TargAddr is part of (if the router client entry is configured with a prefix length). The text has been updated to make this more obvious.


31. next hop ip address wording

Thomas:
I also called this out in my previous review as incorrect, and despite wordsmithing it still is:

        Route.NextHop
              The source IP address of the message advertising the route to
              Route.Address, i.e. an IP address of the AODVv2 router used for
              the next hop on the path toward Route.Address.

If that “message” is an RFC5444 entity, then it does to have a “source IP Address” — the encapsulating IP datagram containing the packet containing the message does. And the message MAY have an Originator Address

AODVv2: Updated to say “the source IP address of the IP packet containing the message advertising...”



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



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

--------------010904070009090401000809--