From nobody Mon Aug 1 08:13:22 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC59A12DC2D; Mon, 1 Aug 2016 08:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org 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 lToblAEbTigB; Mon, 1 Aug 2016 08:13:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1465E12DC3C; Mon, 1 Aug 2016 08:13:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F0CD5240E6E; Mon, 1 Aug 2016 08:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1470064399; bh=M33Y3mfrkc6WbEmZUfZYLMeWk/+1vF7RWN+qRVc5II8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fgjwuBLGKQU9CdW1GwqvYIrzVpwkZMKXf3TK2QzpwIvBHXGQjEw4e4EXpPf/D0UwL BWwv1OxrDLiotwQw08oe9i6CnQ/oOW11C4ABtcu8mGRfb3iAdw2H7abZ8W5EhhTMJH oGa/dVXfn1tUswKn0VHQqvD0vg4K9pcZcOvRAXos= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [129.104.75.146] (unknown [129.104.75.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6E7A0240A0A; Mon, 1 Aug 2016 08:13:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8AB57D52-7FCF-4918-AEA4-ED8AB3F281F1 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (13F69) In-Reply-To: <078BE592-5D84-41C3-B3D4-E7DD28F1DE6E@thomasclausen.org> Date: Mon, 1 Aug 2016 17:13:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7F8E05AD-4907-4CA1-AFAC-F28BABEB5575@thomasclausen.org> References: <078BE592-5D84-41C3-B3D4-E7DD28F1DE6E@thomasclausen.org> To: manet@ietf.org Archived-At: Cc: manet-ads@ietf.org Subject: Re: [manet] Last call on OLSRv2 Sec Threats still open X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:13:21 -0000 --Apple-Mail-8AB57D52-7FCF-4918-AEA4-ED8AB3F281F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable According to my calendar, August 1 has come around, also, now. This has been hanging around in "WG Consensus: Waiting for Write-Up: Informa= tional" status for almost two^Wfour weeks... please consider this a friendly= nag. Thomas -- Thomas Heide Clausen =E2=80=A2 @thclausen =E2=80=A2 thomasclaus= en.org=20 www.arkko.com/tools/allstats/thomasheideclausen.html > On 08 Jul 2016, at 09:37, Thomas Heide Clausen wr= ote: >=20 > According to my calendar, July 1 has come and past, now. >=20 > Thomas >=20 >> On 22 Jun 2016, at 15:56, Justin Dean wrote: >>=20 >> There was a mixup. Last Call for OLSRv2-Sec-Threats document is still op= en and will end on July 1st. I'll take this opportunity to again remind peo= ple to please read and comment to the list. >>=20 >> Justin >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-8AB57D52-7FCF-4918-AEA4-ED8AB3F281F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
According= to my calendar, August 1 has come around, also, now.

This has been hanging aro= und in "WG C= onsensus: Waiting for Write-Up: Informational" status for almost two^Wfour weeks... plea= se consider this a friendly nag.

Thomas<= /div>

According t= o my calendar, July 1 has come and past, now.

Thomas

On 22 J= un 2016, at 15:56, Justin Dean <b= ebemaster@gmail.com> wrote:

There w= as a mixup.  Last Call for OLSRv2-Sec-Threats document is still open an= d will end on July 1st.  I'll take this opportunity to again remind peo= ple to please read and comment to the list.

Justin
___________= ____________________________________
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
= --Apple-Mail-8AB57D52-7FCF-4918-AEA4-ED8AB3F281F1-- From nobody Thu Aug 4 05:52:42 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7247812D512 for ; Thu, 4 Aug 2016 05:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 dlodAnNPqDc0 for ; Thu, 4 Aug 2016 05:52:39 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1D79412D1EA for ; Thu, 4 Aug 2016 05:52:38 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u74CnRHY038467 for ; Thu, 4 Aug 2016 08:49:27 -0400 From: "Wiggins, David - 0665 - MITLL" To: manet IETF Thread-Topic: DLEP IP addr redundant add/drop question Thread-Index: AQHR7k8TH40MhBZCSkOES6BxGdvXag== Date: Thu, 4 Aug 2016 12:52:37 +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_3553145555_9560428" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_09:, , 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-1604210000 definitions=main-1608040140 Archived-At: Subject: [manet] DLEP IP addr redundant add/drop question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 12:52:41 -0000 --B_3553145555_9560428 Content-type: multipart/alternative; boundary="B_3553145555_9547351" --B_3553145555_9547351 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit When an IPv4/6 Address or Attached Subnet data item appears with Flags=Add, but the given address has already been added, should it be ignored, or is that an error? Similarly, if an IPv4/6 Address or Attached Subnet data item appears with Flags=Drop, but the given address has never been added (or has previously been dropped), should it be ignored, or is that an error? Our implementation currently treats these as errors, but this isn't supported by the DLEP draft. It would be somewhat simpler for us to treat these cases as no-ops, not errors. I think either interpretation works, but whatever the answer, I suggest that the intended handling be made explicit in the draft. Possible wording added to the description of the Flags field of these data items: "If it is a new address, but the address already exists on the destination or peer, the data item is ignored. If it is an address withdrawal, but the address does not exist on the destination or peer, the data item is ignored." David --B_3553145555_9547351 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
When an IPv4/6 Address or Att= ached Subnet data item appears with Flags=3DAdd, but the  given address h= as already been added, should it be ignored, or is that an error?
=
Similarly, if an IPv4/6 Address or Attached Subnet data item = appears with Flags=3DDrop, but the  given address has never been added (o= r has previously been dropped), should it be ignored, or is that an error?

Our implementation currently treats these as errors,= but this isn't supported by the DLEP draft.   It would be somewhat sim= pler for us to treat these cases as no-ops, not errors.  I think either= interpretation works, but whatever the answer, I suggest that the intended = handling be made explicit in the draft.  Possible wording added to the = description of the Flags field of these data items:

"If it is a new address, but the address already exists on the destination = or peer, the data item is ignored.  If it is an address withdrawal, but= the address does not exist on the destination or peer, the data item is ign= ored."

David

--B_3553145555_9547351-- --B_3553145555_9560428 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 MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFDskaUHm3YgWAWLv yD+Nd9dBkeYbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDgwNDEyNTIzNVowDQYJKoZIhvcNAQEBBQAEggEAVJFHT2sV9Ucy542GyPGJnxy5cvPXhg5L 885cH20Hdb9e/tCbHscLgwxAkAgUaUasdmmiSC6QRvtzNsfyabWZQaowF9uDmWo1x49K5/Wv SUXC04Qnwa2OFbSqLfo+P6uQgZ/EHa1HZ8dgeW4hidomHFmokcvzTJ2Rh4LsfcLpxyZDgZvr /2bTCywnEsCMNaobqBk3L4yfm291sulI6N2rH/whyu6lrvoM1siB87HUbEPUpSDMifEmglOi /p5+LFh30BjtPWaBiUK5zv64l6lS0bueXRJe2FsLZ4XBz/lUgfQltn0+eST9JhO5GwfOGGO7 P0ebLcszHmbOHUfdIR2/cw== --B_3553145555_9560428-- From nobody Thu Aug 4 06:04:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03A512B04D for ; Thu, 4 Aug 2016 06:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 24zHu2Akgxi0 for ; Thu, 4 Aug 2016 06:04:05 -0700 (PDT) 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 8124F12D18F for ; Thu, 4 Aug 2016 06:04:05 -0700 (PDT) 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; Thu, 4 Aug 2016 14:03:33 +0100 From: Rick Taylor To: "David.Wiggins@ll.mit.edu" , "manet@ietf.org" Thread-Topic: [manet] DLEP IP addr redundant add/drop question Thread-Index: AQHR7lCa/ZgjgVkXmEqx2XULfHc29g== Date: Thu, 4 Aug 2016 13:01:37 +0000 Message-ID: <1470315697.4434.13.camel@tropicalstormsoftware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP IP addr redundant add/drop question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:04:08 -0000 SGkgRGF2aWQsDQoNClRoYXQncyBhIHZlcnkgZ29vZCBwb2ludC4gwqBJbiBhbGwgbXkgaW1wbGVt ZW50YXRpb25zIEkgaWdub3JlIGlmIGENCmR1cGxpY2F0ZSBpcyBhZGRlZCBvciBhbiB1bmtub3du IGlzIHJlbW92ZWQsIGJ1dCB5b3UgYXJlIHJpZ2h0IHRoYXQgaXQNCmlzIHVuY2xlYXIgaW4gdGhl IGRvYyAtIGdvb2QgY2F0Y2ghDQoNClN0YW4gYW5kL29yIEkgd2lsbCBoYXZlIHRvIHVwZGF0ZSwg YnV0IEkgZXhwZWN0IHRoZSAnaWdub3JlJyBiZWhhdmlvdXINCnJhdGhlciB0aGFuICdlcnJvcicg d2lsbCBiZSB0aGUgd2F5IGl0IGdldHMgd3JpdHRlbiB1cC4NCg0KQ2hlZXJzLA0KDQpSaWNrDQoN Ck9uIFRodSwgMjAxNi0wOC0wNCBhdCAxMjo1MiArMDAwMCwgV2lnZ2lucywgRGF2aWQgLSAwNjY1 IC0gTUlUTEwgd3JvdGU6DQo+IFdoZW4gYW4gSVB2NC82IEFkZHJlc3Mgb3IgQXR0YWNoZWQgU3Vi bmV0IGRhdGEgaXRlbSBhcHBlYXJzIHdpdGgNCj4gRmxhZ3M9QWRkLCBidXQgdGhlIMKgZ2l2ZW4g YWRkcmVzcyBoYXMgYWxyZWFkeSBiZWVuIGFkZGVkLCBzaG91bGQgaXQNCj4gYmUgaWdub3JlZCwg b3IgaXMgdGhhdCBhbiBlcnJvcj8NCj4gDQo+IFNpbWlsYXJseSwgaWYgYW4gSVB2NC82IEFkZHJl c3Mgb3IgQXR0YWNoZWQgU3VibmV0IGRhdGEgaXRlbSBhcHBlYXJzDQo+IHdpdGggRmxhZ3M9RHJv cCwgYnV0IHRoZSDCoGdpdmVuIGFkZHJlc3MgaGFzIG5ldmVyIGJlZW4gYWRkZWQgKG9yIGhhcw0K PiBwcmV2aW91c2x5IGJlZW4gZHJvcHBlZCksIHNob3VsZCBpdCBiZSBpZ25vcmVkLCBvciBpcyB0 aGF0IGFuIGVycm9yPw0KPiANCj4gT3VyIGltcGxlbWVudGF0aW9uIGN1cnJlbnRseSB0cmVhdHMg dGhlc2UgYXMgZXJyb3JzLCBidXQgdGhpcyBpc24ndA0KPiBzdXBwb3J0ZWQgYnkgdGhlIERMRVAg ZHJhZnQuIMKgIEl0IHdvdWxkIGJlIHNvbWV3aGF0IHNpbXBsZXIgZm9yIHVzIHRvDQo+IHRyZWF0 IHRoZXNlIGNhc2VzIGFzIG5vLW9wcywgbm90IGVycm9ycy4gwqBJIHRoaW5rIGVpdGhlcg0KPiBp bnRlcnByZXRhdGlvbiB3b3JrcywgYnV0IHdoYXRldmVyIHRoZSBhbnN3ZXIsIEkgc3VnZ2VzdCB0 aGF0IHRoZQ0KPiBpbnRlbmRlZCBoYW5kbGluZyBiZSBtYWRlIGV4cGxpY2l0IGluIHRoZSBkcmFm dC4gwqBQb3NzaWJsZSB3b3JkaW5nDQo+IGFkZGVkIHRvIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg RmxhZ3MgZmllbGQgb2YgdGhlc2UgZGF0YSBpdGVtczoNCj4gDQo+ICJJZiBpdCBpcyBhIG5ldyBh ZGRyZXNzLCBidXQgdGhlIGFkZHJlc3MgYWxyZWFkeSBleGlzdHMgb24gdGhlDQo+IGRlc3RpbmF0 aW9uIG9yIHBlZXIsIHRoZSBkYXRhIGl0ZW0gaXMgaWdub3JlZC4gwqBJZiBpdCBpcyBhbiBhZGRy ZXNzDQo+IHdpdGhkcmF3YWwsIGJ1dCB0aGUgYWRkcmVzcyBkb2VzIG5vdCBleGlzdCBvbiB0aGUg ZGVzdGluYXRpb24gb3INCj4gcGVlciwgdGhlIGRhdGEgaXRlbSBpcyBpZ25vcmVkLiINCj4gDQo+ IERhdmlkDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA== From nobody Thu Aug 4 06:06:53 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB212D53D for ; Thu, 4 Aug 2016 06:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 js1mUhFGnTGB for ; Thu, 4 Aug 2016 06:06:50 -0700 (PDT) Received: from smtp2.idirect.net (smtp2.idirect.net [198.180.159.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 2C7E212D95C for ; Thu, 4 Aug 2016 06:06:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,470,1464667200"; d="scan'208";a="1559063" IronPort-PHdr: =?us-ascii?q?9a23=3AvoQ0qxD+uInQWr2U8YFhUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP/8osbcNUDSrc9gkEXOFd2CrakV06yG6eu9ACQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09?= =?us-ascii?q?fr2zQd+KyZTtnL3rs7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJce?= =?us-ascii?q?kFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dg3szgtlH/?= =?us-ascii?q?RBqL4WFUBn8XmRlgHxLC9BDxV5Pqrizgs/F61jWFNNf7C7szXGLmp+1HQQHphG?= =?us-ascii?q?E4NjE28WfMosh0yqdavFSsqwE1i9r4aZ+UOLxBf6zSfNUBbW5FGMNQS2pMDp7q?= =?us-ascii?q?K8NFCuMHMPpwroThqR0JtxT0TV2pDeXi1hdJi2P4m6og3LJyPxvB2VlqJdsStH?= =?us-ascii?q?XaopG9D7sbV+S43eOAmS7ZZu9S2DnzwInEcwosqu3KW79sJ5mCgXIzHh/I2w3D?= =?us-ascii?q?4bfuOCmYg6FU6zCW?= X-IPAS-Result: =?us-ascii?q?A2D9AACjPKNX/8r6+gpdDgsBAQEBAYN9fAeNJqtugXQJGQu?= =?us-ascii?q?FeQIcgW4UAQEBAQEBAQGBA4IyBAETAYITAQEBAQMBAQEgEToXBAIBCBEEAQEBA?= =?us-ascii?q?gIjAwICAiULFAEICAIEARIIiDeuaY9yAQEBAQEBAQEBAQEBAQEBAQEBARkFgQG?= =?us-ascii?q?FKoRMgTkBhgeCWgWZLgYBjnqBco1VhmSFTYN3HoJIHIERO24Bhk1/AQEB?= From: "Ratliff, Stanley" To: Rick Taylor , "David.Wiggins@ll.mit.edu" , "manet@ietf.org" Thread-Topic: [manet] DLEP IP addr redundant add/drop question Thread-Index: AQHR7k8TH40MhBZCSkOES6BxGdvXaqA5BxuA//+992A= Date: Thu, 4 Aug 2016 13:06:44 +0000 Message-ID: <90244ec4207545e2a10e75f99cf2142b@VAUSDITCHM2.idirect.net> References: <1470315697.4434.13.camel@tropicalstormsoftware.com> In-Reply-To: <1470315697.4434.13.camel@tropicalstormsoftware.com> 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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [manet] DLEP IP addr redundant add/drop question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:06:52 -0000 RGF2aWQsIA0KDQpEaXR0byB3aGF0IFJpY2sgc2FpZC4gV2UgcHV0IHRoZSBkcmFmdCBiYWNrIGlu dG8gQUQgcmV2aWV3IHdpdGggdGhlIC0yNCB2ZXJzaW9uLCBzbyBJJ20gbm90IHN1cmUgYXMgdG8g dGhlIGV4YWN0IHRpbWluZyBvZiB0aGUgY2hhbmdlIChJIGNhbid0IGdpdmUgeW91IGFuIEVUQSku IEJ1dCB3ZSdsbCB3b3JrIHRoYXQgb3V0LiANCg0KUmVnYXJkcywNClN0YW4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNrIFRheWxvcg0KPiBTZW50OiBUaHVyc2RheSwgQXVn dXN0IDA0LCAyMDE2IDk6MDIgQU0NCj4gVG86IERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTsgbWFu ZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBJUCBhZGRyIHJlZHVuZGFu dCBhZGQvZHJvcCBxdWVzdGlvbg0KPiANCj4gSGkgRGF2aWQsDQo+IA0KPiBUaGF0J3MgYSB2ZXJ5 IGdvb2QgcG9pbnQuIMKgSW4gYWxsIG15IGltcGxlbWVudGF0aW9ucyBJIGlnbm9yZSBpZiBhIGR1 cGxpY2F0ZSBpcw0KPiBhZGRlZCBvciBhbiB1bmtub3duIGlzIHJlbW92ZWQsIGJ1dCB5b3UgYXJl IHJpZ2h0IHRoYXQgaXQgaXMgdW5jbGVhciBpbiB0aGUNCj4gZG9jIC0gZ29vZCBjYXRjaCENCj4g DQo+IFN0YW4gYW5kL29yIEkgd2lsbCBoYXZlIHRvIHVwZGF0ZSwgYnV0IEkgZXhwZWN0IHRoZSAn aWdub3JlJyBiZWhhdmlvdXIgcmF0aGVyDQo+IHRoYW4gJ2Vycm9yJyB3aWxsIGJlIHRoZSB3YXkg aXQgZ2V0cyB3cml0dGVuIHVwLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gUmljaw0KPiANCj4gT24g VGh1LCAyMDE2LTA4LTA0IGF0IDEyOjUyICswMDAwLCBXaWdnaW5zLCBEYXZpZCAtIDA2NjUgLSBN SVRMTCB3cm90ZToNCj4gPiBXaGVuIGFuIElQdjQvNiBBZGRyZXNzIG9yIEF0dGFjaGVkIFN1Ym5l dCBkYXRhIGl0ZW0gYXBwZWFycyB3aXRoDQo+ID4gRmxhZ3M9QWRkLCBidXQgdGhlIMKgZ2l2ZW4g YWRkcmVzcyBoYXMgYWxyZWFkeSBiZWVuIGFkZGVkLCBzaG91bGQgaXQgYmUNCj4gPiBpZ25vcmVk LCBvciBpcyB0aGF0IGFuIGVycm9yPw0KPiA+DQo+ID4gU2ltaWxhcmx5LCBpZiBhbiBJUHY0LzYg QWRkcmVzcyBvciBBdHRhY2hlZCBTdWJuZXQgZGF0YSBpdGVtIGFwcGVhcnMNCj4gPiB3aXRoIEZs YWdzPURyb3AsIGJ1dCB0aGUgwqBnaXZlbiBhZGRyZXNzIGhhcyBuZXZlciBiZWVuIGFkZGVkIChv ciBoYXMNCj4gPiBwcmV2aW91c2x5IGJlZW4gZHJvcHBlZCksIHNob3VsZCBpdCBiZSBpZ25vcmVk LCBvciBpcyB0aGF0IGFuIGVycm9yPw0KPiA+DQo+ID4gT3VyIGltcGxlbWVudGF0aW9uIGN1cnJl bnRseSB0cmVhdHMgdGhlc2UgYXMgZXJyb3JzLCBidXQgdGhpcyBpc24ndA0KPiA+IHN1cHBvcnRl ZCBieSB0aGUgRExFUCBkcmFmdC4gwqAgSXQgd291bGQgYmUgc29tZXdoYXQgc2ltcGxlciBmb3Ig dXMgdG8NCj4gPiB0cmVhdCB0aGVzZSBjYXNlcyBhcyBuby1vcHMsIG5vdCBlcnJvcnMuIMKgSSB0 aGluayBlaXRoZXINCj4gPiBpbnRlcnByZXRhdGlvbiB3b3JrcywgYnV0IHdoYXRldmVyIHRoZSBh bnN3ZXIsIEkgc3VnZ2VzdCB0aGF0IHRoZQ0KPiA+IGludGVuZGVkIGhhbmRsaW5nIGJlIG1hZGUg ZXhwbGljaXQgaW4gdGhlIGRyYWZ0LiDCoFBvc3NpYmxlIHdvcmRpbmcNCj4gPiBhZGRlZCB0byB0 aGUgZGVzY3JpcHRpb24gb2YgdGhlIEZsYWdzIGZpZWxkIG9mIHRoZXNlIGRhdGEgaXRlbXM6DQo+ ID4NCj4gPiAiSWYgaXQgaXMgYSBuZXcgYWRkcmVzcywgYnV0IHRoZSBhZGRyZXNzIGFscmVhZHkg ZXhpc3RzIG9uIHRoZQ0KPiA+IGRlc3RpbmF0aW9uIG9yIHBlZXIsIHRoZSBkYXRhIGl0ZW0gaXMg aWdub3JlZC4gwqBJZiBpdCBpcyBhbiBhZGRyZXNzDQo+ID4gd2l0aGRyYXdhbCwgYnV0IHRoZSBh ZGRyZXNzIGRvZXMgbm90IGV4aXN0IG9uIHRoZSBkZXN0aW5hdGlvbiBvciBwZWVyLA0KPiA+IHRo ZSBkYXRhIGl0ZW0gaXMgaWdub3JlZC4iDQo+ID4NCj4gPiBEYXZpZA0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtYW5ldCBtYWls aW5nIGxpc3QNCj4gPiBtYW5ldEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUaGlzIGVsZWN0cm9u aWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMKaW5m b3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRh cnkKYW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsCm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3Bv bnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50 LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwg YW5kIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9y CmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVj ZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRl bHkgbm90aWZ5IHRoZSBzZW5kZXIuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCg== From nobody Thu Aug 4 06:15:50 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F015F12D0BF for ; Thu, 4 Aug 2016 06:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 AKjvXLEKaCPl for ; Thu, 4 Aug 2016 06:15:46 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2F12D0AC for ; Thu, 4 Aug 2016 06:15:46 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u74DCXZB004758; Thu, 4 Aug 2016 09:12:34 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , Rick Taylor , "manet@ietf.org" Thread-Topic: [manet] DLEP IP addr redundant add/drop question Thread-Index: AQHR7k8TH40MhBZCSkOES6BxGdvXaqA5BxuA//+992CAAALqAA== Date: Thu, 4 Aug 2016 13:15:43 +0000 Message-ID: References: <1470315697.4434.13.camel@tropicalstormsoftware.com> <90244ec4207545e2a10e75f99cf2142b@VAUSDITCHM2.idirect.net> In-Reply-To: <90244ec4207545e2a10e75f99cf2142b@VAUSDITCHM2.idirect.net> 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_3553146942_9613662" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_09:, , 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-1604210000 definitions=main-1608040145 Archived-At: Subject: Re: [manet] DLEP IP addr redundant add/drop question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:15:49 -0000 --B_3553146942_9613662 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Stan and Rick, Sounds good to me. Thanks. David On 8/4/16, 9:06 AM, "Ratliff, Stanley" wrote: >David, > >Ditto what Rick said. We put the draft back into AD review with the -24 >version, so I'm not sure as to the exact timing of the change (I can't >give you an ETA). But we'll work that out. > >Regards, >Stan > >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor >> Sent: Thursday, August 04, 2016 9:02 AM >> To: David.Wiggins@ll.mit.edu; manet@ietf.org >> Subject: Re: [manet] DLEP IP addr redundant add/drop question >> >> Hi David, >> >> That's a very good point. In all my implementations I ignore if a >>duplicate is >> added or an unknown is removed, but you are right that it is unclear in >>the >> doc - good catch! >> >> Stan and/or I will have to update, but I expect the 'ignore' behaviour >>rather >> than 'error' will be the way it gets written up. >> >> Cheers, >> >> Rick >> >> On Thu, 2016-08-04 at 12:52 +0000, Wiggins, David - 0665 - MITLL wrote: >> > When an IPv4/6 Address or Attached Subnet data item appears with >> > Flags=Add, but the given address has already been added, should it be >> > ignored, or is that an error? >> > >> > Similarly, if an IPv4/6 Address or Attached Subnet data item appears >> > with Flags=Drop, but the given address has never been added (or has >> > previously been dropped), should it be ignored, or is that an error? >> > >> > Our implementation currently treats these as errors, but this isn't >> > supported by the DLEP draft. It would be somewhat simpler for us to >> > treat these cases as no-ops, not errors. I think either >> > interpretation works, but whatever the answer, I suggest that the >> > intended handling be made explicit in the draft. Possible wording >> > added to the description of the Flags field of these data items: >> > >> > "If it is a new address, but the address already exists on the >> > destination or peer, the data item is ignored. If it is an address >> > withdrawal, but the address does not exist on the destination or peer, >> > the data item is ignored." >> > >> > David >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > >_____________________________________________________ >This 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. >_____________________________________________________ --B_3553146942_9613662 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 MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFCZjXnVTNYwwz8n5 rFyWeZ6bIMbBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDgwNDEzMTU0MlowDQYJKoZIhvcNAQEBBQAEggEABcxf/Md+R3RjJV9CR9TWFHf1dx800ijQ 1vtg3fIe3LJIE519ekDFFpi/w3GLEwAXvFxys7ruL7Ekbd/1m06kI0W3I5YXlenhXc4zzvd8 QOZ49pneBgNGn8mGSJ6fMxtbVyhIauz7HHVSQZ0lxTtAbElAPVZvKBSsctN5HCgQ/k9Lrn4v XLvAA/nfVRsO7sFFtH9bifm0nf+8zfmibrVh7ImTQBdg1bP34UKXk29kM4F3MxdPTqRVXSdQ 4y3akpuCH9KyH5MZpUOIjmAccg1ee3+kd/+r3BQC5Y6kbwkzubRuOvFmRmNqlBSQxIOsxhTQ dcVkGvCZOsT75RIaNNH2GQ== --B_3553146942_9613662-- From nobody Fri Aug 5 06:06:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0426E12D0B1 for ; Fri, 5 Aug 2016 06:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TV_1QbwHDPWq for ; Fri, 5 Aug 2016 06:06:08 -0700 (PDT) Received: from cse.ust.hk (cssvr7.cse.ust.hk [143.89.41.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C153C12D191 for ; Fri, 5 Aug 2016 06:06:07 -0700 (PDT) Received: from imail.cse.ust.hk (cssvr7.cse.ust.hk [143.89.41.157]) by cse.ust.hk (8.15.2/8.12.5) with ESMTP id u75D630G029405 for ; Fri, 5 Aug 2016 21:06:04 +0800 Received: from 131.111.5.142 (SquirrelMail authenticated user dcab) by imail.cse.ust.hk with HTTP; Fri, 5 Aug 2016 21:06:04 +0800 Message-ID: Date: Fri, 5 Aug 2016 21:06:04 +0800 From: "CHATZOPOULOS Dimitrios" To: manet@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Env-From: dcab Archived-At: Subject: [manet] [Deadline extension] SIMPLEX'16 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 13:06:10 -0000 * Apologies for Cross-Posting * The (firm) submission deadline of SIMPLEX'16 has been extended to August 9, 2016, 23:59 (Anywhere on Earth) The 8th Annual Workshop on Simplifying Complex Networks for Practitioners (SIMPLEX'16) November 8, 2016 Singapore In conjunction with IEEE ICNP 2016 http://simplex16.weebly.com/ Network science, sometimes also called "complex networks science", has recently attracted much attention from the scientific community, mainly due to the almost ubiquitous presence of complex networks in real-world systems. Examples of complex networks are found in living organisms, in engineering systems, as well as in social networks. Most of the real-world systems have the required degree of complexity to be called "complex systems". Complexity may have to do with the intricate dynamics of the interacting components, with the non-trivial properties of the underlying network topology, or with the sheer size of the system itself. Despite the numerous workshops and conferences related to network science, it is still a set of loosely interacting communities. Those communities would benefit from better interactions. Simplex aims at triggering different computer science communities (e.g. search, web and social media, communication networks, distributed systems) to propose research areas and topics that should be tackled from the network science perspective. We also seek contributions from network science that are relevant to solve practical computer networking and protocol problems. Two types of contributions are foreseen from prospective authors. The first type would consist of use-cases of theoretical tools and methods to solve practical problems. Such contributions should be as usable as possible by practitioners in the related field. The second type of contributions would come from practitioners who have identified a problem that may be solved by tools from network sciences. The point of such contributions is to make the network sciences community aware of the importance of a high-impact problem, and to suggest means by which the problem in networked systems may be solved by the network sciences community. Both contributions should stimulate interaction between theoreticians and practitioners, and also have high potential impact in either field. We encourage submissions to be cross-disciplinary. Topics for the workshop include, but are not limited to: - Data mining of large scale networks; - Application of complex network theory to the design of distributed and mobile systems; - Analysis of dynamic and time-varying networks; - Network robustness to failures and attacks; - Machine learning and network science; - Complex network theory applied to forwarding/routing problems; - Application of social network analysis to communication and computing system design; - Mobility and connectivity modeling; - Multiplier and multiplexing networks analysis; - Heterogeneous networks analysis and applications; - Network science and data & information retrieval; - Complex network theory and security applications; Authors are encouraged to submit full papers describing original, previously unpublished research, not currently under review by another conference or journal, addressing state-of-the-art research and development in all areas of network science. Papers must be submitted electronically in EasyChair (https://easychair.org/conferences/?conf=simplex2016). The length of papers must be no more than 6 pages, including tables and figures. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the corresponding author's e-mail and postal address. Each submission will receive at least three independent blind reviews from the TPC. At least one of the authors of every accepted paper must register and present their work at the workshop. The technical program committee will select one winner for the *Best Paper Award* and one winner for the *Best Paper Runner-up*. == Important Dates == Submission deadline: August 9, 2016, 23:59 (Anywhere on Earth) (Firm) Author notification: August 20, 2016 Camera­-ready due: August 30, 2016 Workshop date: November 8, 2016 == Workshop Organizers == Advisory Board Members: Dah Ming Chiu Chinese University of Hong Kong, Hong Kong Jon Crowcroft University of Cambridge, UK Zhi-Li Zhang University of Minnesota, USA General Co-chairs: Pan Hui Hong Kong University of Science and Technology, Hong Kong Nishanth Sastry Kings College London, UK TPC Co-chairs: Yang Chen Fudan University, China Aziz Mohaisen State University of New York at Buffalo, USA Publicity Co-chairs: Dimitris Chatzopoulos Hong Kong University of Science and Technology, Hong Kong Yu Xiao Aalto University, Finland TPC Members (tentative): Bogdan Carbunar Florida International University, USA Kwang-Il Goh Korea University, Korea Roberto Gonzalez NEC Laboratories Europe, Germany Bruno Gonçalves New York University, USA Hamed Haddadi Queen Mary, University of London, UK Ah Reum Kang State University of New York at Buffalo, USA Huy Kang Kim Korea University, Korea Nektarios Leontiadis Facebook, USA Yong Li Tsinghua University, China Zhenhua Li Tsinghua University, China Aniket Mahanti University of Auckland, New Zealand Mirco Musolesi University College London, UK Fragkiskos Papadopoulos Cyprus University of Technology, Cyprus Gareth Tyson Queen Mary, University of London, UK Andrew West Verisign Labs, USA Eiko Yoneki University of Cambridge, UK Web Chair: Yuan Xuan Fudan University, China From nobody Mon Aug 8 08:17:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719DE12D624; Mon, 8 Aug 2016 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 GNqciejhMm3h; Mon, 8 Aug 2016 08:17:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 51CF312D623; Mon, 8 Aug 2016 08:17:49 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u78FHmR8054911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 8 Aug 2016 10:17:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: General Area Review Team , "secdir@ietf.org" , "ietf@ietf.org" , manet@ietf.org, draft-ietf-manet-smc-sec-threats.all@ietf.org From: Robert Sparks Message-ID: Date: Mon, 8 Aug 2016 10:17:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:17:52 -0000 I am the assigned Gen-ART and secdir reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. The secdir does the same for the security area directors. Please treat these comments just like any other last call comments. For more information on Gen-Art, please see the FAQ at . For moe information on secdir, see the wiki at Document: draft-ietf-manet-smf-sec-threats-05 Reviewer: Robert Sparks Review Date: 8 Aug 2016 IETF LC End Date: 11 Aug 2016 IESG Telechat date: 18 Aug 2016 Summary: Ready for publication as an Informational RFC This draft provides a discussion of vulnerabilities in Simplified Multicast Forwarding (SMF), focusing on attacking the Duplicate Packet Detection and Relay Set Selection mechanisms. It positions itself as being useful information for those deploying SMF as currently defined. It does not propose mitigations, but does have a section that identifies potential future work that might. I have sent several editorial nits directly to the authors. From nobody Tue Aug 9 02:24:30 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A712D0DA; Tue, 9 Aug 2016 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org 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 FSTFLqoY-nkP; Tue, 9 Aug 2016 02:24:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 ED0E612D0AE; Tue, 9 Aug 2016 02:24:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B372D240E93; Tue, 9 Aug 2016 02:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1470734655; bh=aWK5riFpFYKJvpm7zzn5sWydYFSmVurbaMcmS9q1GtU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=k3A69lnNVA12SSWpuaDDsFlExDV7gvn+oyZjH9s44UOqCvHJu2nyFefbSBzTELosb QNKHz7arc0dxj5Ysjmidvx40l2DUCiytJGuvVWBenZtU1+ncrtR96MpwV1Z3eQjK0v q1AzUl+gSKWbRgAPiQOL3bPBs8ogYV8/WpRtrpW8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.44.183.161] (unknown [37.165.31.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A1D74240302; Tue, 9 Aug 2016 02:24:14 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPhone Mail (14A5322e) In-Reply-To: Date: Tue, 9 Aug 2016 11:24:10 +0200 Content-Transfer-Encoding: 7bit Message-Id: <13F5D40F-712E-4970-9CBF-B0E6A1A13F2D@thomasclausen.org> References: To: Robert Sparks Archived-At: Cc: General Area Review Team , manet@ietf.org, "ietf@ietf.org" , draft-ietf-manet-smc-sec-threats.all@ietf.org, "secdir@ietf.org" Subject: Re: [manet] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 09:24:17 -0000 --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Robert, all, Thank you for this review. Much appreciated. As I understand it, there are n= o major issues to address? If it is alright with you (& with our AD), We propose to fold the "nits" (as= you call them) that you found in with a couple of "nits" raised by Alvaro a= lready, and with whatever else the ongoing LC raises, and spin a revision ca= pturing it all when the LC is closed? Thanks again for your help, Thomas -- Thomas Heide Clausen =E2=80=A2 @thclausen =E2=80=A2 thomasclaus= en.org=20 www.arkko.com/tools/allstats/thomasheideclausen.html > On 8 Aug 2016, at 17:17, Robert Sparks wrote: >=20 > I am the assigned Gen-ART and secdir reviewer for this draft. The General A= rea > Review Team (Gen-ART) reviews all IETF documents being processed by the IE= SG > for the IETF Chair. The secdir does the same for the security area directo= rs. > Please treat these comments just like any other last call comments. >=20 > For more information on Gen-Art, please see the FAQ at > . >=20 > For moe information on secdir, see the wiki at > >=20 > Document: draft-ietf-manet-smf-sec-threats-05 > Reviewer: Robert Sparks > Review Date: 8 Aug 2016 > IETF LC End Date: 11 Aug 2016 > IESG Telechat date: 18 Aug 2016 >=20 > Summary: Ready for publication as an Informational RFC >=20 > This draft provides a discussion of vulnerabilities in Simplified Multicas= t > Forwarding (SMF), focusing on attacking the Duplicate Packet Detection and= > Relay Set Selection mechanisms. It positions itself as being useful inform= ation > for those deploying SMF as currently defined. It does not propose mitigat= ions, > but does have a section that identifies potential future work that might. >=20 > I have sent several editorial nits directly to the authors. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Robert, al= l,

Thank you for this review. Much apprecia= ted. As I understand it, there are no major issues to address?
<= div>
If it is a= lright with you (& with our AD), We propose to fold the "nits" (as you c= all them) that you found in with a couple of "nits" raised by Alvaro already= , and with whatever else the ongoing LC raises, and spin a revision capturin= g it all when the LC is closed?

Thanks again for your help,
=
Thomas


--
T= homas Heide Clausen  =E2=80=A2  @thclausen   =E2=80=A2 = = www.arkko.com/tools/allstats/thomasheideclausen.html

On 8 Aug 2016, at 17:17, Robert Sparks <rjsparks@nostrum.com> wrote:

I am the assigned Gen-ART and secdir reviewer for= this draft. The General Area
Review Team (Gen-ART) reviews a= ll IETF documents being processed by the IESG
for the IETF C= hair. The secdir does the same for the security area directors.
Please treat these comments just like any other last call comments.

For more information on Gen-Art, please see the= FAQ at
<https://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfa= q>.

For moe information on secdir, s= ee the wiki at
<https://trac.tools.ietf.org/area/sec/trac/wik= i/SecDirReview>

Document: draft-ietf= -manet-smf-sec-threats-05
Reviewer: Robert Sparks
= Review Date: 8 Aug 2016
IETF LC End Date: 11 Aug 2016<= /span>
IESG Telechat date: 18 Aug 2016

<= span>Summary: Ready for publication as an Informational RFC
=
This draft provides a discussion of vulnerabilities in Simp= lified Multicast
Forwarding (SMF), focusing on attacking the= Duplicate Packet Detection and
Relay Set Selection mechanis= ms. It positions itself as being useful information
for thos= e deploying SMF as currently defined.  It does not propose mitigations,=
but does have a section that identifies potential future wo= rk that might.

I have sent several editoria= l nits directly to the authors.

___________= ____________________________________
manet mailing list
manet@ietf.org
<= span>https://www.iet= f.org/mailman/listinfo/manet
= --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1-- From nobody Tue Aug 9 12:31:59 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0575812D5CB; Tue, 9 Aug 2016 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mQuF2v-1dOUO; Tue, 9 Aug 2016 12:31:55 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 4967012B060; Tue, 9 Aug 2016 12:31:55 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-ab-57aa30469afc Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 64.89.02568.6403AA75; Tue, 9 Aug 2016 21:34:30 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0301.000; Tue, 9 Aug 2016 15:26:45 -0400 From: Eric Gray To: "draft-ietf-manet-smf-sec-threats@tools.ietf.org" Thread-Topic: RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05 Thread-Index: AdHxrwmJaguaDdoGQriqrxN4uU7wsg== Date: Tue, 9 Aug 2016 19:26:44 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64A871DE8@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64A871DE8eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPuK6bwapwg0U9Bhavjp1isfi35Qm7 xck5P5gtFqx5yu7A4rFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZeyd+p2poGk/Y8WPU/3M DYx/djJ2MXJySAiYSGx78Impi5GLQ0hgA6PEwa8TWSCcZYwSvVuOsoNUsQloSBy7sxasQ0Qg U2Jn1wFWEJtZoFTi+5s9YDXCAnYSR18+ZYeocZaYdOUnC4StJzGhcRJYnEVAReLf4atMIDav gK/EhM43bCA2o4CYxPdTa5ggZopL3HoynwniOgGJJXvOM0PYohIvH/9jhbCVJCYtPQd1Q77E 3OUL2SFmCkqcnPmEZQKj0Cwko2YhKZuFpGwWIwdQXFNi/S59iBJFiSndD9khbA2J1jlz2ZHF FzCyr2LkKC0uyMlNNzLYxAiMkmMSbLo7GO9P9zzEKMDBqMTDqyC1KlyINbGsuDL3EKMEB7OS CO9SXaAQb0piZVVqUX58UWlOavEhRmkOFiVxXrFHiuFCAumJJanZqakFqUUwWSYOTqkGxoC/ RZOE7k353MfpMefX04ucj540J7JeyY7cd8FVjd39lczxJwtvR/kqvX0i1PXkccxbXYX9Mutt lOaHb9XpkfCf88pCsERJz2j5Je4Few/L7/pz5MCS1wuUk1Y/5lHpmnfEn/vikUsFFtyl618b /p7VaNCsvmDhY1/Pl8xmOv1TeVKfhK/veq3EUpyRaKjFXFScCAA+Lxj6jgIAAA== Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" Subject: [manet] RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 19:31:58 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF64A871DE8eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCkRvY3VtZW50OiBTZWN1cml0eSBUaHJlYXRzIGZvciBTaW1wbGlmaWVkIE11bHRpY2Fz dCBGb3J3YXJkaW5nIChTTUYpIC0gZHJhZnQtaWV0Zi1tYW5ldC1zbWYtc2VjLXRocmVhdHMtMDUg KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXNtZi1zZWMtdGhy ZWF0cy0wNSkNClJldmlld2VyOiBFcmljIEdyYXkNClJldmlldyBEYXRlOiA5IEF1Z3VzdCwgMjAx Ng0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1 bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4N Cg0KQ29tbWVudHM6DQpUaGUgZHJhZnQgaXMgbW9zdGx5IHJlYWRhYmxlLiAgVGhlcmUgYXJlIGEg ZmFpciBudW1iZXIgb2YgbGFuZ3VhZ2UgaXJyZWd1bGFyaXRpZXMg4oCTIHdoaWNoIHdlIGFyZSBh c2tlZCBub3QgdG8gc3BlbmQgdGltZSBvbiBpbiB0aGVzZSByZXZpZXdzIOKAkyBpbmNsdWRpbmcg YSBmZXcgdGhhdCBtaWdodCBtYWtlIHJlYWRpbmcgb2Ygc29tZSBwYXJ0cyBvZiB0aGUgZHJhZnQg ZGlmZmljdWx0IGZvciBwZW9wbGUgbm90IGFscmVhZHkgZmFtaWxpYXIgd2l0aCB0aGUgaW50ZW50 aW9ucyBhbmQgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuDQoNCk1ham9yIElzc3VlczoNCk5vIG1h am9yIGlzc3VlcyBmb3VuZC4NCg0KTWlub3IgSXNzdWVzOg0KUkZDIDY2MjEgZGlzY3Vzc2VzIGEg ZmV3IHNlY3VyaXR5IGlzc3VlcyB3aGljaCBkbyBub3QgbG9vayB0byBoYXZlIGJlZW4gcmVmZXJl bmNlZCBpbiB0aGlzIGRyYWZ0LCBldmVuIGluZGlyZWN0bHkuICBUaGVyZSBhcmUgZ29vZCByZWFz b25zIHdoeSB0aGlzIGlzIHVudXN1YWwuDQpTaW1pbGFybHksIHdoaWxlIHRoZSBkcmFmdCBkb2Vz IG1ha2UgYXQgbGVhc3QgYW4gb2JsaXF1ZSByZWZlcmVuY2UgdG8gdGhlIHNlY3VyaXR5IGlzc3Vl cyB0aGF0IGFwcGx5IHRvIFJGQyA2MTMwLCBpdCBpcyBub3QgY2xlYXIgd2l0aG91dCBleHRlbnNp dmUgcmVhZGluZyB3aGF0IHRoaXMgZHJhZnQgYWRkcmVzc2VzIHRoYXQgaXMgbm90IChhdCBsZWFz dCBzdWZmaWNpZW50bHkpIGFkZHJlc3NlZCB0aGVyZSAob3IgaW4gUkZDIDcxODYpLg0KDQpUb3dh cmQgdGhlIGVuZCBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gMyAoU01GIFRocmVh dHMgT3ZlcnZpZXcpLCB0aGUgZHJhZnQgbWFrZXMgYW4gYXNzZXJ0aW9uIHRoYXQgaXMgbm90IGNv bnNpc3RlbnQgd2l0aCBvdGhlciB0ZXh0IGluIHRoZSBzYW1lIHBhcmFncmFwaDsgaXQgY2xhaW1z IHRoYXQg4oCcU01GIHJlbGllcyBvbiBOSERQ4oCdIHdoaWxlIG90aGVyIHRleHQsIGluY2x1ZGlu ZyB0ZXh0IGluIHRoZSBzYW1lIHBhcmFncmFwaCwgc2VlbXMgc3Ryb25nbHkgdG8gaW5kaWNhdGUg dGhhdCBOSERQIGlzIG9uZSBhbHRlcm5hdGl2ZSBhcHByb2FjaCB0aGF0IG1pZ2h0IGJlIHVzZWQu DQoNCk5vdGUgdGhhdCBJIHdhcyB1bmFibGUgdG8gcGFyc2UgcGFydCBvZiB0aGlzIHNhbWUgc2Vu dGVuY2U6IHdoYXQgZG9lcyDigJwobm90IG1hdHRlciBpZiBvdGhlciDigKYgZm9yIDEtaG9wIG5l aWdoYm9yIGRpc2NvdmVyeSnigJ0gbWVhbj8NCg0KU2VjdGlvbiA0LjEuMSAoUmVwbGF5IEF0dGFj aykgYXBwZWFycyB0byBhZGRyZXNzIGFuIGlzc3VlIHRoYXQgYSkgaXMgbm90IG5lY2Vzc2FyaWx5 IGEgY29udHJvbCBwbGFuZSBhdHRhY2sgKGFzIGltcGxpZWQgaW4gdGhlIGZpcnN0IHBhcmFncmFw aCksIGFuZCBiKSBpcyBjbGVhcmx5IGEgdmFyaWF0aW9uIG9mIGEgdGhyZWF0IGRlc2NyaWJlZCBp biB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMgNjYyMSBhcyBhIERv UyBhdHRhY2suICBCZWNhdXNlIHRoZSBzcGVjaWZpYyB0aHJlYXQgaW4gYm90aCBjYXNlcyAodGhl IGNhc2UgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBhbmQgdGhhdCBkZXNjcmliZWQgaW4gUkZD IDY2MjEpIGludm9sdmVzIHVzaW5nIHNvbWUgbWVhbnMgb2YgZGVsaXZlcmluZyBib2d1cyBwYWNr ZXRzIGVhcmxpZXIgdGhhbiBzdWJzZXF1ZW50IGxlZ2l0aW1hdGUgcGFja2V0cywgdGhpcyBkb2Vz IG5vdCAoYXQgbGVhc3QgaW50dWl0aXZlbHkpIHNlZW0gbGlrZSBhIHJlcGxheSBhdHRhY2suDQoN ClNlY3Rpb24gNC4yLjEg4oCTIFByZS1hY3RpdmF0aW9uIEF0dGFja3MgKFByZS1QbGF5KSDigJMg c2ltaWxhcmx5IGFwcGVhcnMgdG8gYWRkcmVzcyBvbmUgc3BlY2lmaWMgZXhhbXBsZSBvZiBhIHNl Y29uZCBnZW5lcmFsIGNsYXNzIG9mIHRocmVhdCBkZXNjcmliZWQgaW4gdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgUkZDIDY2MjEgKGlzc3VlcyB3aXRoIHVzZSBvZiBwcmVk aWN0YWJsZSBzZXF1ZW5jaW5nIHRlY2huaXF1ZXMpLg0KDQpUaGUgc2FtZSBhcHBsaWVzIHRvIHNl Y3Rpb24gNC4yLjIg4oCTIERlLWFjdGl2YXRpb24gYXR0YWNrcy4NCg0KSXQgd291bGQgYmUgdXNl ZnVsIGlmIHRoZSBsZWFkaW5nIHRleHQgaW4gc2VjdGlvbiA0LjIgdGFsa2VkIGdlbmVyYWxseSBh Ym91dCB0aGUgcmVsYXRlZCBhdHRhY2sgdmVjdG9yIGRlc2NyaWJlZCBpbiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMgNjYyMSBhbmQgd2h5IHRoaXMgZHJhZnQgbmVl ZHMgdG8gZXhwYW5kIG9uIHRoaXMgY2xhc3Mgb2YgdGhyZWF0IChhc3NvY2lhdGVkIHdpdGggSS1E UEQpIGRlc2NyaWJlZCB0aGVyZS4NCg0KU2VjdGlvbiA0LjMgYWxzbyBzaW1pbGFybHkgcHJvdmlk ZXMgYW4gZXhwYW5zaW9uIG9uIGEgY2xhc3Mgb2YgdGhyZWF0cyAoYXNzb2NpYXRlZCB3aXRoIEgt RFBEKSBhbHJlYWR5IGRlc2NyaWJlZCBpbiBSRkMgNjYyMS4NCg0KSW4gZ2VuZXJhbCwgSSBmZWVs IHRoYXQgdGhlIGV4cGFuc2lvbnMgcHJvdmlkZWQgaW4gc2VjdGlvbiA0IG9mIHRoaXMgZHJhZnQg cHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24g4oCTIGFzIGV4YW1wbGVzLCBhdCBsZWFzdC4gIEhv d2V2ZXIsIHRoaXMgc2VjdGlvbiBzaG91bGQgZXhwbGljaXRseSByZWZlciB0byBhcHBsaWNhYmxl IHRleHQgaW4gUkZDIDY2MjEsIHdoaWNoIGluY2x1ZGVzIHN1Z2dlc3Rpb25zIG9uIHdheXMgdG8g bWl0aWdhdGUgdGhlc2UgdGhyZWF0cy4gIElmIHRoZSBhdXRob3JzIGFuZC9vciB0aGUgd29ya2lu ZyBncm91cCBmZWVsIHRoYXQgdGhlIHN1Z2dlc3Rpb25zIG1hZGUgaW4gUkZDIDY2MjEgYXJlIGlu c3VmZmljaWVudCwgaXQgd291bGQgYmUgdXNlZnVsIHRvIHNheSB3aHkgdGhpcyBpcyB0aGUgY2Fz ZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQpUaGUgc2VudGVuY2UgY29tcHJpc2luZyBzZWN0aW9uIDUu MSAoUmVsYXkgU2V0IFNlbGVjdGlvbiBDb21tb24gVGhyZWF0cykgZG9lcyBub3QgYXBwZWFyIHRv IGJlIGNvcnJlY3QgYXMgd3JpdHRlbjsgUkZDIDcxODYgZG9lcyBub3QgaW5jbHVkZSBhbnl0aGlu ZyBhYm91dCBSU1MgYWxnb3JpdGhtcy4gIFRvIHRoZSBleHRlbnQgdGhhdCBSU1MgTUFZIGRlcGVu ZCBvbiBOSERQLCBSRkMgNzE4NiBkb2VzIGRlc2NyaWJlIHRocmVhdHMgdG8gTkhEUCB0aGF0IHdv dWxkIGltcGFjdCBSU1MgZm9yIHRoZXNlIGNhc2VzLiAgQXJndWFibHkgdGhlIHNhbWUgdGhyZWF0 cyBtYXkgYXBwbHkgaW5kZXBlbmRlbnQgb2YgaG93IFNNRiByb3V0ZXJzIGJlY29tZSBhd2FyZSBv ZiB0aGUgbmVpZ2hib3Job29kIHRvcG9sb2d5LCBidXQgdGhpcyBpcyBub3QgKGFuZCBwb3NzaWJs eSBjYW5ub3QgYmUpIGtub3duIHdpdGhvdXQgZXhoYXVzdGl2ZSBhbmFseXNpcyBvZiBhbGwgbWV0 aG9kcyBieSB3aGljaCB0aGlzIGluZm9ybWF0aW9uIG1pZ2h0IGJlIGRldGVybWluZWQuDQoNCklu IFNlY3Rpb24gNS4yIChUaHJlYXRzIHRvIEUtQ0RTIEFsZ29yaXRobSksIFJGQyA1NjE0IGlzIGdp dmVuIGFzIGEgcmVmZXJlbmNlIGZvciDigJxFc3NlbnRpYWwgQ29ubmVjdGVkIERvbWluYXRpbmcg U2V04oCdIChvciB0aGUgRS1DRFMgYWxnb3JpdGhtKSwgd2hlbiBSRkMgNTYxNCBhY3R1YWxseSBk b2VzIG5vdCBtZW50aW9uIGVpdGhlciBvbmUgKGl0IGRlZmluZXMgQ0RTIGFuZCB0YWxrcyBhYm91 dCBhIHNtYWxsIG51bWJlciBvZiBhbGdvcml0aG1zIOKAkyBub25lIG9mIHdoaWNoIGFyZSBkaXJl Y3RseSByZWxhdGVkIHRvIEUtQ0RTOyB0aGUgd29yZCDigJxlc3NlbnRpYWzigJ0gZG9lcyBub3Qg YXBwZWFyIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBSRkMgYW55d2hlcmUpLiAgSSB3YXMgbm90IGFi bGUgdG8gZmluZCBhIHJlZmVyZW5jZSBmb3IgdGhpcyB0ZXJtIGluIGEgZmV3IG1pbnV0ZXMgb2Yg cG9raW5nIGFyb3VuZCwgdGhvdWdoIGl0IGlzIGVhc3kgZW5vdWdoIHRvIGZpbmQgcmVmZXJlbmNl cyBmb3Ig4oCcbWluaW11bSBjb25uZWN0ZWQgZG9taW5hdGluZyBzZXQu4oCdDQoNClRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIChzZWN0aW9uIDcpIG9mIHRoaXMgZHJhZnQgc2hv dWxkIHByb3ZpZGUgYSBzdW1tYXJ5IG9mIHNlY3VyaXR5IGlzc3VlcyBpbmNsdWRlZCBvciBhZGRy ZXNzZWQgaW4gdGhpcyBkb2N1bWVudCAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSBieSByZWZlcmVu Y2UpIGFzIHdlbGwgYXMgYW55IHJlbGF0ZWQgc2VjdXJpdHkgaXNzdWVzIHlldCB0byBiZSBhZGRy ZXNzZWQuIE1pbmltYWxseSwgaWYgdGhlIGF1dGhvcnMgZmVlbCB0aGF0IHRoaXMgaW5mb3JtYXRp b24gaXMgcHJvdmlkZWQgaW4gc2VjdGlvbiAzIChTTUYgVGhyZWF0cyBPdmVydmlldyksIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3VsZCBzYXkgdGhpcy4gIE9uZSBhcHBy b2FjaCB3b3VsZCBiZSB0byB1c2UgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g dG8gc3VtbWFyaXplIHRoZSBtYWluIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50Lg0KDQpOaXRzOg0K SSBoYWQgYSBudW1iZXIgb2YgaXNzdWVzIHdpdGgg4oCcZXNvdGVyaWMgcXVlc3Rpb25zIG9mIEVu Z2xpc2ggdXNhZ2Uu4oCdIEhvd2V2ZXIsIGFjY29yZGluZyB0byBvdXIgaW5zdHJ1Y3Rpb25zLCDi gJx0aGUgUkZDIEVkaXRvciB3aWxsIHNwb3QgdGhlc2UsIGFuZCBpdCBpcyBub3QgYSB3aXNlIHVz ZSBvZiB0aW1lIHRvIGRpc2N1c3MgdGhlc2UgdGhpbmdzLuKAnQ0KDQrimLoNCg0K --_000_48E1A67CB9CA044EADFEAB87D814BFF64A871DE8eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uaWNvbg0KCXttc28tc3R5bGUtbmFtZTppY29uO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IZWxsbywNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBoYXZlIGJl ZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dA0KIGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8g dGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBE aXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAwMEREIj7igIs8L3NwYW4+PC9zcGFuPmh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoZXNlIGNvbW1l bnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsDQogYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Eb2N1bWVudDogU2VjdXJpdHkgVGhyZWF0cyBmb3IgU2ltcGxp ZmllZCBNdWx0aWNhc3QgRm9yd2FyZGluZyAoU01GKSAtIGRyYWZ0LWlldGYtbWFuZXQtc21mLXNl Yy10aHJlYXRzLTA1ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tYW5ldC1zbWYtc2VjLXRocmVhdHMtMDUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC88c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5k cmFmdC1pZXRmLW1hbmV0LXNtZi1zZWMtdGhyZWF0cy0wNTwvc3Bhbj48L2E+PC9zcGFuPik8c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXZpZXdlcjogRXJpYyBHcmF5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5SZXZpZXcgRGF0ZTogOSBBdWd1c3QsIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+U3VtbWFyeTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5z IGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZv cmUgcHVibGljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q29tbWVu dHM6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+VGhlIGRyYWZ0IGlzIG1vc3RseSByZWFkYWJsZS4mbmJzcDsgVGhl cmUgYXJlIGEgZmFpciBudW1iZXIgb2YgbGFuZ3VhZ2UgaXJyZWd1bGFyaXRpZXMg4oCTIHdoaWNo IHdlIGFyZSBhc2tlZCBub3QgdG8gc3BlbmQgdGltZSBvbiBpbiB0aGVzZSByZXZpZXdzIOKAkyBp bmNsdWRpbmcgYSBmZXcgdGhhdCBtaWdodCBtYWtlIHJlYWRpbmcgb2Ygc29tZSBwYXJ0cyBvZiB0 aGUgZHJhZnQNCiBkaWZmaWN1bHQgZm9yIHBlb3BsZSBub3QgYWxyZWFkeSBmYW1pbGlhciB3aXRo IHRoZSBpbnRlbnRpb25zIGFuZCBjb250ZW50IG9mIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+TWFqb3IgSXNzdWVzOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5vIG1ham9y IGlzc3VlcyBmb3VuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWlub3IgSXNz dWVzOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlJGQyA2NjIxIGRpc2N1c3NlcyBhIGZldyBzZWN1cml0eSBpc3N1 ZXMgd2hpY2ggZG8gbm90IGxvb2sgdG8gaGF2ZSBiZWVuIHJlZmVyZW5jZWQgaW4gdGhpcyBkcmFm dCwgZXZlbiBpbmRpcmVjdGx5LiZuYnNwOyBUaGVyZSBhcmUgZ29vZCByZWFzb25zIHdoeSB0aGlz IGlzIHVudXN1YWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFybHksIHdoaWxlIHRoZSBkcmFmdCBkb2Vz IG1ha2UgYXQgbGVhc3QgYW4gb2JsaXF1ZSByZWZlcmVuY2UgdG8gdGhlIHNlY3VyaXR5IGlzc3Vl cyB0aGF0IGFwcGx5IHRvIFJGQyA2MTMwLCBpdCBpcyBub3QgY2xlYXIgd2l0aG91dCBleHRlbnNp dmUgcmVhZGluZyB3aGF0IHRoaXMgZHJhZnQgYWRkcmVzc2VzIHRoYXQgaXMgbm90IChhdCBsZWFz dCBzdWZmaWNpZW50bHkpDQogYWRkcmVzc2VkIHRoZXJlIChvciBpbiBSRkMgNzE4NikuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRvd2FyZCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBw YXJhZ3JhcGggaW4gc2VjdGlvbiAzIChTTUYgVGhyZWF0cyBPdmVydmlldyksIHRoZSBkcmFmdCBt YWtlcyBhbiBhc3NlcnRpb24gdGhhdCBpcyBub3QgY29uc2lzdGVudCB3aXRoIG90aGVyIHRleHQg aW4gdGhlIHNhbWUgcGFyYWdyYXBoOyBpdCBjbGFpbXMgdGhhdCDigJxTTUYgcmVsaWVzIG9uIE5I RFDigJ0gd2hpbGUgb3RoZXINCiB0ZXh0LCBpbmNsdWRpbmcgdGV4dCBpbiB0aGUgc2FtZSBwYXJh Z3JhcGgsIHNlZW1zIHN0cm9uZ2x5IHRvIGluZGljYXRlIHRoYXQgTkhEUCBpcw0KPHU+b25lIGFs dGVybmF0aXZlIGFwcHJvYWNoIHRoYXQgbWlnaHQgYmUgdXNlZDwvdT4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk5vdGUgdGhhdCBJIHdhcyB1bmFibGUgdG8gcGFyc2UgcGFydCBv ZiB0aGlzIHNhbWUgc2VudGVuY2U6IHdoYXQgZG9lcyDigJwobm90IG1hdHRlciBpZiBvdGhlciDi gKYgZm9yIDEtaG9wIG5laWdoYm9yIGRpc2NvdmVyeSnigJ0gbWVhbj8NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN0aW9uIDQuMS4xIChSZXBsYXkgQXR0YWNrKSBhcHBlYXJz IHRvIGFkZHJlc3MgYW4gaXNzdWUgdGhhdCBhKSBpcyBub3QgbmVjZXNzYXJpbHkgYSBjb250cm9s IHBsYW5lIGF0dGFjayAoYXMgaW1wbGllZCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoKSwgYW5kIGIp IGlzIGNsZWFybHkgYSB2YXJpYXRpb24gb2YgYSB0aHJlYXQgZGVzY3JpYmVkIGluIHRoZSBTZWN1 cml0eQ0KIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgUkZDIDY2MjEgYXMgYSBEb1MgYXR0YWNr LiZuYnNwOyBCZWNhdXNlIHRoZSBzcGVjaWZpYyB0aHJlYXQgaW4gYm90aCBjYXNlcyAodGhlIGNh c2UgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBhbmQgdGhhdCBkZXNjcmliZWQgaW4gUkZDIDY2 MjEpIGludm9sdmVzIHVzaW5nIHNvbWUgbWVhbnMgb2YgZGVsaXZlcmluZyBib2d1cyBwYWNrZXRz IGVhcmxpZXIgdGhhbiBzdWJzZXF1ZW50IGxlZ2l0aW1hdGUgcGFja2V0cywNCiB0aGlzIGRvZXMg bm90IChhdCBsZWFzdCBpbnR1aXRpdmVseSkgc2VlbSBsaWtlIGEgcmVwbGF5IGF0dGFjay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdGlvbiA0LjIuMSDigJMgUHJlLWFjdGl2 YXRpb24gQXR0YWNrcyAoUHJlLVBsYXkpIOKAkyBzaW1pbGFybHkgYXBwZWFycyB0byBhZGRyZXNz IG9uZSBzcGVjaWZpYyBleGFtcGxlIG9mIGEgc2Vjb25kIGdlbmVyYWwgY2xhc3Mgb2YgdGhyZWF0 IGRlc2NyaWJlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMg NjYyMSAoaXNzdWVzIHdpdGgNCiB1c2Ugb2YgcHJlZGljdGFibGUgc2VxdWVuY2luZyB0ZWNobmlx dWVzKS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBzYW1lIGFw cGxpZXMgdG8gc2VjdGlvbiA0LjIuMiDigJMgRGUtYWN0aXZhdGlvbiBhdHRhY2tzLiZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB0 aGUgbGVhZGluZyB0ZXh0IGluIHNlY3Rpb24gNC4yIHRhbGtlZCBnZW5lcmFsbHkgYWJvdXQgdGhl IHJlbGF0ZWQgYXR0YWNrIHZlY3RvciBkZXNjcmliZWQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gb2YgUkZDIDY2MjEgYW5kIHdoeSB0aGlzIGRyYWZ0IG5lZWRzIHRvIGV4 cGFuZCBvbiB0aGlzIGNsYXNzDQogb2YgdGhyZWF0IChhc3NvY2lhdGVkIHdpdGggSS1EUEQpIGRl c2NyaWJlZCB0aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdGlvbiA0 LjMgYWxzbyBzaW1pbGFybHkgcHJvdmlkZXMgYW4gZXhwYW5zaW9uIG9uIGEgY2xhc3Mgb2YgdGhy ZWF0cyAoYXNzb2NpYXRlZCB3aXRoIEgtRFBEKSBhbHJlYWR5IGRlc2NyaWJlZCBpbiBSRkMgNjYy MS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gZ2VuZXJhbCwgSSBmZWVsIHRo YXQgdGhlIGV4cGFuc2lvbnMgcHJvdmlkZWQgaW4gc2VjdGlvbiA0IG9mIHRoaXMgZHJhZnQgcHJv dmlkZSB1c2VmdWwgaW5mb3JtYXRpb24g4oCTIGFzIGV4YW1wbGVzLCBhdCBsZWFzdC4mbmJzcDsg SG93ZXZlciwgdGhpcyBzZWN0aW9uIHNob3VsZCBleHBsaWNpdGx5IHJlZmVyIHRvIGFwcGxpY2Fi bGUgdGV4dCBpbiBSRkMgNjYyMSwgd2hpY2gNCiBpbmNsdWRlcyBzdWdnZXN0aW9ucyBvbiB3YXlz IHRvIG1pdGlnYXRlIHRoZXNlIHRocmVhdHMuJm5ic3A7IElmIHRoZSBhdXRob3JzIGFuZC9vciB0 aGUgd29ya2luZyBncm91cCBmZWVsIHRoYXQgdGhlIHN1Z2dlc3Rpb25zIG1hZGUgaW4gUkZDIDY2 MjEgYXJlIGluc3VmZmljaWVudCwgaXQgd291bGQgYmUgdXNlZnVsIHRvIHNheSB3aHkgdGhpcyBp cyB0aGUgY2FzZSBpbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgc2VudGVuY2UgY29tcHJpc2luZyBzZWN0aW9uIDUuMSAoUmVsYXkgU2V0IFNlbGVj dGlvbiBDb21tb24gVGhyZWF0cykgZG9lcyBub3QgYXBwZWFyIHRvIGJlIGNvcnJlY3QgYXMgd3Jp dHRlbjsgUkZDIDcxODYgZG9lcyBub3QgaW5jbHVkZSBhbnl0aGluZyBhYm91dCBSU1MgYWxnb3Jp dGhtcy4mbmJzcDsgVG8gdGhlIGV4dGVudCB0aGF0IFJTUyBNQVkgZGVwZW5kIG9uDQogTkhEUCwg UkZDIDcxODYgZG9lcyBkZXNjcmliZSB0aHJlYXRzIHRvIE5IRFAgdGhhdCB3b3VsZCBpbXBhY3Qg UlNTIGZvciB0aGVzZSBjYXNlcy4mbmJzcDsgQXJndWFibHkgdGhlIHNhbWUgdGhyZWF0cyBtYXkg YXBwbHkgaW5kZXBlbmRlbnQgb2YgaG93IFNNRiByb3V0ZXJzIGJlY29tZSBhd2FyZSBvZiB0aGUg bmVpZ2hib3Job29kIHRvcG9sb2d5LCBidXQgdGhpcyBpcyBub3QgKGFuZCBwb3NzaWJseSBjYW5u b3QgYmUpIGtub3duIHdpdGhvdXQgZXhoYXVzdGl2ZQ0KIGFuYWx5c2lzIG9mIGFsbCBtZXRob2Rz IGJ5IHdoaWNoIHRoaXMgaW5mb3JtYXRpb24gbWlnaHQgYmUgZGV0ZXJtaW5lZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gU2VjdGlvbiA1LjIgKFRocmVhdHMgdG8gRS1DRFMg QWxnb3JpdGhtKSwgUkZDIDU2MTQgaXMgZ2l2ZW4gYXMgYSByZWZlcmVuY2UgZm9yIOKAnEVzc2Vu dGlhbCBDb25uZWN0ZWQgRG9taW5hdGluZyBTZXTigJ0gKG9yIHRoZSBFLUNEUyBhbGdvcml0aG0p LCB3aGVuIFJGQyA1NjE0IGFjdHVhbGx5IGRvZXMgbm90IG1lbnRpb24gZWl0aGVyIG9uZSAoaXQg ZGVmaW5lcyBDRFMNCiBhbmQgdGFsa3MgYWJvdXQgYSBzbWFsbCBudW1iZXIgb2YgYWxnb3JpdGht cyDigJMgbm9uZSBvZiB3aGljaCBhcmUgZGlyZWN0bHkgcmVsYXRlZCB0byBFLUNEUzsgdGhlIHdv cmQg4oCcZXNzZW50aWFs4oCdIGRvZXMgbm90IGFwcGVhciB0byBiZSBpbmNsdWRlZCBpbiB0aGUg UkZDIGFueXdoZXJlKS4mbmJzcDsgSSB3YXMgbm90IGFibGUgdG8gZmluZCBhIHJlZmVyZW5jZSBm b3IgdGhpcyB0ZXJtIGluIGEgZmV3IG1pbnV0ZXMgb2YgcG9raW5nIGFyb3VuZCwgdGhvdWdoDQog aXQgaXMgZWFzeSBlbm91Z2ggdG8gZmluZCByZWZlcmVuY2VzIGZvciDigJxtaW5pbXVtIGNvbm5l Y3RlZCBkb21pbmF0aW5nIHNldC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gKHNlY3Rpb24gNykgb2YgdGhpcyBk cmFmdCBzaG91bGQgcHJvdmlkZSBhIHN1bW1hcnkgb2Ygc2VjdXJpdHkgaXNzdWVzIGluY2x1ZGVk IG9yIGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50IChkaXJlY3RseSBvciBpbmRpcmVjdGx5IGJ5 IHJlZmVyZW5jZSkgYXMgd2VsbCBhcyBhbnkgcmVsYXRlZCBzZWN1cml0eQ0KIGlzc3VlcyB5ZXQg dG8gYmUgYWRkcmVzc2VkLiBNaW5pbWFsbHksIGlmIHRoZSBhdXRob3JzIGZlZWwgdGhhdCB0aGlz IGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkIGluIHNlY3Rpb24gMyAoU01GIFRocmVhdHMgT3ZlcnZp ZXcpLCB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzaG91bGQgc2F5IHRoaXMu Jm5ic3A7IE9uZSBhcHByb2FjaCB3b3VsZCBiZSB0byB1c2UgdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gdG8gc3VtbWFyaXplDQogdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9j dW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5pdHM6IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SSBoYWQgYSBudW1iZXIgb2YgaXNzdWVzIHdpdGgg4oCcZXNvdGVyaWMgcXVlc3Rpb25zIG9m IEVuZ2xpc2ggdXNhZ2Uu4oCdIEhvd2V2ZXIsIGFjY29yZGluZyB0byBvdXIgaW5zdHJ1Y3Rpb25z LCDigJx0aGUgUkZDIEVkaXRvciB3aWxsIHNwb3QgdGhlc2UsIGFuZCBpdCBpcyBub3QgYSB3aXNl IHVzZSBvZiB0aW1lIHRvIGRpc2N1c3MgdGhlc2UgdGhpbmdzLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+Sjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_48E1A67CB9CA044EADFEAB87D814BFF64A871DE8eusaamb107erics_-- From nobody Thu Aug 18 05:25:59 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92B012DC36; Thu, 18 Aug 2016 05:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 owvq84Vi9fa3; Thu, 18 Aug 2016 05:25:46 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 119B312DBED; Thu, 18 Aug 2016 05:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EDD62CCB3; Thu, 18 Aug 2016 15:24:02 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k98HJDg2fTXi; Thu, 18 Aug 2016 15:24:02 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id AA7E32CC9C; Thu, 18 Aug 2016 15:24:01 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_31050C27-E8FA-460F-BB65-C0775CC36BDE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Thu, 18 Aug 2016 14:24:00 +0200 Message-Id: <5DFAD12A-BB78-484C-BD77-19B189CA9FEF@piuha.net> References: To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: General Area Review Team , manet@ietf.org, "ietf@ietf.org" , draft-ietf-manet-smc-sec-threats.all@ietf.org Subject: Re: [manet] [Gen-art] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 12:25:49 -0000 --Apple-Mail=_31050C27-E8FA-460F-BB65-C0775CC36BDE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Many thanks for your review, Robert. Jari --Apple-Mail=_31050C27-E8FA-460F-BB65-C0775CC36BDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXtajgAAoJEM80gCTQU46qJC0P/1j4JXbxAYKGFMBOXu705ww7 YDql2AWjylsf+FQviSzjdAdoxL6l4+Dg8imWI9RbuJHPjk+lPTlG3nuqnFwT5Jle QyWVtdsUrDqii++ksbHyVh6jFC+eSjE8Lde9sq+BsnFBVzfjUgcaJwXgt0LHje7/ od9cEHXemYqCsDzPXKMsvnxmu7nkkxcqJuZVTuF0FgTjwlQasUBUqdymaG6gpM7Z xi7F0guWoLjJ7B7EhmASb3s0nsKmsmtJccPEp/DLLJdgUWUyp4RNiv4+5audmpAX /SYoKWT++eKD4ybJAzvimK3wEPtnn3FKeVQsUIGAxkCbF/6aoa0JyW3bV4nfQ2p4 T0hTxVHHpQrVtwHHzBaxfi2kBAnoBza+UYUM1BRsXbASN9cQjw+gw2Ri2xqFiXu3 yNsbAloo33BG1e34FI0fhEDMhMjIJLkbWXaBU85tgEksol/XEHQzHpR2OkO8tww4 ld9tvEvQUdNVYIrseFSZiM1CMIOWm8WidlCqso7AUwcKoYy8h/U21RmAJxW6g6rQ 2NzBxJOo2KiIUCjMmTItHWeHr5779RFune0wwwlSZvKZ+2YMmUlz7L8dgGl7ow3x XHfCvahiOiBsgTi25ntlbJJWCdojtuds2th3bVNLXJqq2zxrgjCp/2XDSqmP1Nfn xs9zFjz/WuRW5QB+cHcE =mR/N -----END PGP SIGNATURE----- --Apple-Mail=_31050C27-E8FA-460F-BB65-C0775CC36BDE-- From nobody Thu Aug 18 09:47:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79912D1BE for ; Thu, 18 Aug 2016 09:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name 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 XCbt9uRf7WG3 for ; Thu, 18 Aug 2016 09:47:53 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 5FD8412DBBC for ; Thu, 18 Aug 2016 09:47:53 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q83so24406705iod.1 for ; Thu, 18 Aug 2016 09:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MUGEO4uCq8kowoz+9YFuQC7z2P13wrU3E9bJTQL5Fkc=; b=uOAV+VstOQvhriEMjZh+j9GaTrLhU5kGPkCFKH/zZu5VlA9/GRI3fFsTGHhrHhYKuc IaZ5yMU9V0G+9o/Cmf4u0luV/0N1IcRh+Yd8BCX4j80zSfdzhefdy5K5PSHwXRveFOmm xORIXpa3wcFRIWbsR4wwsic8Pfg5sAZ9xwivI= 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-transfer-encoding; bh=MUGEO4uCq8kowoz+9YFuQC7z2P13wrU3E9bJTQL5Fkc=; b=jRJUkSr3NS9X44VAYBrV+AfiWpgB9qjlRw6NsNnet8sxRnZKMEvSdp8WEinkLwS0IZ ffb8/nWKZUyiD6cJTOO5AZ26OyT+wiav6+YzVNflxyGGVPPWHHStSEj+4/ndbi3lKyFh ohDumoTU9wqYfb9vr9xj9mctrb6bvb5DlbU8ECyhOFfzgFdRuJvsx8UP7MDuw5c6wtMY rhsWDBENMVBPrcaoIZ11cl595NHV1kAz3lFdNIiXVHx7dSBVycwLVd3q7qMu0UNjuCEc VX5Eog/FpOaGUUyX30Iwccl/DeUoX6qXjNvtkO2kMFysLfiZxk2sJ7KJX8Q4UsTrCR9t pOqg== X-Gm-Message-State: AEkoousILrRjh1z2Ds7Js7IsSgMnBGv4PFaaQGS3uUuVqbkpABT3u+x6jV8eMhOt7w3wi/efgXFB8UuV/+UC3A== X-Received: by 10.107.165.67 with SMTP id o64mr4145653ioe.151.1471538872433; Thu, 18 Aug 2016 09:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.23.88 with HTTP; Thu, 18 Aug 2016 09:47:51 -0700 (PDT) In-Reply-To: <7F8E05AD-4907-4CA1-AFAC-F28BABEB5575@thomasclausen.org> References: <078BE592-5D84-41C3-B3D4-E7DD28F1DE6E@thomasclausen.org> <7F8E05AD-4907-4CA1-AFAC-F28BABEB5575@thomasclausen.org> From: Ulrich Herberg Date: Thu, 18 Aug 2016 09:47:51 -0700 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet-ads@ietf.org, manet@ietf.org Subject: Re: [manet] Last call on OLSRv2 Sec Threats still open X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 16:47:55 -0000 Any updates on this? Thanks Ulrich On Mon, Aug 1, 2016 at 8:13 AM, Thomas Clausen wro= te: > According to my calendar, August 1 has come around, also, now. > > This has been hanging around in "WG Consensus: Waiting for Write-Up: > Informational" status for almost two^Wfour weeks... please consider this = a > friendly nag. > > Thomas > > > > -- > Thomas Heide Clausen =E2=80=A2 @thclausen =E2=80=A2 thomasclausen.or= g > www.arkko.com/tools/allstats/thomasheideclausen.html > On 08 Jul 2016, at 09:37, Thomas Heide Clausen > wrote: > > According to my calendar, July 1 has come and past, now. > > Thomas > > On 22 Jun 2016, at 15:56, Justin Dean wrote: > > > There was a mixup. Last Call for OLSRv2-Sec-Threats document is still op= en > and will end on July 1st. I'll take this opportunity to again remind peo= ple > to please read and comment to the list. > > > Justin > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Aug 26 04:48:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E286312D89E for ; Fri, 26 Aug 2016 04:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XBeoRN8WzxXU for ; Fri, 26 Aug 2016 04:47:59 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 E7A6312D735 for ; Fri, 26 Aug 2016 04:43:09 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b199so54864628lfe.0 for ; Fri, 26 Aug 2016 04:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=MOzyjBdD2RIUM3g1REFkU5Val5ZlYo7HQRRDFRKy+Hc=; b=BZ8DHJtcw7ji9wioAyoOtn9DxCzX66y33md0XrsJ9zXprLDFkp2uR/jne/TKTpbj8f qw5iy+pfHIGlGcbny4wNuUs4f1Bk2Cb8WDQZYQOyxzUI2yGc5qTGVkFbVv7B5kl1n8bI BCqZnqlIELAxD68Mh8Gbo5rlpklrNyj6WOu5wi/PeSbK6L/rh5kpy09fb36OTqckOwvT ZVsuiYexJb2p19+xCxN0Gel32s171qcn66CxThkrEMQZPfFGAF7M5uDX0FI21KfreADA w5umqDBVhx7rObnxA5JKoA0mO4L/sVdC0+obmNayXuoiHefnkBwGZGUdOt5QlB13ZjbB 23DA== 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:from :date:message-id:subject:to; bh=MOzyjBdD2RIUM3g1REFkU5Val5ZlYo7HQRRDFRKy+Hc=; b=BTmvcBnWEFdlv87RgtzKBQBgaluhpUerSX89AbL3MeC1e18X48V5gz5faSSRIQ833Q Geipm1ZPleTwRoah4Cm7/PPZokwz+jBV8yAjJaQS2Wo8ZuRbJeEWZxbcH0SzMbHPlWgV QTHJ5CxKdjHltcS/2gQ1WXCLZw9+r/uocpIlb1UxAYtE78ekbpvTWpApu0r0uJZiFZhX Daexyr7v+4RaDMp8bGIe2u3IA0ZRSR+pzQ5J5HvYvl9XMfkN7fukufbf7oOlxkd3QqwB PwADP0aj6mZLwKhlEZBPbu0eygsKknWhdIj3NzTHgopT2JXYx/lXVlNUQRmaZDqxh9Js 8UUw== X-Gm-Message-State: AE9vXwO68jRptBBX+3Fhllna8CXKah6AIMVMfTD7D6PYDwLNehTtYWFLb3hi+OBqgidmXcYGooTY9VU52s4WSQ== X-Received: by 10.46.32.77 with SMTP id g74mr913839ljg.34.1472211787763; Fri, 26 Aug 2016 04:43:07 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.185.68 with HTTP; Fri, 26 Aug 2016 04:43:06 -0700 (PDT) In-Reply-To: References: <20160725215639.11441.21673.idtracker@ietfa.amsl.com> From: Jiazi YI Date: Fri, 26 Aug 2016 13:43:06 +0200 X-Google-Sender-Auth: ao_wKFPGYojlRU5hS8XoJP-6SkE Message-ID: To: manet , Justin Dean , Stan Ratliff Content-Type: multipart/alternative; boundary=001a1142bc66a4d639053af804cc Archived-At: Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 11:48:02 -0000 --001a1142bc66a4d639053af804cc Content-Type: text/plain; charset=UTF-8 Dear chairs, The olsrv2-multipath document has been "In WG Last Call" for more than two months (since June 8th -- I suppose it should be long enough now ;). Could you please advice the next steps to take regarding the draft? As far as I can see, all the major issues raised have been taken care of. There are some text to be rephrased, but can be easily done in the next revision. best Jiazi On Tue, Jul 26, 2016 at 12:06 AM, Jiazi YI wrote: > Dear all, > > We just submitted a new revision of olsrv2-multipath. > > The update is based on the comments and discussion from the thread > https://www.ietf.org/mail-archive/web/manet/current/msg19164.html > > Other than the editorial changes, an update is that we added an 1-octet > value field in the SOURCE_ROUTE TLV to carry a multiplier information. This > is to make the holding time of the SR-OLSRv2 Router Tuple can be calculated > based on the information carried in the HELLO/TC messages, rather than a > router's predefined holding time. > > Regarding the erasure coding, we temporarily removed the sentence "By > definition, erasure coding is insensitive to the packet misordering.". I'll > have further exchange with Benoit to have more concrete text or references. > > Thanks very much for the comments! > > regards > > Jiazi > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 25, 2016 at 11:56 PM > Subject: New Version Notification for draft-ietf-manet-olsrv2- > multipath-11.txt > To: Benoit Parrein , Jiazi Yi < > jiazi@jiaziyi.com>, Benoit Parrein > > > > > A new version of I-D, draft-ietf-manet-olsrv2-multipath-11.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. > > Name: draft-ietf-manet-olsrv2-multipath > Revision: 11 > Title: Multi-path Extension for the Optimized Link State Routing > Protocol version 2 (OLSRv2) > Document date: 2016-07-25 > Group: manet > Pages: 24 > URL: https://www.ietf.org/internet-drafts/draft-ietf-manet- > olsrv2-multipath-11.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2- > multipath/ > Htmlized: https://tools.ietf.org/html/draft-ietf-manet-olsrv2- > multipath-11 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2- > multipath-11 > > Abstract: > This document specifies a multi-path extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. > > > > > 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. > > The IETF Secretariat > > > --001a1142bc66a4d639053af804cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear chairs,=C2=A0

The olsrv2-multipath= document has been "In WG Last Call" for more than two months (si= nce June 8th -- I suppose it should be long enough now ;). Could you please= advice the next steps to take regarding the draft?=C2=A0

As far as I can see, all the major issues raised have been taken ca= re of. There are some text to be rephrased, but can be easily done in the n= ext revision.=C2=A0

best

= Jiazi

= On Tue, Jul 26, 2016 at 12:06 AM, Jiazi YI <ietf@jiaziyi.com>= wrote:
Dear all,= =C2=A0

We just submitted a new revision of olsrv2-= multipath.=C2=A0

The update is based on the commen= ts and discussion from the thread=C2=A0https://www.iet= f.org/mail-archive/web/manet/current/msg19164.html
=
Other than the editorial changes, an update is that we added= an 1-octet value field in the SOURCE_ROUTE TLV to carry a multiplier infor= mation. This is to make the holding time of the SR-OLSRv2 Router Tuple can = be calculated based on the information carried in the HELLO/TC messages, ra= ther than a router's predefined holding time.=C2=A0

Regarding the erasure coding, we temporarily removed the sentenc= e "By definition, erasure coding is insensitive to the packet misorder= ing.". I'll have further exchange with Benoit to have more concret= e text or references.=C2=A0

Thanks very much= for the comments!

regards

Jiazi
<= div>


-------= --- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 25, 2= 016 at 11:56 PM
Subject: New Version Notification for draft-ietf-manet-o= lsrv2-multipath-11.txt
To: Benoit Parrein <Benoit.Parrein@polyt= ech.univ-nantes.fr>, Jiazi Yi <jiazi@jiaziyi.com>, Benoit Parrein <be= noit.parrein@polytech.univ-nantes.fr>



A new version of I-D, draft-ietf-manet-olsrv2-multipath-11.txt
has been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-manet-olsrv2-= multipath
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A011
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date:=C2=A0 2016-07-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 manet
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf= -manet-olsrv2-multipath-11.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-= multipath/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-11<= /a>
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet= -olsrv2-multipath-11

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension for the Optimiz= ed Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--001a1142bc66a4d639053af804cc-- From nobody Fri Aug 26 07:21:55 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D26E12D08F for ; Fri, 26 Aug 2016 07:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nl8MgkXBEkqi for ; Fri, 26 Aug 2016 07:21:49 -0700 (PDT) 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 40E3B12B03C for ; Fri, 26 Aug 2016 07:13:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,581,1464667200"; d="scan'208,217";a="7487848" IronPort-PHdr: =?us-ascii?q?9a23=3AGBKFGh/ksTVzmv9uRHKM819IXTAuvvDOBiVQ1KB8?= =?us-ascii?q?2uocTK2v8tzYMVDF4r011RmSDNydt6oP1bOe8/i5HzdRudDZ6DFKWacPfidNsd?= =?us-ascii?q?8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4?= =?us-ascii?q?bt74BpTVx5zukbvjotuPO04W3XL9Oeo0d0Tu612J94E/ushLEu4J0BzHo39FKa?= =?us-ascii?q?x95FhDAhatpSv6/dq655V58i5d6LoL/s9EVrjmLexjFeQLRBxvCW0+5dXquB/f?= =?us-ascii?q?VkPPoyJECiRF2iZPVirE5QP7FqbQ+n/7u/Zz8CubNN/3XLFyUjOnueMjTRbuhT?= =?us-ascii?q?tPYzsw9mzLos19kKwdpwiu8Vg34ZPPfICTfNZzd6WVKdkXT2dEV91NWjZpDYa1?= =?us-ascii?q?bo9JBO0Ea6IQlJX0oRM0pAe6BAeiTLf1wyNMh3H4xrEz1cwuFAjH2EorGNdY41?= =?us-ascii?q?rOq9Cgfp0bTeS0wqeMhQ7fZvVS1Ca3oNzTaBk9pfCCU5pxfcvLxEIzUQXIkgPD?= =?us-ascii?q?+sTeIzqJ27FV4CCg5O16WLfq0jZ/pg=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2CaAQCPTcBX/8v6+gpdGgEBAQEVAQEBAYJXMwEBAQEBdHw?= =?us-ascii?q?HjSmeRIcnhQmCASaFdwIcgWUUAQEBAQEBAQEBAQGBBIIyBAEVAQSCEAEBAQEDI?= =?us-ascii?q?wo6EBICAQgRAwEBASgDAgICHxEUCQgCBAESCIgWAyWwCIthDYNdAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBHIYvhEyCQ4FgAQEiBxIWAoJKgloFiCyFdop2LgYBhh+GP?= =?us-ascii?q?oJEgXROhA+JCIZrgU+ECYN5Dw+DHYE1cAGEHQ8bREF/AQEB?= From: "Ratliff, Stanley" To: Jiazi YI , manet , Justin Dean , Stan Ratliff Thread-Topic: [manet] New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txt Thread-Index: AQHR/4+6IXYJw3KrZEWnWvnwc+phaKBbSJ+w Date: Fri, 26 Aug 2016 14:13:21 +0000 Message-ID: References: <20160725215639.11441.21673.idtracker@ietfa.amsl.com> 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: multipart/alternative; boundary="_000_f87886d2eb374215b755388d58a3219dVAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:21:53 -0000 --_000_f87886d2eb374215b755388d58a3219dVAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SmlhemksDQoNCkFDSy4gR2l2ZSBKdXN0aW4gYW5kIG15c2VsZiBhIGNvdXBsZSBvZiBkYXlzIHRv IGRpc2N1c3MuIFNvcnJ5IGFib3V0IHRoYXQsIGJ1dCBteSBzY2hlZHVsZSBoYXMgYmVlbiBjcmF6 eSBsYXRlbHkuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYXppIFlJDQpTZW50OiBGcmlkYXksIEF1 Z3VzdCAyNiwgMjAxNiA3OjQzIEFNDQpUbzogbWFuZXQgPG1hbmV0QGlldGYub3JnPjsgSnVzdGlu IERlYW4gPGJlYmVtYXN0ZXJAZ21haWwuY29tPjsgU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBn bWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMS50eHQNCg0KRGVhciBjaGFp cnMsDQoNClRoZSBvbHNydjItbXVsdGlwYXRoIGRvY3VtZW50IGhhcyBiZWVuICJJbiBXRyBMYXN0 IENhbGwiIGZvciBtb3JlIHRoYW4gdHdvIG1vbnRocyAoc2luY2UgSnVuZSA4dGggLS0gSSBzdXBw b3NlIGl0IHNob3VsZCBiZSBsb25nIGVub3VnaCBub3cgOykuIENvdWxkIHlvdSBwbGVhc2UgYWR2 aWNlIHRoZSBuZXh0IHN0ZXBzIHRvIHRha2UgcmVnYXJkaW5nIHRoZSBkcmFmdD8NCg0KQXMgZmFy IGFzIEkgY2FuIHNlZSwgYWxsIHRoZSBtYWpvciBpc3N1ZXMgcmFpc2VkIGhhdmUgYmVlbiB0YWtl biBjYXJlIG9mLiBUaGVyZSBhcmUgc29tZSB0ZXh0IHRvIGJlIHJlcGhyYXNlZCwgYnV0IGNhbiBi ZSBlYXNpbHkgZG9uZSBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KYmVzdA0KDQpKaWF6aQ0KDQpP biBUdWUsIEp1bCAyNiwgMjAxNiBhdCAxMjowNiBBTSwgSmlhemkgWUkgPGlldGZAamlheml5aS5j b208bWFpbHRvOmlldGZAamlheml5aS5jb20+PiB3cm90ZToNCkRlYXIgYWxsLA0KDQpXZSBqdXN0 IHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBvZiBvbHNydjItbXVsdGlwYXRoLg0KDQpUaGUgdXBk YXRlIGlzIGJhc2VkIG9uIHRoZSBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiBmcm9tIHRoZSB0aHJl YWQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21z ZzE5MTY0Lmh0bWwNCg0KT3RoZXIgdGhhbiB0aGUgZWRpdG9yaWFsIGNoYW5nZXMsIGFuIHVwZGF0 ZSBpcyB0aGF0IHdlIGFkZGVkIGFuIDEtb2N0ZXQgdmFsdWUgZmllbGQgaW4gdGhlIFNPVVJDRV9S T1VURSBUTFYgdG8gY2FycnkgYSBtdWx0aXBsaWVyIGluZm9ybWF0aW9uLiBUaGlzIGlzIHRvIG1h a2UgdGhlIGhvbGRpbmcgdGltZSBvZiB0aGUgU1ItT0xTUnYyIFJvdXRlciBUdXBsZSBjYW4gYmUg Y2FsY3VsYXRlZCBiYXNlZCBvbiB0aGUgaW5mb3JtYXRpb24gY2FycmllZCBpbiB0aGUgSEVMTE8v VEMgbWVzc2FnZXMsIHJhdGhlciB0aGFuIGEgcm91dGVyJ3MgcHJlZGVmaW5lZCBob2xkaW5nIHRp bWUuDQoNClJlZ2FyZGluZyB0aGUgZXJhc3VyZSBjb2RpbmcsIHdlIHRlbXBvcmFyaWx5IHJlbW92 ZWQgdGhlIHNlbnRlbmNlICJCeSBkZWZpbml0aW9uLCBlcmFzdXJlIGNvZGluZyBpcyBpbnNlbnNp dGl2ZSB0byB0aGUgcGFja2V0IG1pc29yZGVyaW5nLiIuIEknbGwgaGF2ZSBmdXJ0aGVyIGV4Y2hh bmdlIHdpdGggQmVub2l0IHRvIGhhdmUgbW9yZSBjb25jcmV0ZSB0ZXh0IG9yIHJlZmVyZW5jZXMu DQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSBjb21tZW50cyENCg0KcmVnYXJkcw0KDQpKaWF6 aQ0KDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4N CkRhdGU6IE1vbiwgSnVsIDI1LCAyMDE2IGF0IDExOjU2IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMS50 eHQNClRvOiBCZW5vaXQgUGFycmVpbiA8QmVub2l0LlBhcnJlaW5AcG9seXRlY2gudW5pdi1uYW50 ZXMuZnI8bWFpbHRvOkJlbm9pdC5QYXJyZWluQHBvbHl0ZWNoLnVuaXYtbmFudGVzLmZyPj4sIEpp YXppIFlpIDxqaWF6aUBqaWF6aXlpLmNvbTxtYWlsdG86amlhemlAamlheml5aS5jb20+PiwgQmVu b2l0IFBhcnJlaW4gPGJlbm9pdC5wYXJyZWluQHBvbHl0ZWNoLnVuaXYtbmFudGVzLmZyPG1haWx0 bzpiZW5vaXQucGFycmVpbkBwb2x5dGVjaC51bml2LW5hbnRlcy5mcj4+DQoNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTExLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWF6aSBZaSBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0Zi1tYW5l dC1vbHNydjItbXVsdGlwYXRoDQpSZXZpc2lvbjogICAgICAgMTENClRpdGxlOiAgICAgICAgICBN dWx0aS1wYXRoIEV4dGVuc2lvbiBmb3IgdGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcg UHJvdG9jb2wgdmVyc2lvbiAyIChPTFNSdjIpDQpEb2N1bWVudCBkYXRlOiAgMjAxNi0wNy0yNQ0K R3JvdXA6ICAgICAgICAgIG1hbmV0DQpQYWdlczogICAgICAgICAgMjQNClVSTDogICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tYW5ldC1v bHNydjItbXVsdGlwYXRoLTExLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1v bHNydjItbXVsdGlwYXRoLTExDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMQ0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGktcGF0aCBleHRlbnNpb24g Zm9yIHRoZSBPcHRpbWl6ZWQgTGluaw0KICAgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9u IDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGUNCiAgIGRpc2pvaW50IHBhdGhzLCBzbyBh cyB0byBpbXByb3ZlIHJlbGlhYmlsaXR5IG9mIHRoZSBPTFNSdjIgcHJvdG9jb2wuDQogICBUaGUg aW50ZXJvcGVyYWJpbGl0eSB3aXRoIE9MU1J2MiBpcyByZXRhaW5lZC4NCg0KDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVz IHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMKaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3 aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkKYW5kL29yIGNvbmZpZGVudGlhbC4g SXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsCm9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIG9yaWdp bmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRo ZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgYW5kIHRoYXQgYW55IHVzZSwgZGlzc2Vt aW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yCmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJv ciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --_000_f87886d2eb374215b755388d58a3219dVAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5KaWF6aSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QUNLLiBHaXZlIEp1c3RpbiBhbmQgbXlzZWxmIGEgY291cGxlIG9mIGRheXMgdG8g ZGlzY3Vzcy4gU29ycnkgYWJvdXQgdGhhdCwgYnV0IG15IHNjaGVkdWxlIGhhcyBiZWVuIGNyYXp5 IGxhdGVseS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1hbmV0IFttYWlsdG86bWFu ZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmlhemkgWUk8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjYsIDIwMTYgNzo0MyBBTTxicj4NCjxiPlRvOjwv Yj4gbWFuZXQgJmx0O21hbmV0QGlldGYub3JnJmd0OzsgSnVzdGluIERlYW4gJmx0O2JlYmVtYXN0 ZXJAZ21haWwuY29tJmd0OzsgU3RhbiBSYXRsaWZmICZsdDtyYXRsaWZmc3RhbkBnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTExLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGNoYWly cywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBvbHNydjItbXVsdGlwYXRoIGRvY3VtZW50IGhhcyBiZWVuICZxdW90O0luIFdHIExhc3QgQ2Fs bCZxdW90OyBmb3IgbW9yZSB0aGFuIHR3byBtb250aHMgKHNpbmNlIEp1bmUgOHRoIC0tIEkgc3Vw cG9zZSBpdCBzaG91bGQgYmUgbG9uZyBlbm91Z2ggbm93IDspLiBDb3VsZCB5b3UgcGxlYXNlIGFk dmljZSB0aGUgbmV4dCBzdGVwcyB0byB0YWtlIHJlZ2FyZGluZyB0aGUgZHJhZnQ/Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZh ciBhcyBJIGNhbiBzZWUsIGFsbCB0aGUgbWFqb3IgaXNzdWVzIHJhaXNlZCBoYXZlIGJlZW4gdGFr ZW4gY2FyZSBvZi4gVGhlcmUgYXJlIHNvbWUgdGV4dCB0byBiZSByZXBocmFzZWQsIGJ1dCBjYW4g YmUgZWFzaWx5IGRvbmUgaW4gdGhlIG5leHQgcmV2aXNpb24uJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlc3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Smlhemk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwg MjYsIDIwMTYgYXQgMTI6MDYgQU0sIEppYXppIFlJICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBq aWF6aXlpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAamlheml5aS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgYWxsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBv ZiBvbHNydjItbXVsdGlwYXRoLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdXBkYXRlIGlzIGJhc2VkIG9uIHRoZSBjb21tZW50 cyBhbmQgZGlzY3Vzc2lvbiBmcm9tIHRoZSB0aHJlYWQmbmJzcDs8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTkxNjQuaHRtbCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFu ZXQvY3VycmVudC9tc2cxOTE2NC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlciB0aGFuIHRoZSBlZGl0b3JpYWwgY2hhbmdl cywgYW4gdXBkYXRlIGlzIHRoYXQgd2UgYWRkZWQgYW4gMS1vY3RldCB2YWx1ZSBmaWVsZCBpbiB0 aGUgU09VUkNFX1JPVVRFIFRMViB0byBjYXJyeSBhIG11bHRpcGxpZXIgaW5mb3JtYXRpb24uIFRo aXMgaXMgdG8gbWFrZSB0aGUgaG9sZGluZyB0aW1lIG9mIHRoZSBTUi1PTFNSdjIgUm91dGVyIFR1 cGxlIGNhbiBiZSBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZQ0KIGluZm9ybWF0aW9uIGNhcnJpZWQg aW4gdGhlIEhFTExPL1RDIG1lc3NhZ2VzLCByYXRoZXIgdGhhbiBhIHJvdXRlcidzIHByZWRlZmlu ZWQgaG9sZGluZyB0aW1lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBlcmFzdXJlIGNvZGluZywg d2UgdGVtcG9yYXJpbHkgcmVtb3ZlZCB0aGUgc2VudGVuY2UgJnF1b3Q7QnkgZGVmaW5pdGlvbiwg ZXJhc3VyZSBjb2RpbmcgaXMgaW5zZW5zaXRpdmUgdG8gdGhlIHBhY2tldCBtaXNvcmRlcmluZy4m cXVvdDsuIEknbGwgaGF2ZSBmdXJ0aGVyIGV4Y2hhbmdlIHdpdGggQmVub2l0IHRvIGhhdmUgbW9y ZSBjb25jcmV0ZSB0ZXh0IG9yIHJlZmVyZW5jZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIHZlcnkgbXVj aCBmb3IgdGhlIGNvbW1lbnRzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkppYXppPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpG cm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogTW9u LCBKdWwgMjUsIDIwMTYgYXQgMTE6NTYgUE08YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMS50eHQ8YnI+ DQpUbzogQmVub2l0IFBhcnJlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpCZW5vaXQuUGFycmVpbkBw b2x5dGVjaC51bml2LW5hbnRlcy5mciIgdGFyZ2V0PSJfYmxhbmsiPkJlbm9pdC5QYXJyZWluQHBv bHl0ZWNoLnVuaXYtbmFudGVzLmZyPC9hPiZndDssIEppYXppIFlpICZsdDs8YSBocmVmPSJtYWls dG86amlhemlAamlheml5aS5jb20iIHRhcmdldD0iX2JsYW5rIj5qaWF6aUBqaWF6aXlpLmNvbTwv YT4mZ3Q7LCBCZW5vaXQgUGFycmVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbm9pdC5wYXJyZWlu QHBvbHl0ZWNoLnVuaXYtbmFudGVzLmZyIiB0YXJnZXQ9Il9ibGFuayI+YmVub2l0LnBhcnJlaW5A cG9seXRlY2gudW5pdi1uYW50ZXMuZnI8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTEu dHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWF6aSBZaSBhbmQg cG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi1tYW5ldC1vbHNy djItbXVsdGlwYXRoPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTE8 YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE11bHRpLXBhdGgg RXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2 ZXJzaW9uIDIgKE9MU1J2Mik8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE2LTA3LTI1PGJy Pg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtYW5ldDxicj4NClBh Z2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjQ8YnI+DQpVUkw6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0 aC0xMS50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTEudHh0PC9hPjxicj4N ClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlw YXRoLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBh dGgtMTE8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEx PC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyBhIG11bHRpLXBhdGggZXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbms8 YnI+DQombmJzcDsgJm5ic3A7U3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2 MikgdG8gZGlzY292ZXIgbXVsdGlwbGU8YnI+DQombmJzcDsgJm5ic3A7ZGlzam9pbnQgcGF0aHMs IHNvIGFzIHRvIGltcHJvdmUgcmVsaWFiaWxpdHkgb2YgdGhlIE9MU1J2MiBwcm90b2NvbC48YnI+ DQombmJzcDsgJm5ic3A7VGhlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBPTFNSdjIgaXMgcmV0YWlu ZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRm Lm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJy PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogIzAwMzM2NjsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPlRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWluczxicj5pbmZvcm1hdGlvbiBmcm9tIGlEaXJl Y3QsIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeTxicj5hbmQvb3IgY29uZmlk ZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWw8YnI+b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgb3JpZ2luYWw8YnI+cmVjaXBpZW50IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9y IGRlbGl2ZXJpbmcgdGhlIGVtYWlsIHRvIHRoZTxicj5pbnRlbmRlZCByZWNpcGllbnQsIGJlIGFk dmlzZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsPGJyPmluIGVycm9yLCBhbmQg dGhhdCBhbnkgdXNlLCBkaXNzZW1pbmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3I8YnI+ Y29weWluZyBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNl aXZlZCB0aGlzIGVtYWlsPGJyPmluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1lZGlh dGVseSBub3RpZnkgdGhlIHNlbmRlci48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC9ib2R5Pg0KPC9odG1sPg0K --_000_f87886d2eb374215b755388d58a3219dVAUSDITCHM2idirectnet_-- From nobody Fri Aug 26 08:58:36 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB59612D0C6 for ; Fri, 26 Aug 2016 08:58:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org 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 6dlZQycZfzfu for ; Fri, 26 Aug 2016 08:58:33 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8DDC512D0E1 for ; Fri, 26 Aug 2016 08:58:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 781642662C0 for ; Fri, 26 Aug 2016 08:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1472227113; bh=f7/IX1NCOaBzNF1OJJrsv9hCLiFt7PzruO+p/xEYdDQ=; h=From:Subject:Date:To:From; b=gIQU1MXkj/KsFoYXBdEcYXccloiKpQ9JUntNNul+1Rc7E1eg1TvBiS9gQSMNL3fiZ arL6wszudj8RrKKBM5c0QVxFGvi1hUfvc7pQU/bP0nJq+TOaoZUdUHv6wCorV540S3 Ydb2gd3mVLGDOr/rf70jEyBDAGDICUcWONLkiZ8I= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.51] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B25EA266309 for ; Fri, 26 Aug 2016 08:58:32 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_387A14E7-8FC4-457B-AAAE-6BF9A3C84951" Message-Id: <71189398-8C9E-4C81-A600-02856E1ECD04@thomasclausen.org> Date: Fri, 26 Aug 2016 17:58:30 +0200 To: manet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [manet] Berlin minutes ? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:58:35 -0000 --Apple-Mail=_387A14E7-8FC4-457B-AAAE-6BF9A3C84951 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, As I was not able to attend the latest Berlin meeting, I wanted to check = the meeting minutes to understand if the WG was heading anywhere = (rechartering etc. having happened, and such), and if so where and what = the strategy for getting there would be.=20 Having not seen any announcement on the list that the minutes had been = posted (!), I was (pleasantly) surprised to see that they were actually = on-line here: =09 https://www.ietf.org/proceedings/96/minutes/minutes-96-manet Until, that is, I saw the annotation in the top of the minutes that: "NOTE: There are a number of inaccuracies in the minutes. Please = refer to the audio in case=20 of doubts: = https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-20160720-1400.mp3= " Given that there=E2=80=99s no indication *where* in the minutes there = are inaccuracies, or if those are merely details or are = misrepresentation, or are omissions, let alone where in the minutes = there are inaccuracies, this is not terribly helpful. Posting minutes, known to be inaccurate, is a first to me =E2=80=94 and = actually explicitly contradicts RFC2026 section 8 which requires = maintaining "complete and accurate minutes of meetings=E2=80=9D. Shall I assume that these are just a =E2=80=9Cplaceholder=E2=80=9D until = the chairs are able to produce =E2=80=9Ccomplete and accurate minutes=E2=80= =9D =E2=80=94 in which case, any estimate as to when that might be?=20 Not having been able to attend the meeting this time, I=E2=80=99m not = able to rely on my own recollection of what went down to =E2=80=9Cfilter=E2= =80=9D the inaccuracies. Thanks, Thomas= --Apple-Mail=_387A14E7-8FC4-457B-AAAE-6BF9A3C84951 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

As I = was not able to attend the latest Berlin meeting, I wanted to check the = meeting minutes to understand if the WG was heading anywhere = (rechartering etc. having happened, and such), and if so where and what = the strategy for getting there would be. 

Having not seen any announcement on the = list that the minutes had been posted (!),  I was (pleasantly) = surprised to see that they were actually on-line here:
=
https://www.ietf.org/proceedings/96/minutes/minutes-96-manet

Until, that is, I saw the = annotation in the top of the minutes that:

"NOTE: There are a number of = inaccuracies in the minutes. Please refer to the audio in = case 
of doubts: https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-201607= 20-1400.mp3"

Given that there=E2=80=99s no indication *where* in the = minutes there are inaccuracies, or if those are merely details or are = misrepresentation, or are omissions, let alone where in the minutes = there are inaccuracies, this is not terribly helpful.

Posting minutes, known = to be inaccurate, is a first to me =E2=80=94 and actually explicitly = contradicts RFC2026 section 8 which requires maintaining "complete and accurate minutes of meetings=E2=80=9D.
<= div class=3D"">
Shall I assume that = these are just a =E2=80=9Cplaceholder=E2=80=9D until the chairs are able = to produce =E2=80=9Ccomplete and accurate minutes=E2=80=9D =E2=80=94 in = which case, any estimate as to when that might be? 

Not having been able to = attend the meeting this time, I=E2=80=99m not able to rely on my own = recollection of what went down  to =E2=80=9Cfilter=E2=80=9D the = inaccuracies.

Thanks,

Thomas
= --Apple-Mail=_387A14E7-8FC4-457B-AAAE-6BF9A3C84951-- From nobody Fri Aug 26 13:41:52 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12E112B047 for ; Fri, 26 Aug 2016 13:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lMVr0PK88BmN for ; Fri, 26 Aug 2016 13:41:49 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 0018212B02F for ; Fri, 26 Aug 2016 13:41:48 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id m60so117217288uam.3 for ; Fri, 26 Aug 2016 13:41:48 -0700 (PDT) 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; bh=qE9L7mCTs5EGrmbBldn8sfO8jBcIlIa5kdC+MmrgMnw=; b=zXHeUUsO9U9Qad4gXRltT44neh8sKnqc6CYLkUkyrq4BNm9aFh34GFzHOkbwzZsLc+ +dYU70NpHXDn2I9yvuIbdHlF1x6+xqdnkjya8zi7A2yl0QYuEiE7bb+HS44IA8Bv97ZO ZMIe9Z12JoRwDouykcSDuyJN3GHREeIekxRFzzTb2XbgJ0Wy2H4V4zYbu5Is7EaBhBDO IEYnG2bsSbZrco4wjojT8fQIbg1f/pXTEc7cTC7uuuZgkaZgBVIFD9FACa1jXehqh0eP JtR4KjfILW4Oydpuwcmt+NXczAB9pZBl+DeDKPkS3vmODfB4bxBk/XRVLp+eAlgxzAkT rr0w== 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; bh=qE9L7mCTs5EGrmbBldn8sfO8jBcIlIa5kdC+MmrgMnw=; b=lE9rJgHetlbbDMqkfwOeE4O/HCAhulmDup+8smbQwTQTlBv9O/xDMzZ5J0WttlvPEc p/4DlBWIRBkbzvSdd5NX90GDsRX6TX6EGMwF+EXxZuCYoH6gnMdLve3JQHmVgUA+QUb/ 1P/3axY70czPDy57zvTslI8KMBFC9RrLds+y5zhXaqEfWa5bTf4y4rZR0vsVEFq4QiOy 289+P4wYk5+HvNA0ufEWpWj+AtieaOS87v1mxRp6yq9b4Md9iTCAKXV2yv1YoJrIyni/ aaxNaQR4kiz4tugDLC1YvY13nQ83cgTiewP7f6OS4vgnb7GyA4zeurXG5tzIZAILiM0M 9Z2g== X-Gm-Message-State: AE9vXwO/2vPBYjw1OO1q5OP6hQAbi1C6mvzlZVQb7fgUejUucJZ2WwV0oUH41FrMizWdwYDhQ9LPUkSEfO5MFg== X-Received: by 10.31.107.150 with SMTP id k22mr3484942vki.56.1472244108026; Fri, 26 Aug 2016 13:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.38 with HTTP; Fri, 26 Aug 2016 13:41:47 -0700 (PDT) In-Reply-To: <71189398-8C9E-4C81-A600-02856E1ECD04@thomasclausen.org> References: <71189398-8C9E-4C81-A600-02856E1ECD04@thomasclausen.org> From: Justin Dean Date: Fri, 26 Aug 2016 16:41:47 -0400 Message-ID: To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=001a114785fc14ea2e053aff8bbf Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Berlin minutes ? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:41:51 -0000 --001a114785fc14ea2e053aff8bbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At the Berlin meeting we had a new volunteer to take the minutes for the meeting. When going to post the minutes which were taken it was noticed that they were not fully complete. Not having the time to revisit the audio and fix them we posted what was provided by the minute taker along with the notice and a link to the audio so people wouldn't be misled with regard to their completeness. We would be more than happy to have someone go over the audio and flush out the minutes. I have the first "free" weekend in quite some time so I hope to make progress on various MANET fronts. Justin On Fri, Aug 26, 2016 at 11:58 AM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > Hi, > > As I was not able to attend the latest Berlin meeting, I wanted to check > the meeting minutes to understand if the WG was heading anywhere > (rechartering etc. having happened, and such), and if so where and what t= he > strategy for getting there would be. > > Having not seen any announcement on the list that the minutes had been > posted (!), I was (pleasantly) surprised to see that they were actually > on-line here: > https://www.ietf.org/proceedings/96/minutes/minutes-96-manet > > Until, that is, I saw the annotation in the top of the minutes that: > > * "NOTE: There are a number of inaccuracies in the minutes. Please refer > to the audio in case * > * of doubts: > https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-20160720-1400.mp= 3 > "* > > Given that there=E2=80=99s no indication *where* in the minutes there are > inaccuracies, or if those are merely details or are misrepresentation, or > are omissions, let alone where in the minutes there are inaccuracies, thi= s > is not terribly helpful. > > Posting minutes, known to be inaccurate, is a first to me =E2=80=94 and a= ctually > explicitly contradicts RFC2026 section 8 which requires maintaining *"com= plete > and accurate minutes of meetings=E2=80=9D*. > > Shall I assume that these are just a =E2=80=9Cplaceholder=E2=80=9D until = the chairs are > able to produce =E2=80=9Ccomplete and accurate minutes=E2=80=9D =E2=80=94= in which case, any > estimate as to when that might be? > > Not having been able to attend the meeting this time, I=E2=80=99m not abl= e to rely > on my own recollection of what went down to =E2=80=9Cfilter=E2=80=9D the= inaccuracies. > > Thanks, > > Thomas > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114785fc14ea2e053aff8bbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the Berlin meeting we had a new volunteer to take = the minutes for the meeting.=C2=A0 When going to post the minutes which wer= e taken it was noticed that they were not fully complete.=C2=A0 Not having = the time to revisit the audio and fix them we posted what was provided by t= he minute taker along with the notice and a link to the audio so people wou= ldn't be misled with regard to their completeness.=C2=A0 We would be mo= re than happy to have someone go over the audio and flush out the minutes. =

I have the first "free" weekend in quite some = time so I hope to make progress on various MANET fronts.

=
Justin

On Fri, Aug 26, 2016 at 11:58 AM, Thomas Heide Clausen <ietf@tho= masclausen.org> wrote:
Hi,

As I was not able to= attend the latest Berlin meeting, I wanted to check the meeting minutes to= understand if the WG was heading anywhere (rechartering etc. having happen= ed, and such), and if so where and what the strategy for getting there woul= d be.=C2=A0

Having not seen any announcement on th= e list that the minutes had been posted (!), =C2=A0I was (pleasantly) surpr= ised to see that they were actually on-line here:
Until, that is, I saw the annotation in the top of the minut= es that:

= "NOTE: There are a number = of inaccuracies in the minutes. Please refer to the audio in case=C2=A0

Given that there=E2=80= =99s no indication *where* in the minutes there are inaccuracies, or if tho= se are merely details or are misrepresentation, or are omissions, let alone= where in the minutes there are inaccuracies, this is not terribly helpful.=

Posting minutes, known to be inaccurate, is a fir= st to me =E2=80=94 and actually explicitly contradicts RFC2026 section 8 wh= ich requires maintaining "complete and accurate minutes of meetings= =E2=80=9D.

Shall I assume that these are just = a =E2=80=9Cplaceholder=E2=80=9D until the chairs are able to produce =E2=80= =9Ccomplete and accurate minutes=E2=80=9D =E2=80=94 in which case, any esti= mate as to when that might be?=C2=A0

Not having be= en able to attend the meeting this time, I=E2=80=99m not able to rely on my= own recollection of what went down =C2=A0to =E2=80=9Cfilter=E2=80=9D the i= naccuracies.

Thanks,

Thom= as

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


--001a114785fc14ea2e053aff8bbf-- From nobody Fri Aug 26 15:39:53 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 381D912D0B1; Fri, 26 Aug 2016 15:39:52 -0700 (PDT) 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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147225119220.28435.6013025524065718623.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2016 15:39:52 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-sec-threats-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 22:39:52 -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-06.txt Pages : 15 Date : 2016-08-26 Abstract: This document analyzes security threats of the Simplified Multicast Forwarding (SMF) mechanism, including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. This document also updates RFC7186 regarding the threats to relay set selection mechanisms using RFC6130. 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-sec-threats-06 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 Aug 26 15:44:02 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD2126D74; Fri, 26 Aug 2016 15:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h_m0vKneWPCN; Fri, 26 Aug 2016 15:43:57 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 14CE012B05E; Fri, 26 Aug 2016 15:43:57 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id f93so66103522lfi.2; Fri, 26 Aug 2016 15:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nptLnSQR0DUfaxPsEK5+kSjLlSqaGqz2gHojpONoD78=; b=FtIzfFtsJXozQgztqHvaUuLDUN4kgHIxs8sj5abRlTZa9OhQXNy1lZZNVPdVOGH2Qj BAgZg2CgjSOSkeA4blgDpkHfO3jQELXNbTXjQAnzFnz8K9ys38biJ2r+JfukIOmiDoSB tqdvLoO4BsUvxBq0MKDcELLBqAofjw4RYidZ31WKZbE5mft/RE1AodmsGce2PhNwxBbj K+EBYDwwxHc4DuGBukIMu+gaLrMZEHVf5m25P5dx+uc6aU4a02U0ZiqS7Yta2h7+GEeY WNs0yJ1ybewOuAL8GmCxwDBX0e+FqQNJdAiJhzIIczJofYeejEsb0i0tpM7bQdQEyMex rXpg== 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:from :date:message-id:subject:to:cc; bh=nptLnSQR0DUfaxPsEK5+kSjLlSqaGqz2gHojpONoD78=; b=bRxjlNeHD25nJCayfwYjcStzYURTiLnleDU/8JHgvDjwfvvIAWQPu8yqXdDNhs/ep9 NuB7Cu0/a2j8vhoLLYXEAOUkQ9vgM0ElfxXtDlJlAS6KEc+R7FK2xe7SukYr2kehUrNC yN7VWaTC55FFiS/4PPWwL3rJPTclnqVk2jnnUKqT0nADzzTw53gP6dlCL10MHHwfsaaQ nrSA8M5eLpc2E3wxnPK2qjcIzEGoC7VIXoSe3DDzYWET5Zlx7XqW/vAxYB/AFYa5+0a6 MBxiLCMiSWV5u1GZrL+sMQOVe0RrmOzJbKwMX3XzVx1Zfr0fa7M6uNTpVRPb1tUrgywk sBCg== X-Gm-Message-State: AE9vXwOw8jWWwRJPE2IONXpm7C5CuIZnpooksQaqALKMEamb9uOtk9SaQR6I7PIX7NCXdveYMYK3xWt/OCCzNg== X-Received: by 10.25.24.30 with SMTP id o30mr2358580lfi.58.1472251435107; Fri, 26 Aug 2016 15:43:55 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.184.2 with HTTP; Fri, 26 Aug 2016 15:43:54 -0700 (PDT) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF64A871DE8@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF64A871DE8@eusaamb107.ericsson.se> From: Jiazi YI Date: Sat, 27 Aug 2016 00:43:54 +0200 X-Google-Sender-Auth: b_S5Ux4N3cgNsBQ29psKvfwE0Ps Message-ID: To: Eric Gray Content-Type: multipart/alternative; boundary=001a11401606cf4af8053b013ff8 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-smf-sec-threats@tools.ietf.org" Subject: Re: [manet] RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 22:44:00 -0000 --001a11401606cf4af8053b013ff8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Eric, all: Thanks very much for your review and comments. We just submitted a new revision based on the comments received. 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-06 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-sec-threats-06 Please find the reply inline: On Tue, Aug 9, 2016 at 9:26 PM, Eric Gray wrote: > > > Major Issues: > > No major issues found. > > > > Minor Issues: > > RFC 6621 discusses a few security issues which do not look to have been > referenced in this draft, even indirectly. There are good reasons why th= is > is unusual. > More explicit references to the security consideration section of RFC6621 are added both in the introduction and related sections. > Similarly, while the draft does make at least an oblique reference to the > security issues that apply to RFC 6130, it is not clear without extensive > reading what this draft addresses that is not (at least sufficiently) > addressed there (or in RFC 7186). > > > Toward the end of the first paragraph in section 3 (SMF Threats Overview)= , > the draft makes an assertion that is not consistent with other text in th= e > same paragraph; it claims that =E2=80=9CSMF relies on NHDP=E2=80=9D while= other text, > including text in the same paragraph, seems strongly to indicate that NHD= P > is *one alternative approach that might be used*. > > > Note that I was unable to parse part of this same sentence: what does > =E2=80=9C(not matter if other =E2=80=A6 for 1-hop neighbor discovery)=E2= =80=9D mean? > SMF requires 1-hop and 2-hop neighbourhood information to reduce the relay set. SMF allows alternative low-layer information to provide necessary neighbourhood information -- but that's only for 1-hop neighbourhood. But for 2-hop neighbour information, only NHDP is used in SMF. We clarified the difference in the section. > > > Section 4.1.1 (Replay Attack) appears to address an issue that a) is not > necessarily a control plane attack (as implied in the first paragraph), > and b) is clearly a variation of a threat described in the Security > Considerations section of RFC 6621 as a DoS attack. Because the specific > threat in both cases (the case described in this section and that describ= ed > in RFC 6621) involves using some means of delivering bogus packets earlie= r > than subsequent legitimate packets, this does not (at least intuitively) > seem like a replay attack. > We changed the name of the section to Attack to Hop Limit to avoid ambiguity. > > > Section 4.2.1 =E2=80=93 Pre-activation Attacks (Pre-Play) =E2=80=93 simil= arly appears to > address one specific example of a second general class of threat describe= d > in the Security Considerations section of RFC 6621 (issues with use of > predictable sequencing techniques). > > > > The same applies to section 4.2.2 =E2=80=93 De-activation attacks. > > > It would be useful if the leading text in section 4.2 talked generally > about the related attack vector described in the Security Considerations > section of RFC 6621 and why this draft needs to expand on this class of > threat (associated with I-DPD) described there. > > > Section 4.3 also similarly provides an expansion on a class of threats > (associated with H-DPD) already described in RFC 6621. > > > In general, I feel that the expansions provided in section 4 of this draf= t > provide useful information =E2=80=93 as examples, at least. However, thi= s section > should explicitly refer to applicable text in RFC 6621, which includes > suggestions on ways to mitigate these threats. If the authors and/or the > working group feel that the suggestions made in RFC 6621 are insufficient= , > it would be useful to say why this is the case in this document. > We added references to related sections in RFC6621 and explained why those are expanded in this document at the begin of section 4. > > > The sentence comprising section 5.1 (Relay Set Selection Common Threats) > does not appear to be correct as written; RFC 7186 does not include > anything about RSS algorithms. To the extent that RSS MAY depend on NHDP= , > RFC 7186 does describe threats to NHDP that would impact RSS for these > cases. Arguably the same threats may apply independent of how SMF router= s > become aware of the neighborhood topology, but this is not (and possibly > cannot be) known without exhaustive analysis of all methods by which this > information might be determined. > The RSS is based on the neighbourhood information obtained from the control plane. For SMF, as far as I can see, only NHDP is used in practice to obtain neighbourhood information. So the common threats listed in section 5.1 such as DoS, eavesdropping, etc. can be applied to SMF directly -- that's also one of the purpose of having RFC7186 as an independent document: related content can be reused by protocols such as SMF and OLSRv2. > > In Section 5.2 (Threats to E-CDS Algorithm), RFC 5614 is given as a > reference for =E2=80=9CEssential Connected Dominating Set=E2=80=9D (or th= e E-CDS > algorithm), when RFC 5614 actually does not mention either one (it define= s > CDS and talks about a small number of algorithms =E2=80=93 none of which = are > directly related to E-CDS; the word =E2=80=9Cessential=E2=80=9D does not = appear to be > included in the RFC anywhere). I was not able to find a reference for th= is > term in a few minutes of poking around, though it is easy enough to find > references for =E2=80=9Cminimum connected dominating set.=E2=80=9D > > In RFC6621, RFC5614 is cited when the E-CDS is introduced: The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] forms a single CDS mesh for the SMF operating region. Although =E2=80=9CEssential Connected Dominating Set=E2=80=9D is not explic= itly used in RFC5614, as a derivative, I think it's still appropriate (and even necessary) to cite the original source? > > The Security Considerations section (section 7) of this draft should > provide a summary of security issues included or addressed in this docume= nt > (directly or indirectly by reference) as well as any related security > issues yet to be addressed. Minimally, if the authors feel that this > information is provided in section 3 (SMF Threats Overview), the Security > Considerations section should say this. One approach would be to use the > Security Considerations section to summarize the main content of the > document. > > By taking consideration of the comments from AD, we summarised the content of the document and merged the "future work" section in this Security Considerations section. > > > Nits: > > I had a number of issues with =E2=80=9Cesoteric questions of English usag= e.=E2=80=9D > However, according to our instructions, =E2=80=9Cthe RFC Editor will spot= these, > and it is not a wise use of time to discuss these things.=E2=80=9D > > > RFC editor is the best teacher to tell us how to write English correctly -- especially for non-native English speakers like me :) Thanks again for your comments!! regards Jiazi > J > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11401606cf4af8053b013ff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Eric, all:=C2=A0

Thanks very much = for your review and comments. We just submitted a new revision based on the= comments received.=C2=A0

The IETF datatracker status page for this draft is:
= ht= tps://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/<= /a>
There's = also a htmlized version available at:
https://tools.ietf.org/html/draft= -ietf-manet-smf-sec-threats-06
A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-sec-threats-06
=C2=A0

Please fin= d the reply inline:

On Tue, Aug 9, 2016 at 9:26 PM, Eric Gray <eric.gray@ericsson.c= om> wrote:

<snip>
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

=C2=A0

Major Issues: =

No major issues found.

=C2=A0

Minor Issues: =

RFC 6621 discusses a few= security issues which do not look to have been referenced in this draft, e= ven indirectly.=C2=A0 There are good reasons why this is unusual.


More explicit references to t= he security consideration section of RFC6621 are added both in the introduc= tion and related sections.=C2=A0
=C2=A0

Similarly, while the dra= ft does make at least an oblique reference to the security issues that appl= y to RFC 6130, it is not clear without extensive reading what this draft ad= dresses that is not (at least sufficiently) addressed there (or in RFC 7186).

=C2=A0

Toward the end of the fi= rst paragraph in section 3 (SMF Threats Overview), the draft makes an asser= tion that is not consistent with other text in the same paragraph; it claim= s that =E2=80=9CSMF relies on NHDP=E2=80=9D while other text, including text in the same paragraph, seems strongly to indicate tha= t NHDP is one alternative approach that might be used.=C2=A0

<= /div>

=

=C2=A0

Note that I was unable t= o parse part of this same sentence: what does =E2=80=9C(not matter if other= =E2=80=A6 for 1-hop neighbor discovery)=E2=80=9D mean?


SMF requires 1-hop and 2-hop neighbourh= ood information to reduce the relay set. SMF allows alternative low-layer i= nformation to provide necessary neighbourhood information -- but that's= only for 1-hop neighbourhood. But for 2-hop neighbour information, only NH= DP is used in SMF.=C2=A0
We clarified the difference in the secti= on.=C2=A0
=C2=A0

=C2=A0

Section 4.1.1 (Replay At= tack) appears to address an issue that a) is not necessarily a control plan= e attack (as implied in the first paragraph),

<= div>

and b) is clearly a = variation of a threat described in the Security Considerations section of RFC 6621 as a DoS attack.=C2=A0 Because the spec= ific threat in both cases (the case described in this section and that desc= ribed in RFC 6621) involves using some means of delivering bogus packets ea= rlier than subsequent legitimate packets, this does not (at least intuitively) seem like a replay attack.

=

We changed the name of the sec= tion to Attack to Hop Limit to avoid ambiguity.=C2=A0
=C2=A0
<= p class=3D"MsoNormal">

=C2=A0

Section 4.2.1 =E2=80=93 = Pre-activation Attacks (Pre-Play) =E2=80=93 similarly appears to address on= e specific example of a second general class of threat described in the Sec= urity Considerations section of RFC 6621 (issues with use of predictable sequencing techniques).=C2=A0

=C2=A0

The same applies to sect= ion 4.2.2 =E2=80=93 De-activation attacks.=C2=A0=C2=A0

=C2=A0

It would be useful if th= e leading text in section 4.2 talked generally about the related attack vec= tor described in the Security Considerations section of RFC 6621 and why th= is draft needs to expand on this class of threat (associated with I-DPD) described there.=C2=A0

<= /div>

=

=C2=A0

Section 4.3 also similar= ly provides an expansion on a class of threats (associated with H-DPD) alre= ady described in RFC 6621.

=C2=A0

In general, I feel that = the expansions provided in section 4 of this draft provide useful informati= on =E2=80=93 as examples, at least.=C2=A0 However, this section should expl= icitly refer to applicable text in RFC 6621, which includes suggestions on ways to mitigate these threats.=C2=A0 If the autho= rs and/or the working group feel that the suggestions made in RFC 6621 are = insufficient, it would be useful to say why this is the case in this docume= nt.


We added referen= ces to related sections in RFC6621 and explained why those are expanded in = this document at the begin of section 4.=C2=A0
=C2=A0

=C2=A0

The sentence comprising = section 5.1 (Relay Set Selection Common Threats) does not appear to be corr= ect as written; RFC 7186 does not include anything about RSS algorithms.=C2= =A0 To the extent that RSS MAY depend on NHDP, RFC 7186 does describe threats to NHDP that would impact RSS for the= se cases.=C2=A0 Arguably the same threats may apply independent of how SMF = routers become aware of the neighborhood topology, but this is not (and pos= sibly cannot be) known without exhaustive analysis of all methods by which this information might be determined.


The RSS is based on the= neighbourhood information obtained from the control plane. For SMF, as far= as I can see, only NHDP is used in practice to obtain neighbourhood inform= ation. So the common threats listed in section 5.1 such as DoS, eavesdroppi= ng, etc. can be applied to SMF directly -- that's also one of the purpo= se of having RFC7186 as an independent document: related content can be reu= sed by protocols such as SMF and OLSRv2.=C2=A0

=

=C2=A0

In Section 5.2 (Threats = to E-CDS Algorithm), RFC 5614 is given as a reference for =E2=80=9CEssentia= l Connected Dominating Set=E2=80=9D (or the E-CDS algorithm), when RFC 5614= actually does not mention either one (it defines CDS and talks about a small number of algorithms =E2=80=93 none of which are d= irectly related to E-CDS; the word =E2=80=9Cessential=E2=80=9D does not app= ear to be included in the RFC anywhere).=C2=A0 I was not able to find a ref= erence for this term in a few minutes of poking around, though it is easy enough to find references for =E2=80=9Cminimum connected domina= ting set.=E2=80=9D

=

In RFC6621, RFC5614 is cited when th= e E-CDS is introduced:=C2=A0

=C2=A0 =C2=A0The= "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]=
=C2=A0 =C2=A0forms a single CDS mesh for the SMF operating regio= n.=C2=A0

Although=C2=A0=E2=80=9CEssential Connected Dominating Set=E2=80=9D is not=C2=A0explici= tly used in RFC5614, as a derivative, I think it's still appropriate (a= nd even necessary) to cite the original=C2=A0source?=C2=A0

=C2=A0

The Security Considerati= ons section (section 7) of this draft should provide a summary of security = issues included or addressed in this document (directly or indirectly by re= ference) as well as any related security issues yet to be addressed. Minimally, if the authors feel that this infor= mation is provided in section 3 (SMF Threats Overview), the Security Consid= erations section should say this.=C2=A0 One approach would be to use the Se= curity Considerations section to summarize the main content of the document.

=

By taking consideration of the comme= nts from AD, we summarised the content of the document and merged the "= ;future work" section in this Security Considerations section.=C2=A0
=C2=A0

=C2= =A0

Nits:

I had a number of issues= with =E2=80=9Cesoteric questions of English usage.=E2=80=9D However, accor= ding to our instructions, =E2=80=9Cthe RFC Editor will spot these, and it i= s not a wise use of time to discuss these things.=E2=80=9D

=C2=A0

=

RFC editor is the best teacher= to tell us how to write English correctly -- especially for non-native Eng= lish speakers like me :)

Thanks again for your com= ments!!=C2=A0

regards

Jia= zi
=C2=A0

<= u>

J<= /span>

=C2=A0


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


--001a11401606cf4af8053b013ff8-- From nobody Sun Aug 28 21:33:28 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9512D0DA for ; Sun, 28 Aug 2016 21:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PPusDncbvcci for ; Sun, 28 Aug 2016 21:33:17 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 2A34412B01F for ; Sun, 28 Aug 2016 21:33:17 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id k90so226968738uak.1 for ; Sun, 28 Aug 2016 21:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qJNlz3Z+pYhdojLz5yyUz1MLDJIaZeGn8LK7ThYkU6o=; b=Lsrvhw+u255+UTEoaQo2rkUIMC7aMZ3hjkzAvSCu3UHJE2GWDM/fKrV71tel7Ew8uT a1erWJS45ChS3mvLF9MA7CT5uaxD/o26oXdRCoNbmrDTPgkn/GO8b1mN9uebOEb8l/pC ddyl0alVaGzmv888bhOP/h+I8c2vFfpOGHw5A6SNpRflfK0itzuUFpjnUz0DSRQIkyA8 bggSjx+8XraG2cYBAYxtPxchm9pIVQaZYk3nvpOaWUIddFY4sO9DSpV/FyRswc9zIC9v oY93Oh2xmlr8s7zg0XvntvOU/3WwDGXjMxLMJ4l/BEjoHyNZJj0iCoBimpdY50XoIlli TFGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qJNlz3Z+pYhdojLz5yyUz1MLDJIaZeGn8LK7ThYkU6o=; b=epWkQZIlruekaL11MQImlLhnGaWGvUsZEp+YD4xSs7EUjqd1V5n3lVwkODNh3KKjHX Rx207vooab8dHNtMBkgXDQAtdK86tbd6rUVJTsUt9NqA9o0SDPK7dOAVroKdPMdvQ4ip yS4pgWY09YvyAi2uMI73xq5XsiurMrxMqHFFqJS2xBJxMzUdofLv9Gq/g8Nf5jnijJq8 piKL4xYhKMBFoJ1rdYUea0yVARcI6+FPHKpOzSPik0mOrWpxa5z+ZNaz5lr+EN5pK+cx EzwU9t2KC2FxxqgXhIZqvTxpEe6yY6Zx602n0LhfVdI25xLd0YezCDCVRWBjzxrykgiD TDTw== X-Gm-Message-State: AE9vXwOyFj1/voD+ZXFtxln7HjV8v7hosgUG+ESNVWbubQEhQClhbt/1Kz7JNaNWJeSIoZYTYfbAyEj8fgZ6Kg== X-Received: by 10.159.54.140 with SMTP id p12mr8667374uap.19.1472445194345; Sun, 28 Aug 2016 21:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.38 with HTTP; Sun, 28 Aug 2016 21:33:13 -0700 (PDT) From: Justin Dean Date: Mon, 29 Aug 2016 00:33:13 -0400 Message-ID: To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03f484c2a1c1053b2e5cf4 Archived-At: Subject: [manet] OLSRv2 sec threats review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 04:33:24 -0000 --94eb2c03f484c2a1c1053b2e5cf4 Content-Type: text/plain; charset=UTF-8 As there weren't many on list comments during or after last call here is my detailed review. Summary is that I'm doing the writeup right now and passing it on up. Most of my comments are of the editorial type with exceptions which are minor and mostly clarification based. Apologies to the author team for not getting this done sooner; I wanted to make sure I did it right. Comments noted as JWD Network Working Group T. Clausen Internet-Draft U. Herberg Intended status: Informational Expires: November 10, 2016 J. Yi Ecole Polytechnique May 9, 2016 Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) draft-ietf-manet-olsrv2-sec-threats-02 Abstract This document analyzes common security threats of the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 10, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Clausen, et al. Expires November 10, 2016 [Page 1]Internet-Draft OLSRv2 Threats May 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . . 4 1.1.2. MPR Flooding . . . . . . . . . . . . . . . . . . . . . 5 1.1.3. Link State Advertisement . . . . . . . . . . . . . . . 5 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 5 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . . 6 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 7 3.2. Hop-count and Hop-limit Attacks . . . . . . . . . . . . . 7 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 7 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 9 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 11 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 11 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . . 11 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 14 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 14 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Inconsistent Topology Maps due to Link State Advertisements . . . . . . . . . . . . . . . . . . . . 16 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 18 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 19 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 20 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Clausen, et al. Expires November 10, 2016 [Page 2]Internet-Draft OLSRv2 Threats May 2016 1. Introduction The Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182], [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains the same basic algorithms as its predecessor, however offers various improvements, e.g., a modular and flexible architecture allowing extensions, such as for security, to be developed as add-ons to the basic protocol. [JWD] NIT: listing RFC7181 first would be helpful. The developments reflected in OLSRv2 have been motivated by increased real-world deployment experiences, e.g., from networks such as FunkFeuer [FUNKFEUER], and the requirements presented for continued successful operation of these networks. With participation in such networks increasing (the FunkFeuer community network has, e.g., roughly 400 individual participants at the time of publication of this document), operating with the assumption, that participants can be "trusted" to behave in a non-destructive way, is utopia. Taking the Internet as an example, as participation in the network increases and becomes more diverse, more efforts are required to preserve the integrity and operation of the network. Most SMTP-servers were, e.g., initially available for use by everyone on the Internet - with an increased populace on the Internet, attacks and abuses caused the recommended practice is today to require authentication and accounting for users of such SMTP servers [RFC5068]. [JWD] NIT language improvement....with an increase in users on the Internet, an increase in attacks and abuses followed necessitating a change in recommended practices; today authentication and accounting for users is required for use of SMTP servers [RFC5068]. As OLSRv2 often is used in wireless environments, it is potentially exposed to different kinds of security threats, some of which are of particular significance as compared to wired networks. As radio signals can be received as well as transmitted by any compatible wireless device within radio range, there is commonly no physical protection as otherwise known for wired networks. A first step towards hardening against attacks disrupting the connectivity of a network, is to understand the vulnerabilities of routing protocol, managing the connectivity. This document therefore analyzes OLSRv2, to understand its inherent vulnerabilities and resiliences. The authors do not claim completeness of the analysis, but hope that the identified attacks, as presented, form a meaningful starting-point for developing and deploying increasingly secured OLSRv2 networks. This document first describes security vulnerabilities to OLSRv2 when it is used without the mandatory-to-implement security mechanisms, as specified in Section 23.5 of [RFC7181]. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the Clausen, et al. Expires November 10, 2016 [Page 3]Internet-Draft OLSRv2 Threats May 2016 vulnerabilities are mitigated. This separation is important since other security mechanisms ([JWD] other) than the mandatory-to-implement ones may be used in a deployment, as explicitly stated in [RFC7181]: "Any deployment of OLSRv2 SHOULD use the security mechanism specified in [RFC7183] but MAY use another mechanism if more appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered." Moreover, this document is also based on the assumption that no additional security mechanism such as IPsec is used in the IP layer or other mechanisms on lower layers, as not all MANET deployments may be able to accommodate such common protection mechanisms (e.g., because of limited resources of MANET routers). The threats related to NHDP (Neighborhood Discovery Protocol) have been discussed in [RFC7186]. As NHDP is a fundamental block of OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2. It should be noted that many OLSRv2 implementations are configurable, and so an attack on the configuration system (such as [RFC6779] and [RFC7184]) can be used to adversely affect the operation of an OLSRv2 implementation. 1.1. OLSRv2 Overview OLSRv2 contains three basic processes: Neighborhood Discovery, MPR Flooding ([JWD] MPR election/flooding not just flooding?) and Link State Advertisements, described in the below with sufficient details for elaborating the analyses in this document. [JWD] NIT make above two separate sentences. 1.1.1. Neighborhood Discovery Neighborhood Discovery is the process, whereby each router discovers the routers which are in direct communication range of itself (1-hop neighbors), and detects with which of these it can establish bi- directional communication. Each router sends HELLO messages periodically, listing the identifiers of all the routers from which it has recently received a HELLO message, as well as the "status" of the link (heard or verified bi-directional). A router A receiving a HELLO message from a neighbor B, in which B indicates to have recently received a HELLO message from A, considers the link A-B to be bi-directional. As B lists identifiers of all its neighbors in its HELLO message, A learns the "neighbors of its neighbors" (2-hop neighbors) through this process. HELLO messages are sent periodically, however certain events may trigger non-periodic HELLOs. OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery mechanism. The vulnerabilities of NHDP are analyzed in [RFC7186]. Clausen, et al. Expires November 10, 2016 [Page 4]Internet-Draft OLSRv2 Threats May 2016 1.1.2. MPR Flooding Multi Point Relay (MPR) Flooding is the process whereby each router is able to efficiently conduct network-wide broadcasts. Each router designates, from among its bi-directional neighbors, a subset (MPR set) such that a multicast ([JWD] OLSRv2 specific multicast) message transmitted by the router and relayed by the MPR set can ([JWD] be) received by all its 2-hop neighbors. MPR selection is encoded in outgoing HELLO messages. ([JWD] NHDP HELLO messages) Routers may express, in their HELLO messages, their "willingness" (an integer between 0 "will never" and 7 "will always") to be selected as MPR, which is taken into consideration for the MPR calculation, and which is useful for example when an OLSRv2 network is "planned". The set of routers having selected a given router as MPR is the MPR- selector-set of that router. A study of the MPR flooding algorithm can be found in [MPR-FLOODING]. 1.1.3. Link State Advertisement Link State Advertisement is the process whereby routers are determining ([JWD] routers determine) which link state information to advertise through the network. Each router must advertise, at least, all links between itself and its MPR selectors, in order to allow all routers to calculate shortest paths. Such link state advertisements are carried in Topology Control (TC) messages, broadcast through the network using the MPR flooding process described above. As a router selects MPRs only from among bi-directional neighbors, links advertised in TC are also bi-directional and routing paths calculated by OLSRv2 contain only bi-directional links. TCs are sent periodically, however certain events may trigger non-periodic TCs. 1.2. Link State Vulnerability Taxonomy Proper functioning of OLSRv2 assumes that (i) each router signals its presence in the network and the topology information that it obtained honestly, (ii) each router can acquire and maintain a topology map, accurately reflecting the effective network topology; and (iii) that the network converges, i.e., that all routers in the network will have sufficiently identical topology maps. [JWD] Nit make above a list. An OLSRv2 network can be disrupted by breaking either ([JWD] any not either) of these assumptions, specifically (a) routers may be prevented from acquiring a topology map of the network; (b) routers may acquire a topology map that does not reflect the effective network topology; and (c) two or more routers may acquire inconsistent topology maps. Clausen, et al. Expires November 10, 2016 [Page 5]Internet-Draft OLSRv2 Threats May 2016 1.3. OLSRv2 Attack Vectors Besides "radio jamming", attacks on OLSRv2 consist of a compromised OLSRv2 router injecting "correctly looking, but invalid, control traffic" (TCs, HELLOs) into the network. A compromised OLSRv2 router can either (a) lie about itself (its identification, its willingness to serve as MPR), henceforth Identity Spoofing, or (b) lie about its relationship to other routers (pretend existence of links to other routers), henceforth Link Spoofing. Such attacks may disrupt the the Link State Advertisement process, through targeting the MPR Flooding mechanism, or by causing incorrect link state information to be included in TCs, causing routers to have incomplete, inaccurate or inconsistent topology maps. In a different class of attacks, a compromised OLSRv2 router injects control traffic, designed so as to cause an in-router resource exhaustion, e.g., by causing the algorithms calculating routing tables or MPR sets to be invoked continuously, preventing the internal state of a router from converging. 2. Terminology This document uses the terminology and notation defined in [RFC5444], [RFC6130] and [RFC7181]. Additionally, it defines the following terminology: Compromised OLSRv2 router: - An attacker that is present in the network and generates syntactically correct OLSRv2 control messages. Control messages emitted by a compromised OLSRv2 router may contain additional information, or omit information, as compared to a control message generated by a non-compromised OLSRv2 router located in the same topological position in the network. Legitimate OLSRv2 router: - An OLSRv2 router that is not a compromised OLSRv2 router. 3. Topology Map Acquisition Topology Map Acquisition relates to the ability for any given router in the network to acquire a representation of the network connectivity. A router, unable to acquire a topology map, is incapable of calculating routing paths and participating in forwarding data. Topology map acquisition can be hindered by (i) TCs to not being delivered to (all) routers in the network, such as what happens in case of Flooding Disruption, or (ii) in case of "jamming" of the communication channel. Clausen, et al. Expires November 10, 2016 [Page 6]Internet-Draft OLSRv2 Threats May 2016 The jamming and flooding disruption due to identity spoofing and link spoofing have been discussed in [RFC7186]. 3.1. Attack on Jittering OLSRv2 incorporates a jittering: a random, but bounded, delay on outgoing control traffic [RFC5148]. This may be necessary when link layers (such as 802.11 [IEEE802.11]) are used that do not guarantee collision-free delivery of frames, and where jitter can reduce the probability of collisions of frames on lower layers. In OLSRv2, TC forwarding is jittered by a value between 0 and MAX_JITTER. In order to reduce the number of transmissions, when a control message is due for transmission, OLSRv2 piggybacks all queued messages into a single transmission. Thus, if a compromised OLSRv2 router sends many TCs within a very short time interval, the jitter time of the attacked router tends to 0. This renders jittering ineffective and can lead to collisions on the link layer. In addition to causing more collisions, forwarding a TC with little or no jittering can make sure that the TC message forwarded by a compromised router arrives before the message forwarded by legitimate routers. The compromised router can thus inject malicious content in the TC, and the legitimate message will be discarded as ([JWD] a) duplicate message. This preemptive action is important for some of the attacks introduced in the following sections. 3.2. Hop-count and Hop-limit Attacks The hop-count and hop-limit fields are the only parts of a TC that are modified when forwarding. A compromised OLSRv2 router can modify either of these when forwarding TCs. [JWD] mention of the integrity TLV here which makes this statement true would be helpful. 3.2.1. Modifying the Hop Limit A compromised OLSRv2 router can decrease the hop limit when forwarding a TC. This will reduce the scope of forwarding the message, and may lead to some routers in the network not receiving that TC. Note that this is not necessarily the same as not relaying the message (i.e., setting the hop limit to 0), as illustrated in Figure 1. Clausen, et al. Expires November 10, 2016 [Page 7]Internet-Draft OLSRv2 Threats May 2016 .---. | X | --'---' __ / \ / \ .---. .---. TC -----> | A | | C | '---' '---' \ .---. / \-- | B |__/ '---' Figure 1: Hop Limit Attack. A TC arrives at and is forwarded by router A, such that it is received by both B and the malicious X. X can forward the TC without any delay (including without jitter) such that its transmissions arrives before that of B at C. Before forwarding, it significantly reduces the hop limit of the message. Router C receives the TC, processes (and forwards) it, and marks it as already received - causing it to discard further copies received from B. Thus, if the TC is forwarded by C, it has a very low hop limit and will not reach the whole network. 3.2.2. Modifying the Hop Count A compromised OLSRv2 router can modify the hop count when forwarding a TC. This may have two consequences: (i) if the hop count is set to the maximum value, then the TC will be forwarded no further by, or (ii) artificially manipulating the hop count may affect the validity time as calculated by recipients, when using distance-dependent validity times as defined in [RFC5497] (e.g., as part of a fish-eye extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]). v_time(1hop)=2s v_time(2hops)=4s v_time(3hops)=6s .---. .---. .---. .---. | A |-------> | B | -------> | X |---------->| C | `---' `---' `---' `---' Figure 2: Different validity times based on the distance in hops. In Figure 2, router A sends a TC with a validity time of two seconds for neighbors that are one hop away, four seconds for routers in a two-hop distance and six seconds in a three-hop distance. If X is a compromised OLSRv2 router and modifies the hop count (say, by decreasing it to 0), then C will calculate the validity time of received information to two seconds - after which it expires unless Clausen, et al. Expires November 10, 2016 [Page 8]Internet-Draft OLSRv2 Threats May 2016 refreshed. If TCs from A are sent less frequently than that up to 3 hops, this causes links advertised in such TCs to be only intermittently available to C. [JWD] this is a really good point! 4. Effective Topology Link-state protocols assume that each router can acquire an accurate topology map, reflecting the effective network topology. This implies that the routing protocol, through its message exchange, identifies a path from a source to a destination, and this path is valid for forwarding data traffic. If an attacker disturbs the correct protocol behavior, the perceived topology map of a router can permanently differ from the effective topology. Considering the example in Figure 3(a), which illustrates the topology map as acquired by router S. This topology map indicates that the routing protocol has identified that for S, a path exists to D via B, which it therefore assumes can be used for transmitting data. If, effectively, B does not forward data traffic from S, then the topology map in S does not accurately reflect the effective network topology. Rather, the effective network topology from the point of view of S would be as indicated in Figure 3(b): D is not part of the network reachable from router S. .---. .---. .---. .---. .---. | S |----| B |----| D | | S |----| B | `---' `---' `---' `---' `---' (a) (b) Figure 3: Incorrect Data Traffic Forwarding. Some of the attacks related to NHDP, such as message timing attack, indirect channel overloading have been discussed in [RFC7186]. Other threats specific to OLSRv2 are further detailed in this section. 4.1. Incorrect Forwarding OLSRv2 routers exchange information using link-local transmissions (link-local multicast or limited broadcast) for their control messages, with the routing process in each router retransmitting received messages destined for network-wide diffusion. Thus, if the operating system in a router is not configured to enable forwarding, this will not affect the operating of the routing protocol, or the topology map acquired by the routing protocol. It will, however, Clausen, et al. Expires November 10, 2016 [Page 9]Internet-Draft OLSRv2 Threats May 2016 cause a discrepancy between the effective topology and the topology map, as indicated in Figure 3(a) and Figure 3(b). [JWD] the term unicast forwarding should be used as without that term it may be assumed that forwarding of multicast is being disrupted which isn't the case. This situation is not hypothetical. A common error seen when deploying OLSRv2-based networks using Linux-based computers as router is to neglect enabling IP forwarding, which effectively becomes an accidental attack of this type. 4.2. Wormholes A wormhole, depicted in the example in Figure 4, may be established between two collaborating devices, connected by an out-of-band channel. These devices send traffic through the "tunnel" to their alter-ego, which "replays" the traffic. Thus, routers D and S appear as if direct neighbors and reachable from each other in 1 hop through the tunnel, with the path through the MANET being 100 hops long. .---. .---. | S |---- ....100-hop long path ... ---| D | `---. / `---' \ / \ / \X=============================X 1-hop path via wormhole Figure 4: Wormholing between two collaborating devices not participating in the routing protocol. The consequences of such a wormhole in the network depends on the detailed behavior of the wormhole. If the wormhole relays only control traffic, but not data traffic, the same considerations as in Section 4.1 applies. If, however, the wormhole relays all traffic, control and data alike, it is connectivity-wise identical to a usable link - and the routing protocol will correctly generate a topology map reflecting the effective network topology. The efficiency of the topology so obtained depends on (i) the wormhole characteristics, (ii) how the wormhole presents itself, and (iii) how paths are calculated. Assuming that paths are calculated with unit-cost for all links, including the "link" presented by the wormhole: if the real characteristics of the wormhole are as-if it was a path of more than 100 hops (e.g., with respect to delay, bandwidth, etc.), then the Clausen, et al. Expires November 10, 2016 [Page 10]Internet-Draft OLSRv2 Threats May 2016 presence of the wormhole results in a degradation in performance as compared to using the non-wormhole path. Conversely, if the "link" presented by the wormhole has better characteristics, the wormhole results in improved performance. If paths are calculated using non-unit-costs for all links, and if the cost of the "link" presented by the wormhole correctly represents the actual cost (e.g., if the cost is established through measurements across the wormhole), then the wormhole may in the worst case cause no degradation in performance, in the best case improve performance by offering a better path. If the cost of the "link" presented by the wormhole is misrepresented, then the same considerations as for unit-cost links apply. An additional consideration with regards to wormholes is, that such may present topologically attractive paths for the network - however it may be undesirable to have data traffic transit such a path: an attacker could, by virtue of introducing a wormhole, acquire the ability to record and inspect transiting data traffic. 4.3. Sequence Number Attacks OLSRv2 uses two different sequence numbers in TCs, to (i) avoid processing and forwarding the same message more than once (Message Sequence Number), and (ii) to ensure that old information, arriving late due to, e.g., long paths or other delays, is not allowed to overwrite fresher information (Advertised Neighbor Sequence Number - ANSN). 4.3.1. Message Sequence Number An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network, and transmitting a large number of TCs, each with different Message Sequence Numbers. Subsequent TCs with the same sequence numbers, originating from the router whose identity was spoofed, would hence be ignored, until eventually information concerning these "spoofed" TCs expires. [JWD] it should be mentioned that this is fixed with the signing TLV. 4.3.2. Advertised Neighbor Sequence Number (ANSN) An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network, and transmitting a single TC, with an ANSN significantly larger than that which was last used by the legitimate router. Routers will retain this larger ANSN as "the most fresh information" and discard subsequent TCs with lower sequence numbers as being "old". [JWD] again it should be mentioned that this is fixed with the signing TLV. Clausen, et al. Expires November 10, 2016 [Page 11]Internet-Draft OLSRv2 Threats May 2016 4.4. Indirect Jamming Indirect Jamming is an attack in which a compromised OLSRv2 router is, by its actions, causing legitimate routers to generate inordinate amounts of control traffic, thereby increasing both channel occupation and the overhead incurred in each router for processing this control traffic. This control traffic will be originated from legitimate routers, thus to the wider network, the malicious device may remain undetected. The general mechanism whereby a malicious router can cause indirect jamming is for it to participate in the protocol by generating plausible control traffic, and to tune this control traffic to in turn trigger receiving routers to generate additional traffic. For OLSRv2, such an indirect attack can be directed at, respectively, the Neighborhood Discovery mechanism and the Link State Advertisement mechanism. The most efficient indirect jamming attack in OLSRv2 is to target control traffic, destined for network-wide diffusion. This is illustrated in Figure 5. The malicious router X selects router A as MPR at time t0 in a HELLO. This causes X to appear as MPR selector for A and, consequently, A sets X to be advertised in its "Neighbor Set" and increments the associated "Advertised Neighbor Sequence Number" (ANSN). Router A must, then, advertise the link between itself and X in subsequent outgoing TCs (t1), also including the ANSN in such TCs. Upon X having received this TC, it declares the link between itself and A as no longer valid (t2) in a HELLO (indicating the link to a as LOST). Since only symmetric links are advertised by OLSRv2 routers, A will upon receipt hereof remove X from the set of advertised neighbors and increment the ANSN. Router A will then in subsequent TCs advertise the remaining set of advertised neighbors (i.e., with X removed) and the corresponding ANSN (t3). Upon X having received this information in another TC from A, it may repeat this cycle, alternating advertising the link A-X as "LOST" and as "MPR". Clausen, et al. Expires November 10, 2016 [Page 12]Internet-Draft OLSRv2 Threats May 2016 broadcast TC ANS={} TC:() (X-A) ANSN ANSN++ ANSN .---. .---. .---. .---. | A | | A | | A | | A | '---' '---' '---' '---' ^ | ^ | | | | | | select | |indicate | | as MPR | |as LOST | .---. .---. .---. .---. | X | | X | | X | | X | '---' '---' '---' '---' t0 t1 t2 t3 Figure 5: Indirect Jamming in Link State Advertisement: the malicious X flips between link status MPR and LOST. Routers receiving a TC will parse and process this message, specifically updating their topology map as a consequence of successful receipt. If the ANSN between two successive TCs from the same router has incremented, then the topology has changed and routing sets are to be recalculated. This is a potentially computationally costly operation. A compromised OLSRv2 router may chose to conduct this attack against all its neighbors, thus attaining maximum disruptive impact on the network with relatively little overhead of its own: other than participating in the Neighborhood Discovery procedure, the compromised OLSRv2 router will monitor TCs generated by its neighbors and alternate the advertised status for each such neighbor, between "MPR" and "LOST". The compromised OLSRv2 router will indicate its willingness to be zero (thus, avoid being selected as MPR) and may ignore all other protocol operations, while still remaining effective as an attacker. The basic operation of OLSRv2 employs periodic message emissions, and by this attack it can be ensured that each such periodic message will entail routing table recalculation in all routers in the network. If the routers in the network have "triggered TCs" enabled, this attack may also cause an increased TC frequency. Triggered TCs are intended to allow a (stable) network to have relatively low TC emission frequencies, yet still allow link breakage or link emergence to be advertised through the network rapidly. A minimum message interval (typically much smaller than the regular periodic message interval) is imposed, to rate-limit worst-case message emissions. This attack can cause the TC interval to, permanently, become equal Clausen, et al. Expires November 10, 2016 [Page 13]Internet-Draft OLSRv2 Threats May 2016 to the minimum message interval. [RFC7181] proposes as default that the minimum TC interval be 0.25 x TC interval. [JWD glad this was mentioned. Something might be said regarding the reduced effectiveness of the compromised node is not ever selected as an MPR as the calculation for routing might only affect a leaf router (dependent on implementation) Indirect Jamming by a compromised OLSRv2 router can thus have two effects: it may cause increased frequency of TC generation and transmission, and it will cause additional routing table recalculation in all routers in the network. 5. Inconsistent Topology Inconsistent topology maps can occur by a compromised OLSRv2 router employing either of identity spoofing or link spoofing for conducting an attack against an OLSRv2 network. The threats related to NHDP, such as identity spoofing in NHDP, link spoofing in NHDP and creating loops have been illustrated in [RFC7186]. This section mainly addresses the vulnerabilities in [RFC7181]. 5.1. Identity Spoofing Identity spoofing can be employed by a compromised OLSRv2 router via the Neighborhood Discovery process and via the Link State Advertisement process. Either of them causes inconsistent topology maps in routers in the network. The inconsistent topology maps due to neighborhood discovery has been discussed in [RFC7186]. For OLSRv2, the attack on link state advertisements can also cause inconsistent topology maps. An inconsistent topology map may occur when the compromised OLSRv2 router takes part in the Link State Advertisement (LSA) procedure, by selecting a neighbor as MPR, which in turn advertises the spoofed identities of the compromised OLSRv2 router. This attack will alter the topology maps of all routers of the network. [JWD] this is the only play that the term LSA is used. Suggest removing it. [JWD] also it should be mentioned that spoofing is protected against if using the SHOULD use TLVs A -- B -- C -- D -- E -- F -- X (X spoofs A) Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the identity of A, leading to a wrongly perceived topology. In Figure 6, router X spoofs the address of router A. If X selects F as MPR, all routers in the network will be informed about the link F-A by the TCs originating from F. Assuming that (the real) A selects B as MPR, the link B-A will also be advertised in the network. Clausen, et al. Expires November 10, 2016 [Page 14]Internet-Draft OLSRv2 Threats May 2016 When calculating paths, B and C will calculate paths to A via B, as illustrated in Figure 7(a); for these routers, the shortest path to A is via B. E and F will calculate paths to A via F, as illustrated in Figure 7(b); for these routers, the shortest path to A is via the compromised OLSRv2 router X, and these are thus disconnected from the real A. D will have a choice: the path calculated to A via B is of the same length as the path via the compromised OLSRv2 router X, as illustrated in Figure 7(b). In general, the following observations can be made: o The network will be split in two, with those routers closer to B than to X reaching A, whereas those routers closer to X than to B will be unable to reach A. o Routers beyond B, i.e., routers beyond one hop away from A will be unable to detect this identity spoofing. The identity spoofing attack via the Link State Advertisement procedure has a higher impact than the attack on the neighborhood discovery procedure, since it alters the topology maps of all routers in the network, and not only in the 2-hop neighborhood. However, the attack is easier to detect by other routers in the network. Since the compromised OLSRv2 router is advertised in the whole network, routers whose identities are spoofed by the compromised OLSRv2 router can detect the attack. For example, when a receives a TC from F advertising the link F-A, it can deduce that some entity is injecting incorrect Link State information as it does not have F as one of its direct neighbors. (X spoofs A) A < ---- B < ---- C E ----> F ----> X (a) Routers B and C (b) Routers E and F A < --- B < --- C < --- D ---> E ---> F ----> X (X spoofs A) Figure 7: Routing paths towards A, as calculated by the different routers in the network in presence of a compromised OLSRv2 router X, spoofing the address of A. As the compromised OLSRv2 router X does not itself send the TCs, but rather, by virtue of MPR selection, ensures that the addresses it Clausen, et al. Expires November 10, 2016 [Page 15]Internet-Draft OLSRv2 Threats May 2016 spoofs are advertised in TCs from its MPR selector F, the attack may be difficult to counter: simply ignoring TCs that originate from F may also suppress the link state information for other, legitimate, MPR selectors of F. Identity spoofing by a compromised OLSRv2 router, participating in the Link State Advertisement process by selecting MPRs only, thus, creates a situation wherein two or more routers have substantially inconsistent topology maps: traffic for an identified destination is, depending on where in the network it appears, delivered to different routers. [JWD] Link State Advertisement is again used here suggest lowercase. 5.2. Link Spoofing Link Spoofing is a situation in which a router advertises non- existing links to another router (possibly not present in the network). Essentially, TCs and HELLOs both advertise links to direct neighbor routers, with the difference being the scope of the advertisement. Thus, link spoofing consists of a compromised OLSRv2 router, reporting that it has neighbors routers which are, either, not present in the network, or which are effectively not neighbors of the compromised OLSRv2 router. It can be noted that a situation similar to link spoofing may occur temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 routers: if A was, but is no more, a neighbor of B, then A may still be advertising a link to B for the duration of the time it takes for the the Neighborhood Discovery process to determine this changed neighborhood. In the context of this document, link spoofing refers to a persistent situation where a compromised OLSRv2 router intentionally advertises links to other routers, for which it is not a direct neighbor. [JWD] this is a similar attack to the above but is not protected against but the attacker is more easily identified. One difference is that TC messages with spoofed links may be hop count limited making detection more difficult. 5.2.1. Inconsistent Topology Maps due to Link State Advertisements Figure 8 illustrates a network, in which the compromised OLSRv2 router X spoofs links to a existing router A by participating in the Link State Advertisement process and including this non-existing link in its advertisements. A --- B --- C --- D --- E --- F --- G --- H --- X (X spoofs the link to A) Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a Clausen, et al. Expires November 10, 2016 [Page 16]Internet-Draft OLSRv2 Threats May 2016 spoofed link to A in its TCs, thus all routers will record both of the links X-A and B-A. As TCs are flooded through the network, all routers will receive and record information describing a link X-A in this link state information. If A has selected router B as MPR, B will likewise flood this link state information through the network, thus all routers will receive and record information describing a link B-A. When calculating routing paths, B, C and D will calculate paths to A via B, as illustrated in Figure 9(a); for these routers, the shortest path to A is via B. F and G will calculate paths to A via X, as illustrated in Figure 9(b); for these routers, the shortest path to A is via X, and these are thus disconnected from the real router A. E will have a choice: the path calculated to A via B is of the same length as the path via X, as illustrated in Figure 9(b). A < --- B < --- C < --- D F ---> G ---> X ---> A (a) Routers B, C, and D (b) Routers F and G A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A (c) Router E Figure 9: Routing paths towards router A, as calculated by the different routers in the network in presence of a compromised OLSRv2 router X, spoofing a link to router A. In general, the following observations can be made: o The network will be separated in two, with those routers closer to B than to X reaching A, whereas those routers closer to X than to B unable to reach A. o Routers beyond B, i.e., routers beyond one hop away from A will be unable to detect this link spoofing. The impact of this attack is similar to that presented in Section 5.2.1, however, is easier to detect as the compromised OLSRv2 router is generating control traffic reaching the entire network. Clausen, et al. Expires November 10, 2016 [Page 17]Internet-Draft OLSRv2 Threats May 2016 6. Mitigation of Security Vulnerabilities for OLSRv2 As described in Section 1, [RFC7183] specifies a security mechanism for OLSRv2 that is mandatory to implement. However, deployments may choose to use different security mechanisms if more appropriate. Therefore, it is important to understand both the inherent resilience of OLSRv2 against security vulnerabilities when not using the mechanisms specified in [RFC7183], as well as the protection that [RFC7183] provides when used in a deployment. 6.1. Inherent OLSRv2 Resilience OLSRv2 (without the mandatory-to-implement security mechanisms in [RFC7183]) provides some inherent resilience against part of the attacks described in this document. In particular, it provides the following resilience: o Sequence numbers: OLSRv2 employs message sequence numbers, specific per router identity and message type. Routers keep an "information freshness" number (ANSN), incremented each time the content of a Link State Advertisement from a router changes. This allows rejecting "old" information and duplicate messages, and provides some protection against "message replay". This, however, also presents an attack vector (Section 4.3). o Ignoring uni-directional links: The Neighborhood Discovery process detects and admits only bi-directional links for use in MPR selection and Link State Advertisement. Jamming attacks may affect only reception of control traffic, however OLSRv2 will correctly recognize, and ignore, such a link as not bi- directional. o Message interval bounds: The frequency of control messages, with minimum intervals imposed for HELLO and TCs. This may limit the impact from an indirect jamming attack (Section 4.4). o Additional reasons for rejecting control messages: The OLSRv2 specification includes a list of reasons, for which an incoming control message should be rejected as malformed - and allows that a protocol extension may recognize additional reasons for OLSRv2 to consider a message malformed. This allows - together with the flexible message format [RFC5444] - addition of security mechanisms, such as digital signatures, while remaining compliant with the OLSRv2 standard specification. Clausen, et al. Expires November 10, 2016 [Page 18]Internet-Draft OLSRv2 Threats May 2016 6.2. Resilience by using RFC7183 with OLSRv2 [RFC7183] specifies mechanisms for integrity and replay protection for NHDP and OLSRv2, using the generalized packet/message format described in [RFC5444] and the TLV definitions in [RFC7182]. The specification describes how to add an Integrity Check Value (ICV) in a TLV to each control message, providing a digital signature of the content of the message using HMAC/SHA-256. In addition, a timestamp TLV is added to the message prior to creating the ICV, enabling replay protection of messages. The document specifies how to sign outgoing messages and how to verify incoming messages, as well as under which circumstances a non-valid message is rejected. Because of the HMAC/SHA-256 ICV, a shared key between all routers in the MANET is assumed. A router without valid credentials is not able to create an ICV that can be correctly verified by other routers in the MANET; therefore, such an incorrectly signed message will be rejected by other MANET routers, and the router cannot participate in the OLSRv2 routing process (i.e., the malicious router will be ignored by other, legitimate routers). [RFC7183] does not address the case where a router with valid credentials has been compromised. Such a compromised router will not be excluded from the routing process, and other means of detecting such a router are necessary if required in a deployment (in addition to using asymmetric keys, allowing to revoke access to one particular router instead of revoking the shared key used by all routers in the MANET). In the following sections, each of the vulnerabilities described earlier in this document will be evaluated in terms of whether OLSRv2 with the mechanisms in [RFC7183] provides sufficient protection against the attack. It is implicitly assumed in each of the following sections that [RFC7183] is used with OLSRv2. [JWD] this is a really important part of the document and should be moved up to provide the reader with a better understanding. Without this it will be easy for a reader to assume that all attacks presented are equally possible. A summary was given but more details (along with an inline sentence per attack pointing to appropriate section below) would help quite a lot. 6.2.1. Topology Map Acquisition Attack on Jittering - As only OLSRv2 routers with valid credentials can participate in the routing process, a malicious router cannot reduce the jitter time of an attacked router to 0 by sending many TC messages in a short time. The attacked router would reject all the incoming messages as "invalid" and not forward them. The same applies for the case where a malicious router wants to assure that by forcing a zero jitter interval, the message arrives before the same message forwarded by legitimate routers. Modifying the Hop Limit - As the hop limit is not protected by [RFC7183] (since it is a mutual field, changing at every hop), this attack is still feasible. Clausen, et al. Expires November 10, 2016 [Page 19]Internet-Draft OLSRv2 Threats May 2016 Modifying the Hop Count - Similarly to the hop limit, as the hop count is not protected by [RFC7183] (since it is a mutual field, changing at every hop), this attack is still feasible. 6.2.2. Effective Topology Incorrect Forwarding - As only OLSRv2 routers with valid credentials can participate in the routing process, a malicious router will not be part of the topology of other legitimate OLSRv2 routers. Therefore, no data traffic will be sent to the malicious router for forwarding. Wormholes - Since a wormhole consists of at least two devices forwarding (unmodified) traffic, this attack is still feasible and undetectable by the OLSRv2 routing process since the attack does not involve the OLSRv2 protocol itself (but rather lower layers). By using [RFC7183], it can at least be assured that the content of the control messages is not modified while being forwarded via the wormhole. Moreover, the timestamp TLV assures that the forwarding can only be done in a short time window after the actual TC message has been sent. Message Sequence Number - As the message sequence number is included in the ICV calculation, OLSRv2 is protected against this attack. Advertised Neighbor Sequence Number (ANSN) - As the ANSN is included in the ICV calculation, OLSRv2 is protected against this attack. Indirect Jamming - Since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, this attack is mitigated. 6.2.3. Inconsistent Topology Identity Spoofing - Since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, a router without valid credentials may spoof its identity (e.g., IP source address or message originator address), but the messages will be ignored by other routers. As the mandatory mechanism in [RFC7183] uses shared keys amongst all MANET routers, a single compromised router may spoof its identity and cause harm to the network stability. Removing this one malicious router once detected implies rekeying all other routers in the MANET. Asymmetric keys, in particular when using identity based signatures, such as specified in [IBS] may further allow to revoke single routers and to verify their identity based on the ICV itself. Clausen, et al. Expires November 10, 2016 [Page 20]Internet-Draft OLSRv2 Threats May 2016 Link Spoofing - Similar to identity spoofing, a malicious router without valid credential may spoof links, but its control messages will be rejected by other routers, thereby mitigating the attack. Inconsistent Topology Maps due to Link State Advertisements - The same considerations as for link spoofing apply. 7. Security Considerations This document does not specify a protocol or a procedure. The document, however, reflects on security considerations for OLSRv2, and its constituent parts, including NHDP. 8. IANA Considerations This document has no actions for IANA. 9. References 9.1. Normative References [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014. [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, April 2014. 9.2. Informative References [FUNKFEUER] "http://www.funkfeuer.at/". [IBS] Dearlove, C., "Identity-Based Signatures for MANET Routing Protocols", work in progress draft-ietf-manet-ibs-05, March 2016. [IEEE802.11] "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Spec.", 2007. [MPR-FLOODING] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint relaying: An efficient technique for flooding in mobile Clausen, et al. Expires November 10, 2016 [Page 21]Internet-Draft OLSRv2 Threats May 2016 wireless networks.", 2001. [OLSR-FSR] Clausen, T., "Combining Temporal and Spatial Partial Topology for MANET routing-Merging OLSR and FSR, Proceedings of the 2003 IEEE Conference of Wireless Personal Multimedia Communications (WPMC 03)", 2003. [OLSR-FSR-Scaling] Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G. Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal of Communication and Networks (JCN), Special Issue on Mobile Ad Hoc Wireless Networks", 2004. [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003. [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", RFC 5068, BCP 134, October 2007. [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009. [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of Managed Objects for the Neighborhood Discovery Protocol", RFC 6779, May 2012. [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014. [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) Clausen, et al. Expires November 10, 2016 [Page 22]Internet-Draft OLSRv2 Threats May 2016 and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014. [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2", RFC 7184, April 2014. [RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7187, April 2014. [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, April 2014. Authors' Addresses Thomas Clausen Phone: +33-6-6058-9349 Email: T.Clausen@computer.org URI: http://www.thomasclausen.org Ulrich Herberg Email: ulrich@herberg.name URI: http://www.herberg.name Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex, France Phone: +33 1 77 57 80 85 Email: jiazi@jiaziyi.com URI: http://www.jiaziyi.com/ Clausen, et al. Expires November 10, 2016 [Page 23] --94eb2c03f484c2a1c1053b2e5cf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
As there weren't many on list comments during or =
after last call here is my detailed review.
Summary is that I'm doin=
g the writeup right now and passing it on up.  Most of my comments 
are =
of the editorial type with exceptions which are minor and mostly clarificat=
ion based.

Apologies to the author team for not getting t=
his done sooner; I wanted to make sure I did it right.

Co=
mments noted as JWD



Network Working Group        =
                                 T. Clausen
Internet-Draft                                                U. Herberg
Intended status: Informational
Expires: November 10, 2016                                         J. Yi
                                                     Ecole Polytechnique
                                                             May 9, 2016

Security Threats for the Optimized Link State Routing Protocol version 2
                                (OLSRv2)
                 draft-ietf-manet-olsrv2-sec-threats-02

Abstract

   This document analyzes common security threats of the Optimized Link
   State Routing Protocol version 2 (OLSRv2) and describes their
   potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
   then analyzes which of these security vulnerabilities can be
   mitigated when using the mandatory-to-implement security mechanisms
   for OLSRv2, and how the vulnerabilities are mitigated.

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 10, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.or=
g/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Clausen, et al.         Expires November 10, 2016         =
      [Page 1]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  OLSRv2 Overview  . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Neighborhood Discovery . . . . . . . . . . . . . . . .  4
       1.1.2.  MPR Flooding . . . . . . . . . . . . . . . . . . . . .  5
       1.1.3.  Link State Advertisement . . . . . . . . . . . . . . .  5
     1.2.  Link State Vulnerability Taxonomy  . . . . . . . . . . . .  5
     1.3.  OLSRv2 Attack Vectors  . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Topology Map Acquisition . . . . . . . . . . . . . . . . . . .  6
     3.1.  Attack on Jittering  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Hop-count and Hop-limit Attacks  . . . . . . . . . . . . .  7
       3.2.1.  Modifying the Hop Limit  . . . . . . . . . . . . . . .  7
       3.2.2.  Modifying the Hop Count  . . . . . . . . . . . . . . .  8
   4.  Effective Topology . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Incorrect Forwarding . . . . . . . . . . . . . . . . . . .  9
     4.2.  Wormholes  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Sequence Number Attacks  . . . . . . . . . . . . . . . . . 11
       4.3.1.  Message Sequence Number  . . . . . . . . . . . . . . . 11
       4.3.2.  Advertised Neighbor Sequence Number (ANSN) . . . . . . 11
     4.4.  Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12
   5.  Inconsistent Topology  . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  Inconsistent Topology Maps due to Link State
               Advertisements . . . . . . . . . . . . . . . . . . . . 16
   6.  Mitigation of Security Vulnerabilities for OLSRv2  . . . . . . 18
     6.1.  Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18
     6.2.  Resilience by using RFC7183 with OLSRv2  . . . . . . . . . 19
       6.2.1.  Topology Map Acquisition . . . . . . . . . . . . . . . 19
       6.2.2.  Effective Topology . . . . . . . . . . . . . . . . . . 20
       6.2.3.  Inconsistent Topology  . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 2=
3

Clausen, et al.         Expires November 10, 2016         =
      [Page 2]
Internet-Draft               OLSRv2 Threats               =
      May 2016

1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182],
   [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a
   routing protocol for MANETs (Mobile Ad hoc NETworks).  OLSRv2 retains
   the same basic algorithms as its predecessor, however offers various
   improvements, e.g., a modular and flexible architecture allowing
   extensions, such as for security, to be developed as add-ons to the
   basic protocol.
[JWD] NIT: listing RFC7181 first would be =
helpful.
  
  =C2=A0The developments reflected in OLSRv2 h=
ave been motivated by increased
   real-world deployment experiences, e.g., from networks such as
   FunkFeuer [FUNKFEUER], and the requirements presented for continued
   successful operation of these networks.  With participation in such
   networks increasing (the FunkFeuer community network has, e.g.,
   roughly 400 individual participants at the time of publication of
   this document), operating with the assumption, that participants can
   be "trusted" to behave in a non-destructive way, is utopia.  T=
aking
   the Internet as an example, as participation in the network increases
   and becomes more diverse, more efforts are required to preserve the
   integrity and operation of the network.  Most SMTP-servers were,
   e.g., initially available for use by everyone on the Internet - with
   an increased populace on the Internet, attacks and abuses caused the
   recommended practice is today to require authentication and
   accounting for users of such SMTP servers [RFC5068].

[=
JWD] NIT language improvement....with an increase in users on the Internet,=
 
an increase in attacks and abuses followed necessitating a change in r=
ecommended 
practices; today authentication and accounting for users is =
required for use of SMTP servers [RFC5068].

  =C2=A0As OL=
SRv2 often is used in wireless environments, it is potentially
   exposed to different kinds of security threats, some of which are of
   particular significance as compared to wired networks.  As radio
   signals can be received as well as transmitted by any compatible
   wireless device within radio range, there is commonly no physical
   protection as otherwise known for wired networks.

   A first step towards hardening against attacks disrupting the
   connectivity of a network, is to understand the vulnerabilities of
   routing protocol, managing the connectivity.  This document therefore
   analyzes OLSRv2, to understand its inherent vulnerabilities and
   resiliences.  The authors do not claim completeness of the analysis,
   but hope that the identified attacks, as presented, form a meaningful
   starting-point for developing and deploying increasingly secured
   OLSRv2 networks.

   This document first describes security vulnerabilities to OLSRv2 when
   it is used without the mandatory-to-implement security mechanisms, as
   specified in Section 23.5 of [RFC7181].  It then analyzes which of
   these security vulnerabilities can be mitigated when using the
   mandatory-to-implement security mechanisms for OLSRv2, and how the

Clausen, et al.         Expires November 10, 2016         =
      [Page 3]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   vulnerabilities are mitigated.  This separation is important since
   other security mechanisms ([JWD] other) than the mandatory-to-implement =
ones may be
   used in a deployment, as explicitly stated in [RFC7181]:

      "Any deployment of OLSRv2 SHOULD use the security mechanism
      specified in [RFC7183] but MAY use another mechanism if more
      appropriate in an OLSRv2 deployment.  For example, for longer-term
      OLSRv2 deployments, alternative security mechanisms (e.g.,
      rekeying) SHOULD be considered."

   Moreover, this document is also based on the assumption that no
   additional security mechanism such as IPsec is used in the IP layer
   or other mechanisms on lower layers, as not all MANET deployments may
   be able to accommodate such common protection mechanisms (e.g.,
   because of limited resources of MANET routers).

   The threats related to NHDP (Neighborhood Discovery Protocol) have
   been discussed in [RFC7186].  As NHDP is a fundamental block of
   OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.

   It should be noted that many OLSRv2 implementations are configurable,
   and so an attack on the configuration system (such as [RFC6779] and
   [RFC7184]) can be used to adversely affect the operation of an OLSRv2
   implementation.

1.1.  OLSRv2 Overview

   OLSRv2 contains three basic processes: Neighborhood Discovery, MPR
   Flooding ([JWD] MPR election/flooding not just flooding?) and Link State=
 Advertisements, described in the below with
   sufficient details for elaborating the analyses in this document.
[JWD] NIT make above two separate sentences. 
1.1.1.  Neighborhood Discovery

   Neighborhood Discovery is the process, whereby each router discovers
   the routers which are in direct communication range of itself (1-hop
   neighbors), and detects with which of these it can establish bi-
   directional communication.  Each router sends HELLO messages
   periodically, listing the identifiers of all the routers from which
   it has recently received a HELLO message, as well as the "status&qu=
ot; of
   the link (heard or verified bi-directional).  A router A receiving a
   HELLO message from a neighbor B, in which B indicates to have
   recently received a HELLO message from A, considers the link A-B to
   be bi-directional.  As B lists identifiers of all its neighbors in
   its HELLO message, A learns the "neighbors of its neighbors" (=
2-hop
   neighbors) through this process.  HELLO messages are sent
   periodically, however certain events may trigger non-periodic HELLOs.
   OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery
   mechanism.  The vulnerabilities of NHDP are analyzed in [RFC7186].

Clausen, et al.         Expires November 10, 2016         =
      [Page 4]
Internet-Draft               OLSRv2 Threats               =
      May 2016

1.1.2.  MPR Flooding

   Multi Point Relay (MPR) Flooding is the process whereby each router
   is able to efficiently conduct network-wide broadcasts.  Each router
   designates, from among its bi-directional neighbors, a subset (MPR
   set) such that a multicast ([JWD] OLSRv2 specific multicast) message tra=
nsmitted by the router and
   relayed by the MPR set can ([JWD] be) received by all its 2-hop neighbor=
s.  MPR
   selection is encoded in outgoing HELLO messages. ([JWD] NHDP HELLO messa=
ges)

   Routers may express, in their HELLO messages, their "willingness&qu=
ot; (an
   integer between 0 "will never" and 7 "will always") =
to be selected as
   MPR, which is taken into consideration for the MPR calculation, and
   which is useful for example when an OLSRv2 network is "planned"=
;.  The
   set of routers having selected a given router as MPR is the MPR-
   selector-set of that router.  A study of the MPR flooding algorithm
   can be found in [MPR-FLOODING].

1.1.3.  Link State Advertisement

   Link State Advertisement is the process whereby routers are
   determining ([JWD] routers determine) which link state information to ad=
vertise through the
   network.  Each router must advertise, at least, all links between
   itself and its MPR selectors, in order to allow all routers to
   calculate shortest paths.  Such link state advertisements are carried
   in Topology Control (TC) messages, broadcast through the network
   using the MPR flooding process described above.  As a router selects
   MPRs only from among bi-directional neighbors, links advertised in TC
   are also bi-directional and routing paths calculated by OLSRv2
   contain only bi-directional links.  TCs are sent periodically,
   however certain events may trigger non-periodic TCs.

1.2.  Link State Vulnerability Taxonomy

   Proper functioning of OLSRv2 assumes that (i) each router signals its
   presence in the network and the topology information that it obtained
   honestly, (ii) each router can acquire and maintain a topology map,
   accurately reflecting the effective network topology; and (iii) that
   the network converges, i.e., that all routers in the network will
   have sufficiently identical topology maps.
[JWD] Nit make =
above a list.

  =C2=A0An OLSRv2 network can be disrupted =
by breaking either ([JWD] any not either) of these
   assumptions, specifically (a) routers may be prevented from acquiring
   a topology map of the network; (b) routers may acquire a topology map
   that does not reflect the effective network topology; and (c) two or
   more routers may acquire inconsistent topology maps.

Clausen, et al.         Expires November 10, 2016         =
      [Page 5]
Internet-Draft               OLSRv2 Threats               =
      May 2016

1.3.  OLSRv2 Attack Vectors

   Besides "radio jamming", attacks on OLSRv2 consist of a compro=
mised
   OLSRv2 router injecting "correctly looking, but invalid, control
   traffic" (TCs, HELLOs) into the network.  A compromised OLSRv2 rout=
er
   can either (a) lie about itself (its identification, its willingness
   to serve as MPR), henceforth Identity Spoofing, or (b) lie about its
   relationship to other routers (pretend existence of links to other
   routers), henceforth Link Spoofing.  Such attacks may disrupt the the
   Link State Advertisement process, through targeting the MPR Flooding
   mechanism, or by causing incorrect link state information to be
   included in TCs, causing routers to have incomplete, inaccurate or
   inconsistent topology maps.  In a different class of attacks, a
   compromised OLSRv2 router injects control traffic, designed so as to
   cause an in-router resource exhaustion, e.g., by causing the
   algorithms calculating routing tables or MPR sets to be invoked
   continuously, preventing the internal state of a router from
   converging.

2.  Terminology

   This document uses the terminology and notation defined in [RFC5444],
   [RFC6130] and [RFC7181].  Additionally, it defines the following
   terminology:

   Compromised OLSRv2 router: -  An attacker that is present in the
      network and generates syntactically correct OLSRv2 control
      messages.  Control messages emitted by a compromised OLSRv2 router
      may contain additional information, or omit information, as
      compared to a control message generated by a non-compromised
      OLSRv2 router located in the same topological position in the
      network.

   Legitimate OLSRv2 router: -  An OLSRv2 router that is not a
      compromised OLSRv2 router.

3.  Topology Map Acquisition

   Topology Map Acquisition relates to the ability for any given router
   in the network to acquire a representation of the network
   connectivity.  A router, unable to acquire a topology map, is
   incapable of calculating routing paths and participating in
   forwarding data.  Topology map acquisition can be hindered by (i) TCs
   to not being delivered to (all) routers in the network, such as what
   happens in case of Flooding Disruption, or (ii) in case of "jamming=
"
   of the communication channel.

Clausen, et al.         Expires November 10, 2016         =
      [Page 6]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   The jamming and flooding disruption due to identity spoofing and link
   spoofing have been discussed in [RFC7186].

3.1.  Attack on Jittering

   OLSRv2 incorporates a jittering: a random, but bounded, delay on
   outgoing control traffic [RFC5148].  This may be necessary when link
   layers (such as 802.11 [IEEE802.11]) are used that do not guarantee
   collision-free delivery of frames, and where jitter can reduce the
   probability of collisions of frames on lower layers.

   In OLSRv2, TC forwarding is jittered by a value between 0 and
   MAX_JITTER.  In order to reduce the number of transmissions, when a
   control message is due for transmission, OLSRv2 piggybacks all queued
   messages into a single transmission.  Thus, if a compromised OLSRv2
   router sends many TCs within a very short time interval, the jitter
   time of the attacked router tends to 0.  This renders jittering
   ineffective and can lead to collisions on the link layer.

   In addition to causing more collisions, forwarding a TC with little
   or no jittering can make sure that the TC message forwarded by a
   compromised router arrives before the message forwarded by legitimate
   routers.  The compromised router can thus inject malicious content in
   the TC, and the legitimate message will be discarded as ([JWD] a) duplic=
ate
   message.  This preemptive action is important for some of the attacks
   introduced in the following sections.

3.2.  Hop-count and Hop-limit Attacks

   The hop-count and hop-limit fields are the only parts of a TC that
   are modified when forwarding.  A compromised OLSRv2 router can modify
   either of these when forwarding TCs.

[JWD] mention of =
the integrity TLV here which makes this statement true would be helpful.

3.2.1.  Modifying the Hop Limit

   A compromised OLSRv2 router can decrease the hop limit when
   forwarding a TC.  This will reduce the scope of forwarding the
   message, and may lead to some routers in the network not receiving
   that TC.  Note that this is not necessarily the same as not relaying
   the message (i.e., setting the hop limit to 0), as illustrated in
   Figure 1.

Clausen, et al.         Expires November 10, 2016         =
      [Page 7]
Internet-Draft               OLSRv2 Threats               =
      May 2016

                            .---.
                            | X |
                          --'---' __
                         /          \
                        /            \
                    .---.              .---.
        TC ----->   | A |              | C |
                    '---'              '---'
                        \    .---.   /
                         \-- | B |__/
                             '---'

                        Figure 1: Hop Limit Attack.

   A TC arrives at and is forwarded by router A, such that it is
   received by both B and the malicious X. X can forward the TC without
   any delay (including without jitter) such that its transmissions
   arrives before that of B at C. Before forwarding, it significantly
   reduces the hop limit of the message.  Router C receives the TC,
   processes (and forwards) it, and marks it as already received -
   causing it to discard further copies received from B. Thus, if the TC
   is forwarded by C, it has a very low hop limit and will not reach the
   whole network.

3.2.2.  Modifying the Hop Count

   A compromised OLSRv2 router can modify the hop count when forwarding
   a TC.  This may have two consequences: (i) if the hop count is set to
   the maximum value, then the TC will be forwarded no further by, or
   (ii) artificially manipulating the hop count may affect the validity
   time as calculated by recipients, when using distance-dependent
   validity times as defined in [RFC5497] (e.g., as part of a fish-eye
   extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]).

           v_time(1hop)=3D2s  v_time(2hops)=3D4s   v_time(3hops)=3D6s
   .---.         .---.          .---.           .---.
   | A |-------> | B | -------> | X |---------->| C |
   `---'         `---'          `---'           `---'

     Figure 2: Different validity times based on the distance in hops.

   In Figure 2, router A sends a TC with a validity time of two seconds
   for neighbors that are one hop away, four seconds for routers in a
   two-hop distance and six seconds in a three-hop distance.  If X is a
   compromised OLSRv2 router and modifies the hop count (say, by
   decreasing it to 0), then C will calculate the validity time of
   received information to two seconds - after which it expires unless

Clausen, et al.         Expires November 10, 2016         =
      [Page 8]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   refreshed.  If TCs from A are sent less frequently than that up to 3
   hops, this causes links advertised in such TCs to be only
   intermittently available to C.

[JWD] this is a really =
good point!

=C2=A04.  Effective Topology=


   Link-state protocols assume that each router can acquire an accurate
   topology map, reflecting the effective network topology.  This
   implies that the routing protocol, through its message exchange,
   identifies a path from a source to a destination, and this path is
   valid for forwarding data traffic.  If an attacker disturbs the
   correct protocol behavior, the perceived topology map of a router can
   permanently differ from the effective topology.

   Considering the example in Figure 3(a), which illustrates the
   topology map as acquired by router S. This topology map indicates
   that the routing protocol has identified that for S, a path exists to
   D via B, which it therefore assumes can be used for transmitting
   data.  If, effectively, B does not forward data traffic from S, then
   the topology map in S does not accurately reflect the effective
   network topology.  Rather, the effective network topology from the
   point of view of S would be as indicated in Figure 3(b): D is not
   part of the network reachable from router S.

      .---.    .---.    .---.           .---.    .---.
      | S |----| B |----| D |           | S |----| B |
      `---'    `---'    `---'           `---'    `---'

              (a)                             (b)

               Figure 3: Incorrect Data Traffic Forwarding.

   Some of the attacks related to NHDP, such as message timing attack,
   indirect channel overloading have been discussed in [RFC7186].  Other
   threats specific to OLSRv2 are further detailed in this section.

4.1.  Incorrect Forwarding

   OLSRv2 routers exchange information using link-local transmissions
   (link-local multicast or limited broadcast) for their control
   messages, with the routing process in each router retransmitting
   received messages destined for network-wide diffusion.  Thus, if the
   operating system in a router is not configured to enable forwarding,
   this will not affect the operating of the routing protocol, or the
   topology map acquired by the routing protocol.  It will, however,

Clausen, et al.         Expires November 10, 2016         =
      [Page 9]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   cause a discrepancy between the effective topology and the topology
   map, as indicated in Figure 3(a) and Figure 3(b).

[JWD=
] the term unicast forwarding should be used as without that term it may be assumed that forwarding of multicast is being disrupted which isn'=
t the case.

  =C2=A0This situation is not hypothetical.  A co=
mmon error seen when
   deploying OLSRv2-based networks using Linux-based computers as router
   is to neglect enabling IP forwarding, which effectively becomes an
   accidental attack of this type.

4.2.  Wormholes

   A wormhole, depicted in the example in Figure 4, may be established
   between two collaborating devices, connected by an out-of-band
   channel.  These devices send traffic through the "tunnel" to t=
heir
   alter-ego, which "replays" the traffic.  Thus, routers D and S=
 appear
   as if direct neighbors and reachable from each other in 1 hop through
   the tunnel, with the path through the MANET being 100 hops long.

   .---.                                     .---.
   | S |----   ....100-hop long path  ... ---| D |
   `---.                                   / `---'
       \                                  /
        \                                /
         \X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3DX

                1-hop path via wormhole

        Figure 4:  Wormholing between two collaborating devices not
                  participating in the routing protocol.

   The consequences of such a wormhole in the network depends on the
   detailed behavior of the wormhole.  If the wormhole relays only
   control traffic, but not data traffic, the same considerations as in
   Section 4.1 applies.  If, however, the wormhole relays all traffic,
   control and data alike, it is connectivity-wise identical to a usable
   link - and the routing protocol will correctly generate a topology
   map reflecting the effective network topology.  The efficiency of the
   topology so obtained depends on (i) the wormhole characteristics,
   (ii) how the wormhole presents itself, and (iii) how paths are
   calculated.

   Assuming that paths are calculated with unit-cost for all links,
   including the "link" presented by the wormhole: if the real
   characteristics of the wormhole are as-if it was a path of more than
   100 hops (e.g., with respect to delay, bandwidth, etc.), then the

Clausen, et al.         Expires November 10, 2016         =
     [Page 10]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   presence of the wormhole results in a degradation in performance as
   compared to using the non-wormhole path.  Conversely, if the "link&=
quot;
   presented by the wormhole has better characteristics, the wormhole
   results in improved performance.

   If paths are calculated using non-unit-costs for all links, and if
   the cost of the "link" presented by the wormhole correctly rep=
resents
   the actual cost (e.g., if the cost is established through
   measurements across the wormhole), then the wormhole may in the worst
   case cause no degradation in performance, in the best case improve
   performance by offering a better path.  If the cost of the "link&qu=
ot;
   presented by the wormhole is misrepresented, then the same
   considerations as for unit-cost links apply.

   An additional consideration with regards to wormholes is, that such
   may present topologically attractive paths for the network - however
   it may be undesirable to have data traffic transit such a path: an
   attacker could, by virtue of introducing a wormhole, acquire the
   ability to record and inspect transiting data traffic.

4.3.  Sequence Number Attacks

   OLSRv2 uses two different sequence numbers in TCs, to (i) avoid
   processing and forwarding the same message more than once (Message
   Sequence Number), and (ii) to ensure that old information, arriving
   late due to, e.g., long paths or other delays, is not allowed to
   overwrite fresher information (Advertised Neighbor Sequence Number -
   ANSN).

4.3.1.  Message Sequence Number

   An attack may consist of a compromised OLSRv2 router spoofing the
   identity of another router in the network, and transmitting a large
   number of TCs, each with different Message Sequence Numbers.
   Subsequent TCs with the same sequence numbers, originating from the
   router whose identity was spoofed, would hence be ignored, until
   eventually information concerning these "spoofed" TCs expires.=


[JWD] it should be mentioned that this is fixed with the=
 signing TLV.

4.3.2.  Advertised Neighbo=
r Sequence Number (ANSN)

   An attack may consist of a compromised OLSRv2 router spoofing the
   identity of another router in the network, and transmitting a single
   TC, with an ANSN significantly larger than that which was last used
   by the legitimate router.  Routers will retain this larger ANSN as
   "the most fresh information" and discard subsequent TCs with l=
ower
   sequence numbers as being "old".

[JWD] again it should be mentioned that this is fixed with the signing =
TLV.

Clausen, et al.         Expires November 10, 2016         =
     [Page 11]
Internet-Draft               OLSRv2 Threats               =
      May 2016

4.4.  Indirect Jamming

   Indirect Jamming is an attack in which a compromised OLSRv2 router
   is, by its actions, causing legitimate routers to generate inordinate
   amounts of control traffic, thereby increasing both channel
   occupation and the overhead incurred in each router for processing
   this control traffic.  This control traffic will be originated from
   legitimate routers, thus to the wider network, the malicious device
   may remain undetected.

   The general mechanism whereby a malicious router can cause indirect
   jamming is for it to participate in the protocol by generating
   plausible control traffic, and to tune this control traffic to in
   turn trigger receiving routers to generate additional traffic.  For
   OLSRv2, such an indirect attack can be directed at, respectively, the
   Neighborhood Discovery mechanism and the Link State Advertisement
   mechanism.

   The most efficient indirect jamming attack in OLSRv2 is to target
   control traffic, destined for network-wide diffusion.  This is
   illustrated in Figure 5.

   The malicious router X selects router A as MPR at time t0 in a HELLO.
   This causes X to appear as MPR selector for A and, consequently, A
   sets X to be advertised in its "Neighbor Set" and increments t=
he
   associated "Advertised Neighbor Sequence Number" (ANSN).  Rout=
er A
   must, then, advertise the link between itself and X in subsequent
   outgoing TCs (t1), also including the ANSN in such TCs.  Upon X
   having received this TC, it declares the link between itself and A as
   no longer valid (t2) in a HELLO (indicating the link to a as LOST).
   Since only symmetric links are advertised by OLSRv2 routers, A will
   upon receipt hereof remove X from the set of advertised neighbors and
   increment the ANSN.  Router A will then in subsequent TCs advertise
   the remaining set of advertised neighbors (i.e., with X removed) and
   the corresponding ANSN (t3).  Upon X having received this information
   in another TC from A, it may repeat this cycle, alternating
   advertising the link A-X as "LOST" and as "MPR".

Clausen, et al.         Expires November 10, 2016         =
     [Page 12]
Internet-Draft               OLSRv2 Threats               =
      May 2016

              broadcast TC    ANS=3D{}         TC:()
               (X-A) ANSN      ANSN++          ANSN
      .---.        .---.        .---.        .---.
      | A |        | A |        | A |        | A |
      '---'        '---'        '---'        '-=
--'
        ^            |            ^            |
        |            |            |            |
        | select     |            |indicate    |
        | as MPR     |            |as LOST     |
      .---.        .---.        .---.        .---.
      | X |        | X |        | X |        | X |
      '---'        '---'        '---'        '-=
--'

        t0           t1            t2           t3

   Figure 5: Indirect Jamming in Link State Advertisement: the malicious
                 X flips between link status MPR and LOST.

   Routers receiving a TC will parse and process this message,
   specifically updating their topology map as a consequence of
   successful receipt.  If the ANSN between two successive TCs from the
   same router has incremented, then the topology has changed and
   routing sets are to be recalculated.  This is a potentially
   computationally costly operation.

   A compromised OLSRv2 router may chose to conduct this attack against
   all its neighbors, thus attaining maximum disruptive impact on the
   network with relatively little overhead of its own: other than
   participating in the Neighborhood Discovery procedure, the
   compromised OLSRv2 router will monitor TCs generated by its neighbors
   and alternate the advertised status for each such neighbor, between
   "MPR" and "LOST".  The compromised OLSRv2 router wil=
l indicate its
   willingness to be zero (thus, avoid being selected as MPR) and may
   ignore all other protocol operations, while still remaining effective
   as an attacker.

   The basic operation of OLSRv2 employs periodic message emissions, and
   by this attack it can be ensured that each such periodic message will
   entail routing table recalculation in all routers in the network.

   If the routers in the network have "triggered TCs" enabled, th=
is
   attack may also cause an increased TC frequency.  Triggered TCs are
   intended to allow a (stable) network to have relatively low TC
   emission frequencies, yet still allow link breakage or link emergence
   to be advertised through the network rapidly.  A minimum message
   interval (typically much smaller than the regular periodic message
   interval) is imposed, to rate-limit worst-case message emissions.
   This attack can cause the TC interval to, permanently, become equal

Clausen, et al.         Expires November 10, 2016         =
     [Page 13]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   to the minimum message interval.  [RFC7181] proposes as default that
   the minimum TC interval be 0.25 x TC interval.
[JWD glad this was mentioned.  Something might be said regarding the reduce=
d
effectiveness of the compromised node is not ever selected as an MPR a=
s the
calculation for routing might only affect a leaf router (dependent=
 on implementation) 

   Indirect Jamming by a compromised OLSRv2 router can thus have two
   effects: it may cause increased frequency of TC generation and
   transmission, and it will cause additional routing table
   recalculation in all routers in the network.

5.  Inconsistent Topology

   Inconsistent topology maps can occur by a compromised OLSRv2 router
   employing either of identity spoofing or link spoofing for conducting
   an attack against an OLSRv2 network.  The threats related to NHDP,
   such as identity spoofing in NHDP, link spoofing in NHDP and creating
   loops have been illustrated in [RFC7186].  This section mainly
   addresses the vulnerabilities in [RFC7181].

5.1.  Identity Spoofing

   Identity spoofing can be employed by a compromised OLSRv2 router via
   the Neighborhood Discovery process and via the Link State
   Advertisement process.  Either of them causes inconsistent topology
   maps in routers in the network.  The inconsistent topology maps due
   to neighborhood discovery has been discussed in [RFC7186].  For
   OLSRv2, the attack on link state advertisements can also cause
   inconsistent topology maps.

   An inconsistent topology map may occur when the compromised OLSRv2
   router takes part in the Link State Advertisement (LSA) procedure, by
   selecting a neighbor as MPR, which in turn advertises the spoofed
   identities of the compromised OLSRv2 router.  This attack will alter
   the topology maps of all routers of the network.

[JWD] this is the only play that the term LSA is used.  Sugg=
est removing it.
[JWD] also it should be mentioned that spoof=
ing is protected against if using the SHOULD use TLVs
   A --=
 B -- C -- D -- E -- F -- X

                               (X spoofs A)

    Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the
          identity of A, leading to a wrongly perceived topology.

   In Figure 6, router X spoofs the address of router A. If X selects F
   as MPR, all routers in the network will be informed about the link
   F-A by the TCs originating from F. Assuming that (the real) A selects
   B as MPR, the link B-A will also be advertised in the network.

Clausen, et al.         Expires November 10, 2016         =
     [Page 14]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   When calculating paths, B and C will calculate paths to A via B, as
   illustrated in Figure 7(a); for these routers, the shortest path to A
   is via B. E and F will calculate paths to A via F, as illustrated in
   Figure 7(b); for these routers, the shortest path to A is via the
   compromised OLSRv2 router X, and these are thus disconnected from the
   real A. D will have a choice: the path calculated to A via B is of
   the same length as the path via the compromised OLSRv2 router X, as
   illustrated in Figure 7(b).

   In general, the following observations can be made:

   o  The network will be split in two, with those routers closer to B
      than to X reaching A, whereas those routers closer to X than to B
      will be unable to reach A.

   o  Routers beyond B, i.e., routers beyond one hop away from A will be
      unable to detect this identity spoofing.

   The identity spoofing attack via the Link State Advertisement
   procedure has a higher impact than the attack on the neighborhood
   discovery procedure, since it alters the topology maps of all routers
   in the network, and not only in the 2-hop neighborhood.  However, the
   attack is easier to detect by other routers in the network.  Since
   the compromised OLSRv2 router is advertised in the whole network,
   routers whose identities are spoofed by the compromised OLSRv2 router
   can detect the attack.  For example, when a receives a TC from F
   advertising the link F-A, it can deduce that some entity is injecting
   incorrect Link State information as it does not have F as one of its
   direct neighbors.
                                            =
     (X spoofs A)

      A < ---- B < ---- C           E ----> F ----> X

      (a) Routers B and C           (b) Routers E and F

         A < --- B < --- C < --- D ---> E ---> F ----> X

                                                    (X spoofs A)

     Figure 7: Routing paths towards A, as calculated by the different
   routers in the network in presence of a compromised OLSRv2 router X,
                        spoofing the address of A.

   As the compromised OLSRv2 router X does not itself send the TCs, but
   rather, by virtue of MPR selection, ensures that the addresses it

Clausen, et al.         Expires November 10, 2016         =
     [Page 15]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   spoofs are advertised in TCs from its MPR selector F, the attack may
   be difficult to counter: simply ignoring TCs that originate from F
   may also suppress the link state information for other, legitimate,
   MPR selectors of F.

   Identity spoofing by a compromised OLSRv2 router, participating in
   the Link State Advertisement process by selecting MPRs only, thus,
   creates a situation wherein two or more routers have substantially
   inconsistent topology maps: traffic for an identified destination is,
   depending on where in the network it appears, delivered to different
   routers.

[JWD] Link State Advertisement is again used =
here suggest lowercase.

=C2=A05.2.  Link=
 Spoofing

   Link Spoofing is a situation in which a router advertises non-
   existing links to another router (possibly not present in the
   network).  Essentially, TCs and HELLOs both advertise links to direct
   neighbor routers, with the difference being the scope of the
   advertisement.  Thus, link spoofing consists of a compromised OLSRv2
   router, reporting that it has neighbors routers which are, either,
   not present in the network, or which are effectively not neighbors of
   the compromised OLSRv2 router.

   It can be noted that a situation similar to link spoofing may occur
   temporarily in an OLSR or OLSRv2 network without compromised OLSRv2
   routers: if A was, but is no more, a neighbor of B, then A may still
   be advertising a link to B for the duration of the time it takes for
   the the Neighborhood Discovery process to determine this changed
   neighborhood.

   In the context of this document, link spoofing refers to a persistent
   situation where a compromised OLSRv2 router intentionally advertises
   links to other routers, for which it is not a direct neighbor.

[J=
WD] this is a similar attack to the above but is not protected against 
=
but the attacker is more easily identified.  One difference is that TC 
=
messages with spoofed links may be hop count limited making detection more =
difficult.=20

5.2.1.  Inconsistent Topology Maps due to Link State Adver=
tisements

   Figure 8 illustrates a network, in which the compromised OLSRv2
   router X spoofs links to a existing router A by participating in the
   Link State Advertisement process and including this non-existing link
   in its advertisements.

   A --- B --- C --- D --- E --- F --- G --- H --- X

                             (X spoofs the link to A)

   Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a

Clausen, et al.         Expires November 10, 2016         =
     [Page 16]
Internet-Draft               OLSRv2 Threats               =
      May 2016

    spoofed link to A in its TCs, thus all routers will record both of
                          the links X-A and B-A.

   As TCs are flooded through the network, all routers will receive and
   record information describing a link X-A in this link state
   information.  If A has selected router B as MPR, B will likewise
   flood this link state information through the network, thus all
   routers will receive and record information describing a link B-A.

   When calculating routing paths, B, C and D will calculate paths to A
   via B, as illustrated in Figure 9(a); for these routers, the shortest
   path to A is via B. F and G will calculate paths to A via X, as
   illustrated in Figure 9(b); for these routers, the shortest path to A
   is via X, and these are thus disconnected from the real router A. E
   will have a choice: the path calculated to A via B is of the same
   length as the path via X, as illustrated in Figure 9(b).

   A < --- B < --- C < --- D           F ---> G ---> X ---&g=
t; A

       (a) Routers B, C, and D           (b) Routers F and G

   A < --- B < --- C < --- D < --- E ---> F ---> G --->=
; X ---> A

                          (c) Router E

      Figure 9: Routing paths towards router A, as calculated by the
   different routers in the network in presence of a compromised OLSRv2
                  router X, spoofing a link to router A.

   In general, the following observations can be made:

   o  The network will be separated in two, with those routers closer to
      B than to X reaching A, whereas those routers closer to X than to
      B unable to reach A.

   o  Routers beyond B, i.e., routers beyond one hop away from A will be
      unable to detect this link spoofing.

   The impact of this attack is similar to that presented in
   Section 5.2.1, however, is easier to detect as the compromised OLSRv2
   router is generating control traffic reaching the entire network.

Clausen, et al.         Expires November 10, 2016         =
     [Page 17]
Internet-Draft               OLSRv2 Threats               =
      May 2016

6.  Mitigation of Security Vulnerabilities for OLSRv2

   As described in Section 1, [RFC7183] specifies a security mechanism
   for OLSRv2 that is mandatory to implement.  However, deployments may
   choose to use different security mechanisms if more appropriate.
   Therefore, it is important to understand both the inherent resilience
   of OLSRv2 against security vulnerabilities when not using the
   mechanisms specified in [RFC7183], as well as the protection that
   [RFC7183] provides when used in a deployment.

6.1.  Inherent OLSRv2 Resilience

   OLSRv2 (without the mandatory-to-implement security mechanisms in
   [RFC7183]) provides some inherent resilience against part of the
   attacks described in this document.  In particular, it provides the
   following resilience:

   o  Sequence numbers: OLSRv2 employs message sequence numbers,
      specific per router identity and message type.  Routers keep an
      "information freshness" number (ANSN), incremented each tim=
e the
      content of a Link State Advertisement from a router changes.  This
      allows rejecting "old" information and duplicate messages, =
and
      provides some protection against "message replay".  This, h=
owever,
      also presents an attack vector (Section 4.3).

   o  Ignoring uni-directional links: The Neighborhood Discovery process
      detects and admits only bi-directional links for use in MPR
      selection and Link State Advertisement.  Jamming attacks may
      affect only reception of control traffic, however OLSRv2 will
      correctly recognize, and ignore, such a link as not bi-
      directional.

   o  Message interval bounds: The frequency of control messages, with
      minimum intervals imposed for HELLO and TCs.  This may limit the
      impact from an indirect jamming attack (Section 4.4).

   o  Additional reasons for rejecting control messages: The OLSRv2
      specification includes a list of reasons, for which an incoming
      control message should be rejected as malformed - and allows that
      a protocol extension may recognize additional reasons for OLSRv2
      to consider a message malformed.  This allows - together with the
      flexible message format [RFC5444] - addition of security
      mechanisms, such as digital signatures, while remaining compliant
      with the OLSRv2 standard specification.

Clausen, et al.         Expires November 10, 2016         =
     [Page 18]
Internet-Draft               OLSRv2 Threats               =
      May 2016

6.2.  Resilience by using RFC7183 with OLSRv2

   [RFC7183] specifies mechanisms for integrity and replay protection
   for NHDP and OLSRv2, using the generalized packet/message format
   described in [RFC5444] and the TLV definitions in [RFC7182].  The
   specification describes how to add an Integrity Check Value (ICV) in
   a TLV to each control message, providing a digital signature of the
   content of the message using HMAC/SHA-256.  In addition, a timestamp
   TLV is added to the message prior to creating the ICV, enabling
   replay protection of messages.  The document specifies how to sign
   outgoing messages and how to verify incoming messages, as well as
   under which circumstances a non-valid message is rejected.  Because
   of the HMAC/SHA-256 ICV, a shared key between all routers in the
   MANET is assumed.  A router without valid credentials is not able to
   create an ICV that can be correctly verified by other routers in the
   MANET; therefore, such an incorrectly signed message will be rejected
   by other MANET routers, and the router cannot participate in the
   OLSRv2 routing process (i.e., the malicious router will be ignored by
   other, legitimate routers).  [RFC7183] does not address the case
   where a router with valid credentials has been compromised.  Such a
   compromised router will not be excluded from the routing process, and
   other means of detecting such a router are necessary if required in a
   deployment (in addition to using asymmetric keys, allowing to revoke
   access to one particular router instead of revoking the shared key
   used by all routers in the MANET).

   In the following sections, each of the vulnerabilities described
   earlier in this document will be evaluated in terms of whether OLSRv2
   with the mechanisms in [RFC7183] provides sufficient protection
   against the attack.  It is implicitly assumed in each of the
   following sections that [RFC7183] is used with OLSRv2.

[JWD] this is a really important part of the document and should be moved<=
br>up to provide the reader with a better understanding.  Without this it w=
ill
be easy for a reader to assume that all attacks presented are equall=
y possible.
A summary was given but more details (along with an inline s=
entence per attack 
pointing to appropriate section below) would help qu=
ite a lot.

6.2.1.  Topology Map Acquisit=
ion

   Attack on Jittering -  As only OLSRv2 routers with valid credentials
      can participate in the routing process, a malicious router cannot
      reduce the jitter time of an attacked router to 0 by sending many
      TC messages in a short time.  The attacked router would reject all
      the incoming messages as "invalid" and not forward them.  T=
he same
      applies for the case where a malicious router wants to assure that
      by forcing a zero jitter interval, the message arrives before the
      same message forwarded by legitimate routers.

   Modifying the Hop Limit -  As the hop limit is not protected by
      [RFC7183] (since it is a mutual field, changing at every hop),
      this attack is still feasible.

Clausen, et al.         Expires November 10, 2016         =
     [Page 19]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   Modifying the Hop Count -  Similarly to the hop limit, as the hop
      count is not protected by [RFC7183] (since it is a mutual field,
      changing at every hop), this attack is still feasible.

6.2.2.  Effective Topology

   Incorrect Forwarding -  As only OLSRv2 routers with valid credentials
      can participate in the routing process, a malicious router will
      not be part of the topology of other legitimate OLSRv2 routers.
      Therefore, no data traffic will be sent to the malicious router
      for forwarding.

   Wormholes -  Since a wormhole consists of at least two devices
      forwarding (unmodified) traffic, this attack is still feasible and
      undetectable by the OLSRv2 routing process since the attack does
      not involve the OLSRv2 protocol itself (but rather lower layers).
      By using [RFC7183], it can at least be assured that the content of
      the control messages is not modified while being forwarded via the
      wormhole.  Moreover, the timestamp TLV assures that the forwarding
      can only be done in a short time window after the actual TC
      message has been sent.

   Message Sequence Number -  As the message sequence number is included
      in the ICV calculation, OLSRv2 is protected against this attack.

   Advertised Neighbor Sequence Number (ANSN) -  As the ANSN is included
      in the ICV calculation, OLSRv2 is protected against this attack.

   Indirect Jamming -  Since the control messages of a malicious router
      will be rejected by other legitimate OLSRv2 routers in the MANET,
      this attack is mitigated.

6.2.3.  Inconsistent Topology

   Identity Spoofing -  Since the control messages of a malicious router
      will be rejected by other legitimate OLSRv2 routers in the MANET,
      a router without valid credentials may spoof its identity (e.g.,
      IP source address or message originator address), but the messages
      will be ignored by other routers.  As the mandatory mechanism in
      [RFC7183] uses shared keys amongst all MANET routers, a single
      compromised router may spoof its identity and cause harm to the
      network stability.  Removing this one malicious router once
      detected implies rekeying all other routers in the MANET.
      Asymmetric keys, in particular when using identity based
      signatures, such as specified in [IBS] may further allow to revoke
      single routers and to verify their identity based on the ICV
      itself.

Clausen, et al.         Expires November 10, 2016         =
     [Page 20]
Internet-Draft               OLSRv2 Threats               =
      May 2016

   Link Spoofing -  Similar to identity spoofing, a malicious router
      without valid credential may spoof links, but its control messages
      will be rejected by other routers, thereby mitigating the attack.

   Inconsistent Topology Maps due to Link State Advertisements -  The
      same considerations as for link spoofing apply.

7.  Security Considerations

   This document does not specify a protocol or a procedure.  The
   document, however, reflects on security considerations for OLSRv2,
   and its constituent parts, including NHDP.

8.  IANA Considerations

   This document has no actions for IANA.

9.  References

9.1.  Normative References

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2&quo=
t;,
              RFC 7181, April 2014.

   [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats f=
or
              the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
              April 2014.

9.2.  Informative References

   [FUNKFEUER]
              "http://www.funkfeu=
er.at/".

   [IBS]      Dearlove, C., "Identity-Based Signatures for MANET Routi=
ng
              Protocols", work in progress draft-ietf-manet-ibs-05,
              March 2016.

   [IEEE802.11]
              "IEEE 802.11: Wireless LAN Medium Access Control (MAC) a=
nd
              Physical Layer (PHY) Spec.", 2007.

   [MPR-FLOODING]
              Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
              relaying: An efficient technique for flooding in mobile

Clausen, et al.         Expires November 10, 2016         =
     [Page 21]
Internet-Draft               OLSRv2 Threats               =
      May 2016

              wireless networks.", 2001.

   [OLSR-FSR]
              Clausen, T., "Combining Temporal and Spatial Partial
              Topology for MANET routing-Merging OLSR and FSR,
              Proceedings of the 2003 IEEE Conference of Wireless
              Personal Multimedia Communications (WPMC 03)", 2003.

   [OLSR-FSR-Scaling]
              Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G.
              Rodolakis, "Fish eye OLSR scaling properties, IEEE Journ=
al
              of Communication and Networks (JCN), Special Issue on
              Mobile Ad Hoc Wireless Networks", 2004.

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
              Finch, "Email Submission Operations: Access and
              Accountability Requirements", RFC 5068, BCP 134,
              October 2007.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444=
,
              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

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

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol"=
,
              RFC 6779, May 2012.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, April 2014.

   [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)

Clausen, et al.         Expires November 10, 2016         =
     [Page 22]
Internet-Draft               OLSRv2 Threats               =
      May 2016

              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7183, April 2014.

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, April 2014.

   [RFC7187]  Dearlove, C. and T. Clausen, "Routing Multipoint Relay
              Optimization for the Optimized Link State Routing Protocol
              Version 2 (OLSRv2)", RFC 7187, April 2014.

   [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routi=
ng
              Protocol Version 2 (OLSRv2) and MANET Neighborhood
              Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
              April 2014.

Authors' Addresses

   Thomas Clausen

   Phone: +33-6-6058-9349
   Email: T.Clausen@computer.org<=
/a>
   URI:   http://www.thomasclausen=
.org

   Ulrich Herberg

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

   Jiazi Yi
   Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 1 77 57 80 85
   Email: jiazi@jiaziyi.com
   URI:   http://www.jiaziyi.com/

Clausen, et al.         Expires November 10, 2016         =
     [Page 23]
--94eb2c03f484c2a1c1053b2e5cf4-- From nobody Sun Aug 28 22:50:17 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D912D0DA for ; Sun, 28 Aug 2016 22:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TsslToB-EC2E for ; Sun, 28 Aug 2016 22:50:15 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 F01E412D093 for ; Sun, 28 Aug 2016 22:50:14 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id l2so128566108qkf.3 for ; Sun, 28 Aug 2016 22:50:14 -0700 (PDT) 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; bh=ZMbQGXdgiFpE3NHL7BhS65JhdzFt2TWM8/Ixn/Hsd+A=; b=GF9Y/9JHpj79IvYNZIFpiu7w5+iFFfYiltZgjC7M3NGr/kLSvDTu5pFinIw2GIAV2v Gl95nbR5eY2JptaVJgcDO/gC+ttoSwroM4ua1uNXD3AUCud2IFginTcXrJk7/Se4c39E +uJpfxoFJs4wLUfcyLwCJGYcThwEcUvCtmlu8jO8ymeCE3lRkHzFTMrbb6dQlQlotq65 wKTb8Q3w6od3ch0E/0ZDttlgP2F60ZfVUmMtU2YkkMgNg4wgaiXVgfp7kw6Ydmmj6rhR aJXXpU+Zd6G19ITBbrjBvCiQd9TcLXooi0FINOGZNfhkmTdsMNSb8dcjRn08U8KqrRFy wNhA== 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; bh=ZMbQGXdgiFpE3NHL7BhS65JhdzFt2TWM8/Ixn/Hsd+A=; b=e4rzQwviBSDXPN1BMSCnE5DpFS+JZraRMKe3DnXoSVe9MbRqSpX6cGUMXmn5o0DRCa us80tlexZ5D3TiEjsn1LiIQVu0x04vcFTTpABFlVpCrknSvbUY3eQ20ib95rCI7JlDP7 /SiY8kGVweUc+MvoszfqxE+sUsJfdQz5yK7wKhUHF4RuJ03WVjmRb4V68g4tYltiKQVw +IlbpCKw8rqner4kLB8vivy2+mKL5Fvtdg7UafGNclPqKZIIaA/X6Wo9ndiuKTi3FxFl YjVYvrQ8f05oo5HMiJwTBBU93Go9+oyDPwwkx5p+iDsl0LZ8R0nSxzzR8C956Z5n55J4 jYTQ== X-Gm-Message-State: AE9vXwNEh5hffA7A3QeVvFPSRNU1Q575F9xNEK5V9s60x5/6lBttJR0zHoC8ySyrNRPRwTf+M6+vq+qgGn6LlA== X-Received: by 10.55.94.66 with SMTP id s63mr17663410qkb.31.1472449814109; Sun, 28 Aug 2016 22:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.81.137 with HTTP; Sun, 28 Aug 2016 22:50:13 -0700 (PDT) In-Reply-To: <71189398-8C9E-4C81-A600-02856E1ECD04@thomasclausen.org> References: <71189398-8C9E-4C81-A600-02856E1ECD04@thomasclausen.org> From: Abdussalam Baryun Date: Mon, 29 Aug 2016 07:50:13 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=001a114f5c061ea48b053b2f7065 Archived-At: Cc: manet Subject: Re: [manet] Berlin minutes ? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 05:50:17 -0000 --001a114f5c061ea48b053b2f7065 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Thomas, I have not been able to attend the meeting remotely also. However, it is important that we continue to check/review these issues. I will try to do my best to make the complete corrections. On Fri, Aug 26, 2016 at 5:58 PM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > Hi, > > As I was not able to attend the latest Berlin meeting, I wanted to check > the meeting minutes to understand if the WG was heading anywhere > (rechartering etc. having happened, and such), and if so where and what t= he > strategy for getting there would be. > > Having not seen any announcement on the list that the minutes had been > posted (!), I was (pleasantly) surprised to see that they were actually > on-line here: > https://www.ietf.org/proceedings/96/minutes/minutes-96-manet > > Until, that is, I saw the annotation in the top of the minutes that: > > * "NOTE: There are a number of inaccuracies in the minutes. Please refer > to the audio in case * > * of doubts: > https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-20160720-1400.mp= 3 > "* > > Given that there=E2=80=99s no indication *where* in the minutes there are > inaccuracies, or if those are merely details or are misrepresentation, or > are omissions, let alone where in the minutes there are inaccuracies, thi= s > is not terribly helpful. > > Posting minutes, known to be inaccurate, is a first to me =E2=80=94 and a= ctually > explicitly contradicts RFC2026 section 8 which requires maintaining *"com= plete > and accurate minutes of meetings=E2=80=9D*. > In IETF there is always updates even for RFCs. I don't think any thing in the human production can be complete or correct 100 %. Human always have a production error as Machines do. Only God (Allah) is complete and produces 100% accurate and complete. Best Regards AB --001a114f5c061ea48b053b2f7065 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Thomas,

I have not be= en able to attend the meeting remotely also. However, it is important that = we continue to check/review these issues. I will try to do my best to make = the complete corrections.

On Fri, Aug 26, 2016 at 5:58 PM, Thomas Heide Clausen <= ietf@thomasclausen.org> wrote:
Hi,

As I was not able to= attend the latest Berlin meeting, I wanted to check the meeting minutes to= understand if the WG was heading anywhere (rechartering etc. having happen= ed, and such), and if so where and what the strategy for getting there woul= d be.=C2=A0

Having not seen any announcement on th= e list that the minutes had been posted (!), =C2=A0I was (pleasantly) surpr= ised to see that they were actually on-line here:
Until, that is, I saw the annotation in the top of the minut= es that:

= "NOTE: There are a number = of inaccuracies in the minutes. Please refer to the audio in case=C2=A0

Given that there=E2=80= =99s no indication *where* in the minutes there are inaccuracies, or if tho= se are merely details or are misrepresentation, or are omissions, let alone= where in the minutes there are inaccuracies, this is not terribly helpful.=

Posting minutes, known to be inaccurate, is a fir= st to me =E2=80=94 and actually explicitly contradicts RFC2026 section 8 wh= ich requires maintaining "complete and accurate minutes of meetings= =E2=80=9D.

In IETF there is= always updates even for RFCs. I don't think any thing in the human pro= duction can be complete or correct 100 %. Human always have a production er= ror as Machines do. Only God (Allah)=C2=A0is complete and produces 100% acc= urate and complete.=C2=A0

Best Regards
A= B=C2=A0
--001a114f5c061ea48b053b2f7065-- From nobody Sun Aug 28 23:25:08 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DA12D13A for ; Sun, 28 Aug 2016 23:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZZifac8g0xvR for ; Sun, 28 Aug 2016 23:25:04 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 07E3A12D0E8 for ; Sun, 28 Aug 2016 23:25:04 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w38so63916324qtb.0 for ; Sun, 28 Aug 2016 23:25:03 -0700 (PDT) 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; bh=Q1xlCDVX9IccH9iX+sVe4jl6ijnZA52GDMqd6Qu0ZFQ=; b=pxzU/jx1+1vetSEgzOKENavEYpfhL8thJXfNyDgXpiV6TyO0FMGj2iqJqGTzPPImwA kOg28Uyi7u5pV1+QZMOe8Ekgo0SnZ8FrvlFhorvrJDsEo4YsdNsDjXponMc/WQDfnWcR 55ZmTs73qdSW0IpfoXKT8ubCtVxIwgLT5LaBbis2Xvxk37lUXn4eW9vxJLhwKVklruQJ Z452c93iU/fgpGc2tHS2pbD93Kx5G8vR36Ha1teoyQsBgzYt+e0qL5iK4yZndNMBjzQL pDJ/QazYrL/gXnek6avj5qh20pTt0T80jLTRGxoVK9wyCCAdI4TSYPMqlCGZLAn2wDcs 5IXA== 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; bh=Q1xlCDVX9IccH9iX+sVe4jl6ijnZA52GDMqd6Qu0ZFQ=; b=j/pLiBXsTdwm9lPfGRmkcdZmLzPpDroDavVhN1brYcIXnljE5Pmwp7R6ydas7JNJqV RyXIQTDrU7CDjXUmvs3a7Bi9UDhgqz0K4I3MYH1e3yKA18yF0/qc7BKfiaGTNT8Y87G1 /rARwD+kInGvk0gaNZdawpwN5oxt+h1glhw6SOtZwhCu7bRbH/h87v1aDgElt1O5qOiI mh7EH/3Q4my4AaEKo0GNPLBtut9TELRlXfRjkj9qDEiveEGRCiPgx4QzdJdAh6rruqz+ /OcHZFDmlumi3Ll2n9zUURdW3+CiobVJZ+Tdhjo01ilOXzHnkhMfs9gDfFcbEXe028ge FbuA== X-Gm-Message-State: AE9vXwNLFJGeMgeTfY9c9rInV24GKmMvAjDr6ZPSQQ5F0Rzaa6UKwAd0MYmxS9We49XJNjVz8sXL9u6ORZoO0w== X-Received: by 10.237.59.212 with SMTP id s20mr16503190qte.126.1472451903009; Sun, 28 Aug 2016 23:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.81.137 with HTTP; Sun, 28 Aug 2016 23:25:02 -0700 (PDT) In-Reply-To: References: From: Abdussalam Baryun Date: Mon, 29 Aug 2016 08:25:02 +0200 Message-ID: To: Justin Dean Content-Type: multipart/alternative; boundary=94eb2c190c30a0baca053b2fecd1 Archived-At: Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] OLSRv2 sec threats review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 06:25:07 -0000 --94eb2c190c30a0baca053b2fecd1 Content-Type: text/plain; charset=UTF-8 Thanks Justin, I would add my quick comments, On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean wrote: > As there weren't many on list comments during or after last call here is my detailed review. > Summary is that I'm doing the writeup right now and passing it on up. Most of my comments > are of the editorial type with exceptions which are minor and mostly clarification based. > > Apologies to the author team for not getting this done sooner; I wanted to make sure I did it right. > > > Comments noted as JWD > > > > > Network Working Group T. Clausen > Internet-Draft U. Herberg > Intended status: Informational > Expires: November 10, 2016 J. Yi > Ecole Polytechnique > May 9, 2016 > > Security Threats for the Optimized Link State Routing Protocol version 2 > (OLSRv2) > draft-ietf-manet-olsrv2-sec-threats-02 > Abstract > > This document analyzes common security threats of the Optimized Link > State Routing Protocol version 2 (OLSRv2) and describes their > potential impacts on Mobile Ad Hoc Network (MANET) operations. It > then analyzes which of these security vulnerabilities can be > mitigated when using the mandatory-to-implement security mechanisms > for OLSRv2, and how the vulnerabilities are mitigated. > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on November 10, 2016. > Copyright Notice > > Copyright (c) 2016 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > Clausen, et al. Expires November 10, 2016 [Page 1]Internet-Draft OLSRv2 Threats May 2016 > > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 4 > 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . . 4 > 1.1.2. MPR Flooding . . . . . . . . . . . . . . . . . . . . . 5 > 1.1.3. Link State Advertisement . . . . . . . . . . . . . . . 5 > 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 5 > 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 6 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . . 6 > 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 7 > 3.2. Hop-count and Hop-limit Attacks . . . . . . . . . . . . . 7 > 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 7 > 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 > 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 > 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 9 > 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 10 > 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 11 > 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 11 > 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . . 11 > 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12 > 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 14 > 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 14 > 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 > 5.2.1. Inconsistent Topology Maps due to Link State > Advertisements . . . . . . . . . . . . . . . . . . . . 16 > 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 18 > 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 > 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 19 > 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 > 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 20 > 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 20 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 > Clausen, et al. Expires November 10, 2016 [Page 2]Internet-Draft OLSRv2 Threats May 2016 > 1. Introduction > > The Optimized Link State Routing Protocol version 2 (OLSRv2) > [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182], > [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a > routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains > the same basic algorithms as its predecessor, however offers various > improvements, e.g., a modular and flexible architecture allowing > extensions, such as for security, to be developed as add-ons to the > basic protocol. > > [JWD] NIT: listing RFC7181 first would be helpful. > > [AB] why the introduction says basic algorithms as OLSRv1, it is confusing, I think they are not having similar procedures. The plural of algorithms even makes it confused. It is better to say 'basic algorithm'. > > The developments reflected in OLSRv2 have been motivated by increased > real-world deployment experiences, e.g., from networks such as > FunkFeuer [FUNKFEUER], and the requirements presented for continued > successful operation of these networks. With participation in such > networks increasing (the FunkFeuer community network has, e.g., > roughly 400 individual participants at the time of publication of > this document), operating with the assumption, that participants can > be "trusted" to behave in a non-destructive way, is utopia. Taking > the Internet as an example, as participation in the network increases > and becomes more diverse, more efforts are required to preserve the > integrity and operation of the network. Most SMTP-servers were, > e.g., initially available for use by everyone on the Internet - with > an increased populace on the Internet, attacks and abuses caused the > recommended practice is today to require authentication and > accounting for users of such SMTP servers [RFC5068]. > > [JWD] NIT language improvement....with an increase in users on the Internet, > an increase in attacks and abuses followed necessitating a change in recommended > practices; today authentication and accounting for users is required for use of SMTP servers [RFC5068]. > > > As OLSRv2 often is used in wireless environments, it is potentially > exposed to different kinds of security threats, some of which are of > particular significance as compared to wired networks. As radio > signals can be received as well as transmitted by any compatible > wireless device within radio range, there is commonly no physical > protection as otherwise known for wired networks. > > [AB] it should not only say about wireless and wired, but what about Mobile environment, OLSRv2 is for MANET, so it is not only for wireless. Threats are more in Mobile environment than Wireless environment. So please add some words about the different threats for OLSRv2 in Mobile, in addition to the threats in wireless. Otherwise the draft needs to state what states that are mobile environment threats, or what states are covered in the draft. We need for threats, to define the environment under study/analysis, or the scenarios. I don't know if IETF they do this or not for threat document, but IMHO it is very important to have some basic mobile scenarios. > > A first step towards hardening against attacks disrupting the > connectivity of a network, is to understand the vulnerabilities of > routing protocol, managing the connectivity. This document therefore > analyzes OLSRv2, to understand its inherent vulnerabilities and > resiliences. The authors do not claim completeness of the analysis, > but hope that the identified attacks, as presented, form a meaningful > starting-point for developing and deploying increasingly secured > OLSRv2 networks. > > So the analysis is not complete, we need to say why? if we say why it will be good for future work to solve the issue. However, we can describe the analysis as simple-analysis or any other word ( basic, general, ,,,,), that will help the reader understand that there may be future analysis that will use this draft as its start for more deep/specific/complete analysis. > > This document first describes security vulnerabilities to OLSRv2 when > it is used without the mandatory-to-implement security mechanisms, as > specified in Section 23.5 of [RFC7181]. It then analyzes which of > these security vulnerabilities can be mitigated when using the > mandatory-to-implement security mechanisms for OLSRv2, and how the > Clausen, et al. Expires November 10, 2016 [Page 3]Internet-Draft OLSRv2 Threats May 2016 > > vulnerabilities are mitigated. This separation is important since > other security mechanisms ([JWD] other) than the mandatory-to-implement ones may be > used in a deployment, as explicitly stated in [RFC7181]: > > "Any deployment of OLSRv2 SHOULD use the security mechanism > specified in [RFC7183] but MAY use another mechanism if more > appropriate in an OLSRv2 deployment. For example, for longer-term > OLSRv2 deployments, alternative security mechanisms (e.g., > rekeying) SHOULD be considered." > > Moreover, this document is also based on the assumption that no > additional security mechanism such as IPsec is used in the IP layer > or other mechanisms on lower layers, as not all MANET deployments may > be able to accommodate such common protection mechanisms (e.g., > because of limited resources of MANET routers). > > The threats related to NHDP (Neighborhood Discovery Protocol) have > been discussed in [RFC7186]. As NHDP is a fundamental block of > OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2. > > It should be noted that many OLSRv2 implementations are configurable, > and so an attack on the configuration system (such as [RFC6779] and > [RFC7184]) can be used to adversely affect the operation of an OLSRv2 > implementation. > > [AB] I cannot understand the paragraph, I think there is edit error in lines of------- system and can be used .... will continue review, Regards AB --94eb2c190c30a0baca053b2fecd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Justin,

I would add m= y quick comments,

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean <bebemaster@gmail.co= m> wrote:
As there =
weren't many on list comments during or after last call here is my deta=
iled review.
Summary is that I'm doing the writeup right now and pas=
sing it on up.  Most of my comments 
are of the editorial type with exce=
ptions which are minor and mostly clarification based.

Ap=
ologies to the author team for not getting this done sooner; I wanted to ma=
ke sure I did it right.

Comments noted as JWD



Network Working Group = T. Clausen Internet-Draft U. Herberg Intended status: Informational Expires: November 10, 2016 J. Yi Ecole Polytechnique May 9, 2016 Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) draft-ietf-manet-olsrv2-sec-threats-02 Abstract This document analyzes common security threats of the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 10, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http= ://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Clausen, et al. Expires November 10, 2016 [Page= 1] Internet-Draft OLSRv2 Threats May 2= 016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . . 4 1.1.2. MPR Flooding . . . . . . . . . . . . . . . . . . . . . 5 1.1.3. Link State Advertisement . . . . . . . . . . . . . . . 5 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 5 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . . 6 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 7 3.2. Hop-count and Hop-limit Attacks . . . . . . . . . . . . . 7 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 7 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 9 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 11 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 11 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . . 11 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 14 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 14 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Inconsistent Topology Maps due to Link State Advertisements . . . . . . . . . . . . . . . . . . . . 16 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 18 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 19 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 20 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 2= 3 Clausen, et al. Expires November 10, 2016 [Page= 2] Internet-Draft OLSRv2 Threats May 2= 016 1. Introduction The Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182], [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains the same basic algorithms as its predecessor, however offers various improvements, e.g., a modular and flexible architecture allowing extensions, such as for security, to be developed as add-ons to the basic protocol.
[JWD] NIT: listing RFC7181 first would be =
helpful.
[AB] why the introduction says ba= sic algorithms as OLSRv1, it is confusing, I think they are not having=C2= =A0similar procedures. The plural of algorithms even makes it confused. It = is better to say 'basic algorithm'.
  
  =C2=A0The developments reflected in OLSRv2=
 have been motivated by increased
   real-world deployment experiences, e.g., from networks such as
   FunkFeuer [FUNKFEUER], and the requirements presented for continued
   successful operation of these networks.  With participation in such
   networks increasing (the FunkFeuer community network has, e.g.,
   roughly 400 individual participants at the time of publication of
   this document), operating with the assumption, that participants can
   be "trusted" to behave in a non-destructive way, is utopia.  T=
aking
   the Internet as an example, as participation in the network increases
   and becomes more diverse, more efforts are required to preserve the
   integrity and operation of the network.  Most SMTP-servers were,
   e.g., initially available for use by everyone on the Internet - with
   an increased populace on the Internet, attacks and abuses caused the
   recommended practice is today to require authentication and
   accounting for users of such SMTP servers [RFC5068].

[=
JWD] NIT language improvement....with an increase in users on the Internet,=
 
an increase in attacks and abuses followed necessitating a change in r=
ecommended 
practices; today authentication and accounting for users is =
required for use of SMTP servers [RFC5068].

  =C2=A0As OL=
SRv2 often is used in wireless environments, it is potentially
   exposed to different kinds of security threats, some of which are of
   particular significance as compared to wired networks.  As radio
   signals can be received as well as transmitted by any compatible
   wireless device within radio range, there is commonly no physical
   protection as otherwise known for wired networks.
[AB] it should not only say about wireless and wired, but what about=
 Mobile environment,=C2=A0OLSRv2 is for MANET, so it is not only for wirele=
ss. Threats are more in Mobile environment than Wireless environment. So pl=
ease add some words about the different threats for OLSRv2 in Mobile, in ad=
dition to the threats in wireless. Otherwise the draft needs to state what =
states that are mobile environment threats, or what states are covered in t=
he draft.

We need for threats, to define the envir=
onment under study/analysis, or the scenarios. I don't know if IETF the=
y do this or not for threat document, but IMHO it is very important to have=
 some basic mobile scenarios.
   A first step towards hardening against attacks disrupting the
   connectivity of a network, is to understand the vulnerabilities of
   routing protocol, managing the connectivity.  This document therefore
   analyzes OLSRv2, to understand its inherent vulnerabilities and
   resiliences.  The authors do not claim completeness of the analysis,
   but hope that the identified attacks, as presented, form a meaningful
   starting-point for developing and deploying increasingly secured
   OLSRv2 networks.

So the anal=
ysis is not complete, we need to say why? if we say why it will be good for=
 future work to solve the=C2=A0issue. However, we can describe the analysis=
 as simple-analysis or=C2=A0any other word ( basic, general, ,,,,), that wi=
ll help the reader understand that there may be future analysis that will u=
se this draft as its start for more deep/specific/complete analysis.=C2=A0<=
/div>
   This document first describes security vulnerabilities to OLSRv2 when
   it is used without the mandatory-to-implement security mechanisms, as
   specified in Section 23.5 of [RFC7181].  It then analyzes which of
   these security vulnerabilities can be mitigated when using the
   mandatory-to-implement security mechanisms for OLSRv2, and how the

Clausen, et al.         Expires November 10, 2016               [Page=
 3]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   vulnerabilities are mitigated.  This separation is important since
   other security mechanisms ([JWD] other) than the mandatory-to-implement =
ones may be
   used in a deployment, as explicitly stated in [RFC7181]:

      "Any deployment of OLSRv2 SHOULD use the security mechanism
      specified in [RFC7183] but MAY use another mechanism if more
      appropriate in an OLSRv2 deployment.  For example, for longer-term
      OLSRv2 deployments, alternative security mechanisms (e.g.,
      rekeying) SHOULD be considered."

   Moreover, this document is also based on the assumption that no
   additional security mechanism such as IPsec is used in the IP layer
   or other mechanisms on lower layers, as not all MANET deployments may
   be able to accommodate such common protection mechanisms (e.g.,
   because of limited resources of MANET routers).

   The threats related to NHDP (Neighborhood Discovery Protocol) have
   been discussed in [RFC7186].  As NHDP is a fundamental block of
   OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.

   It should be noted that many OLSRv2 implementations are configurable,
   and so an attack on the configuration system (such as [RFC6779] and
   [RFC7184]) can be used to adversely affect the operation of an OLSRv2
   implementation.
[AB] I cannot understand th=
e paragraph, I think there is edit error in lines of-------=C2=A0 system an=
d can be used ....=C2=A0

will continue review,

Regards
AB


--94eb2c190c30a0baca053b2fecd1--


From nobody Tue Aug 30 01:24:56 2016
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB03E12D89B for ; Tue, 30 Aug 2016 01:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SOeAEduInR_a for ; Tue, 30 Aug 2016 01:24:48 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 596B012D888 for ; Tue, 30 Aug 2016 01:24:47 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id l89so8105578lfi.1 for ; Tue, 30 Aug 2016 01:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=maOqTfSq0FoH8jlHLdUqc+x1W7l9FML+x0Relakrldo=; b=OZMiZ+MiUtE4VZHApb+6RjN6ATiqdA+wjzbffa+M44RuwwG4/qocacgW3rHvJhvNb8 bUFOWdld46DVsOLJ3veVAB+zKZtL5WOpYTQ1ikt/WBHpceSlP60LF9yLeRzceFAZkKBS GX+ZbQJ1VY8xuDlf+HTXB7vxEr1pezYRkO4x1zacjN1K9U0kMev3RM/MsKzo5QRrvuo5 QBv3Vi6EU1rEPDY5Z0rTznFWcAS9iCdmmVxPO30Rube9rzOAruaD8w8Dj9fZRza44SSb 7KXBX9C/unjIw5sYsKfWVAVxZ0f81zo4Q0UiOQcedW4ADNt7P8X/HfaGh/kv3DecrxSG pkag==
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:from :date:message-id:subject:to:cc; bh=maOqTfSq0FoH8jlHLdUqc+x1W7l9FML+x0Relakrldo=; b=ekq/s/XAgzfwhEw55+RDu9cAj5Mv/276Xn57iQupz+jFC/IGZWaL/Q+pCqQTYkEd3s m3JmxrXGPW+rYyUF9fOCCjL8oNM1NhKsTsc3RPEawhPuL38dEYc4PI5MoBnwahOSO9kh r3p6WIf3fVgiqNij4FV5QiXQfZj5pW2ln1Dlb87E46fDf2kztc7sr6rEbFwbR35gXPqH 5SM9jUmbOGWx+ldFfZNg15yrNJiVk7QOffKmrRmLidqDTbN3UVhq4BLe2Mv7cytClNm2 JlZGAL8OPZTSZS++R3Y9vpSD6n/31l7nM0qhEpvxntBLDKVe8gwK5VjFoCnFkXyYvfVr MAmQ==
X-Gm-Message-State: AE9vXwM3PptzVXeoyq46pCndlipnHqOL7jDTXV6yFbmCu9uwfDrU2eYSOYVUMXBKnDdNVbeLWUX4Pz2/LIbOcw==
X-Received: by 10.25.215.145 with SMTP id q17mr687543lfi.30.1472545485097; Tue, 30 Aug 2016 01:24:45 -0700 (PDT)
MIME-Version: 1.0
Sender: yi.jiazi@gmail.com
Received: by 10.114.184.2 with HTTP; Tue, 30 Aug 2016 01:24:43 -0700 (PDT)
In-Reply-To: 
References: 
From: Jiazi YI 
Date: Tue, 30 Aug 2016 10:24:43 +0200
X-Google-Sender-Auth: t0oZUUdHML5ShxBaXUFaX0Mj8qc
Message-ID: 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=001a114113da8e10e9053b45b671
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] OLSRv2 sec threats review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 08:24:55 -0000

--001a114113da8e10e9053b45b671
Content-Type: text/plain; charset=UTF-8

Thanks very much for the review, Justin.

We will update the draft based on the comments received and make a
submission soon.

regards

Jiazi

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean  wrote:

> As there weren't many on list comments during or after last call here is my detailed review.
> Summary is that I'm doing the writeup right now and passing it on up.  Most of my comments
> are of the editorial type with exceptions which are minor and mostly clarification based.
>
> Apologies to the author team for not getting this done sooner; I wanted to make sure I did it right.
>
>
> Comments noted as JWD
>
>
>
>
> Network Working Group                                         T. Clausen
> Internet-Draft                                                U. Herberg
> Intended status: Informational
> Expires: November 10, 2016                                         J. Yi
>                                                      Ecole Polytechnique
>                                                              May 9, 2016
>
> Security Threats for the Optimized Link State Routing Protocol version 2
>                                 (OLSRv2)
>                  draft-ietf-manet-olsrv2-sec-threats-02
> Abstract
>
>    This document analyzes common security threats of the Optimized Link
>    State Routing Protocol version 2 (OLSRv2) and describes their
>    potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
>    then analyzes which of these security vulnerabilities can be
>    mitigated when using the mandatory-to-implement security mechanisms
>    for OLSRv2, and how the vulnerabilities are mitigated.
> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on November 10, 2016.
> Copyright Notice
>
>    Copyright (c) 2016 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
> Clausen, et al.         Expires November 10, 2016               [Page 1]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  OLSRv2 Overview  . . . . . . . . . . . . . . . . . . . . .  4
>        1.1.1.  Neighborhood Discovery . . . . . . . . . . . . . . . .  4
>        1.1.2.  MPR Flooding . . . . . . . . . . . . . . . . . . . . .  5
>        1.1.3.  Link State Advertisement . . . . . . . . . . . . . . .  5
>      1.2.  Link State Vulnerability Taxonomy  . . . . . . . . . . . .  5
>      1.3.  OLSRv2 Attack Vectors  . . . . . . . . . . . . . . . . . .  6
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
>    3.  Topology Map Acquisition . . . . . . . . . . . . . . . . . . .  6
>      3.1.  Attack on Jittering  . . . . . . . . . . . . . . . . . . .  7
>      3.2.  Hop-count and Hop-limit Attacks  . . . . . . . . . . . . .  7
>        3.2.1.  Modifying the Hop Limit  . . . . . . . . . . . . . . .  7
>        3.2.2.  Modifying the Hop Count  . . . . . . . . . . . . . . .  8
>    4.  Effective Topology . . . . . . . . . . . . . . . . . . . . . .  9
>      4.1.  Incorrect Forwarding . . . . . . . . . . . . . . . . . . .  9
>      4.2.  Wormholes  . . . . . . . . . . . . . . . . . . . . . . . . 10
>      4.3.  Sequence Number Attacks  . . . . . . . . . . . . . . . . . 11
>        4.3.1.  Message Sequence Number  . . . . . . . . . . . . . . . 11
>        4.3.2.  Advertised Neighbor Sequence Number (ANSN) . . . . . . 11
>      4.4.  Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12
>    5.  Inconsistent Topology  . . . . . . . . . . . . . . . . . . . . 14
>      5.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . . . . 14
>      5.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . . . 16
>        5.2.1.  Inconsistent Topology Maps due to Link State
>                Advertisements . . . . . . . . . . . . . . . . . . . . 16
>    6.  Mitigation of Security Vulnerabilities for OLSRv2  . . . . . . 18
>      6.1.  Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18
>      6.2.  Resilience by using RFC7183 with OLSRv2  . . . . . . . . . 19
>        6.2.1.  Topology Map Acquisition . . . . . . . . . . . . . . . 19
>        6.2.2.  Effective Topology . . . . . . . . . . . . . . . . . . 20
>        6.2.3.  Inconsistent Topology  . . . . . . . . . . . . . . . . 20
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
>    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
>    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
>      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
>      9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
> Clausen, et al.         Expires November 10, 2016               [Page 2]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.  Introduction
>
>    The Optimized Link State Routing Protocol version 2 (OLSRv2)
>    [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182],
>    [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a
>    routing protocol for MANETs (Mobile Ad hoc NETworks).  OLSRv2 retains
>    the same basic algorithms as its predecessor, however offers various
>    improvements, e.g., a modular and flexible architecture allowing
>    extensions, such as for security, to be developed as add-ons to the
>    basic protocol.
>
> [JWD] NIT: listing RFC7181 first would be helpful.
>
>
>    The developments reflected in OLSRv2 have been motivated by increased
>    real-world deployment experiences, e.g., from networks such as
>    FunkFeuer [FUNKFEUER], and the requirements presented for continued
>    successful operation of these networks.  With participation in such
>    networks increasing (the FunkFeuer community network has, e.g.,
>    roughly 400 individual participants at the time of publication of
>    this document), operating with the assumption, that participants can
>    be "trusted" to behave in a non-destructive way, is utopia.  Taking
>    the Internet as an example, as participation in the network increases
>    and becomes more diverse, more efforts are required to preserve the
>    integrity and operation of the network.  Most SMTP-servers were,
>    e.g., initially available for use by everyone on the Internet - with
>    an increased populace on the Internet, attacks and abuses caused the
>    recommended practice is today to require authentication and
>    accounting for users of such SMTP servers [RFC5068].
>
> [JWD] NIT language improvement....with an increase in users on the Internet,
> an increase in attacks and abuses followed necessitating a change in recommended
> practices; today authentication and accounting for users is required for use of SMTP servers [RFC5068].
>
>
>    As OLSRv2 often is used in wireless environments, it is potentially
>    exposed to different kinds of security threats, some of which are of
>    particular significance as compared to wired networks.  As radio
>    signals can be received as well as transmitted by any compatible
>    wireless device within radio range, there is commonly no physical
>    protection as otherwise known for wired networks.
>
>    A first step towards hardening against attacks disrupting the
>    connectivity of a network, is to understand the vulnerabilities of
>    routing protocol, managing the connectivity.  This document therefore
>    analyzes OLSRv2, to understand its inherent vulnerabilities and
>    resiliences.  The authors do not claim completeness of the analysis,
>    but hope that the identified attacks, as presented, form a meaningful
>    starting-point for developing and deploying increasingly secured
>    OLSRv2 networks.
>
>    This document first describes security vulnerabilities to OLSRv2 when
>    it is used without the mandatory-to-implement security mechanisms, as
>    specified in Section 23.5 of [RFC7181].  It then analyzes which of
>    these security vulnerabilities can be mitigated when using the
>    mandatory-to-implement security mechanisms for OLSRv2, and how the
> Clausen, et al.         Expires November 10, 2016               [Page 3]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    vulnerabilities are mitigated.  This separation is important since
>    other security mechanisms ([JWD] other) than the mandatory-to-implement ones may be
>    used in a deployment, as explicitly stated in [RFC7181]:
>
>       "Any deployment of OLSRv2 SHOULD use the security mechanism
>       specified in [RFC7183] but MAY use another mechanism if more
>       appropriate in an OLSRv2 deployment.  For example, for longer-term
>       OLSRv2 deployments, alternative security mechanisms (e.g.,
>       rekeying) SHOULD be considered."
>
>    Moreover, this document is also based on the assumption that no
>    additional security mechanism such as IPsec is used in the IP layer
>    or other mechanisms on lower layers, as not all MANET deployments may
>    be able to accommodate such common protection mechanisms (e.g.,
>    because of limited resources of MANET routers).
>
>    The threats related to NHDP (Neighborhood Discovery Protocol) have
>    been discussed in [RFC7186].  As NHDP is a fundamental block of
>    OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.
>
>    It should be noted that many OLSRv2 implementations are configurable,
>    and so an attack on the configuration system (such as [RFC6779] and
>    [RFC7184]) can be used to adversely affect the operation of an OLSRv2
>    implementation.
> 1.1.  OLSRv2 Overview
>
>    OLSRv2 contains three basic processes: Neighborhood Discovery, MPR
>    Flooding ([JWD] MPR election/flooding not just flooding?) and Link State Advertisements, described in the below with
>    sufficient details for elaborating the analyses in this document.
>
> [JWD] NIT make above two separate sentences.
>
> 1.1.1.  Neighborhood Discovery
>
>    Neighborhood Discovery is the process, whereby each router discovers
>    the routers which are in direct communication range of itself (1-hop
>    neighbors), and detects with which of these it can establish bi-
>    directional communication.  Each router sends HELLO messages
>    periodically, listing the identifiers of all the routers from which
>    it has recently received a HELLO message, as well as the "status" of
>    the link (heard or verified bi-directional).  A router A receiving a
>    HELLO message from a neighbor B, in which B indicates to have
>    recently received a HELLO message from A, considers the link A-B to
>    be bi-directional.  As B lists identifiers of all its neighbors in
>    its HELLO message, A learns the "neighbors of its neighbors" (2-hop
>    neighbors) through this process.  HELLO messages are sent
>    periodically, however certain events may trigger non-periodic HELLOs.
>    OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery
>    mechanism.  The vulnerabilities of NHDP are analyzed in [RFC7186].
> Clausen, et al.         Expires November 10, 2016               [Page 4]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.1.2.  MPR Flooding
>
>    Multi Point Relay (MPR) Flooding is the process whereby each router
>    is able to efficiently conduct network-wide broadcasts.  Each router
>    designates, from among its bi-directional neighbors, a subset (MPR
>    set) such that a multicast ([JWD] OLSRv2 specific multicast) message transmitted by the router and
>    relayed by the MPR set can ([JWD] be) received by all its 2-hop neighbors.  MPR
>    selection is encoded in outgoing HELLO messages. ([JWD] NHDP HELLO messages)
>
>    Routers may express, in their HELLO messages, their "willingness" (an
>    integer between 0 "will never" and 7 "will always") to be selected as
>    MPR, which is taken into consideration for the MPR calculation, and
>    which is useful for example when an OLSRv2 network is "planned".  The
>    set of routers having selected a given router as MPR is the MPR-
>    selector-set of that router.  A study of the MPR flooding algorithm
>    can be found in [MPR-FLOODING].
> 1.1.3.  Link State Advertisement
>
>    Link State Advertisement is the process whereby routers are
>    determining ([JWD] routers determine) which link state information to advertise through the
>    network.  Each router must advertise, at least, all links between
>    itself and its MPR selectors, in order to allow all routers to
>    calculate shortest paths.  Such link state advertisements are carried
>    in Topology Control (TC) messages, broadcast through the network
>    using the MPR flooding process described above.  As a router selects
>    MPRs only from among bi-directional neighbors, links advertised in TC
>    are also bi-directional and routing paths calculated by OLSRv2
>    contain only bi-directional links.  TCs are sent periodically,
>    however certain events may trigger non-periodic TCs.
> 1.2.  Link State Vulnerability Taxonomy
>
>    Proper functioning of OLSRv2 assumes that (i) each router signals its
>    presence in the network and the topology information that it obtained
>    honestly, (ii) each router can acquire and maintain a topology map,
>    accurately reflecting the effective network topology; and (iii) that
>    the network converges, i.e., that all routers in the network will
>    have sufficiently identical topology maps.
>
> [JWD] Nit make above a list.
>
>
>    An OLSRv2 network can be disrupted by breaking either ([JWD] any not either) of these
>    assumptions, specifically (a) routers may be prevented from acquiring
>    a topology map of the network; (b) routers may acquire a topology map
>    that does not reflect the effective network topology; and (c) two or
>    more routers may acquire inconsistent topology maps.
> Clausen, et al.         Expires November 10, 2016               [Page 5]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.3.  OLSRv2 Attack Vectors
>
>    Besides "radio jamming", attacks on OLSRv2 consist of a compromised
>    OLSRv2 router injecting "correctly looking, but invalid, control
>    traffic" (TCs, HELLOs) into the network.  A compromised OLSRv2 router
>    can either (a) lie about itself (its identification, its willingness
>    to serve as MPR), henceforth Identity Spoofing, or (b) lie about its
>    relationship to other routers (pretend existence of links to other
>    routers), henceforth Link Spoofing.  Such attacks may disrupt the the
>    Link State Advertisement process, through targeting the MPR Flooding
>    mechanism, or by causing incorrect link state information to be
>    included in TCs, causing routers to have incomplete, inaccurate or
>    inconsistent topology maps.  In a different class of attacks, a
>    compromised OLSRv2 router injects control traffic, designed so as to
>    cause an in-router resource exhaustion, e.g., by causing the
>    algorithms calculating routing tables or MPR sets to be invoked
>    continuously, preventing the internal state of a router from
>    converging.
> 2.  Terminology
>
>    This document uses the terminology and notation defined in [RFC5444],
>    [RFC6130] and [RFC7181].  Additionally, it defines the following
>    terminology:
>
>    Compromised OLSRv2 router: -  An attacker that is present in the
>       network and generates syntactically correct OLSRv2 control
>       messages.  Control messages emitted by a compromised OLSRv2 router
>       may contain additional information, or omit information, as
>       compared to a control message generated by a non-compromised
>       OLSRv2 router located in the same topological position in the
>       network.
>
>    Legitimate OLSRv2 router: -  An OLSRv2 router that is not a
>       compromised OLSRv2 router.
> 3.  Topology Map Acquisition
>
>    Topology Map Acquisition relates to the ability for any given router
>    in the network to acquire a representation of the network
>    connectivity.  A router, unable to acquire a topology map, is
>    incapable of calculating routing paths and participating in
>    forwarding data.  Topology map acquisition can be hindered by (i) TCs
>    to not being delivered to (all) routers in the network, such as what
>    happens in case of Flooding Disruption, or (ii) in case of "jamming"
>    of the communication channel.
> Clausen, et al.         Expires November 10, 2016               [Page 6]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    The jamming and flooding disruption due to identity spoofing and link
>    spoofing have been discussed in [RFC7186].
> 3.1.  Attack on Jittering
>
>    OLSRv2 incorporates a jittering: a random, but bounded, delay on
>    outgoing control traffic [RFC5148].  This may be necessary when link
>    layers (such as 802.11 [IEEE802.11]) are used that do not guarantee
>    collision-free delivery of frames, and where jitter can reduce the
>    probability of collisions of frames on lower layers.
>
>    In OLSRv2, TC forwarding is jittered by a value between 0 and
>    MAX_JITTER.  In order to reduce the number of transmissions, when a
>    control message is due for transmission, OLSRv2 piggybacks all queued
>    messages into a single transmission.  Thus, if a compromised OLSRv2
>    router sends many TCs within a very short time interval, the jitter
>    time of the attacked router tends to 0.  This renders jittering
>    ineffective and can lead to collisions on the link layer.
>
>    In addition to causing more collisions, forwarding a TC with little
>    or no jittering can make sure that the TC message forwarded by a
>    compromised router arrives before the message forwarded by legitimate
>    routers.  The compromised router can thus inject malicious content in
>    the TC, and the legitimate message will be discarded as ([JWD] a) duplicate
>    message.  This preemptive action is important for some of the attacks
>    introduced in the following sections.
> 3.2.  Hop-count and Hop-limit Attacks
>
>    The hop-count and hop-limit fields are the only parts of a TC that
>    are modified when forwarding.  A compromised OLSRv2 router can modify
>    either of these when forwarding TCs.
>
> [JWD] mention of the integrity TLV here which makes this statement true would be helpful.
>
>
> 3.2.1.  Modifying the Hop Limit
>
>    A compromised OLSRv2 router can decrease the hop limit when
>    forwarding a TC.  This will reduce the scope of forwarding the
>    message, and may lead to some routers in the network not receiving
>    that TC.  Note that this is not necessarily the same as not relaying
>    the message (i.e., setting the hop limit to 0), as illustrated in
>    Figure 1.
> Clausen, et al.         Expires November 10, 2016               [Page 7]Internet-Draft               OLSRv2 Threats                     May 2016
>
>                             .---.
>                             | X |
>                           --'---' __
>                          /          \
>                         /            \
>                     .---.              .---.
>         TC ----->   | A |              | C |
>                     '---'              '---'
>                         \    .---.   /
>                          \-- | B |__/
>                              '---'
>
>                         Figure 1: Hop Limit Attack.
>
>    A TC arrives at and is forwarded by router A, such that it is
>    received by both B and the malicious X. X can forward the TC without
>    any delay (including without jitter) such that its transmissions
>    arrives before that of B at C. Before forwarding, it significantly
>    reduces the hop limit of the message.  Router C receives the TC,
>    processes (and forwards) it, and marks it as already received -
>    causing it to discard further copies received from B. Thus, if the TC
>    is forwarded by C, it has a very low hop limit and will not reach the
>    whole network.
> 3.2.2.  Modifying the Hop Count
>
>    A compromised OLSRv2 router can modify the hop count when forwarding
>    a TC.  This may have two consequences: (i) if the hop count is set to
>    the maximum value, then the TC will be forwarded no further by, or
>    (ii) artificially manipulating the hop count may affect the validity
>    time as calculated by recipients, when using distance-dependent
>    validity times as defined in [RFC5497] (e.g., as part of a fish-eye
>    extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]).
>
>            v_time(1hop)=2s  v_time(2hops)=4s   v_time(3hops)=6s
>    .---.         .---.          .---.           .---.
>    | A |-------> | B | -------> | X |---------->| C |
>    `---'         `---'          `---'           `---'
>
>      Figure 2: Different validity times based on the distance in hops.
>
>    In Figure 2, router A sends a TC with a validity time of two seconds
>    for neighbors that are one hop away, four seconds for routers in a
>    two-hop distance and six seconds in a three-hop distance.  If X is a
>    compromised OLSRv2 router and modifies the hop count (say, by
>    decreasing it to 0), then C will calculate the validity time of
>    received information to two seconds - after which it expires unless
> Clausen, et al.         Expires November 10, 2016               [Page 8]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    refreshed.  If TCs from A are sent less frequently than that up to 3
>    hops, this causes links advertised in such TCs to be only
>    intermittently available to C.
>
> [JWD] this is a really good point!
>
>
>  4.  Effective Topology
>
>    Link-state protocols assume that each router can acquire an accurate
>    topology map, reflecting the effective network topology.  This
>    implies that the routing protocol, through its message exchange,
>    identifies a path from a source to a destination, and this path is
>    valid for forwarding data traffic.  If an attacker disturbs the
>    correct protocol behavior, the perceived topology map of a router can
>    permanently differ from the effective topology.
>
>    Considering the example in Figure 3(a), which illustrates the
>    topology map as acquired by router S. This topology map indicates
>    that the routing protocol has identified that for S, a path exists to
>    D via B, which it therefore assumes can be used for transmitting
>    data.  If, effectively, B does not forward data traffic from S, then
>    the topology map in S does not accurately reflect the effective
>    network topology.  Rather, the effective network topology from the
>    point of view of S would be as indicated in Figure 3(b): D is not
>    part of the network reachable from router S.
>
>       .---.    .---.    .---.           .---.    .---.
>       | S |----| B |----| D |           | S |----| B |
>       `---'    `---'    `---'           `---'    `---'
>
>               (a)                             (b)
>
>                Figure 3: Incorrect Data Traffic Forwarding.
>
>    Some of the attacks related to NHDP, such as message timing attack,
>    indirect channel overloading have been discussed in [RFC7186].  Other
>    threats specific to OLSRv2 are further detailed in this section.
> 4.1.  Incorrect Forwarding
>
>    OLSRv2 routers exchange information using link-local transmissions
>    (link-local multicast or limited broadcast) for their control
>    messages, with the routing process in each router retransmitting
>    received messages destined for network-wide diffusion.  Thus, if the
>    operating system in a router is not configured to enable forwarding,
>    this will not affect the operating of the routing protocol, or the
>    topology map acquired by the routing protocol.  It will, however,
> Clausen, et al.         Expires November 10, 2016               [Page 9]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    cause a discrepancy between the effective topology and the topology
>    map, as indicated in Figure 3(a) and Figure 3(b).
>
> [JWD] the term unicast forwarding should be used as without that term it may
> be assumed that forwarding of multicast is being disrupted which isn't the case.
>
>
>    This situation is not hypothetical.  A common error seen when
>    deploying OLSRv2-based networks using Linux-based computers as router
>    is to neglect enabling IP forwarding, which effectively becomes an
>    accidental attack of this type.
> 4.2.  Wormholes
>
>    A wormhole, depicted in the example in Figure 4, may be established
>    between two collaborating devices, connected by an out-of-band
>    channel.  These devices send traffic through the "tunnel" to their
>    alter-ego, which "replays" the traffic.  Thus, routers D and S appear
>    as if direct neighbors and reachable from each other in 1 hop through
>    the tunnel, with the path through the MANET being 100 hops long.
>
>    .---.                                     .---.
>    | S |----   ....100-hop long path  ... ---| D |
>    `---.                                   / `---'
>        \                                  /
>         \                                /
>          \X=============================X
>
>                 1-hop path via wormhole
>
>         Figure 4:  Wormholing between two collaborating devices not
>                   participating in the routing protocol.
>
>    The consequences of such a wormhole in the network depends on the
>    detailed behavior of the wormhole.  If the wormhole relays only
>    control traffic, but not data traffic, the same considerations as in
>    Section 4.1 applies.  If, however, the wormhole relays all traffic,
>    control and data alike, it is connectivity-wise identical to a usable
>    link - and the routing protocol will correctly generate a topology
>    map reflecting the effective network topology.  The efficiency of the
>    topology so obtained depends on (i) the wormhole characteristics,
>    (ii) how the wormhole presents itself, and (iii) how paths are
>    calculated.
>
>    Assuming that paths are calculated with unit-cost for all links,
>    including the "link" presented by the wormhole: if the real
>    characteristics of the wormhole are as-if it was a path of more than
>    100 hops (e.g., with respect to delay, bandwidth, etc.), then the
> Clausen, et al.         Expires November 10, 2016              [Page 10]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    presence of the wormhole results in a degradation in performance as
>    compared to using the non-wormhole path.  Conversely, if the "link"
>    presented by the wormhole has better characteristics, the wormhole
>    results in improved performance.
>
>    If paths are calculated using non-unit-costs for all links, and if
>    the cost of the "link" presented by the wormhole correctly represents
>    the actual cost (e.g., if the cost is established through
>    measurements across the wormhole), then the wormhole may in the worst
>    case cause no degradation in performance, in the best case improve
>    performance by offering a better path.  If the cost of the "link"
>    presented by the wormhole is misrepresented, then the same
>    considerations as for unit-cost links apply.
>
>    An additional consideration with regards to wormholes is, that such
>    may present topologically attractive paths for the network - however
>    it may be undesirable to have data traffic transit such a path: an
>    attacker could, by virtue of introducing a wormhole, acquire the
>    ability to record and inspect transiting data traffic.
> 4.3.  Sequence Number Attacks
>
>    OLSRv2 uses two different sequence numbers in TCs, to (i) avoid
>    processing and forwarding the same message more than once (Message
>    Sequence Number), and (ii) to ensure that old information, arriving
>    late due to, e.g., long paths or other delays, is not allowed to
>    overwrite fresher information (Advertised Neighbor Sequence Number -
>    ANSN).
> 4.3.1.  Message Sequence Number
>
>    An attack may consist of a compromised OLSRv2 router spoofing the
>    identity of another router in the network, and transmitting a large
>    number of TCs, each with different Message Sequence Numbers.
>    Subsequent TCs with the same sequence numbers, originating from the
>    router whose identity was spoofed, would hence be ignored, until
>    eventually information concerning these "spoofed" TCs expires.
>
> [JWD] it should be mentioned that this is fixed with the signing TLV.
>
>
> 4.3.2.  Advertised Neighbor Sequence Number (ANSN)
>
>    An attack may consist of a compromised OLSRv2 router spoofing the
>    identity of another router in the network, and transmitting a single
>    TC, with an ANSN significantly larger than that which was last used
>    by the legitimate router.  Routers will retain this larger ANSN as
>    "the most fresh information" and discard subsequent TCs with lower
>    sequence numbers as being "old".
> [JWD] again it should be mentioned that this is fixed with the signing TLV.
> Clausen, et al.         Expires November 10, 2016              [Page 11]Internet-Draft               OLSRv2 Threats                     May 2016
> 4.4.  Indirect Jamming
>
>    Indirect Jamming is an attack in which a compromised OLSRv2 router
>    is, by its actions, causing legitimate routers to generate inordinate
>    amounts of control traffic, thereby increasing both channel
>    occupation and the overhead incurred in each router for processing
>    this control traffic.  This control traffic will be originated from
>    legitimate routers, thus to the wider network, the malicious device
>    may remain undetected.
>
>    The general mechanism whereby a malicious router can cause indirect
>    jamming is for it to participate in the protocol by generating
>    plausible control traffic, and to tune this control traffic to in
>    turn trigger receiving routers to generate additional traffic.  For
>    OLSRv2, such an indirect attack can be directed at, respectively, the
>    Neighborhood Discovery mechanism and the Link State Advertisement
>    mechanism.
>
>    The most efficient indirect jamming attack in OLSRv2 is to target
>    control traffic, destined for network-wide diffusion.  This is
>    illustrated in Figure 5.
>
>    The malicious router X selects router A as MPR at time t0 in a HELLO.
>    This causes X to appear as MPR selector for A and, consequently, A
>    sets X to be advertised in its "Neighbor Set" and increments the
>    associated "Advertised Neighbor Sequence Number" (ANSN).  Router A
>    must, then, advertise the link between itself and X in subsequent
>    outgoing TCs (t1), also including the ANSN in such TCs.  Upon X
>    having received this TC, it declares the link between itself and A as
>    no longer valid (t2) in a HELLO (indicating the link to a as LOST).
>    Since only symmetric links are advertised by OLSRv2 routers, A will
>    upon receipt hereof remove X from the set of advertised neighbors and
>    increment the ANSN.  Router A will then in subsequent TCs advertise
>    the remaining set of advertised neighbors (i.e., with X removed) and
>    the corresponding ANSN (t3).  Upon X having received this information
>    in another TC from A, it may repeat this cycle, alternating
>    advertising the link A-X as "LOST" and as "MPR".
> Clausen, et al.         Expires November 10, 2016              [Page 12]Internet-Draft               OLSRv2 Threats                     May 2016
>
>               broadcast TC    ANS={}         TC:()
>                (X-A) ANSN      ANSN++          ANSN
>       .---.        .---.        .---.        .---.
>       | A |        | A |        | A |        | A |
>       '---'        '---'        '---'        '---'
>         ^            |            ^            |
>         |            |            |            |
>         | select     |            |indicate    |
>         | as MPR     |            |as LOST     |
>       .---.        .---.        .---.        .---.
>       | X |        | X |        | X |        | X |
>       '---'        '---'        '---'        '---'
>
>         t0           t1            t2           t3
>
>    Figure 5: Indirect Jamming in Link State Advertisement: the malicious
>                  X flips between link status MPR and LOST.
>
>    Routers receiving a TC will parse and process this message,
>    specifically updating their topology map as a consequence of
>    successful receipt.  If the ANSN between two successive TCs from the
>    same router has incremented, then the topology has changed and
>    routing sets are to be recalculated.  This is a potentially
>    computationally costly operation.
>
>    A compromised OLSRv2 router may chose to conduct this attack against
>    all its neighbors, thus attaining maximum disruptive impact on the
>    network with relatively little overhead of its own: other than
>    participating in the Neighborhood Discovery procedure, the
>    compromised OLSRv2 router will monitor TCs generated by its neighbors
>    and alternate the advertised status for each such neighbor, between
>    "MPR" and "LOST".  The compromised OLSRv2 router will indicate its
>    willingness to be zero (thus, avoid being selected as MPR) and may
>    ignore all other protocol operations, while still remaining effective
>    as an attacker.
>
>    The basic operation of OLSRv2 employs periodic message emissions, and
>    by this attack it can be ensured that each such periodic message will
>    entail routing table recalculation in all routers in the network.
>
>    If the routers in the network have "triggered TCs" enabled, this
>    attack may also cause an increased TC frequency.  Triggered TCs are
>    intended to allow a (stable) network to have relatively low TC
>    emission frequencies, yet still allow link breakage or link emergence
>    to be advertised through the network rapidly.  A minimum message
>    interval (typically much smaller than the regular periodic message
>    interval) is imposed, to rate-limit worst-case message emissions.
>    This attack can cause the TC interval to, permanently, become equal
> Clausen, et al.         Expires November 10, 2016              [Page 13]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    to the minimum message interval.  [RFC7181] proposes as default that
>    the minimum TC interval be 0.25 x TC interval.
> [JWD glad this was mentioned.  Something might be said regarding the reduced
> effectiveness of the compromised node is not ever selected as an MPR as the
> calculation for routing might only affect a leaf router (dependent on implementation)
>
>    Indirect Jamming by a compromised OLSRv2 router can thus have two
>    effects: it may cause increased frequency of TC generation and
>    transmission, and it will cause additional routing table
>    recalculation in all routers in the network.
> 5.  Inconsistent Topology
>
>    Inconsistent topology maps can occur by a compromised OLSRv2 router
>    employing either of identity spoofing or link spoofing for conducting
>    an attack against an OLSRv2 network.  The threats related to NHDP,
>    such as identity spoofing in NHDP, link spoofing in NHDP and creating
>    loops have been illustrated in [RFC7186].  This section mainly
>    addresses the vulnerabilities in [RFC7181].
> 5.1.  Identity Spoofing
>
>    Identity spoofing can be employed by a compromised OLSRv2 router via
>    the Neighborhood Discovery process and via the Link State
>    Advertisement process.  Either of them causes inconsistent topology
>    maps in routers in the network.  The inconsistent topology maps due
>    to neighborhood discovery has been discussed in [RFC7186].  For
>    OLSRv2, the attack on link state advertisements can also cause
>    inconsistent topology maps.
>
>    An inconsistent topology map may occur when the compromised OLSRv2
>    router takes part in the Link State Advertisement (LSA) procedure, by
>    selecting a neighbor as MPR, which in turn advertises the spoofed
>    identities of the compromised OLSRv2 router.  This attack will alter
>    the topology maps of all routers of the network.
>
> [JWD] this is the only play that the term LSA is used.  Suggest removing it.
>
> [JWD] also it should be mentioned that spoofing is protected against if using the SHOULD use TLVs
>
>    A -- B -- C -- D -- E -- F -- X
>
>                                (X spoofs A)
>
>     Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the
>           identity of A, leading to a wrongly perceived topology.
>
>    In Figure 6, router X spoofs the address of router A. If X selects F
>    as MPR, all routers in the network will be informed about the link
>    F-A by the TCs originating from F. Assuming that (the real) A selects
>    B as MPR, the link B-A will also be advertised in the network.
> Clausen, et al.         Expires November 10, 2016              [Page 14]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    When calculating paths, B and C will calculate paths to A via B, as
>    illustrated in Figure 7(a); for these routers, the shortest path to A
>    is via B. E and F will calculate paths to A via F, as illustrated in
>    Figure 7(b); for these routers, the shortest path to A is via the
>    compromised OLSRv2 router X, and these are thus disconnected from the
>    real A. D will have a choice: the path calculated to A via B is of
>    the same length as the path via the compromised OLSRv2 router X, as
>    illustrated in Figure 7(b).
>
>    In general, the following observations can be made:
>
>    o  The network will be split in two, with those routers closer to B
>       than to X reaching A, whereas those routers closer to X than to B
>       will be unable to reach A.
>
>    o  Routers beyond B, i.e., routers beyond one hop away from A will be
>       unable to detect this identity spoofing.
>
>    The identity spoofing attack via the Link State Advertisement
>    procedure has a higher impact than the attack on the neighborhood
>    discovery procedure, since it alters the topology maps of all routers
>    in the network, and not only in the 2-hop neighborhood.  However, the
>    attack is easier to detect by other routers in the network.  Since
>    the compromised OLSRv2 router is advertised in the whole network,
>    routers whose identities are spoofed by the compromised OLSRv2 router
>    can detect the attack.  For example, when a receives a TC from F
>    advertising the link F-A, it can deduce that some entity is injecting
>    incorrect Link State information as it does not have F as one of its
>    direct neighbors.
>
>                                                  (X spoofs A)
>
>       A < ---- B < ---- C           E ----> F ----> X
>
>       (a) Routers B and C           (b) Routers E and F
>
>          A < --- B < --- C < --- D ---> E ---> F ----> X
>
>                                                     (X spoofs A)
>
>      Figure 7: Routing paths towards A, as calculated by the different
>    routers in the network in presence of a compromised OLSRv2 router X,
>                         spoofing the address of A.
>
>    As the compromised OLSRv2 router X does not itself send the TCs, but
>    rather, by virtue of MPR selection, ensures that the addresses it
> Clausen, et al.         Expires November 10, 2016              [Page 15]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    spoofs are advertised in TCs from its MPR selector F, the attack may
>    be difficult to counter: simply ignoring TCs that originate from F
>    may also suppress the link state information for other, legitimate,
>    MPR selectors of F.
>
>    Identity spoofing by a compromised OLSRv2 router, participating in
>    the Link State Advertisement process by selecting MPRs only, thus,
>    creates a situation wherein two or more routers have substantially
>    inconsistent topology maps: traffic for an identified destination is,
>    depending on where in the network it appears, delivered to different
>    routers.
>
> [JWD] Link State Advertisement is again used here suggest lowercase.
>
>
>  5.2.  Link Spoofing
>
>    Link Spoofing is a situation in which a router advertises non-
>    existing links to another router (possibly not present in the
>    network).  Essentially, TCs and HELLOs both advertise links to direct
>    neighbor routers, with the difference being the scope of the
>    advertisement.  Thus, link spoofing consists of a compromised OLSRv2
>    router, reporting that it has neighbors routers which are, either,
>    not present in the network, or which are effectively not neighbors of
>    the compromised OLSRv2 router.
>
>    It can be noted that a situation similar to link spoofing may occur
>    temporarily in an OLSR or OLSRv2 network without compromised OLSRv2
>    routers: if A was, but is no more, a neighbor of B, then A may still
>    be advertising a link to B for the duration of the time it takes for
>    the the Neighborhood Discovery process to determine this changed
>    neighborhood.
>
>    In the context of this document, link spoofing refers to a persistent
>    situation where a compromised OLSRv2 router intentionally advertises
>    links to other routers, for which it is not a direct neighbor.
>
> [JWD] this is a similar attack to the above but is not protected against
> but the attacker is more easily identified.  One difference is that TC
> messages with spoofed links may be hop count limited making detection more difficult.
> 5.2.1.  Inconsistent Topology Maps due to Link State Advertisements
>
>    Figure 8 illustrates a network, in which the compromised OLSRv2
>    router X spoofs links to a existing router A by participating in the
>    Link State Advertisement process and including this non-existing link
>    in its advertisements.
>
>    A --- B --- C --- D --- E --- F --- G --- H --- X
>
>                              (X spoofs the link to A)
>
>    Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a
> Clausen, et al.         Expires November 10, 2016              [Page 16]Internet-Draft               OLSRv2 Threats                     May 2016
>
>     spoofed link to A in its TCs, thus all routers will record both of
>                           the links X-A and B-A.
>
>    As TCs are flooded through the network, all routers will receive and
>    record information describing a link X-A in this link state
>    information.  If A has selected router B as MPR, B will likewise
>    flood this link state information through the network, thus all
>    routers will receive and record information describing a link B-A.
>
>    When calculating routing paths, B, C and D will calculate paths to A
>    via B, as illustrated in Figure 9(a); for these routers, the shortest
>    path to A is via B. F and G will calculate paths to A via X, as
>    illustrated in Figure 9(b); for these routers, the shortest path to A
>    is via X, and these are thus disconnected from the real router A. E
>    will have a choice: the path calculated to A via B is of the same
>    length as the path via X, as illustrated in Figure 9(b).
>
>    A < --- B < --- C < --- D           F ---> G ---> X ---> A
>
>        (a) Routers B, C, and D           (b) Routers F and G
>
>    A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A
>
>                           (c) Router E
>
>       Figure 9: Routing paths towards router A, as calculated by the
>    different routers in the network in presence of a compromised OLSRv2
>                   router X, spoofing a link to router A.
>
>    In general, the following observations can be made:
>
>    o  The network will be separated in two, with those routers closer to
>       B than to X reaching A, whereas those routers closer to X than to
>       B unable to reach A.
>
>    o  Routers beyond B, i.e., routers beyond one hop away from A will be
>       unable to detect this link spoofing.
>
>    The impact of this attack is similar to that presented in
>    Section 5.2.1, however, is easier to detect as the compromised OLSRv2
>    router is generating control traffic reaching the entire network.
> Clausen, et al.         Expires November 10, 2016              [Page 17]Internet-Draft               OLSRv2 Threats                     May 2016
> 6.  Mitigation of Security Vulnerabilities for OLSRv2
>
>    As described in Section 1, [RFC7183] specifies a security mechanism
>    for OLSRv2 that is mandatory to implement.  However, deployments may
>    choose to use different security mechanisms if more appropriate.
>    Therefore, it is important to understand both the inherent resilience
>    of OLSRv2 against security vulnerabilities when not using the
>    mechanisms specified in [RFC7183], as well as the protection that
>    [RFC7183] provides when used in a deployment.
> 6.1.  Inherent OLSRv2 Resilience
>
>    OLSRv2 (without the mandatory-to-implement security mechanisms in
>    [RFC7183]) provides some inherent resilience against part of the
>    attacks described in this document.  In particular, it provides the
>    following resilience:
>
>    o  Sequence numbers: OLSRv2 employs message sequence numbers,
>       specific per router identity and message type.  Routers keep an
>       "information freshness" number (ANSN), incremented each time the
>       content of a Link State Advertisement from a router changes.  This
>       allows rejecting "old" information and duplicate messages, and
>       provides some protection against "message replay".  This, however,
>       also presents an attack vector (Section 4.3).
>
>    o  Ignoring uni-directional links: The Neighborhood Discovery process
>       detects and admits only bi-directional links for use in MPR
>       selection and Link State Advertisement.  Jamming attacks may
>       affect only reception of control traffic, however OLSRv2 will
>       correctly recognize, and ignore, such a link as not bi-
>       directional.
>
>    o  Message interval bounds: The frequency of control messages, with
>       minimum intervals imposed for HELLO and TCs.  This may limit the
>       impact from an indirect jamming attack (Section 4.4).
>
>    o  Additional reasons for rejecting control messages: The OLSRv2
>       specification includes a list of reasons, for which an incoming
>       control message should be rejected as malformed - and allows that
>       a protocol extension may recognize additional reasons for OLSRv2
>       to consider a message malformed.  This allows - together with the
>       flexible message format [RFC5444] - addition of security
>       mechanisms, such as digital signatures, while remaining compliant
>       with the OLSRv2 standard specification.
> Clausen, et al.         Expires November 10, 2016              [Page 18]Internet-Draft               OLSRv2 Threats                     May 2016
> 6.2.  Resilience by using RFC7183 with OLSRv2
>
>    [RFC7183] specifies mechanisms for integrity and replay protection
>    for NHDP and OLSRv2, using the generalized packet/message format
>    described in [RFC5444] and the TLV definitions in [RFC7182].  The
>    specification describes how to add an Integrity Check Value (ICV) in
>    a TLV to each control message, providing a digital signature of the
>    content of the message using HMAC/SHA-256.  In addition, a timestamp
>    TLV is added to the message prior to creating the ICV, enabling
>    replay protection of messages.  The document specifies how to sign
>    outgoing messages and how to verify incoming messages, as well as
>    under which circumstances a non-valid message is rejected.  Because
>    of the HMAC/SHA-256 ICV, a shared key between all routers in the
>    MANET is assumed.  A router without valid credentials is not able to
>    create an ICV that can be correctly verified by other routers in the
>    MANET; therefore, such an incorrectly signed message will be rejected
>    by other MANET routers, and the router cannot participate in the
>    OLSRv2 routing process (i.e., the malicious router will be ignored by
>    other, legitimate routers).  [RFC7183] does not address the case
>    where a router with valid credentials has been compromised.  Such a
>    compromised router will not be excluded from the routing process, and
>    other means of detecting such a router are necessary if required in a
>    deployment (in addition to using asymmetric keys, allowing to revoke
>    access to one particular router instead of revoking the shared key
>    used by all routers in the MANET).
>
>    In the following sections, each of the vulnerabilities described
>    earlier in this document will be evaluated in terms of whether OLSRv2
>    with the mechanisms in [RFC7183] provides sufficient protection
>    against the attack.  It is implicitly assumed in each of the
>    following sections that [RFC7183] is used with OLSRv2.
>
> [JWD] this is a really important part of the document and should be moved
> up to provide the reader with a better understanding.  Without this it will
> be easy for a reader to assume that all attacks presented are equally possible.
> A summary was given but more details (along with an inline sentence per attack
> pointing to appropriate section below) would help quite a lot.
>
>
> 6.2.1.  Topology Map Acquisition
>
>    Attack on Jittering -  As only OLSRv2 routers with valid credentials
>       can participate in the routing process, a malicious router cannot
>       reduce the jitter time of an attacked router to 0 by sending many
>       TC messages in a short time.  The attacked router would reject all
>       the incoming messages as "invalid" and not forward them.  The same
>       applies for the case where a malicious router wants to assure that
>       by forcing a zero jitter interval, the message arrives before the
>       same message forwarded by legitimate routers.
>
>    Modifying the Hop Limit -  As the hop limit is not protected by
>       [RFC7183] (since it is a mutual field, changing at every hop),
>       this attack is still feasible.
> Clausen, et al.         Expires November 10, 2016              [Page 19]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    Modifying the Hop Count -  Similarly to the hop limit, as the hop
>       count is not protected by [RFC7183] (since it is a mutual field,
>       changing at every hop), this attack is still feasible.
> 6.2.2.  Effective Topology
>
>    Incorrect Forwarding -  As only OLSRv2 routers with valid credentials
>       can participate in the routing process, a malicious router will
>       not be part of the topology of other legitimate OLSRv2 routers.
>       Therefore, no data traffic will be sent to the malicious router
>       for forwarding.
>
>    Wormholes -  Since a wormhole consists of at least two devices
>       forwarding (unmodified) traffic, this attack is still feasible and
>       undetectable by the OLSRv2 routing process since the attack does
>       not involve the OLSRv2 protocol itself (but rather lower layers).
>       By using [RFC7183], it can at least be assured that the content of
>       the control messages is not modified while being forwarded via the
>       wormhole.  Moreover, the timestamp TLV assures that the forwarding
>       can only be done in a short time window after the actual TC
>       message has been sent.
>
>    Message Sequence Number -  As the message sequence number is included
>       in the ICV calculation, OLSRv2 is protected against this attack.
>
>    Advertised Neighbor Sequence Number (ANSN) -  As the ANSN is included
>       in the ICV calculation, OLSRv2 is protected against this attack.
>
>    Indirect Jamming -  Since the control messages of a malicious router
>       will be rejected by other legitimate OLSRv2 routers in the MANET,
>       this attack is mitigated.
> 6.2.3.  Inconsistent Topology
>
>    Identity Spoofing -  Since the control messages of a malicious router
>       will be rejected by other legitimate OLSRv2 routers in the MANET,
>       a router without valid credentials may spoof its identity (e.g.,
>       IP source address or message originator address), but the messages
>       will be ignored by other routers.  As the mandatory mechanism in
>       [RFC7183] uses shared keys amongst all MANET routers, a single
>       compromised router may spoof its identity and cause harm to the
>       network stability.  Removing this one malicious router once
>       detected implies rekeying all other routers in the MANET.
>       Asymmetric keys, in particular when using identity based
>       signatures, such as specified in [IBS] may further allow to revoke
>       single routers and to verify their identity based on the ICV
>       itself.
> Clausen, et al.         Expires November 10, 2016              [Page 20]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    Link Spoofing -  Similar to identity spoofing, a malicious router
>       without valid credential may spoof links, but its control messages
>       will be rejected by other routers, thereby mitigating the attack.
>
>    Inconsistent Topology Maps due to Link State Advertisements -  The
>       same considerations as for link spoofing apply.
> 7.  Security Considerations
>
>    This document does not specify a protocol or a procedure.  The
>    document, however, reflects on security considerations for OLSRv2,
>    and its constituent parts, including NHDP.
> 8.  IANA Considerations
>
>    This document has no actions for IANA.
> 9.  References
> 9.1.  Normative References
>
>    [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
>               "The Optimized Link State Routing Protocol Version 2",
>               RFC 7181, April 2014.
>
>    [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats for
>               the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
>               April 2014.
> 9.2.  Informative References
>
>    [FUNKFEUER]
>               "http://www.funkfeuer.at/".
>
>    [IBS]      Dearlove, C., "Identity-Based Signatures for MANET Routing
>               Protocols", work in progress draft-ietf-manet-ibs-05,
>               March 2016.
>
>    [IEEE802.11]
>               "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and
>               Physical Layer (PHY) Spec.", 2007.
>
>    [MPR-FLOODING]
>               Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
>               relaying: An efficient technique for flooding in mobile
> Clausen, et al.         Expires November 10, 2016              [Page 21]Internet-Draft               OLSRv2 Threats                     May 2016
>
>               wireless networks.", 2001.
>
>    [OLSR-FSR]
>               Clausen, T., "Combining Temporal and Spatial Partial
>               Topology for MANET routing-Merging OLSR and FSR,
>               Proceedings of the 2003 IEEE Conference of Wireless
>               Personal Multimedia Communications (WPMC 03)", 2003.
>
>    [OLSR-FSR-Scaling]
>               Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G.
>               Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal
>               of Communication and Networks (JCN), Special Issue on
>               Mobile Ad Hoc Wireless Networks", 2004.
>
>    [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
>               Routing Protocol", RFC 3626, October 2003.
>
>    [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
>               Finch, "Email Submission Operations: Access and
>               Accountability Requirements", RFC 5068, BCP 134,
>               October 2007.
>
>    [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
>               Considerations in Mobile Ad Hoc Networks (MANETs)",
>               RFC 5148, February 2008.
>
>    [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
>               "Generalized MANET Packet/Message Format", RFC 5444,
>               February 2009.
>
>    [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
>               Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
>               March 2009.
>
>    [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
>               Network (MANET) Neighborhood Discovery Protocol (NHDP)",
>               RFC 6130, April 2011.
>
>    [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
>               Managed Objects for the Neighborhood Discovery Protocol",
>               RFC 6779, May 2012.
>
>    [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
>               Check Value and Timestamp TLV Definitions for Mobile Ad
>               Hoc Networks (MANETs)", RFC 7182, April 2014.
>
>    [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
>               Protection for the Neighborhood Discovery Protocol (NHDP)
> Clausen, et al.         Expires November 10, 2016              [Page 22]Internet-Draft               OLSRv2 Threats                     May 2016
>
>               and Optimized Link State Routing Protocol Version 2
>               (OLSRv2)", RFC 7183, April 2014.
>
>    [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
>               Managed Objects for the Optimized Link State Routing
>               Protocol Version 2", RFC 7184, April 2014.
>
>    [RFC7187]  Dearlove, C. and T. Clausen, "Routing Multipoint Relay
>               Optimization for the Optimized Link State Routing Protocol
>               Version 2 (OLSRv2)", RFC 7187, April 2014.
>
>    [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
>               Protocol Version 2 (OLSRv2) and MANET Neighborhood
>               Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
>               April 2014.
> Authors' Addresses
>
>    Thomas Clausen
>
>    Phone: +33-6-6058-9349
>    Email: T.Clausen@computer.org
>    URI:   http://www.thomasclausen.org
>
>    Ulrich Herberg
>
>    Email: ulrich@herberg.name
>    URI:   http://www.herberg.name
>
>    Jiazi Yi
>    Ecole Polytechnique
>    91128 Palaiseau Cedex,
>    France
>
>    Phone: +33 1 77 57 80 85
>    Email: jiazi@jiaziyi.com
>    URI:   http://www.jiaziyi.com/
> Clausen, et al.         Expires November 10, 2016              [Page 23]
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--001a114113da8e10e9053b45b671
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks very much for the review, Justin.=C2=A0

We will update the draft based on the comments received and make a =
submission soon.=C2=A0

regards

Jiazi

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean <bebemaster@gmail.co=
m> wrote:
=

As there weren't many on list comments during or after last call h=
ere is my detailed review.
Summary is that I'm doing the writeup rig=
ht now and passing it on up.  Most of my comments 
are of the editorial =
type with exceptions which are minor and mostly clarification based.
Apologies to the author team for not getting this done sooner; =
I wanted to make sure I did it right.

Comments noted as J=
WD



Network Working Group                         =
                T. Clausen
Internet-Draft                                                U. Herberg
Intended status: Informational
Expires: November 10, 2016                                         J. Yi
                                                     Ecole Polytechnique
                                                             May 9, 2016

Security Threats for the Optimized Link State Routing Protocol version 2
                                (OLSRv2)
                 draft-ietf-manet-olsrv2-sec-threats-02

Abstract

   This document analyzes common security threats of the Optimized Link
   State Routing Protocol version 2 (OLSRv2) and describes their
   potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
   then analyzes which of these security vulnerabilities can be
   mitigated when using the mandatory-to-implement security mechanisms
   for OLSRv2, and how the vulnerabilities are mitigated.

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 10, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http=
://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Clausen, et al.         Expires November 10, 2016               [Page=
 1]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  OLSRv2 Overview  . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Neighborhood Discovery . . . . . . . . . . . . . . . .  4
       1.1.2.  MPR Flooding . . . . . . . . . . . . . . . . . . . . .  5
       1.1.3.  Link State Advertisement . . . . . . . . . . . . . . .  5
     1.2.  Link State Vulnerability Taxonomy  . . . . . . . . . . . .  5
     1.3.  OLSRv2 Attack Vectors  . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Topology Map Acquisition . . . . . . . . . . . . . . . . . . .  6
     3.1.  Attack on Jittering  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Hop-count and Hop-limit Attacks  . . . . . . . . . . . . .  7
       3.2.1.  Modifying the Hop Limit  . . . . . . . . . . . . . . .  7
       3.2.2.  Modifying the Hop Count  . . . . . . . . . . . . . . .  8
   4.  Effective Topology . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Incorrect Forwarding . . . . . . . . . . . . . . . . . . .  9
     4.2.  Wormholes  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Sequence Number Attacks  . . . . . . . . . . . . . . . . . 11
       4.3.1.  Message Sequence Number  . . . . . . . . . . . . . . . 11
       4.3.2.  Advertised Neighbor Sequence Number (ANSN) . . . . . . 11
     4.4.  Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12
   5.  Inconsistent Topology  . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  Inconsistent Topology Maps due to Link State
               Advertisements . . . . . . . . . . . . . . . . . . . . 16
   6.  Mitigation of Security Vulnerabilities for OLSRv2  . . . . . . 18
     6.1.  Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18
     6.2.  Resilience by using RFC7183 with OLSRv2  . . . . . . . . . 19
       6.2.1.  Topology Map Acquisition . . . . . . . . . . . . . . . 19
       6.2.2.  Effective Topology . . . . . . . . . . . . . . . . . . 20
       6.2.3.  Inconsistent Topology  . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 2=
3

Clausen, et al.         Expires November 10, 2016               [Page=
 2]
Internet-Draft               OLSRv2 Threats                     May 2=
016

1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182],
   [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a
   routing protocol for MANETs (Mobile Ad hoc NETworks).  OLSRv2 retains
   the same basic algorithms as its predecessor, however offers various
   improvements, e.g., a modular and flexible architecture allowing
   extensions, such as for security, to be developed as add-ons to the
   basic protocol.
[JWD] NIT: listing RFC7181 first would be =
helpful.
  
  =C2=A0The developments reflected in OLSRv2 h=
ave been motivated by increased
   real-world deployment experiences, e.g., from networks such as
   FunkFeuer [FUNKFEUER], and the requirements presented for continued
   successful operation of these networks.  With participation in such
   networks increasing (the FunkFeuer community network has, e.g.,
   roughly 400 individual participants at the time of publication of
   this document), operating with the assumption, that participants can
   be "trusted" to behave in a non-destructive way, is utopia.  T=
aking
   the Internet as an example, as participation in the network increases
   and becomes more diverse, more efforts are required to preserve the
   integrity and operation of the network.  Most SMTP-servers were,
   e.g., initially available for use by everyone on the Internet - with
   an increased populace on the Internet, attacks and abuses caused the
   recommended practice is today to require authentication and
   accounting for users of such SMTP servers [RFC5068].

[=
JWD] NIT language improvement....with an increase in users on the Internet,=
 
an increase in attacks and abuses followed necessitating a change in r=
ecommended 
practices; today authentication and accounting for users is =
required for use of SMTP servers [RFC5068].

  =C2=A0As OL=
SRv2 often is used in wireless environments, it is potentially
   exposed to different kinds of security threats, some of which are of
   particular significance as compared to wired networks.  As radio
   signals can be received as well as transmitted by any compatible
   wireless device within radio range, there is commonly no physical
   protection as otherwise known for wired networks.

   A first step towards hardening against attacks disrupting the
   connectivity of a network, is to understand the vulnerabilities of
   routing protocol, managing the connectivity.  This document therefore
   analyzes OLSRv2, to understand its inherent vulnerabilities and
   resiliences.  The authors do not claim completeness of the analysis,
   but hope that the identified attacks, as presented, form a meaningful
   starting-point for developing and deploying increasingly secured
   OLSRv2 networks.

   This document first describes security vulnerabilities to OLSRv2 when
   it is used without the mandatory-to-implement security mechanisms, as
   specified in Section 23.5 of [RFC7181].  It then analyzes which of
   these security vulnerabilities can be mitigated when using the
   mandatory-to-implement security mechanisms for OLSRv2, and how the

Clausen, et al.         Expires November 10, 2016               [Page=
 3]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   vulnerabilities are mitigated.  This separation is important since
   other security mechanisms ([JWD] other) than the mandatory-to-implement =
ones may be
   used in a deployment, as explicitly stated in [RFC7181]:

      "Any deployment of OLSRv2 SHOULD use the security mechanism
      specified in [RFC7183] but MAY use another mechanism if more
      appropriate in an OLSRv2 deployment.  For example, for longer-term
      OLSRv2 deployments, alternative security mechanisms (e.g.,
      rekeying) SHOULD be considered."

   Moreover, this document is also based on the assumption that no
   additional security mechanism such as IPsec is used in the IP layer
   or other mechanisms on lower layers, as not all MANET deployments may
   be able to accommodate such common protection mechanisms (e.g.,
   because of limited resources of MANET routers).

   The threats related to NHDP (Neighborhood Discovery Protocol) have
   been discussed in [RFC7186].  As NHDP is a fundamental block of
   OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.

   It should be noted that many OLSRv2 implementations are configurable,
   and so an attack on the configuration system (such as [RFC6779] and
   [RFC7184]) can be used to adversely affect the operation of an OLSRv2
   implementation.

1.1.  OLSRv2 Overview

   OLSRv2 contains three basic processes: Neighborhood Discovery, MPR
   Flooding ([JWD] MPR election/flooding not just flooding?) and Link State=
 Advertisements, described in the below with
   sufficient details for elaborating the analyses in this document.
[JWD] NIT make above two separate sentences. 
1=
.1.1.  Neighborhood Discovery

   Neighborhood Discovery is the process, whereby each router discovers
   the routers which are in direct communication range of itself (1-hop
   neighbors), and detects with which of these it can establish bi-
   directional communication.  Each router sends HELLO messages
   periodically, listing the identifiers of all the routers from which
   it has recently received a HELLO message, as well as the "status&qu=
ot; of
   the link (heard or verified bi-directional).  A router A receiving a
   HELLO message from a neighbor B, in which B indicates to have
   recently received a HELLO message from A, considers the link A-B to
   be bi-directional.  As B lists identifiers of all its neighbors in
   its HELLO message, A learns the "neighbors of its neighbors" (=
2-hop
   neighbors) through this process.  HELLO messages are sent
   periodically, however certain events may trigger non-periodic HELLOs.
   OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery
   mechanism.  The vulnerabilities of NHDP are analyzed in [RFC7186].

Clausen, et al.         Expires November 10, 2016               [Page=
 4]
Internet-Draft               OLSRv2 Threats                     May 2=
016

1.1.2.  MPR Flooding

   Multi Point Relay (MPR) Flooding is the process whereby each router
   is able to efficiently conduct network-wide broadcasts.  Each router
   designates, from among its bi-directional neighbors, a subset (MPR
   set) such that a multicast ([JWD] OLSRv2 specific multicast) message tra=
nsmitted by the router and
   relayed by the MPR set can ([JWD] be) received by all its 2-hop neighbor=
s.  MPR
   selection is encoded in outgoing HELLO messages. ([JWD] NHDP HELLO messa=
ges)

   Routers may express, in their HELLO messages, their "willingness&qu=
ot; (an
   integer between 0 "will never" and 7 "will always") =
to be selected as
   MPR, which is taken into consideration for the MPR calculation, and
   which is useful for example when an OLSRv2 network is "planned"=
;.  The
   set of routers having selected a given router as MPR is the MPR-
   selector-set of that router.  A study of the MPR flooding algorithm
   can be found in [MPR-FLOODING].

1.1.3.  Link State Advertisement

   Link State Advertisement is the process whereby routers are
   determining ([JWD] routers determine) which link state information to ad=
vertise through the
   network.  Each router must advertise, at least, all links between
   itself and its MPR selectors, in order to allow all routers to
   calculate shortest paths.  Such link state advertisements are carried
   in Topology Control (TC) messages, broadcast through the network
   using the MPR flooding process described above.  As a router selects
   MPRs only from among bi-directional neighbors, links advertised in TC
   are also bi-directional and routing paths calculated by OLSRv2
   contain only bi-directional links.  TCs are sent periodically,
   however certain events may trigger non-periodic TCs.

1.2.  Link State Vulnerability Taxonomy

   Proper functioning of OLSRv2 assumes that (i) each router signals its
   presence in the network and the topology information that it obtained
   honestly, (ii) each router can acquire and maintain a topology map,
   accurately reflecting the effective network topology; and (iii) that
   the network converges, i.e., that all routers in the network will
   have sufficiently identical topology maps.
[JWD] Nit make =
above a list.

  =C2=A0An OLSRv2 network can be disrupted =
by breaking either ([JWD] any not either) of these
   assumptions, specifically (a) routers may be prevented from acquiring
   a topology map of the network; (b) routers may acquire a topology map
   that does not reflect the effective network topology; and (c) two or
   more routers may acquire inconsistent topology maps.

Clausen, et al.         Expires November 10, 2016               [Page=
 5]
Internet-Draft               OLSRv2 Threats                     May 2=
016

1.3.  OLSRv2 Attack Vectors

   Besides "radio jamming", attacks on OLSRv2 consist of a compro=
mised
   OLSRv2 router injecting "correctly looking, but invalid, control
   traffic" (TCs, HELLOs) into the network.  A compromised OLSRv2 rout=
er
   can either (a) lie about itself (its identification, its willingness
   to serve as MPR), henceforth Identity Spoofing, or (b) lie about its
   relationship to other routers (pretend existence of links to other
   routers), henceforth Link Spoofing.  Such attacks may disrupt the the
   Link State Advertisement process, through targeting the MPR Flooding
   mechanism, or by causing incorrect link state information to be
   included in TCs, causing routers to have incomplete, inaccurate or
   inconsistent topology maps.  In a different class of attacks, a
   compromised OLSRv2 router injects control traffic, designed so as to
   cause an in-router resource exhaustion, e.g., by causing the
   algorithms calculating routing tables or MPR sets to be invoked
   continuously, preventing the internal state of a router from
   converging.

2.  Terminology

   This document uses the terminology and notation defined in [RFC5444],
   [RFC6130] and [RFC7181].  Additionally, it defines the following
   terminology:

   Compromised OLSRv2 router: -  An attacker that is present in the
      network and generates syntactically correct OLSRv2 control
      messages.  Control messages emitted by a compromised OLSRv2 router
      may contain additional information, or omit information, as
      compared to a control message generated by a non-compromised
      OLSRv2 router located in the same topological position in the
      network.

   Legitimate OLSRv2 router: -  An OLSRv2 router that is not a
      compromised OLSRv2 router.

3.  Topology Map Acquisition

   Topology Map Acquisition relates to the ability for any given router
   in the network to acquire a representation of the network
   connectivity.  A router, unable to acquire a topology map, is
   incapable of calculating routing paths and participating in
   forwarding data.  Topology map acquisition can be hindered by (i) TCs
   to not being delivered to (all) routers in the network, such as what
   happens in case of Flooding Disruption, or (ii) in case of "jamming=
"
   of the communication channel.

Clausen, et al.         Expires November 10, 2016               [Page=
 6]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   The jamming and flooding disruption due to identity spoofing and link
   spoofing have been discussed in [RFC7186].

3.1.  Attack on Jittering

   OLSRv2 incorporates a jittering: a random, but bounded, delay on
   outgoing control traffic [RFC5148].  This may be necessary when link
   layers (such as 802.11 [IEEE802.11]) are used that do not guarantee
   collision-free delivery of frames, and where jitter can reduce the
   probability of collisions of frames on lower layers.

   In OLSRv2, TC forwarding is jittered by a value between 0 and
   MAX_JITTER.  In order to reduce the number of transmissions, when a
   control message is due for transmission, OLSRv2 piggybacks all queued
   messages into a single transmission.  Thus, if a compromised OLSRv2
   router sends many TCs within a very short time interval, the jitter
   time of the attacked router tends to 0.  This renders jittering
   ineffective and can lead to collisions on the link layer.

   In addition to causing more collisions, forwarding a TC with little
   or no jittering can make sure that the TC message forwarded by a
   compromised router arrives before the message forwarded by legitimate
   routers.  The compromised router can thus inject malicious content in
   the TC, and the legitimate message will be discarded as ([JWD] a) duplic=
ate
   message.  This preemptive action is important for some of the attacks
   introduced in the following sections.

3.2.  Hop-count and Hop-limit Attacks

   The hop-count and hop-limit fields are the only parts of a TC that
   are modified when forwarding.  A compromised OLSRv2 router can modify
   either of these when forwarding TCs.

[JWD] mention of =
the integrity TLV here which makes this statement true would be helpful.

3.2.1.  Modifying the Hop Limit

   A compromised OLSRv2 router can decrease the hop limit when
   forwarding a TC.  This will reduce the scope of forwarding the
   message, and may lead to some routers in the network not receiving
   that TC.  Note that this is not necessarily the same as not relaying
   the message (i.e., setting the hop limit to 0), as illustrated in
   Figure 1.

Clausen, et al.         Expires November 10, 2016               [Page=
 7]
Internet-Draft               OLSRv2 Threats                     May 2=
016

                            .---.
                            | X |
                          --'---' __
                         /          \
                        /            \
                    .---.              .---.
        TC ----->   | A |              | C |
                    '---'              '---'
                        \    .---.   /
                         \-- | B |__/
                             '---'

                        Figure 1: Hop Limit Attack.

   A TC arrives at and is forwarded by router A, such that it is
   received by both B and the malicious X. X can forward the TC without
   any delay (including without jitter) such that its transmissions
   arrives before that of B at C. Before forwarding, it significantly
   reduces the hop limit of the message.  Router C receives the TC,
   processes (and forwards) it, and marks it as already received -
   causing it to discard further copies received from B. Thus, if the TC
   is forwarded by C, it has a very low hop limit and will not reach the
   whole network.

3.2.2.  Modifying the Hop Count

   A compromised OLSRv2 router can modify the hop count when forwarding
   a TC.  This may have two consequences: (i) if the hop count is set to
   the maximum value, then the TC will be forwarded no further by, or
   (ii) artificially manipulating the hop count may affect the validity
   time as calculated by recipients, when using distance-dependent
   validity times as defined in [RFC5497] (e.g., as part of a fish-eye
   extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]).

           v_time(1hop)=3D2s  v_time(2hops)=3D4s   v_time(3hops)=3D6s
   .---.         .---.          .---.           .---.
   | A |-------> | B | -------> | X |---------->| C |
   `---'         `---'          `---'           `---'

     Figure 2: Different validity times based on the distance in hops.

   In Figure 2, router A sends a TC with a validity time of two seconds
   for neighbors that are one hop away, four seconds for routers in a
   two-hop distance and six seconds in a three-hop distance.  If X is a
   compromised OLSRv2 router and modifies the hop count (say, by
   decreasing it to 0), then C will calculate the validity time of
   received information to two seconds - after which it expires unless

Clausen, et al.         Expires November 10, 2016               [Page=
 8]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   refreshed.  If TCs from A are sent less frequently than that up to 3
   hops, this causes links advertised in such TCs to be only
   intermittently available to C.

[JWD] this is a really =
good point!

=C2=A04.  Effective Topology

   Link-state protocols assume that each router can acquire an accurate
   topology map, reflecting the effective network topology.  This
   implies that the routing protocol, through its message exchange,
   identifies a path from a source to a destination, and this path is
   valid for forwarding data traffic.  If an attacker disturbs the
   correct protocol behavior, the perceived topology map of a router can
   permanently differ from the effective topology.

   Considering the example in Figure 3(a), which illustrates the
   topology map as acquired by router S. This topology map indicates
   that the routing protocol has identified that for S, a path exists to
   D via B, which it therefore assumes can be used for transmitting
   data.  If, effectively, B does not forward data traffic from S, then
   the topology map in S does not accurately reflect the effective
   network topology.  Rather, the effective network topology from the
   point of view of S would be as indicated in Figure 3(b): D is not
   part of the network reachable from router S.

      .---.    .---.    .---.           .---.    .---.
      | S |----| B |----| D |           | S |----| B |
      `---'    `---'    `---'           `---'    `---'

              (a)                             (b)

               Figure 3: Incorrect Data Traffic Forwarding.

   Some of the attacks related to NHDP, such as message timing attack,
   indirect channel overloading have been discussed in [RFC7186].  Other
   threats specific to OLSRv2 are further detailed in this section.

4.1.  Incorrect Forwarding

   OLSRv2 routers exchange information using link-local transmissions
   (link-local multicast or limited broadcast) for their control
   messages, with the routing process in each router retransmitting
   received messages destined for network-wide diffusion.  Thus, if the
   operating system in a router is not configured to enable forwarding,
   this will not affect the operating of the routing protocol, or the
   topology map acquired by the routing protocol.  It will, however,

Clausen, et al.         Expires November 10, 2016               [Page=
 9]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   cause a discrepancy between the effective topology and the topology
   map, as indicated in Figure 3(a) and Figure 3(b).

[JWD=
] the term unicast forwarding should be used as without that term it may be assumed that forwarding of multicast is being disrupted which isn'=
t the case.

  =C2=A0This situation is not hypothetical.  A co=
mmon error seen when
   deploying OLSRv2-based networks using Linux-based computers as router
   is to neglect enabling IP forwarding, which effectively becomes an
   accidental attack of this type.

4.2.  Wormholes

   A wormhole, depicted in the example in Figure 4, may be established
   between two collaborating devices, connected by an out-of-band
   channel.  These devices send traffic through the "tunnel" to t=
heir
   alter-ego, which "replays" the traffic.  Thus, routers D and S=
 appear
   as if direct neighbors and reachable from each other in 1 hop through
   the tunnel, with the path through the MANET being 100 hops long.

   .---.                                     .---.
   | S |----   ....100-hop long path  ... ---| D |
   `---.                                   / `---'
       \                                  /
        \                                /
         \X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3DX

                1-hop path via wormhole

        Figure 4:  Wormholing between two collaborating devices not
                  participating in the routing protocol.

   The consequences of such a wormhole in the network depends on the
   detailed behavior of the wormhole.  If the wormhole relays only
   control traffic, but not data traffic, the same considerations as in
   Section 4.1 applies.  If, however, the wormhole relays all traffic,
   control and data alike, it is connectivity-wise identical to a usable
   link - and the routing protocol will correctly generate a topology
   map reflecting the effective network topology.  The efficiency of the
   topology so obtained depends on (i) the wormhole characteristics,
   (ii) how the wormhole presents itself, and (iii) how paths are
   calculated.

   Assuming that paths are calculated with unit-cost for all links,
   including the "link" presented by the wormhole: if the real
   characteristics of the wormhole are as-if it was a path of more than
   100 hops (e.g., with respect to delay, bandwidth, etc.), then the

Clausen, et al.         Expires November 10, 2016              [Page =
10]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   presence of the wormhole results in a degradation in performance as
   compared to using the non-wormhole path.  Conversely, if the "link&=
quot;
   presented by the wormhole has better characteristics, the wormhole
   results in improved performance.

   If paths are calculated using non-unit-costs for all links, and if
   the cost of the "link" presented by the wormhole correctly rep=
resents
   the actual cost (e.g., if the cost is established through
   measurements across the wormhole), then the wormhole may in the worst
   case cause no degradation in performance, in the best case improve
   performance by offering a better path.  If the cost of the "link&qu=
ot;
   presented by the wormhole is misrepresented, then the same
   considerations as for unit-cost links apply.

   An additional consideration with regards to wormholes is, that such
   may present topologically attractive paths for the network - however
   it may be undesirable to have data traffic transit such a path: an
   attacker could, by virtue of introducing a wormhole, acquire the
   ability to record and inspect transiting data traffic.

4.3.  Sequence Number Attacks

   OLSRv2 uses two different sequence numbers in TCs, to (i) avoid
   processing and forwarding the same message more than once (Message
   Sequence Number), and (ii) to ensure that old information, arriving
   late due to, e.g., long paths or other delays, is not allowed to
   overwrite fresher information (Advertised Neighbor Sequence Number -
   ANSN).

4.3.1.  Message Sequence Number

   An attack may consist of a compromised OLSRv2 router spoofing the
   identity of another router in the network, and transmitting a large
   number of TCs, each with different Message Sequence Numbers.
   Subsequent TCs with the same sequence numbers, originating from the
   router whose identity was spoofed, would hence be ignored, until
   eventually information concerning these "spoofed" TCs expires.=


[JWD] it should be mentioned that this is fixed with the=
 signing TLV.

4.3.2.  Advertised Neighbor Sequence =
Number (ANSN)

   An attack may consist of a compromised OLSRv2 router spoofing the
   identity of another router in the network, and transmitting a single
   TC, with an ANSN significantly larger than that which was last used
   by the legitimate router.  Routers will retain this larger ANSN as
   "the most fresh information" and discard subsequent TCs with l=
ower
   sequence numbers as being "old".

[JWD] again it should be mentioned that this is fixed with the signing =
TLV.

Clausen, et al.         Expires November 10, 2016              [Page =
11]
Internet-Draft               OLSRv2 Threats                     May 2=
016

4.4.  Indirect Jamming

   Indirect Jamming is an attack in which a compromised OLSRv2 router
   is, by its actions, causing legitimate routers to generate inordinate
   amounts of control traffic, thereby increasing both channel
   occupation and the overhead incurred in each router for processing
   this control traffic.  This control traffic will be originated from
   legitimate routers, thus to the wider network, the malicious device
   may remain undetected.

   The general mechanism whereby a malicious router can cause indirect
   jamming is for it to participate in the protocol by generating
   plausible control traffic, and to tune this control traffic to in
   turn trigger receiving routers to generate additional traffic.  For
   OLSRv2, such an indirect attack can be directed at, respectively, the
   Neighborhood Discovery mechanism and the Link State Advertisement
   mechanism.

   The most efficient indirect jamming attack in OLSRv2 is to target
   control traffic, destined for network-wide diffusion.  This is
   illustrated in Figure 5.

   The malicious router X selects router A as MPR at time t0 in a HELLO.
   This causes X to appear as MPR selector for A and, consequently, A
   sets X to be advertised in its "Neighbor Set" and increments t=
he
   associated "Advertised Neighbor Sequence Number" (ANSN).  Rout=
er A
   must, then, advertise the link between itself and X in subsequent
   outgoing TCs (t1), also including the ANSN in such TCs.  Upon X
   having received this TC, it declares the link between itself and A as
   no longer valid (t2) in a HELLO (indicating the link to a as LOST).
   Since only symmetric links are advertised by OLSRv2 routers, A will
   upon receipt hereof remove X from the set of advertised neighbors and
   increment the ANSN.  Router A will then in subsequent TCs advertise
   the remaining set of advertised neighbors (i.e., with X removed) and
   the corresponding ANSN (t3).  Upon X having received this information
   in another TC from A, it may repeat this cycle, alternating
   advertising the link A-X as "LOST" and as "MPR".

Clausen, et al.         Expires November 10, 2016              [Page =
12]
Internet-Draft               OLSRv2 Threats                     May 2=
016

              broadcast TC    ANS=3D{}         TC:()
               (X-A) ANSN      ANSN++          ANSN
      .---.        .---.        .---.        .---.
      | A |        | A |        | A |        | A |
      '---'        '---'        '---'        '-=
--'
        ^            |            ^            |
        |            |            |            |
        | select     |            |indicate    |
        | as MPR     |            |as LOST     |
      .---.        .---.        .---.        .---.
      | X |        | X |        | X |        | X |
      '---'        '---'        '---'        '-=
--'

        t0           t1            t2           t3

   Figure 5: Indirect Jamming in Link State Advertisement: the malicious
                 X flips between link status MPR and LOST.

   Routers receiving a TC will parse and process this message,
   specifically updating their topology map as a consequence of
   successful receipt.  If the ANSN between two successive TCs from the
   same router has incremented, then the topology has changed and
   routing sets are to be recalculated.  This is a potentially
   computationally costly operation.

   A compromised OLSRv2 router may chose to conduct this attack against
   all its neighbors, thus attaining maximum disruptive impact on the
   network with relatively little overhead of its own: other than
   participating in the Neighborhood Discovery procedure, the
   compromised OLSRv2 router will monitor TCs generated by its neighbors
   and alternate the advertised status for each such neighbor, between
   "MPR" and "LOST".  The compromised OLSRv2 router wil=
l indicate its
   willingness to be zero (thus, avoid being selected as MPR) and may
   ignore all other protocol operations, while still remaining effective
   as an attacker.

   The basic operation of OLSRv2 employs periodic message emissions, and
   by this attack it can be ensured that each such periodic message will
   entail routing table recalculation in all routers in the network.

   If the routers in the network have "triggered TCs" enabled, th=
is
   attack may also cause an increased TC frequency.  Triggered TCs are
   intended to allow a (stable) network to have relatively low TC
   emission frequencies, yet still allow link breakage or link emergence
   to be advertised through the network rapidly.  A minimum message
   interval (typically much smaller than the regular periodic message
   interval) is imposed, to rate-limit worst-case message emissions.
   This attack can cause the TC interval to, permanently, become equal

Clausen, et al.         Expires November 10, 2016              [Page =
13]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   to the minimum message interval.  [RFC7181] proposes as default that
   the minimum TC interval be 0.25 x TC interval.
[JWD glad this was mentioned.  Something might be said regarding the reduce=
d
effectiveness of the compromised node is not ever selected as an MPR a=
s the
calculation for routing might only affect a leaf router (dependent=
 on implementation) 

   Indirect Jamming by a compromised OLSRv2 router can thus have two
   effects: it may cause increased frequency of TC generation and
   transmission, and it will cause additional routing table
   recalculation in all routers in the network.

5.  Inconsistent Topology

   Inconsistent topology maps can occur by a compromised OLSRv2 router
   employing either of identity spoofing or link spoofing for conducting
   an attack against an OLSRv2 network.  The threats related to NHDP,
   such as identity spoofing in NHDP, link spoofing in NHDP and creating
   loops have been illustrated in [RFC7186].  This section mainly
   addresses the vulnerabilities in [RFC7181].

5.1.  Identity Spoofing

   Identity spoofing can be employed by a compromised OLSRv2 router via
   the Neighborhood Discovery process and via the Link State
   Advertisement process.  Either of them causes inconsistent topology
   maps in routers in the network.  The inconsistent topology maps due
   to neighborhood discovery has been discussed in [RFC7186].  For
   OLSRv2, the attack on link state advertisements can also cause
   inconsistent topology maps.

   An inconsistent topology map may occur when the compromised OLSRv2
   router takes part in the Link State Advertisement (LSA) procedure, by
   selecting a neighbor as MPR, which in turn advertises the spoofed
   identities of the compromised OLSRv2 router.  This attack will alter
   the topology maps of all routers of the network.

[JWD] this is the only play that the term LSA is used.  Sugg=
est removing it.
[JWD] also it should be mentioned that spoof=
ing is protected against if using the SHOULD use TLVs
   A --=
 B -- C -- D -- E -- F -- X

                               (X spoofs A)

    Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the
          identity of A, leading to a wrongly perceived topology.

   In Figure 6, router X spoofs the address of router A. If X selects F
   as MPR, all routers in the network will be informed about the link
   F-A by the TCs originating from F. Assuming that (the real) A selects
   B as MPR, the link B-A will also be advertised in the network.

Clausen, et al.         Expires November 10, 2016              [Page =
14]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   When calculating paths, B and C will calculate paths to A via B, as
   illustrated in Figure 7(a); for these routers, the shortest path to A
   is via B. E and F will calculate paths to A via F, as illustrated in
   Figure 7(b); for these routers, the shortest path to A is via the
   compromised OLSRv2 router X, and these are thus disconnected from the
   real A. D will have a choice: the path calculated to A via B is of
   the same length as the path via the compromised OLSRv2 router X, as
   illustrated in Figure 7(b).

   In general, the following observations can be made:

   o  The network will be split in two, with those routers closer to B
      than to X reaching A, whereas those routers closer to X than to B
      will be unable to reach A.

   o  Routers beyond B, i.e., routers beyond one hop away from A will be
      unable to detect this identity spoofing.

   The identity spoofing attack via the Link State Advertisement
   procedure has a higher impact than the attack on the neighborhood
   discovery procedure, since it alters the topology maps of all routers
   in the network, and not only in the 2-hop neighborhood.  However, the
   attack is easier to detect by other routers in the network.  Since
   the compromised OLSRv2 router is advertised in the whole network,
   routers whose identities are spoofed by the compromised OLSRv2 router
   can detect the attack.  For example, when a receives a TC from F
   advertising the link F-A, it can deduce that some entity is injecting
   incorrect Link State information as it does not have F as one of its
   direct neighbors.
                                            =
     (X spoofs A)

      A < ---- B < ---- C           E ----> F ----> X

      (a) Routers B and C           (b) Routers E and F

         A < --- B < --- C < --- D ---> E ---> F ----> X

                                                    (X spoofs A)

     Figure 7: Routing paths towards A, as calculated by the different
   routers in the network in presence of a compromised OLSRv2 router X,
                        spoofing the address of A.

   As the compromised OLSRv2 router X does not itself send the TCs, but
   rather, by virtue of MPR selection, ensures that the addresses it

Clausen, et al.         Expires November 10, 2016              [Page =
15]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   spoofs are advertised in TCs from its MPR selector F, the attack may
   be difficult to counter: simply ignoring TCs that originate from F
   may also suppress the link state information for other, legitimate,
   MPR selectors of F.

   Identity spoofing by a compromised OLSRv2 router, participating in
   the Link State Advertisement process by selecting MPRs only, thus,
   creates a situation wherein two or more routers have substantially
   inconsistent topology maps: traffic for an identified destination is,
   depending on where in the network it appears, delivered to different
   routers.

[JWD] Link State Advertisement is again used =
here suggest lowercase.

=C2=A05.2.  Link Spoofing

   Link Spoofing is a situation in which a router advertises non-
   existing links to another router (possibly not present in the
   network).  Essentially, TCs and HELLOs both advertise links to direct
   neighbor routers, with the difference being the scope of the
   advertisement.  Thus, link spoofing consists of a compromised OLSRv2
   router, reporting that it has neighbors routers which are, either,
   not present in the network, or which are effectively not neighbors of
   the compromised OLSRv2 router.

   It can be noted that a situation similar to link spoofing may occur
   temporarily in an OLSR or OLSRv2 network without compromised OLSRv2
   routers: if A was, but is no more, a neighbor of B, then A may still
   be advertising a link to B for the duration of the time it takes for
   the the Neighborhood Discovery process to determine this changed
   neighborhood.

   In the context of this document, link spoofing refers to a persistent
   situation where a compromised OLSRv2 router intentionally advertises
   links to other routers, for which it is not a direct neighbor.

[J=
WD] this is a similar attack to the above but is not protected against 
=
but the attacker is more easily identified.  One difference is that TC 
=
messages with spoofed links may be hop count limited making detection more =
difficult.=20

5.2.1.  Inconsistent Topology Maps due to Link State Advertisements

   Figure 8 illustrates a network, in which the compromised OLSRv2
   router X spoofs links to a existing router A by participating in the
   Link State Advertisement process and including this non-existing link
   in its advertisements.

   A --- B --- C --- D --- E --- F --- G --- H --- X

                             (X spoofs the link to A)

   Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a

Clausen, et al.         Expires November 10, 2016              [Page =
16]
Internet-Draft               OLSRv2 Threats                     May 2=
016

    spoofed link to A in its TCs, thus all routers will record both of
                          the links X-A and B-A.

   As TCs are flooded through the network, all routers will receive and
   record information describing a link X-A in this link state
   information.  If A has selected router B as MPR, B will likewise
   flood this link state information through the network, thus all
   routers will receive and record information describing a link B-A.

   When calculating routing paths, B, C and D will calculate paths to A
   via B, as illustrated in Figure 9(a); for these routers, the shortest
   path to A is via B. F and G will calculate paths to A via X, as
   illustrated in Figure 9(b); for these routers, the shortest path to A
   is via X, and these are thus disconnected from the real router A. E
   will have a choice: the path calculated to A via B is of the same
   length as the path via X, as illustrated in Figure 9(b).

   A < --- B < --- C < --- D           F ---> G ---> X ---&g=
t; A

       (a) Routers B, C, and D           (b) Routers F and G

   A < --- B < --- C < --- D < --- E ---> F ---> G --->=
; X ---> A

                          (c) Router E

      Figure 9: Routing paths towards router A, as calculated by the
   different routers in the network in presence of a compromised OLSRv2
                  router X, spoofing a link to router A.

   In general, the following observations can be made:

   o  The network will be separated in two, with those routers closer to
      B than to X reaching A, whereas those routers closer to X than to
      B unable to reach A.

   o  Routers beyond B, i.e., routers beyond one hop away from A will be
      unable to detect this link spoofing.

   The impact of this attack is similar to that presented in
   Section 5.2.1, however, is easier to detect as the compromised OLSRv2
   router is generating control traffic reaching the entire network.

Clausen, et al.         Expires November 10, 2016              [Page =
17]
Internet-Draft               OLSRv2 Threats                     May 2=
016

6.  Mitigation of Security Vulnerabilities for OLSRv2

   As described in Section 1, [RFC7183] specifies a security mechanism
   for OLSRv2 that is mandatory to implement.  However, deployments may
   choose to use different security mechanisms if more appropriate.
   Therefore, it is important to understand both the inherent resilience
   of OLSRv2 against security vulnerabilities when not using the
   mechanisms specified in [RFC7183], as well as the protection that
   [RFC7183] provides when used in a deployment.

6.1.  Inherent OLSRv2 Resilience

   OLSRv2 (without the mandatory-to-implement security mechanisms in
   [RFC7183]) provides some inherent resilience against part of the
   attacks described in this document.  In particular, it provides the
   following resilience:

   o  Sequence numbers: OLSRv2 employs message sequence numbers,
      specific per router identity and message type.  Routers keep an
      "information freshness" number (ANSN), incremented each tim=
e the
      content of a Link State Advertisement from a router changes.  This
      allows rejecting "old" information and duplicate messages, =
and
      provides some protection against "message replay".  This, h=
owever,
      also presents an attack vector (Section 4.3).

   o  Ignoring uni-directional links: The Neighborhood Discovery process
      detects and admits only bi-directional links for use in MPR
      selection and Link State Advertisement.  Jamming attacks may
      affect only reception of control traffic, however OLSRv2 will
      correctly recognize, and ignore, such a link as not bi-
      directional.

   o  Message interval bounds: The frequency of control messages, with
      minimum intervals imposed for HELLO and TCs.  This may limit the
      impact from an indirect jamming attack (Section 4.4).

   o  Additional reasons for rejecting control messages: The OLSRv2
      specification includes a list of reasons, for which an incoming
      control message should be rejected as malformed - and allows that
      a protocol extension may recognize additional reasons for OLSRv2
      to consider a message malformed.  This allows - together with the
      flexible message format [RFC5444] - addition of security
      mechanisms, such as digital signatures, while remaining compliant
      with the OLSRv2 standard specification.

Clausen, et al.         Expires November 10, 2016              [Page =
18]
Internet-Draft               OLSRv2 Threats                     May 2=
016

6.2.  Resilience by using RFC7183 with OLSRv2

   [RFC7183] specifies mechanisms for integrity and replay protection
   for NHDP and OLSRv2, using the generalized packet/message format
   described in [RFC5444] and the TLV definitions in [RFC7182].  The
   specification describes how to add an Integrity Check Value (ICV) in
   a TLV to each control message, providing a digital signature of the
   content of the message using HMAC/SHA-256.  In addition, a timestamp
   TLV is added to the message prior to creating the ICV, enabling
   replay protection of messages.  The document specifies how to sign
   outgoing messages and how to verify incoming messages, as well as
   under which circumstances a non-valid message is rejected.  Because
   of the HMAC/SHA-256 ICV, a shared key between all routers in the
   MANET is assumed.  A router without valid credentials is not able to
   create an ICV that can be correctly verified by other routers in the
   MANET; therefore, such an incorrectly signed message will be rejected
   by other MANET routers, and the router cannot participate in the
   OLSRv2 routing process (i.e., the malicious router will be ignored by
   other, legitimate routers).  [RFC7183] does not address the case
   where a router with valid credentials has been compromised.  Such a
   compromised router will not be excluded from the routing process, and
   other means of detecting such a router are necessary if required in a
   deployment (in addition to using asymmetric keys, allowing to revoke
   access to one particular router instead of revoking the shared key
   used by all routers in the MANET).

   In the following sections, each of the vulnerabilities described
   earlier in this document will be evaluated in terms of whether OLSRv2
   with the mechanisms in [RFC7183] provides sufficient protection
   against the attack.  It is implicitly assumed in each of the
   following sections that [RFC7183] is used with OLSRv2.

[JWD] this is a really important part of the document and should be moved<=
br>up to provide the reader with a better understanding.  Without this it w=
ill
be easy for a reader to assume that all attacks presented are equall=
y possible.
A summary was given but more details (along with an inline s=
entence per attack 
pointing to appropriate section below) would help qu=
ite a lot.

6.2.1.  Topology Map Acquisition

   Attack on Jittering -  As only OLSRv2 routers with valid credentials
      can participate in the routing process, a malicious router cannot
      reduce the jitter time of an attacked router to 0 by sending many
      TC messages in a short time.  The attacked router would reject all
      the incoming messages as "invalid" and not forward them.  T=
he same
      applies for the case where a malicious router wants to assure that
      by forcing a zero jitter interval, the message arrives before the
      same message forwarded by legitimate routers.

   Modifying the Hop Limit -  As the hop limit is not protected by
      [RFC7183] (since it is a mutual field, changing at every hop),
      this attack is still feasible.

Clausen, et al.         Expires November 10, 2016              [Page =
19]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   Modifying the Hop Count -  Similarly to the hop limit, as the hop
      count is not protected by [RFC7183] (since it is a mutual field,
      changing at every hop), this attack is still feasible.

6.2.2.  Effective Topology

   Incorrect Forwarding -  As only OLSRv2 routers with valid credentials
      can participate in the routing process, a malicious router will
      not be part of the topology of other legitimate OLSRv2 routers.
      Therefore, no data traffic will be sent to the malicious router
      for forwarding.

   Wormholes -  Since a wormhole consists of at least two devices
      forwarding (unmodified) traffic, this attack is still feasible and
      undetectable by the OLSRv2 routing process since the attack does
      not involve the OLSRv2 protocol itself (but rather lower layers).
      By using [RFC7183], it can at least be assured that the content of
      the control messages is not modified while being forwarded via the
      wormhole.  Moreover, the timestamp TLV assures that the forwarding
      can only be done in a short time window after the actual TC
      message has been sent.

   Message Sequence Number -  As the message sequence number is included
      in the ICV calculation, OLSRv2 is protected against this attack.

   Advertised Neighbor Sequence Number (ANSN) -  As the ANSN is included
      in the ICV calculation, OLSRv2 is protected against this attack.

   Indirect Jamming -  Since the control messages of a malicious router
      will be rejected by other legitimate OLSRv2 routers in the MANET,
      this attack is mitigated.

6.2.3.  Inconsistent Topology

   Identity Spoofing -  Since the control messages of a malicious router
      will be rejected by other legitimate OLSRv2 routers in the MANET,
      a router without valid credentials may spoof its identity (e.g.,
      IP source address or message originator address), but the messages
      will be ignored by other routers.  As the mandatory mechanism in
      [RFC7183] uses shared keys amongst all MANET routers, a single
      compromised router may spoof its identity and cause harm to the
      network stability.  Removing this one malicious router once
      detected implies rekeying all other routers in the MANET.
      Asymmetric keys, in particular when using identity based
      signatures, such as specified in [IBS] may further allow to revoke
      single routers and to verify their identity based on the ICV
      itself.

Clausen, et al.         Expires November 10, 2016              [Page =
20]
Internet-Draft               OLSRv2 Threats                     May 2=
016

   Link Spoofing -  Similar to identity spoofing, a malicious router
      without valid credential may spoof links, but its control messages
      will be rejected by other routers, thereby mitigating the attack.

   Inconsistent Topology Maps due to Link State Advertisements -  The
      same considerations as for link spoofing apply.

7.  Security Considerations

   This document does not specify a protocol or a procedure.  The
   document, however, reflects on security considerations for OLSRv2,
   and its constituent parts, including NHDP.

8.  IANA Considerations

   This document has no actions for IANA.

9.  References

9.1.  Normative References

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2&quo=
t;,
              RFC 7181, April 2014.

   [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats f=
or
              the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
              April 2014.

9.2.  Informative References

   [FUNKFEUER]
              "=
http://www.funkfeuer.at/".

   [IBS]      Dearlove, C., "Identity-Based Signatures for MANET Routi=
ng
              Protocols", work in progress draft-ietf-manet-ibs-05,
              March 2016.

   [IEEE802.11]
              "IEEE 802.11: Wireless LAN Medium Access Control (MAC) a=
nd
              Physical Layer (PHY) Spec.", 2007.

   [MPR-FLOODING]
              Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
              relaying: An efficient technique for flooding in mobile

Clausen, et al.         Expires November 10, 2016              [Page =
21]
Internet-Draft               OLSRv2 Threats                     May 2=
016

              wireless networks.", 2001.

   [OLSR-FSR]
              Clausen, T., "Combining Temporal and Spatial Partial
              Topology for MANET routing-Merging OLSR and FSR,
              Proceedings of the 2003 IEEE Conference of Wireless
              Personal Multimedia Communications (WPMC 03)", 2003.

   [OLSR-FSR-Scaling]
              Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G.
              Rodolakis, "Fish eye OLSR scaling properties, IEEE Journ=
al
              of Communication and Networks (JCN), Special Issue on
              Mobile Ad Hoc Wireless Networks", 2004.

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
              Finch, "Email Submission Operations: Access and
              Accountability Requirements", RFC 5068, BCP 134,
              October 2007.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444=
,
              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

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

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol"=
,
              RFC 6779, May 2012.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, April 2014.

   [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)

Clausen, et al.         Expires November 10, 2016              [Page =
22]
Internet-Draft               OLSRv2 Threats                     May 2=
016

              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7183, April 2014.

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, April 2014.

   [RFC7187]  Dearlove, C. and T. Clausen, "Routing Multipoint Relay
              Optimization for the Optimized Link State Routing Protocol
              Version 2 (OLSRv2)", RFC 7187, April 2014.

   [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routi=
ng
              Protocol Version 2 (OLSRv2) and MANET Neighborhood
              Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
              April 2014.

Authors' Addresses

   Thomas Clausen

   Phone: +33-6-6058-9349
   Email: T.Cla=
usen@computer.org
   URI:   http:/=
/www.thomasclausen.org

   Ulrich Herberg

   Email: ulrich@h=
erberg.name
   URI:   http://www.=
herberg.name

   Jiazi Yi
   Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 1 77 57 80 85
   Email: jiazi@jiaz=
iyi.com
   URI:   http://www.=
jiaziyi.com/

Clausen, et al.         Expires November 10, 2016              [Page =
23]


_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a114113da8e10e9053b45b671--


From nobody Tue Aug 30 02:12:16 2016
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416B012D190 for ; Tue, 30 Aug 2016 02:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.467
X-Spam-Level: 
X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 mAIkQ8ESC7AA for ; Tue, 30 Aug 2016 02:12:13 -0700 (PDT)
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 36FD912D8B1 for ; Tue, 30 Aug 2016 02:12:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,255,1470697200";  d="scan'208,217";a="103481378"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 30 Aug 2016 10:11:25 +0100
X-IronPort-AV: E=Sophos;i="5.30,255,1470697200";  d="scan'208,217";a="132240743"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 30 Aug 2016 10:11:24 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.250]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Tue, 30 Aug 2016 10:11:23 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] OLSRv2 sec threats review
Thread-Index: AQHSAa6Eho2jC7Np20WfxYqCvez/fqBhNstw
Date: Tue, 30 Aug 2016 09:11:22 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D92413665GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] OLSRv2 sec threats review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 09:12:15 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D92413665GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

TG9va2luZyBhdCBKdXN0aW7igJlzIGNvbW1lbnRzIG1lYW5zIEnigJl2ZSBjYXVnaHQgYW4gZXJy
b3IsIG9yIGF0IGxlYXN0IGEg4oCcZG9u4oCZdCBkbyB0aGF04oCdLg0KDQoNCiAgIEluIEZpZ3Vy
ZSAyLCByb3V0ZXIgQSBzZW5kcyBhIFRDIHdpdGggYSB2YWxpZGl0eSB0aW1lIG9mIHR3byBzZWNv
bmRzDQoNCiAgIGZvciBuZWlnaGJvcnMgdGhhdCBhcmUgb25lIGhvcCBhd2F5LCBmb3VyIHNlY29u
ZHMgZm9yIHJvdXRlcnMgaW4gYQ0KDQogICB0d28taG9wIGRpc3RhbmNlIGFuZCBzaXggc2Vjb25k
cyBpbiBhIHRocmVlLWhvcCBkaXN0YW5jZS4NCg0KVGhvc2UgbG9vayBtb3JlIGxpa2UgaW50ZXJ2
YWwgdGltZXMgdGhhbiB2YWxpZGl0eSB0aW1lcyB3aXRoIGRlZmF1bHQgcGFyYW1ldGVycyAod2hp
Y2ggaXTigJlzIGVhc2llc3QgdG8gdXNlIGFzIGFuIGV4YW1wbGUpLiBJIHN1Z2dlc3QgbXVsdGlw
bHlpbmcgYnkgdGhyZWUuIEJ1dCB0aGVuIOKApg0KDQpUaGF04oCZcyBhIGJhZCBwYXR0ZXJuIG9m
IHZhbGlkaXR5IHRpbWVzLiBJdOKAmXMgbGVnYWwgdW5kZXIgNTQ5NyAoSSB0aGluayksIGJ1dCBJ
IGRvbuKAmXQgaGF2ZSB0aGUgdGltZSByaWdodCBub3cgdG8gZGV0ZXJtaW5lIGlmIGl0IHZpb2xh
dGVzIGEgTVVTVCBvciBhIFNIT1VMRCBmb3IgT0xTUnYyLiBJIHRoaW5rIGl0IGRvZXMsIGJ1dCBp
biBhbnkgY2FzZSBpdOKAmXMgYSBiYWQgcGF0dGVybiB3ZSBkb27igJl0IHdhbnQgdG8gc3VnZ2Vz
dC4NCg0KVGhhdOKAmXMgYmVjYXVzZSB5b3UgY2Fu4oCZdCBzZW5kIG1lc3NhZ2VzIGF0IHR3byBz
ZWNvbmQgaW50ZXJ2YWxzIHdpdGggYW55IHBhdHRlcm4gb2YgaG9wIGxpbWl0cyB0aGF0IG1lYW5z
IGVhY2ggbm9kZSBzZWVzIGEgcmVndWxhciBwYXR0ZXJuIG9mIG1lc3NhZ2VzIHdpdGggYXBwcm9w
cmlhdGUgaW50ZXJ2YWxzLg0KDQpFYXN5IGZpeCwgY2hhbmdlIHRoZSBzaXggdG8gZWlnaHQuIE9y
IHdpdGggdGhlIHRyaXBsaW5nIHN1Z2dlc3Rpb24gYWJvdmUsIDI0Lg0KDQpBbHNvLCBpdOKAmXMg
YSBiYWQgZXhhbXBsZSBpbiBhbm90aGVyIHdheS4gSXQgc3VnZ2VzdHMgc2VuZGluZyBzb21lIFRD
IG1lc3NhZ2VzIG9ubHkgb25lIGhvcC4gQnV0IG9uZSBob3AgVEMgbWVzc2FnZXMgYXJlIHByZXR0
eSB1c2VsZXNzLCBldmVyeXRoaW5nIHlvdSBuZWVkIGZyb20gdGhlbSBpcyBpbiBhIEhFTExPIG1l
c3NhZ2UgLSB1bmxlc3MgeW91IGhhdmUgYW55IGF0dGFjaGVkIG5ldHdvcmtzLiBUbyBhdm9pZCBw
ZW9wbGUgaGF2aW5nIHRvIGdvIGRvd24gdGhhdCBjdWwgZGUgc2FjIChvbmUgaG9wLCB1c2VsZXNz
LCB1bmxlc3MgYXR0YWNoZWQgbmV0d29ya3MsIG5vdCBtZW50aW9uZWQpIEnigJlkIHVzZSB0d28s
IHRocmVlIGFuZCBmb3VyIGhvcHMgcmF0aGVyIHRoYW4gb25lLCB0d28gYW5kIHRocmVlLiAoTWln
aHQgbWVhbiBvdGhlciBjaGFuZ2VzLikNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5p
b3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBM
YWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQg
IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFp
bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJl
Y2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu
dGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5v
dGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55
IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv
dGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D92413665GLKXM0002VGREEN_
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
e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn
aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p
bHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw
dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcgYXQgSnVzdGlu4oCZcyBj
b21tZW50cyBtZWFucyBJ4oCZdmUgY2F1Z2h0IGFuIGVycm9yLCBvciBhdCBsZWFzdCBhIOKAnGRv
buKAmXQgZG8gdGhhdOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSW4gRmlndXJlIDIsIHJvdXRl
ciBBIHNlbmRzIGEgVEMgd2l0aCBhIHZhbGlkaXR5IHRpbWUgb2YgdHdvIHNlY29uZHM8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZm9yIG5laWdoYm9ycyB0aGF0IGFyZSBvbmUg
aG9wIGF3YXksIGZvdXIgc2Vjb25kcyBmb3Igcm91dGVycyBpbiBhPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7IHR3by1ob3AgZGlzdGFuY2UgYW5kIHNpeCBzZWNvbmRzIGluIGEg
dGhyZWUtaG9wIGRpc3RhbmNlLiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhvc2UgbG9vayBtb3JlIGxp
a2UgaW50ZXJ2YWwgdGltZXMgdGhhbiB2YWxpZGl0eSB0aW1lcyB3aXRoIGRlZmF1bHQgcGFyYW1l
dGVycyAod2hpY2ggaXTigJlzIGVhc2llc3QgdG8gdXNlIGFzIGFuIGV4YW1wbGUpLiBJIHN1Z2dl
c3QgbXVsdGlwbHlpbmcgYnkgdGhyZWUuIEJ1dA0KIHRoZW4g4oCmPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF04oCZ
cyBhIGJhZCBwYXR0ZXJuIG9mIHZhbGlkaXR5IHRpbWVzLiBJdOKAmXMgbGVnYWwgdW5kZXIgNTQ5
NyAoSSB0aGluayksIGJ1dCBJIGRvbuKAmXQgaGF2ZSB0aGUgdGltZSByaWdodCBub3cgdG8gZGV0
ZXJtaW5lIGlmIGl0IHZpb2xhdGVzIGEgTVVTVCBvciBhIFNIT1VMRA0KIGZvciBPTFNSdjIuIEkg
dGhpbmsgaXQgZG9lcywgYnV0IGluIGFueSBjYXNlIGl04oCZcyBhIGJhZCBwYXR0ZXJuIHdlIGRv
buKAmXQgd2FudCB0byBzdWdnZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgYmVjYXVzZSB5b3UgY2Fu
4oCZdCBzZW5kIG1lc3NhZ2VzIGF0IHR3byBzZWNvbmQgaW50ZXJ2YWxzIHdpdGggYW55IHBhdHRl
cm4gb2YgaG9wIGxpbWl0cyB0aGF0IG1lYW5zIGVhY2ggbm9kZSBzZWVzIGEgcmVndWxhciBwYXR0
ZXJuIG9mIG1lc3NhZ2VzIHdpdGggYXBwcm9wcmlhdGUNCiBpbnRlcnZhbHMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5F
YXN5IGZpeCwgY2hhbmdlIHRoZSBzaXggdG8gZWlnaHQuIE9yIHdpdGggdGhlIHRyaXBsaW5nIHN1
Z2dlc3Rpb24gYWJvdmUsIDI0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbywgaXTigJlzIGEgYmFkIGV4YW1wbGUg
aW4gYW5vdGhlciB3YXkuIEl0IHN1Z2dlc3RzIHNlbmRpbmcgc29tZSBUQyBtZXNzYWdlcyBvbmx5
IG9uZSBob3AuIEJ1dCBvbmUgaG9wIFRDIG1lc3NhZ2VzIGFyZSBwcmV0dHkgdXNlbGVzcywgZXZl
cnl0aGluZyB5b3UgbmVlZA0KIGZyb20gdGhlbSBpcyBpbiBhIEhFTExPIG1lc3NhZ2UgLSB1bmxl
c3MgeW91IGhhdmUgYW55IGF0dGFjaGVkIG5ldHdvcmtzLiBUbyBhdm9pZCBwZW9wbGUgaGF2aW5n
IHRvIGdvIGRvd24gdGhhdCBjdWwgZGUgc2FjIChvbmUgaG9wLCB1c2VsZXNzLCB1bmxlc3MgYXR0
YWNoZWQgbmV0d29ya3MsIG5vdCBtZW50aW9uZWQpIEnigJlkIHVzZSB0d28sIHRocmVlIGFuZCBm
b3VyIGhvcHMgcmF0aGVyIHRoYW4gb25lLCB0d28gYW5kIHRocmVlLiAoTWlnaHQgbWVhbg0KIG90
aGVyIGNoYW5nZXMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2lu
ZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJy
Pg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUi
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7
PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i
PmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg
RXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFu
PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl
bGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBO
bzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwPioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
PGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0
aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg
eW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBm
cm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90
IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRp
c3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KjwvcD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D92413665GLKXM0002VGREEN_--


From nobody Tue Aug 30 02:15:20 2016
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBEB12D8DA for ; Tue, 30 Aug 2016 02:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.468
X-Spam-Level: 
X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 gBb96QVVeJfc for ; Tue, 30 Aug 2016 02:15:17 -0700 (PDT)
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 5EBD812D8DE for ; Tue, 30 Aug 2016 02:15:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,255,1470697200"; d="scan'208";a="103485550"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 30 Aug 2016 10:15:17 +0100
X-IronPort-AV: E=Sophos;i="5.30,255,1470697200"; d="scan'208";a="132242089"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 30 Aug 2016 10:15:16 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.250]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Tue, 30 Aug 2016 10:15:15 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] OLSRv2 sec threats review
Thread-Index: AQHSAa6Eho2jC7Np20WfxYqCvez/fqBhOoCQ
Date: Tue, 30 Aug 2016 09:15:15 +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: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [manet] OLSRv2 sec threats review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 09:15:19 -0000

QWxzbywgZHJhZnQtaWV0Zi1tYW5ldC1pYnMtMDUgaXMgUkZDIDc4NTkuDQoNCi0tIA0KQ2hyaXN0
b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDog
wqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v
bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cu
YmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0
ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJl
ZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZ
UA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp
ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl
Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUg
aXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90
IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJp
YnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK


From nobody Wed Aug 31 18:37:36 2016
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1094912D7E7; Wed, 31 Aug 2016 18:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 jWPy55_Mzhv7; Wed, 31 Aug 2016 18:37:32 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B743712D7E3; Wed, 31 Aug 2016 18:37:22 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id AFA10B80D13; Wed, 31 Aug 2016 18:37:22 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160901013722.AFA10B80D13@rfc-editor.org>
Date: Wed, 31 Aug 2016 18:37:22 -0700 (PDT)
Archived-At: 
Cc: drafts-update-ref@iana.org, manet@ietf.org, rfc-editor@rfc-editor.org
Subject: [manet] RFC 7939 on Definition of Managed Objects for the Neighborhood Discovery Protocol
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Sep 2016 01:37:34 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7939

        Title:      Definition of Managed Objects for 
                    the Neighborhood Discovery Protocol 
        Author:     U. Herberg, R. Cole,
                    I. Chakeres, T. Clausen
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2016
        Mailbox:    ulrich@herberg.name, 
                    rgcole01@comcast.net, 
                    ian.chakeres@gmail.com, 
                    T.Clausen@computer.org
        Pages:      72
        Characters: 140619
        Obsoletes:  RFC 6779

        I-D Tag:    draft-ietf-manet-rfc6779bis-07.txt

        URL:        https://www.rfc-editor.org/info/rfc7939

        DOI:        http://dx.doi.org/10.17487/RFC7939

This document replaces RFC 6779; it contains revisions and extensions
to the original document.  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 extensions described in this document add
objects and values to support the NHDP optimization specified in RFC
7466.  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.

This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC