From henning.rogge@fkie.fraunhofer.de Tue Apr 2 01:32:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552F621F988F for ; Tue, 2 Apr 2013 01:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zOZoMr2dAwJ for ; Tue, 2 Apr 2013 01:32:07 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1361421F9864 for ; Tue, 2 Apr 2013 01:32:07 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UMwdR-00054u-5x for manet@ietf.org; Tue, 02 Apr 2013 10:32:05 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UMwdR-00039v-3J for manet@ietf.org; Tue, 02 Apr 2013 10:32:05 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 2 Apr 2013 10:32:04 +0200 Message-ID: <515A977C.6050500@fkie.fraunhofer.de> Date: Tue, 2 Apr 2013 10:31:56 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090805060300050105000502" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.7/16942/Tue Apr 2 04:38:34 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Subject: Re: [manet] rfc6622-bis-01 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:32:08 -0000 --------------ms090805060300050105000502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/25/2013 10:01 PM, Justin Dean wrote: > Below I have included my comments in-line tagged with JD. The new TLV > subtype assignment confuses the issue of replacement of 6622. Are ther= e > situations where ICV TLVs with subtype 1 as defined in 6622 are > > more appropriate? My guess is No. In any case I shouldn't be guessing,= > so that should be made more clear. I think subtype 2 does only apply to RFC5444 messages that must not be=20 forwarded. The Source-IP of the UDP-packets forwarding the message do change every=20 hop, so OLSRv2 TCs (as an example) must use subtype 1. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090805060300050105000502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA0MDIwODMyMDJaMCMGCSqGSIb3DQEJBDEWBBRTONyPbWkdW7ynGRMRr6sxXV9PfjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEATNOacl9P/Rk1oc8eXTAAK/un12xS9ul30qVmp4Jj/9Gb fApQR1FFP8nSzN2tjqswiPO5LsbafLlhQ2L5oHVxyegAARb5WcQM5svvsbMywQrny9UnGCuX cO0mRdkWzMWavn41WsOBdJXWcw5QKSv2jI+gTFi4xw1GlTCPZ/LOn4YBDLxZy4xprJ2ehCVs 9QBeym/YSTtKmM15gN4Jz8E0Q7JvASm9FiOuEmXcXKWo6Pv5P0nfN8br3Xh4jOgjvObUx3Zq 0Gl7qVdai5pEXym8zrZbPLWdxyhEE8cC7eSmeULUHSK7tfYQ6WItK9UFv0OJJOJqvBUNAB41 LnxLy18lTwAAAAAAAA== --------------ms090805060300050105000502-- From henning.rogge@fkie.fraunhofer.de Tue Apr 2 04:33:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A7721F9800 for ; Tue, 2 Apr 2013 04:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfKtL4MrzDia for ; Tue, 2 Apr 2013 04:33:14 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4E321F97FC for ; Tue, 2 Apr 2013 04:33:13 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UMzSg-0006d6-Nc; Tue, 02 Apr 2013 13:33:10 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UMzSg-000814-Kt; Tue, 02 Apr 2013 13:33:10 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 2 Apr 2013 13:33:10 +0200 Message-ID: <515AC1EE.3040201@fkie.fraunhofer.de> Date: Tue, 2 Apr 2013 13:33:02 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> In-Reply-To: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010802030605040502000102" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.7/16944/Tue Apr 2 12:38:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d3ee2152a352ac5394ad35a39f99d059 Cc: Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:33:15 -0000 --------------ms010802030605040502000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Stan, here is a first review of DLEP-04. I plan to start an implementation of=20 this draft this month, so you will most likely get more comments during=20 this. > 3. Credits > > DLEP includes an OPTIONAL credit-windowing scheme analogous to the > one documented in [RFC5578]. In this scheme, traffic between the > router and modem is treated as two unidirectional windows. This > document identifies these windows as the "Modem Receive Window", or > MRW, and the "Router Receive Window", or RRW. > > If credits are used, they MUST be granted by the receiver on a given= > window - that is, on the "Modem Receive Window" (MRW), the modem is > responsible for granting credits to the router, allowing it (the > router) to send data to the modem. Likewise, the router is > responsible for granting credits on the RRW, which allows the modem > to send data to the router. > > DLEP expresses all credit data in number of octets. The total number= > of credits on a window, and the increment to add to a grant, are > always expressed as a 64-bit unsigned quantity. > > If used, credits are managed on a neighbor-specific basis; that is, > separate credit counts are maintained for each neighbor requiring th= e > service. Credits do not apply to the DLEP session that exists betwee= n > routers and modems. Two questions... first, we can have a credit window for multicast/broadcast too, right? second, can you tell me the motivation for the Receiving Credit Window?=20 I have not enough experience to argue for or against it, but it feels=20 strange. The transmission Credit Window is important to prevent a transmission=20 queue on the modem increasing the delay by buffering outgoing packets of = the router and to allow router based Quality of Service handling like=20 prioritization. But I am not sure what to do with the receiving window. > 6. Normal Session Flow > > At the start of a run, DLEP implementations (both router and modem) > initialize the communications path. In a UDP implementation, this > includes opening a socket and binding to the well-known port address= > (TBD). Once the communications path is established, modem > implementations are free to issue a "Peer Discovery" message. The > Peer Discovery MAY be sent either to the multicast address allocated= > for DLEP (TBD), or to a unicast address, obtained via a-priori > configuration. > > Routers receiving a Peer Discovery message respond with a "Peer > Offer" signal to indicate readiness to participate in the DLEP > > > > Ratliff et al. Expires September 26, 2013 [Page 10= ] > =0C > Internet-Draft DLEP March 201= 3 > > > session. The receiver of a Peer Offer message responds with a "Peer > Offer ACK" message, completing discovery. While the Peer Discovery > message MAY be sent to the DLEP multicast address (TBD), the Peer > Offer, and all subsequent traffic, is sent to the unicast address > that originated the Peer Discovery. Once the Peer Offer signal is > acknowledged, both participants (router and modem) transition to the= > "in session" state, creating a logical, stateful session between the= > modem and the router. Subsequent DLEP signals are then processed > within the context of this router/modem session. In the UDP-based > implementation, traffic between DLEP modems and routers is correlate= d > using the UDP 4-tuple (Source Address, Source Port, Destination > Address, Destination Port). DLEP partners use these signals to build= > their respective information bases regarding destinations that are > accessible via the modem, and link characteristics associated with > those destinations. This sounds reasonable. > 8. Generic DLEP Packet Definition > > The Generic DLEP Packet consists of a sequence of TLVs. The first TL= V > represents the signal being communicated (e.g., a "Neighbor Up", or = a > "Peer Offer"). Subsequent TLVs contain the data items pertinent to > the signal (e.g., Maximum Data Rate, or Latency, etc). > > The Generic DLEP Packet Definition contains the following fields: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Signal TLV Type | Length | DLEP data items... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Signal - One of the DLEP Signal TLV type values > defined in this document. > > Length - The length of all of the DLEP data items > associated with this signal. I would suggest increasing the length field to 2 octets. 256 bytes might = be not enough if someone deals with lots of metrics. The other option=20 might be to leave the length problem to the transport protocol and=20 assume DLEP can detect the length without putting it into its content=20 (by looking at the length of the UDP packet for example). We also need to add the sequence number field here (also 2 octets?). We=20 might also need sequence number fields/TLVs for each ACK message,=20 otherwise we should mention that the modem/radio and the router must use = "stop and wait" to transmit packets to each other. > 9. DLEP Data Items > > As mentioned earlier, DLEP protocol messages are transported as a > collection of TLVs. The first TLV present in a DLEP message MUST be > one of the Signal TLVs, documented in section [INSERT REFERENCE > HERE]. The signals are followed by one or more data items, indicatin= g > the specific changes that need to be instantiated in the receiver's > information base. Missing reference. > 9.10 Expected Forwarding Time > > The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item. > If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer > Discovery, and Peer Update messages to indicate the typical latency > between the arrival of a given packet at the transmitting device and= > the reception of the packet at the other end of the link. EFT > combines transmission time, idle time, waiting time, freezing time, > and queuing time to the degree that those values are meaningful to a= > given transmission medium. > > The Expected Forwarding Time TLV contains the following fields: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 4 | EFT (ms) = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | EFT (ms) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TLV Type - TBD > > Length - 4 > > EFT - A 32-bit unsigned number, representing the expected > forwarding time, in milliseconds, on the link. > > > 9.11 Latency > > The Latency TLV is an OPTIONAL data item. If supported, it is used i= n > Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, Link > Characteristics Request, and Link Characteristics ACK messages to > indicate the amount of latency on the link, or in the case of the > Link Characteristics Request, to indicate the maximum latency > required on the link. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 2 | Latency (ms) = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TLV Type - TBD > > Length - 2 Why can the EFT by much longer than the Latency? It might make sense to=20 give both fields a 4 octet value > 9.12 Resources (Receive) > > The Receive Resources TLV is an OPTIONAL data item. If supported, it= > is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update= , > and Link Characteristics ACK messages to indicate a percentage (0- > 100) amount of resources (e.g. battery power), committed to receivin= g > data, remaining on the originating peer. > 9.13 Resources (Transmit) > > The Transmit Resources TLV is an OPTIONAL data item. If supported, i= t > is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update= , > and Link Characteristics ACK messages to indicate a percentage (0- > 100) amount of resources (e.g. battery power), committed to > transmitting data, remaining on the originating peer. I think most devices will only have a single "resource" value for the=20 whole device... how do we signal this, just putting both resource TLVs=20 into the message with the same value? > 9.16 Status > > The Status TLV is sent as part of an acknowledgement message, from > either the modem or the router, to indicate the success or failure o= f > a given request. > > The Status TLV contains the following fields: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 1 | Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TLV Type - TBD > > Length - 1 > > Termination Code - 0 =3D Success, Non-zero =3D Failure. Specific val= ues > > > > Ratliff et al. Expires September 26, 2013 [Page 24= ] > =0C > Internet-Draft DLEP March 201= 3 > > > of a non-zero termination code depend on the > operation requested (e.g. Neighbor Up, > Neighbor Down, etc). Do we need an IANA registry for this values? I don't think the document=20 specified even a single failure value. > 9.17 Heartbeat Interval/Threshold =2E.. > The Heartbeat Interval/Threshold TLV contains the following fields: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 1 | Interval | Threshold = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TLV Type - TBD > > Length - 1 Length =3D 2 > 9.21 Credit Request > > The Credit Request TLV is an OPTIONAL TLV. If credits are supported,= > the Credit Request TLV MAY be sent from either DLEP participant, via= > a Neighbor Update signal, to indicate the desire for the partner to > grant additional credits in order for data transfer to proceed on th= e > session. If the corresponding Neighbor Up message for this session > did NOT contain a Credit Window Status TLV, indicating that credits > are to be used on the session, then the Credit Request TLV MUST be > rejected by the receiver via a Neighbor Update ACK message. > > The Credit Request TLV contains the following fields: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 0 | Reserved, MUST| > | | | be set to 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TLV Type - TBD > > > > > Ratliff et al. Expires September 26, 2013 [Page 28= ] > > Internet-Draft DLEP March 201= 3 > > > Length - 0 Alternative A: Length =3D 1 > Reserved - This field is currently unused and MUST be set to 0. Alternative B: drop this unused field > 10. DLEP Protocol Messages > > DLEP messages are encoded as a string of Type-Length-Value (TLV) > constructs. The first TLV in a DLEP message MUST be a valid DLEP > signal, as defined in section 11.1 of this document. The second TLV > MUST be the Identification data item, defined in section 10.1 > Following those two TLVs are 0 or more TLVs, representing the data > items that are appropriate for the signal. The layout of a DLEP > message is thus: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DLEP Signal |DLEP Message |Identification |Identification | > | Type value |length (9 + |TLV Type |TLV length | > | (value TBD) |optional TLVs) |(TBD) |(8) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Router ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Modem ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start of optional DLEP | > | TLVs... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > All DLEP messages (signals) begin with this structure. Therefore, in= > the following descriptions of specific messages, this header > structure is assumed, and will not be replicated. The DLEP Identification TLV has been dropped from this draft, so it=20 should be dropped from the protocol message description too. In fact, the whole chapter 10 could be dropped, we already described it=20 in chapter 8. Chapter 10.1 could become 8.1 (maybe). > 12. Peer Offer Message > > The Peer Offer Message is sent by a DLEP router in response to a Pee= r > Discovery Message. Upon receipt, and processing, of a Peer Offer > message, the modem MUST respond with a Peer Offer ACK message, > completing the discovery phase of DLEP. Both DLEP participants > (router and modem) would then enter an "in session" state. Any > subsequent Discovery messages sent or received on this session MUST > be considered an error, and the session MUST be terminated as if a > Peer Termination Message had been received. > > The Peer Offer message MUST be sent to the unicast address of the > originator of Peer Discovery, regardless of whether the discovery wa= s > received on the DLEP multicast address (TBD) or on a unicast > address. > > To construct a Peer Offer message, the initial TLV type value is set= > to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by > any OPTIONAL Data Item TLVs the implementation supports: > > Optional Data Item TLVs: > > - DLEP Version > - Peer Type > - IPv4 Address > - IPv6 Address > - Status > - Heartbeat Interval > - Heartbeat Threshold > - Link Characteristics ACK Timer What happens if the Modem/Radio receives a Peer Offer Message with a=20 Status with value not equals 0? I am not sure about the semantics here. > 13. Peer Offer ACK Message > > The Peer Offer ACK message acknowledges receipt of a Peer Offer > message, and completes the router/modem session establishment for > DLEP. The Peer Offer ACK message MUST be sent to unicast address of > the originator of a Peer Offer message. The Peer Offer ACK message > MUST contain an OPTIONAL Status data item, indicating success or > failure of the attempt to establish a router/modem session. "MUST contain a Status data item." The OPTIONAL should be removed, it contradicts the MUST. > To construct a Peer Offer ACK message, the initial TLV type value is= > set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's ar= e > placed into the packet next: > > Mandatory Data Item TLVs: > - Status > > Note that there are NO OPTIONAL data item TLVs specified for this I assume that a "Status value =3D 1" Peer Offer Ack will mean the=20 Modem/Radio rejects the Routers Peer Offer, right? > > Ratliff et al. Expires September 26, 2013 [Page 31= ] > =0C > Internet-Draft DLEP March 201= 3 > > > message. > > 14. Peer Update Message > > The Peer Update message is an OPTIONAL message, sent by a DLEP peer > to indicate local Layer 3 address changes, or for metric changes on = a > modem-wide basis. For example, addition of an IPv4 address to the > router would prompt a Peer Update message to its attached DLEP > modems. Also, a modem that changes its Maximum Data Rate for all > destinations MAY reflect that change via a Peer Update Message to it= s > attached router(s). > > Concerning Layer 3 addresses, if the modem is capable of > understanding and forwarding this information (via proprietary > mechanisms), the address update would prompt any remote DLEP modems > (DLEP-enabled modems in a remote node) to issue a "Neighbor Update" > message to their local routers with the new (or deleted) addresses. > Modems that do not track Layer 3 addresses SHOULD silently parse and= > ignore the Peer Update Message. Modems that track Layer 3 addresses > MUST acknowledge the Peer Update with a Peer Update ACK message. > Routers receiving a Peer Update with metric changes MUST apply the > new metric to all neighbors (remote nodes) accessible via the modem.= > Supporting implementations are free to employ heuristics to > retransmit Peer Update messages. The sending of Peer Update Messages= > for Layer 3 address changes SHOULD cease when a either participant > (router or modem) determines that the other implementation does NOT > support Layer 3 address tracking. Can we split this message into two? I think the semantics of the Routers Peer Update and the Modems/Radios=20 Peer Update is quite different. > 15. Peer Update ACK Message > > Optional Data Item TLVs: > - Status > 16. Peer Termination Message > > Optional Data Item TLVs: > - Status > > 17. Peer Termination ACK Message > Optional Data Item TLVs: > - Status I assume that the receiver of this three messages is allowed to ignore=20 the value of the Status TLV? > 19. Neighbor Up ACK Message > > Optional Data Item TLVs: > - Credit Window Status No optional Status TLV for this one? > 21. Neighbor Down ACK Message > > A DLEP participant sends the Neighbor Down ACK Message to indicate > whether a received Neighbor Down Message was successfully processed.= > If successfully processed, the sender of the ACK MUST have removed > all entries in the information base that pertain to the referenced > neighbor. As with the Neighbor Down message, there are NO OPTIONAL > Data Item TLVs defined for the Neighbor Down ACK message. > > To construct a Neighbor Down message, the initial TLV type value is > set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The mandatory data item > TLVs follow: > > - MAC Address Data item > - Status data item Status data item should be optional? > 25. Link Characteristics ACK Message > > After placing the mandatory data item TLV into the packet, the > implementation would place any supported OPTIONAL data item TLVs. > Possible OPTIONAL data item TLVs are: > > Current Data Rate - If present, this value represents the requeste= d > data rate in bits per second (bps). > > Latency - If present, this value represents the NEW > maximum latency (or unchanged, if the request > is denied), expressed in milliseconds, on the > link. No optional Status TLV for this one? Thats all for now... Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010802030605040502000102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA0MDIxMTMzMDhaMCMGCSqGSIb3DQEJBDEWBBTfBrhtWt4fPJIZ1RfMrXFit5M5IDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAe+l1DQmi1KZSXHAA2t+7kC8QkeypIEs64EcGH9wHnx8g 3QtnCHKqPV8Y83ydRVSChrXA3XpBmxa2qMLl7QndQ8B3mJxC/S9FEqtBe0iXOWDUKVCunOlQ 9NofpWN17RpI5pL+oR/EJQeA1x1S2wMEheYIud89Nk6Y+70ffYSdoPRR83v3L59mJotmmxHR B1OdxLN1HVeJfYd8MoGg3RqVe4Lb2Ux25dCHYNDEVatN5GGO0hrmGNUS/s5gLQyn6g3viyxQ Ry0tf7WY7BIZnF1gyqzuYMm3a+sAYPHwMDOA6RNwvXcSf/AlTPG/2Z/qqWv0bc4DdiQiSOpL vgqxOp62VAAAAAAAAA== --------------ms010802030605040502000102-- From iesg-secretary@ietf.org Tue Apr 2 09:19:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5F21F8B16; Tue, 2 Apr 2013 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9b5idi4vvpZ; Tue, 2 Apr 2013 09:19:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B416121F8C0C; Tue, 2 Apr 2013 09:19:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402161903.21105.87248.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 09:19:03 -0700 Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'The Optimized Link State Routing Protocol version 2' to Proposed Standard (draft-ietf-manet-olsrv2-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:19:05 -0000 The IESG has approved the following document: - 'The Optimized Link State Routing Protocol version 2' (draft-ietf-manet-olsrv2-19.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ Technical Summary This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link-state information. A secondary optimization is that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. Working Group Summary o OLSRv2 is the routing protocol, which uses as constituent parts (and from which was spun off) the already published by the MANET Working Group RFCs 5148, 5444, 5497, and 6130. The document also uses RFC 5498 - also already published by the MANET Working Group. This document is, therefore, an integral part of the Working Group deliverables, and its publication completes the charter item of a "proactive MANET protocol". o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This version of OLSRv2 was given a one month WGLC, so as to ensure sufficient time to review the document. o The Working Group is actively working on the associated MIB document (draft-ietf-manet-olsrv2-mib) There was an issue concerning the differences between the -14 and -15 revisions of the document, brought up by one WG member. The consensus opinion from the WG is that the document should proceed, without additional edits. Document Quality There is a number of independent implementations of OLSRv2. Those listed below have, explicitly, consented to be nominatively mentioned: o Ecole Polytechnique, France (Contact: Thomas Clausen) o CRC - Communications Research Centre Canada (Contact: Yannick Lacharite) o INRIA, France (Contact: Cedric Adjih) o Hitachi Yokohama Research Lab, Japan (Contact: Hiroki Satoh) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) o Fraunhofer FKIE is working on the olsr.org implementation of OLSRv2 (Contact: Henning Rogge) o Niigata University, Japan http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ (Contact: Hiroei Imai) Over the years, several interoperability events have been organized, in France, Canada, Japan, Austria, .... Personnel The Document Shepherd is Stan Ratliff (sratliff@cisco.com) The Responsible AD is Adrian Farrel (adrian@olddog.co.uk) From iesg-secretary@ietf.org Tue Apr 2 09:19:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94A21F8BA6 for ; Tue, 2 Apr 2013 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI4+Kh4BZR9p; Tue, 2 Apr 2013 09:19:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C504B21F8C83; Tue, 2 Apr 2013 09:19:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-manet-olsrv2 X-IETF-Draft-revision: 19 Message-ID: <20130402161903.21105.3077.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 09:19:03 -0700 Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'The Optimized Link State Routing Protocol version 2' to Proposed Standard (draft-ietf-manet-olsrv2-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:19:05 -0000 The IESG has approved the following document: - 'The Optimized Link State Routing Protocol version 2' (draft-ietf-manet-olsrv2-19.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ Technical Summary This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link-state information. A secondary optimization is that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. Working Group Summary o OLSRv2 is the routing protocol, which uses as constituent parts (and from which was spun off) the already published by the MANET Working Group RFCs 5148, 5444, 5497, and 6130. The document also uses RFC 5498 - also already published by the MANET Working Group. This document is, therefore, an integral part of the Working Group deliverables, and its publication completes the charter item of a "proactive MANET protocol". o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This version of OLSRv2 was given a one month WGLC, so as to ensure sufficient time to review the document. o The Working Group is actively working on the associated MIB document (draft-ietf-manet-olsrv2-mib) There was an issue concerning the differences between the -14 and -15 revisions of the document, brought up by one WG member. The consensus opinion from the WG is that the document should proceed, without additional edits. Document Quality There is a number of independent implementations of OLSRv2. Those listed below have, explicitly, consented to be nominatively mentioned: o Ecole Polytechnique, France (Contact: Thomas Clausen) o CRC - Communications Research Centre Canada (Contact: Yannick Lacharite) o INRIA, France (Contact: Cedric Adjih) o Hitachi Yokohama Research Lab, Japan (Contact: Hiroki Satoh) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) o Fraunhofer FKIE is working on the olsr.org implementation of OLSRv2 (Contact: Henning Rogge) o Niigata University, Japan http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ (Contact: Hiroei Imai) Over the years, several interoperability events have been organized, in France, Canada, Japan, Austria, .... Personnel The Document Shepherd is Stan Ratliff (sratliff@cisco.com) The Responsible AD is Adrian Farrel (adrian@olddog.co.uk) From adrian@olddog.co.uk Tue Apr 2 13:46:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2291421F8DFB for ; Tue, 2 Apr 2013 13:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9+oCMCAzB9b for ; Tue, 2 Apr 2013 13:46:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 38AA921F8DAC for ; Tue, 2 Apr 2013 13:46:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32Kkggc027766; Tue, 2 Apr 2013 21:46:42 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32KkfLf027760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 21:46:42 +0100 From: "Adrian Farrel" To: Date: Tue, 2 Apr 2013 21:46:43 +0100 Message-ID: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4v4yzENGA+eUaDR7+5Fm27idIJzA== Content-Language: en-gb Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-olsrv2-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:46:45 -0000 Thanks for your work on this document, and sorry for the long time it has taken me to review it. It looks like you have done a really thorough job - I can normally pick a few holes in a MIB I think the only big question we are going to get (again) is about the level of write (and create) access. Do you think that it would be helpful to add an Informational reference to draft-nguyen-manet-management-00 and some discussion in the document about why you have some level of write access? Maybe this is just a little more text in Section 9. I think you should think about this while I run the IETF last call. That will attract an OPS Dir review that may dwell on the point further. --- My other comments are quite small and can all be taken as IETF last call comments to be fixed later... The RFC Editor might become confused by the different uses of "XXXX" in the document. It would be worth sorting them out just to make life easier. --- Tiny point... In olsrv2AHoldTime you have... a value = 3 x olsrv2TcInterval is recommended. But in draft-ietf-manet-olsrv2-15 you have a value >= 3 x TC_INTERVAL is RECOMMENDED. --- I think olsrv2LinkMetricType needs to be mentioned in Section 8 because, according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences of a change are quite significant. --- Possibly just me being puzzled: Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be limited to Integer32 (0..65535)? I agree that larger would be a great validation of OLSRv2, but I wondered how quickly we might reach that threshold. Ditto olsrv2TibRouterTopologySetIndex --- Cheers, Adrian From yi.jiazi@gmail.com Tue Apr 2 13:56:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2121F87D1 for ; Tue, 2 Apr 2013 13:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp+AD6G6Rrkq for ; Tue, 2 Apr 2013 13:56:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C951C21F8D0F for ; Tue, 2 Apr 2013 13:56:23 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so877052wid.11 for ; Tue, 02 Apr 2013 13:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=nhJ2Zw79yTOZdwZWh7WzBu+obxOSVBzVZA2NgguuMao=; b=iyYMcOQmzf0p1piXYI9gURZIfZ872n8KAEBuQy0QNR5ID9bRXOITGvJgObOEPy3Epx /UygyJ+4LFnXeBsdtHu3c2FFGQrHqpPexZBJMsCHJu0neF/iSyZZGqnl3MQ2jYu1Z2oF kVTROJg37uXqo3aSckyStppXjxXAEt0W2HLJH51JgX9wl6QPG541Dll4R/92Wi6R34rQ kQtcJfNu9IkJGgWPzusDWs+v052/onINP2y4Hc33nNE8OoI9aUeRSV4M/yM1voNltG6J 3ZMUKy9VgtW+PzBqEUpPIeHQy39YSkuZPtaHiaZ6s83XT+buCF3wSJ5MH586CJ02RtA9 NLHw== X-Received: by 10.194.86.234 with SMTP id s10mr24621980wjz.34.1364936182814; Tue, 02 Apr 2013 13:56:22 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id gl11sm21161736wic.8.2013.04.02.13.56.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 13:56:22 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <1364740656964-363492.post@n7.nabble.com> Date: Tue, 2 Apr 2013 22:56:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364740656964-363492.post@n7.nabble.com> To: Ahmed A. Elawamry X-Mailer: Apple Mail (2.1503) Cc: manet@ietf.org Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:56:24 -0000 Hi,=20 I'm not sure what's your definition of "topology discovery" and "data = collection cycle".=20 The control plan of LOADng is about "find the desired routes on demand". = The data plan/forwarding has no significant difference with other = routing protocols - it's simply hop-by-hop IP forwarding. The only = difference is that if there is no available route, LOADng needs to = trigger a route discovery (normal routing protocol do "best effort").=20 best Jiazi On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry = wrote: > Hello All, >=20 > I'm new to the MANET working group but i am following the mailing list > regarding the LOADng protocol. As mentioned at the LOADng drafts that = it is > a reactive routing protocol extracted from the AODV; Thus, it has two = cycles > (topology discovery and data collection cycle). Most of the = discussions and > results are about the topology discovery cycle but i didn't found the > corresponding results at the data collection cycle as you know that = the most > iterative operation is the data collection cycle not topology = discovery. Are > there any justification about that?! >=20 > Thanks, > Ahmed A. Elawamry >=20 >=20 >=20 > -- > View this message in context: = http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html > Sent from the IETF - manet mailing list archive at Nabble.com. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Tue Apr 2 14:03:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C599B21F8B16 for ; Tue, 2 Apr 2013 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAvWHBrHTaJB for ; Tue, 2 Apr 2013 14:03:54 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id B5E3E21F8BBA for ; Tue, 2 Apr 2013 14:03:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32L3qOH023410; Tue, 2 Apr 2013 22:03:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32L3pwp023399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 22:03:52 +0100 From: "Adrian Farrel" To: References: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> In-Reply-To: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> Date: Tue, 2 Apr 2013 22:03:52 +0100 Message-ID: <04c701ce2fe5$95082bc0$bf188340$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHFFr3EKr0BpdW5/JEhJPoIRcLNlJjVnDAA Content-Language: en-gb Cc: manet@ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-olsrv2-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:03:54 -0000 Ooops, I just ran idnits. Looks like the references are in a bit of a mess as well. [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsr-17 (work in progress), October 2012. *** should read draft-ietf-manet-olsrv2 Do you really need a normative reference to RFC 3781? This is a Downref (which we can handle if necessary), but I don't see why it is referenced. Because these both show as Downrefs, and because Downrefs get called out in IETF last call, I need an answer to these points before I can go forward. If answering them involves respinning the document, then it would be good to pick up the other points as well. Thanks, Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 02 April 2013 21:47 > To: draft-ietf-manet-olsrv2-mib@tools.ietf.org > Cc: manet@ietf.org > Subject: [manet] AD review of draft-ietf-manet-olsrv2-mib > > Thanks for your work on this document, and sorry for the long time it > has taken me to review it. It looks like you have done a really > thorough job - I can normally pick a few holes in a MIB > > I think the only big question we are going to get (again) is about the > level of write (and create) access. Do you think that it would be > helpful to add an Informational reference to > draft-nguyen-manet-management-00 and some discussion in the document > about why you have some level of write access? Maybe this is just a > little more text in Section 9. > > I think you should think about this while I run the IETF last call. > That will attract an OPS Dir review that may dwell on the point further. > > --- > > My other comments are quite small and can all be taken as IETF last call > comments to be fixed later... > > > > The RFC Editor might become confused by the different uses of "XXXX" > in the document. It would be worth sorting them out just to make life > easier. > > --- > > Tiny point... > > In olsrv2AHoldTime you have... > a value = 3 x olsrv2TcInterval is > recommended. > But in draft-ietf-manet-olsrv2-15 you have > a value >= 3 x > TC_INTERVAL is RECOMMENDED. > > --- > > I think olsrv2LinkMetricType needs to be mentioned in Section 8 because, > according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences > of a change are quite significant. > > --- > > Possibly just me being puzzled: > > Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be > limited to Integer32 (0..65535)? I agree that larger would be a great > validation of OLSRv2, but I wondered how quickly we might reach that > threshold. > > Ditto olsrv2TibRouterTopologySetIndex > > --- > > Cheers, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ahmed_awamry_86@yahoo.com Wed Apr 3 13:42:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01A121F8E77 for ; Wed, 3 Apr 2013 13:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XEryT68tITU for ; Wed, 3 Apr 2013 13:42:35 -0700 (PDT) Received: from nm24-vm2.bullet.mail.ne1.yahoo.com (nm24-vm2.bullet.mail.ne1.yahoo.com [98.138.91.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0444521F8E63 for ; Wed, 3 Apr 2013 13:42:34 -0700 (PDT) Received: from [98.138.226.177] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 03 Apr 2013 20:42:34 -0000 Received: from [98.138.88.233] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 03 Apr 2013 20:42:34 -0000 Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 03 Apr 2013 20:42:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 609046.47750.bm@omp1033.mail.ne1.yahoo.com Received: (qmail 9120 invoked by uid 60001); 3 Apr 2013 20:42:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365021754; bh=elnHxC4e/Cwaut/qmAxs47Ubio7OYsKcsbkSa8CnlB4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wlkcuYuZkLjZjA9AY0LuyesD/abFV89lHCAsyBjXz97BDCHk5X8/jjezzUdPEhrzHbZ9/rgkrlR1YFzcAM3HRHxSfSjtg7vp+pDxfYSUHV5KMYKzuxJcdJGg4uNPLfbpWWf+u1G4hwaEswiorJJZK1uN4Y98uonv5G9IlE0B3Nw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dvoIfY5418FQDtI2VEcZZ3Jhp2HbOdr3VbOoChTKFLSrW7hkTMxq6h/HdXvQIFPJJimmEy8l5JtK/hMGAQsNjJwqkSSwLZnOd983Zrgt6aEyeG3q2pZifAwGn9VEN+KfqMcCXgjn1j4XT+1fO4Q7OE+OSM1/SpsPfGmx62GpTKo=; X-YMail-OSG: 15TfaP0VM1ki0Vit1Pm7sogmQgiYbwACkh0zPSCZLsqvF27 AF6g_xLvQczTcOC8nkjEVAdzlT2jVDzC8X50j6c4ufK.YqKq7T.PXsULExf4 EN4YxjzaLKmiH6EnsUtnbKctMQKT2ThGU61kMsAz3t9XCWWQSbKWFWWHwMQv 6rBhMjW0hX8EMKU5y8DO3UKFK2D6Bitd_J9RnRbf5qEdCkjrhebCiugtHgld Ygk1BTY3U9RNNmVQjD4Q41tOE2xt8azsDr2eLPsk442VlC4XWaKX1GgRdvmM gYwe9mEc5CIb8UXr4GjBphGlx5Cgx8j8XFQDxwTTPsMG9LLP2YoCWNzMqVSn Bj4HGCwZXFS5RQ1q_kcgZT7h_5CribM72snm8jf6MtM2k3Fy.c.5ffq.MsM9 GSuoE4kX4aoXdqtOlMn_ZH9mcY4BCzWm0l1Dzh7ELkfeh46NE191FBIm7H.e denBs_.kFjCG_23UMyj53LqrRMQQ0OqJg26wYRq_r1NMiTxTSFt.sFY14zyR vd1aox9Hewmp63bIsSWNVXzAFtRHxyOgHIT7Rt.4qLhv3F2FbA.lljpzDL7v pQQC7SoKdIKfp6QqsLhsDE7J4tPqWdTKJOpdGvGykVCeM.wjhmLMLxSJgJQo 74_X1vYt19oyP_7k8k19EseZPGPknnf8BUvpLk3qwkobVJh5VlO9J2kSuz7M U5vi3NDg7Tz_FGIPtIJ16isGCDzu1x7HUaNZiDr8mxvmsXdrF.02OllJgPkG VZqKB0k7IERU- Received: from [217.55.72.253] by web122302.mail.ne1.yahoo.com via HTTP; Wed, 03 Apr 2013 13:42:34 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpUaGFuayB5b3UgZm9yIHlvdXIgYW5zd2VyLiBJIG1lYW4gYnkgdG9wb2xvZ3kgZGlzY292ZXJ5IHRoYXQgZmluZGluZyByb3V0ZXMgdG8gdGhlIHJlcXVpcmVkIGRlc3RpbmF0aW9uIChjb25zdHJ1Y3Rpbmcgcm91dGluZyB0YWJsZSkuIEFzIHlvdSBrbm93LCB0aGlzIHBoYXNlIGlzIGltcGxlbWVudGVkIG9uIGRlbWFuZCBhbmQgaW4gY2FzZSBvZiBSRVJSLiBJIHdhbnQgdG8gbWVudGlvbiB0aGF0IHRoZSBkYXRhIGNvbGxlY3Rpb24gY3ljbGUgaXMgcmVwZWF0ZWQgYSBsb3Qgb2YgdGltZXMgKGZvciABMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <1364740656964-363492.post@n7.nabble.com> Message-ID: <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> Date: Wed, 3 Apr 2013 13:42:34 -0700 (PDT) From: AHMED AWAMRY To: Jiazi Yi In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1800448838-1766753598-1365021754=:6552" Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: AHMED AWAMRY List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 20:42:35 -0000 --1800448838-1766753598-1365021754=:6552 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AThank you for your answer. I mean by topology discovery that findi= ng routes to the required destination (constructing routing table). As you = know, this phase is implemented on demand and in case of RERR. I want to me= ntion that the data collection cycle is repeated a lot of times (for exampl= e if there will be a session between two nodes) so, it's good to mention th= e results and the test cases regarding the data collection cycle because it= will be very effective measurement=A0 for the routing protocol behavior.= =0A=0A=0A=0A=A0Thanks,=0AAhmed A. Elawamry,=0A=0A=0AFrom: Jiazi Yi =0ATo: Ahmed A. Elawamry =0ACc: manet= @ietf.org =0ASent: Tuesday, April 2, 2013 10:56 PM=0ASubject: Re: [manet] L= OADng Data Collection Cycle=0A =0AHi, =0A=0AI'm not sure what's your defini= tion of "topology discovery" and "data collection cycle". =0AThe control pl= an of LOADng is about "find the desired routes on demand". The data plan/fo= rwarding has no significant difference with other routing protocols - it's = simply hop-by-hop IP forwarding. The only difference is that if there is no= available route, LOADng needs to trigger a route discovery (normal routing= protocol do "best effort"). =0A=0Abest=0A=0AJiazi=0A=0AOn Mar 31, 2013, at= 4:37 PM, Ahmed A. Elawamry wrote:=0A=0A> Hello= All,=0A> =0A> I'm new to the MANET working group but i am following the ma= iling list=0A> regarding the LOADng protocol. As mentioned at the LOADng dr= afts that it is=0A> a reactive routing protocol extracted from the AODV; Th= us, it has two cycles=0A> (topology discovery and data collection cycle). M= ost of the discussions and=0A> results are about the topology discovery cyc= le but i didn't found the=0A> corresponding results at the data collection = cycle as you know that the most=0A> iterative operation is the data collect= ion cycle not topology discovery. Are=0A> there any justification about tha= t?!=0A> =0A> Thanks,=0A> Ahmed A. Elawamry=0A> =0A> =0A> =0A> --=0A> View t= his message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection= -Cycle-tp363492.html=0A> Sent from the IETF - manet mailing list archive at= Nabble.com.=0A> _______________________________________________=0A> manet = mailing list=0A> manet@ietf.org=0A> https://www.ietf.org/mailman/listinfo/m= anet --1800448838-1766753598-1365021754=:6552 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you = for your answer. I mean by topology discovery that finding routes to the re= quired destination (constructing routing table). As you know, this phase is= implemented on demand and in case of RERR. I want to mention that the data= collection cycle is repeated a lot of times (for example if there will be = a session between two nodes) so, it's good to mention the results and the t= est cases regarding the data collection cycle because it will be very effec= tive measurement  for the routing protocol behavior.


 Thanks,
Ahmed A. Elawamry,

From: Jiazi Yi = <ietf@jiaziyi.com>
To: Ahmed A. Elawamry <ahmed_awamry_86@yahoo.com>
Cc: manet@ietf.org
Sent: Tuesday, April 2, 2013 10:56 PM Subject: Re: [manet] LOA= Dng Data Collection Cycle

=0AHi,

I'm not sur= e what's your definition of "topology discovery" and "data collection cycle= ".
The control plan of LOADng is about "find the desired routes on dema= nd". The data plan/forwarding has no significant difference with other rout= ing protocols - it's simply hop-by-hop IP forwarding. The only difference i= s that if there is no available route, LOADng needs to trigger a route disc= overy (normal routing protocol do "best effort").

best

Jiazi=

On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry <a= hmed_awamry_86@yahoo.com> wrote:

> Hello All,
>
= > I'm new to the MANET working group but i am following the mailing list=
> regarding the LOADng protocol. As mentioned at the LOADng drafts t= hat it is
> a reactive routing protocol extracted from the AODV; Thus= , it has two cycles
> (topology discovery and data collection cycle). Most of the discussions and
> results ar= e about the topology discovery cycle but i didn't found the
> corresp= onding results at the data collection cycle as you know that the most
&g= t; iterative operation is the data collection cycle not topology discovery.= Are
> there any justification about that?!
>
> Thanks,<= br>> Ahmed A. Elawamry
>
>
>
> --
> Vie= w this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collect= ion-Cycle-tp363492.html
> Sent from the IETF - manet mailing list arc= hive at Nabble.com.> _______________________________________________
> manet mailing= list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

<= br>
--1800448838-1766753598-1365021754=:6552-- From yi.jiazi@gmail.com Thu Apr 4 02:49:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30521F9647 for ; Thu, 4 Apr 2013 02:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeibwDR+mE7p for ; Thu, 4 Apr 2013 02:49:58 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8E21F9644 for ; Thu, 4 Apr 2013 02:49:53 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so492327wiw.2 for ; Thu, 04 Apr 2013 02:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=1MTZ0TAvOswihXPRu0y4oediljnxx3V6IJpOHkJudxA=; b=HIgYp+VTOfiUfEU0MInPmBl0D1X5bbQQfJKIfbgQQ2sC6CfxkwPqTwfkngkosAKY+8 j7jt3Dx1M9V/7seV7zhbwmZvSwGXowKYTs6Rqs17gI88f2Z6p347yOYjZnKp6TYKqR7b WQMIacm5O2xB7vVeflRxnfcw7i37S2sgw/Rg4vtdH+e5eQqSIRN8SHJGTTAK1v4HfVbG Pj2XCwgFc7gJqgDQjvpluvsZsSZxxwvOb6OrD3LA+/KogWej1KjCQnS/suY7Qw7d7N0Q 3lrjrSfxkCXuJW8Wkkmp7WqmCbrL6rOjVgSf9T3KNlj0fLLkEdsSkYQkTkkqtHO3+Qb7 1Yqg== X-Received: by 10.180.72.228 with SMTP id g4mr28444673wiv.22.1365068992434; Thu, 04 Apr 2013 02:49:52 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bj9sm30003941wib.4.2013.04.04.02.49.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 02:49:51 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> Date: Thu, 4 Apr 2013 11:49:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> To: AHMED AWAMRY X-Mailer: Apple Mail (2.1503) Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:49:59 -0000 Hi,=20 I would be careful when talking about "session" in the network layer. I = think you are more talking about data transmission between two = nodes(routers)? In fact, there have been several publications about the performance of = LOADng and its extensions. More publications are in the pipeline.=20 Please check: LOADng: Towards AODV Version 2 IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Conference Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere = http://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID11410= 82.PDF Smart Route Request for On-demand Route Discovery in Constrained = Environments IEEE ICWITS 2012, IEEE International Conference on Wireless Information = Technology and Systems Jiazi Yi, Thomas Clausen, Antonin Bas = http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb= 00ae8ff62c37d68175.pdf Efficient Data Acquisition in Sensor Networks:Introducing (the) LOADng = Collection Tree Protocol IEEE WiCom 2012, The 8th IEEE International Conference on Wireless Communications, Networking and Mobile Computing. Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere = http://hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71= a44d49330f9d2e4ee5.pdf Expanding Ring Search for Route Discovery in LOADng Routing Protocol The 1st International Workshop on Smart Technologies for Energy, = Information and Communication Antonin Bas, Jiazi Yi, Thomas Clausen = http://hipercom.thomasclausen.net/resteam/data/publications/0c54e160b9e3ab= a9e7c383f64c1fda03.pdf There is also a draft about interop test of LOADng: Experience with the LOADng routing protocol for LLNs T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, SATOH. = H. Y. Morii = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= best Jiazi On Apr 3, 2013, at 10:42 PM, AHMED AWAMRY = wrote: > Hi, >=20 > Thank you for your answer. I mean by topology discovery that finding = routes to the required destination (constructing routing table). As you = know, this phase is implemented on demand and in case of RERR. I want to = mention that the data collection cycle is repeated a lot of times (for = example if there will be a session between two nodes) so, it's good to = mention the results and the test cases regarding the data collection = cycle because it will be very effective measurement for the routing = protocol behavior. >=20 >=20 > Thanks, > Ahmed A. Elawamry, >=20 > From: Jiazi Yi > To: Ahmed A. Elawamry =20 > Cc: manet@ietf.org=20 > Sent: Tuesday, April 2, 2013 10:56 PM > Subject: Re: [manet] LOADng Data Collection Cycle >=20 > Hi,=20 >=20 > I'm not sure what's your definition of "topology discovery" and "data = collection cycle".=20 > The control plan of LOADng is about "find the desired routes on = demand". The data plan/forwarding has no significant difference with = other routing protocols - it's simply hop-by-hop IP forwarding. The only = difference is that if there is no available route, LOADng needs to = trigger a route discovery (normal routing protocol do "best effort").=20 >=20 > best >=20 > Jiazi >=20 > On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry = wrote: >=20 > > Hello All, > >=20 > > I'm new to the MANET working group but i am following the mailing = list > > regarding the LOADng protocol. As mentioned at the LOADng drafts = that it is > > a reactive routing protocol extracted from the AODV; Thus, it has = two cycles > > (topology discovery and data collection cycle). Most of the = discussions and > > results are about the topology discovery cycle but i didn't found = the > > corresponding results at the data collection cycle as you know that = the most > > iterative operation is the data collection cycle not topology = discovery. Are > > there any justification about that?! > >=20 > > Thanks, > > Ahmed A. Elawamry > >=20 > >=20 > >=20 > > -- > > View this message in context: = http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html > > Sent from the IETF - manet mailing list archive at Nabble.com. > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 From yi.jiazi@gmail.com Thu Apr 4 03:14:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA5321F9632 for ; Thu, 4 Apr 2013 03:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=3.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgaKO+8c80Vy for ; Thu, 4 Apr 2013 03:14:57 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F50C21F9622 for ; Thu, 4 Apr 2013 03:14:57 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so2467474wgh.21 for ; Thu, 04 Apr 2013 03:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=No0PwgB01ut2P3ihkOpSetR8P3lbKUfutS7bMAeBYrM=; b=nfCP9X+wR6C76pK4vM5DNq0gYT+bKjBbeS62fDEVyZTGuVhGCqMu0YmD9O/isRErbN sru1o01LtEUWcY1eL76n8qtDOo7nyOhHnSBQdpYeoGR81/5UnPxp+cutKJK2Ug3iaBAu G4GyjB1SWymyCeOSbygNBjNgiVirwYm4jVivGppkz288LYE+7/kP60hPxF3WWg22fTHx neWz1KX2EPJw+T4COPBmZYtJdXo53RVWRLyZx47q36BimuSz/jnCJmLXfnlOsuurwuYC RxvRnOC/hTvMy3zUwQPrB6rCaUFZwlQvYjTXtkfr0bpMTuKIzwmfShVLBswkqa3m+qp/ rpRQ== X-Received: by 10.180.77.66 with SMTP id q2mr8251872wiw.13.1365070496068; Thu, 04 Apr 2013 03:14:56 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id du2sm30168289wib.0.2013.04.04.03.14.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 03:14:55 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: Date: Thu, 4 Apr 2013 12:14:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> To: AHMED AWAMRY X-Mailer: Apple Mail (2.1503) Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:14:58 -0000 Hi Ahmed,=20 There is one important thing that I have to mention: some of those = publications introduce different options/extensions of LOADng, but most = of them are not part of LOADng draft (yet).=20 This is generally because of the fundamental difference between = scientific publications and IETF Internet Draft (especially standard = track draft): o The scientific publications is to investigate new approaches, and = explore *possible* ideas that can be introduced to an Internet Draft.=20 o The IETF Internet Draft is to document clear, simple, and = well-understood technical approaches that can be implemented in the real = world.=20 Therefore, for LOADng, while we are keeping exploring new ideas and = options, those options won't exist in the IETF draft until we are sure = that they can serve the real world (based on more operational = experiences and tests in different scenarios).=20 best Jiazi On Apr 4, 2013, at 11:49 AM, Jiazi Yi wrote: > Hi,=20 >=20 > I would be careful when talking about "session" in the network layer. = I think you are more talking about data transmission between two = nodes(routers)? >=20 > In fact, there have been several publications about the performance of = LOADng and its extensions. More publications are in the pipeline.=20 > Please check: >=20 > LOADng: Towards AODV Version 2 > IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Conference > Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere > = http://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID11410= 82.PDF >=20 > Smart Route Request for On-demand Route Discovery in Constrained = Environments > IEEE ICWITS 2012, IEEE International Conference on Wireless = Information Technology and Systems > Jiazi Yi, Thomas Clausen, Antonin Bas > = http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb= 00ae8ff62c37d68175.pdf >=20 > Efficient Data Acquisition in Sensor Networks:Introducing (the) LOADng = Collection Tree Protocol > IEEE WiCom 2012, The 8th IEEE International Conference on Wireless > Communications, Networking and Mobile Computing. > Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere > = http://hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71= a44d49330f9d2e4ee5.pdf >=20 > Expanding Ring Search for Route Discovery in LOADng Routing Protocol > The 1st International Workshop on Smart Technologies for Energy, = Information and Communication > Antonin Bas, Jiazi Yi, Thomas Clausen > = http://hipercom.thomasclausen.net/resteam/data/publications/0c54e160b9e3ab= a9e7c383f64c1fda03.pdf >=20 >=20 > There is also a draft about interop test of LOADng: >=20 > Experience with the LOADng routing protocol for LLNs > T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, = SATOH. H. Y. Morii > = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= >=20 > best >=20 > Jiazi >=20 > On Apr 3, 2013, at 10:42 PM, AHMED AWAMRY = wrote: >=20 >> Hi, >>=20 >> Thank you for your answer. I mean by topology discovery that finding = routes to the required destination (constructing routing table). As you = know, this phase is implemented on demand and in case of RERR. I want to = mention that the data collection cycle is repeated a lot of times (for = example if there will be a session between two nodes) so, it's good to = mention the results and the test cases regarding the data collection = cycle because it will be very effective measurement for the routing = protocol behavior. >>=20 >>=20 >> Thanks, >> Ahmed A. Elawamry, >>=20 >> From: Jiazi Yi >> To: Ahmed A. Elawamry =20 >> Cc: manet@ietf.org=20 >> Sent: Tuesday, April 2, 2013 10:56 PM >> Subject: Re: [manet] LOADng Data Collection Cycle >>=20 >> Hi,=20 >>=20 >> I'm not sure what's your definition of "topology discovery" and "data = collection cycle".=20 >> The control plan of LOADng is about "find the desired routes on = demand". The data plan/forwarding has no significant difference with = other routing protocols - it's simply hop-by-hop IP forwarding. The only = difference is that if there is no available route, LOADng needs to = trigger a route discovery (normal routing protocol do "best effort").=20 >>=20 >> best >>=20 >> Jiazi >>=20 >> On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry = wrote: >>=20 >>> Hello All, >>>=20 >>> I'm new to the MANET working group but i am following the mailing = list >>> regarding the LOADng protocol. As mentioned at the LOADng drafts = that it is >>> a reactive routing protocol extracted from the AODV; Thus, it has = two cycles >>> (topology discovery and data collection cycle). Most of the = discussions and >>> results are about the topology discovery cycle but i didn't found = the >>> corresponding results at the data collection cycle as you know that = the most >>> iterative operation is the data collection cycle not topology = discovery. Are >>> there any justification about that?! >>>=20 >>> Thanks, >>> Ahmed A. Elawamry >>>=20 >>>=20 >>>=20 >>> -- >>> View this message in context: = http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html >>> Sent from the IETF - manet mailing list archive at Nabble.com. >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >=20 From ahmed_awamry_86@yahoo.com Thu Apr 4 05:01:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF04021F95E7 for ; Thu, 4 Apr 2013 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNiV+qQtMPRp for ; Thu, 4 Apr 2013 05:01:16 -0700 (PDT) Received: from nm18.bullet.mail.ne1.yahoo.com (nm18.bullet.mail.ne1.yahoo.com [98.138.90.81]) by ietfa.amsl.com (Postfix) with ESMTP id 627F721F93FB for ; Thu, 4 Apr 2013 05:01:16 -0700 (PDT) Received: from [98.138.90.50] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 12:01:15 -0000 Received: from [98.138.89.170] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 12:01:15 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 04 Apr 2013 12:01:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 477431.24473.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 48310 invoked by uid 60001); 4 Apr 2013 12:01:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365076875; bh=ab8GOCeja/tYtVLw1erWFYcqd3nVSFgWZGgvsfuB+WU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lku6lxTdCSuSQuU30TCw1Kc2FIaeF16r2xhCOnMf3bvofe6mr44mL/Q5o3k1yfYK3XiCBorMHoEK9/FpBPDq9iVGkhBXoJ1VG+OptxnFIn5HZ3Rao0oSLgnnuaxUdonNX+lkx6vyOMKCEQ1g1Yrz5oqNpKQM0CQ8C00nflhKUzQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lHDvcL+t5UhgtYq2cUBvciceJ+G3BrnryakS2Smb+lDlqcf5RYWvF2YI+s5NE9xE7ewUWyrEsme97OdhOAsv62eRCzMPlFm7andjK7FQOPsPe0TtsMvqs9i4LGCugR6ySGXYcB0L78NW1CP1HUalF/FtVFX3ghA10mkZVEcsfuU=; X-YMail-OSG: RXb7fK0VM1kGt6bIcAzfcXGJ71fxWE1Zp.C1Pm1b0cdjRxP k.HqwL3wKheMS55ocIEL.gtkCXS5A2wiLSqktW8xHAh8ARn0on0G9MX_qHrg em7DJNFGt_TTki_m__BprOLPC6xGyzHgOxZ9Oe4ijocXimJIDRArOQOwYMPf h1KZDz0GHUX0b6GUrs1Mpr.xSGETRIF9UwNQgDvzQkj0rWb2zaoxSL_a.R3r t03MZjlRC8kUY99Py4Feqpw08uS3L6Ot4O7.JEOQ6w1R.Xruk66cWCBnD.0C FuaszG7OqYirVf8TZEa9b_Do9Qg_qSlqU9vtkKjbi0rXrIDqWKg97Du2.Aha 2Fzfg3sSEOREfSF0NBwTC3_u8hnWOgZecUuDOwHQ_i3faqws_Y6cGCD0oqZ_ Ji8L1_PtYTLa1HpoBXOP5vcSdogrlqj57JpLsc4ErjMn1m2R.5IapgQMbjrI 8Ggq8fnojK3VQI.REL6_yi.1apjWLzffJUFZlH0weGeaEAPlS5oso4Ri7KPa tMuzHRMypUa1eVqhs1wuZQdkmylrjbTxi03dusD1NFq8diujD8x_fahHIcFe 8mFMMZTbQi.3F4zsN0a2mJ3l30Zm6Kmlh6kAhxjL4Xu7IoF_CmvC_gdY4ilf RsfPjB_zqpOp30vtTStdrPNh1hDZ0ZsI6Rxkxs1m2Oo2_IVv1qJ63ZPKBvrr 4oWOUEnUf8dEr3jhVG.BOdOPyXNihGG4MSjmVJSynK7g9vNKnhqPiq4juDzi IJBiIomf6U6bJlekhMX99jEMD26WhTEyh55EIkjYewYney6tOdfGo7IEuk1N SxH_qkdOmOI8Y0gfIqTVvv.makWyua7gHZt_pvwf1XEIGOmiiGGHUwEiFaow zmsMqWTnakyEJShwHPos80ewBCtu75dISraEV1MpsRnJUBOEwUdkq7gDzxro Ku5FdGHZPrrCxWpjyCASKy7uxlEDM7OiGhpBb2tePemMB0mFslvLU57uJpHu q914PIM_9A49bJSo.l1ZnGd5VClSeJdU2AhKq7BoG8uW1lHtPgSlU Received: from [193.49.124.107] by web122302.mail.ne1.yahoo.com via HTTP; Thu, 04 Apr 2013 05:01:15 PDT X-Rocket-MIMEInfo: 002.001, SGkgSmlhemksCgpUaGFuayB5b3UgZm9yIGlsbHVzdHJhdGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBJRVRGIGRyYWZ0IGFuZCB0aGUgc2NpZW50aWZpYyBwdWJsaWNhdGlvbnMuIEFsc28sIHJlZ2FyZGluZyB0aGUgcHVibGljYXRpb25zIHNlbnQuIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgcmVzdWx0cyBsaXN0ZWQgYXQgdGhlIHNlbnQgcHVibGljYXRpb25zLgoKMS4gV2hhdCBpcyB0aGUgcHJvcGFnYXRpb24gZGVsYXkgc2V0IG9uIGV2YWx1YXRpbmcgdGhlIEVuZC1Uby1FbmQgZGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> Message-ID: <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> Date: Thu, 4 Apr 2013 05:01:15 -0700 (PDT) From: AHMED AWAMRY To: Jiazi Yi In-Reply-To: <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1800448838-1745946888-1365076875=:48060" Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: AHMED AWAMRY List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 12:01:18 -0000 --1800448838-1745946888-1365076875=:48060 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jiazi,=0A=0AThank you for illustrating the difference between the IETF d= raft and the scientific publications. Also, regarding the publications sent= . I have some questions about the results listed at the sent publications.= =0A=0A1. What is the propagation delay set on evaluating the End-To-End del= ay? as i know that the propagation delay affects largely the end-to-end del= ay result. This is because , when you changed the propagation delay of the = channel (wireless or wired) you will gain different results.=0A=0A2. Regard= ing the overhead, I think=A0 that there are two points of view related to t= he overhead:=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 A. Network= Overhead (like the one mentioned at the papers)=0A=A0=A0=A0 =A0=A0=A0 =A0= =A0=A0 =A0=A0=A0 =A0=A0=A0 B. Processing Overhead (like memory usage and re= quired processing)=0ADid you estimate the factor *2.B*? if yes, what is its= value?=0A=0A=A0=A0=A0 =0A=A0=A0 Thanks,=0A=0A=A0=0AAhmed A. Elawamry,=0A= =0A=0A=0A________________________________=0A From: Jiazi Yi =0ATo: AHMED AWAMRY =0ACc: "manet@ietf.org" = =0ASent: Thursday, April 4, 2013 12:14 PM=0ASubject: Re: [= manet] LOADng Data Collection Cycle=0A =0AHi Ahmed, =0A=0AThere is one impo= rtant thing that I have to mention: some of those publications introduce di= fferent options/extensions of LOADng, but most of them are not part of LOAD= ng draft (yet). =0A=0AThis is generally because of the fundamental differen= ce between scientific publications and IETF Internet Draft (especially stan= dard track draft):=0A=0A=A0 o The scientific publications is to investigat= e new approaches, and explore *possible* ideas that can be introduced to an= Internet Draft. =0A=A0 o The IETF Internet Draft is to document clear, si= mple, and well-understood technical approaches that can be implemented in t= he real world. =0A=0ATherefore, for LOADng, while we are keeping exploring = new ideas and options, those options won't exist in the IETF draft until we= are sure that they can serve the real world (based on more operational exp= eriences and tests in different scenarios). =0A=0Abest=0A=0AJiazi=0A=0AOn A= pr 4, 2013, at 11:49 AM, Jiazi Yi wrote:=0A=0A> Hi, =0A>= =0A> I would be careful when talking about "session" in the network layer.= I think you are more talking about data transmission between two nodes(rou= ters)?=0A> =0A> In fact, there have been several publications about the per= formance of LOADng and its extensions. More publications are in the pipelin= e. =0A> Please check:=0A> =0A> LOADng: Towards AODV Version 2=0A> IEEE VTC = 2012 Fall, IEEE 76th Vehicular Technology Conference=0A> Thomas Clausen, Ji= azi Yi, Axel Colin de Verdiere=0A> http://www-mobile.ecs.soton.ac.uk/home/c= onference/VTC12-Fall/DATA/PID1141082.PDF=0A> =0A> Smart Route Request for O= n-demand Route Discovery in Constrained Environments=0A> IEEE ICWITS 2012, = IEEE International Conference on Wireless Information Technology and System= s=0A> Jiazi Yi, Thomas Clausen, Antonin Bas=0A> http://hipercom.thomasclaus= en.net/resteam/data/publications/154942d0d353eb00ae8ff62c37d68175.pdf=0A> = =0A> Efficient Data Acquisition in Sensor Networks:Introducing (the) LOADng= Collection Tree Protocol=0A> IEEE WiCom 2012, The 8th IEEE International C= onference on Wireless=0A> Communications, Networking and Mobile Computing.= =0A> Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere=0A> http://hipercom.t= homasclausen.net/resteam/data/publications/1b5774b6394c71a44d49330f9d2e4ee5= .pdf=0A> =0A> Expanding Ring Search for Route Discovery in LOADng Routing P= rotocol=0A> The 1st International Workshop on Smart Technologies for Energy= , Information and Communication=0A> Antonin Bas, Jiazi Yi, Thomas Clausen= =0A> http://hipercom.thomasclausen.net/resteam/data/publications/0c54e160b9= e3aba9e7c383f64c1fda03.pdf=0A> =0A> =0A> There is also a draft about intero= p test of LOADng:=0A> =0A> Experience with the LOADng routing protocol for = LLNs=0A> T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, = SATOH. H. Y. Morii=0A> http://tools.ietf.org/html/draft-lavenu-lln-loadng-i= nteroperability-report=0A> =0A> best=0A> =0A> Jiazi=0A> =0A> On Apr 3, 2013= , at 10:42 PM, AHMED AWAMRY wrote:=0A> =0A>> Hi= ,=0A>> =0A>> Thank you for your answer. I mean by topology discovery that f= inding routes to the required destination (constructing routing table). As = you know, this phase is implemented on demand and in case of RERR. I want t= o mention that the data collection cycle is repeated a lot of times (for ex= ample if there will be a session between two nodes) so, it's good to mentio= n the results and the test cases regarding the data collection cycle becaus= e it will be very effective measurement=A0 for the routing protocol behavio= r.=0A>> =0A>> =0A>> Thanks,=0A>> Ahmed A. Elawamry,=0A>> =0A>> From: Jiazi = Yi =0A>> To: Ahmed A. Elawamry =0A>> Cc: manet@ietf.org =0A>> Sent: Tuesday, April 2, 2013 10:56 PM=0A>>= Subject: Re: [manet] LOADng Data Collection Cycle=0A>> =0A>> Hi, =0A>> =0A= >> I'm not sure what's your definition of "topology discovery" and "data co= llection cycle". =0A>> The control plan of LOADng is about "find the desire= d routes on demand". The data plan/forwarding has no significant difference= with other routing protocols - it's simply hop-by-hop IP forwarding. The o= nly difference is that if there is no available route, LOADng needs to trig= ger a route discovery (normal routing protocol do "best effort"). =0A>> =0A= >> best=0A>> =0A>> Jiazi=0A>> =0A>> On Mar 31, 2013, at 4:37 PM, Ahmed A. E= lawamry wrote:=0A>> =0A>>> Hello All,=0A>>> =0A= >>> I'm new to the MANET working group but i am following the mailing list= =0A>>> regarding the LOADng protocol. As mentioned at the LOADng drafts tha= t it is=0A>>> a reactive routing protocol extracted from the AODV; Thus, it= has two cycles=0A>>> (topology discovery and data collection cycle). Most = of the discussions and=0A>>> results are about the topology discovery cycle= but i didn't found the=0A>>> corresponding results at the data collection = cycle as you know that the most=0A>>> iterative operation is the data colle= ction cycle not topology discovery. Are=0A>>> there any justification about= that?!=0A>>> =0A>>> Thanks,=0A>>> Ahmed A. Elawamry=0A>>> =0A>>> =0A>>> = =0A>>> --=0A>>> View this message in context: http://ietf.10.n7.nabble.com/= LOADng-Data-Collection-Cycle-tp363492.html=0A>>> Sent from the IETF - manet= mailing list archive at Nabble.com.=0A>>> ________________________________= _______________=0A>>> manet mailing list=0A>>> manet@ietf.org=0A>>> https:/= /www.ietf.org/mailman/listinfo/manet=0A>> =0A>> =0A>> =0A> --1800448838-1745946888-1365076875=:48060 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jiazi,<= /span>

Thank you for illustrati= ng the difference between the IETF draft and the scientific publications. A= lso, regarding the publications sent. I have some questions about the resul= ts listed at the sent publications.

1. What is the propagation delay set on evaluating the End-To-E= nd delay? as i know that the propagation delay affects largely the end-to-e= nd delay result. This is because , when you changed the propagation delay o= f the channel (wireless or wired) you will gain different results.

2. Regarding the overhead, I thi= nk  that there are two points of view related to the overhead:<= /div>
          &nbs= p;         A. Network Overhead (like the one mentioned at the pape= rs)
           = ;     =     B. Processing Overhead (like memory usage and required p= rocessing)
Did you estimate the factor= *2.B*? if yes, what is its value?

&nb= sp;  
   Thanks,
 
Ahmed A. Elawamry,

From: Jiazi Yi <= ;ietf@jiaziyi.com>
To:<= /b> AHMED AWAMRY <ahmed_awamry_86@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Thursday, April 4, 2013 12:= 14 PM
Subject: Re: [ma= net] LOADng Data Collection Cycle

=0AHi Ahmed,
<= br>There is one important thing that I have to mention: some of those publi= cations introduce different options/extensions of LOADng, but most of them = are not part of LOADng draft (yet).

This is generally because of th= e fundamental difference between scientific publications and IETF Internet = Draft (especially standard track draft):

  o The scientific pu= blications is to investigate new approaches, and explore *possible* ideas t= hat can be introduced to an Internet Draft.
  o The IETF Internet= Draft is to document clear, simple, and well-understood technical approach= es that can be implemented in the real world.

Therefore, for LOADng= , while we are keeping exploring new ideas and options, those options won't= exist in the IETF draft until we are sure that they can serve the real wor= ld (based on more operational experiences and tests in different scenarios)= .

best

Jiazi

On Apr 4, 2013, at 11:49 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:

> Hi,
&g= t;
> I would be careful when talking about "session" in the network = layer. I think you are more talking about data transmission between two nod= es(routers)?
>
> In fact, there have been several publications= about the performance of LOADng and its extensions. More publications are = in the pipeline.
> Please check:
>
> LOADng: Towards AO= DV Version 2
> IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Con= ference
> Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere
> ht= tp://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID1141082.= PDF
>
> Smart Route Request for On-demand Route Discovery in C= onstrained Environments
> IEEE ICWITS 2012, IEEE International Confer= ence on Wireless Information Technology and Systems
> Jiazi Yi, Thomas Clausen, Antonin Bas
> http://hipercom.thomasclausen.net/rest= eam/data/publications/154942d0d353eb00ae8ff62c37d68175.pdf
>
>= Efficient Data Acquisition in Sensor Networks:Introducing (the) LOADng Col= lection Tree Protocol
> IEEE WiCom 2012, The 8th IEEE International C= onference on Wireless
> Communications, Networking and Mobile Computi= ng.
> Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere
> http:/= /hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71a44d493= 30f9d2e4ee5.pdf
>
> Expanding Ring Search for Route Discovery = in LOADng Routing Protocol
> The 1st International Workshop on Smart = Technologies for Energy, Information and Communication
> Antonin Bas,= Jiazi Yi, Thomas Clausen
> http://hipercom.thomasclausen.net/resteam= /data/publications/0c54e160b9e3aba9e7c383f64c1fda03.pdf
>
> > There is also a draft about interop test of LOADng:
>
> Experience with the LOADng routing protocol for LLNs
> T. C= lausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, SATOH. H. Y. = Morii
> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interopera= bility-report
>
> best
>
> Jiazi
>
>= On Apr 3, 2013, at 10:42 PM, AHMED AWAMRY <ahmed_awamry_= 86@yahoo.com> wrote:
>
>> Hi,
>>
>&g= t; Thank you for your answer. I mean by topology discovery that finding rou= tes to the required destination (constructing routing table). As you know, = this phase is implemented on demand and in case of RERR. I want to mention = that the data collection cycle is repeated a lot of times (for example if t= here will be a session between two nodes) so, it's good to mention the resu= lts and the test cases regarding the data collection cycle because it will be very effective measurement  for the routing protocol behavior= .
>>
>>
>> Thanks,
>> Ahmed A. Elawam= ry,
>>
>> From: Jiazi Yi <ietf@jiaziyi.com>
&g= t;> To: Ahmed A. Elawamry <ahmed_awamry_86@yahoo.com>
>> Cc: manet@ietf.org
>> Sent: Tuesday, April 2, 20= 13 10:56 PM
>> Subject: Re: [manet] LOADng Data Collection Cycle>>
>> Hi,
>>
>> I'm not sure what's y= our definition of "topology discovery" and "data collection cycle".
>= ;> The control plan of LOADng is about "find the desired routes on deman= d". The data plan/forwarding has no significant difference with other routi= ng protocols - it's simply hop-by-hop IP forwarding. The only difference is t= hat if there is no available route, LOADng needs to trigger a route discove= ry (normal routing protocol do "best effort").
>>
>> be= st
>>
>> Jiazi
>>
>> On Mar 31, 2013,= at 4:37 PM, Ahmed A. Elawamry <ahmed_awamry_86@yahoo.com= > wrote:
>>
>>> Hello All,
>>> >>> I'm new to the MANET working group but i am following the mai= ling list
>>> regarding the LOADng protocol. As mentioned at th= e LOADng drafts that it is
>>> a reactive routing protocol extr= acted from the AODV; Thus, it has two cycles
>>> (topology disc= overy and data collection cycle). Most of the discussions and
>>&g= t; results are about the topology discovery cycle but i didn't found the
>>> corresponding results at the data collection cycle as = you know that the most
>>> iterative operation is the data coll= ection cycle not topology discovery. Are
>>> there any justific= ation about that?!
>>>
>>> Thanks,
>>>= Ahmed A. Elawamry
>>>
>>>
>>>
&g= t;>> --
>>> View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363= 492.html
>>> Sent from the IETF - manet mailing list archiv= e at Nabble.com.
>>> __________________________________________= _____
>>> manet mailing list
>>> manet@ietf.org
>= ;>> https://www.ietf.org/mailman/listinfo/manet
>&= gt;
>>
>>
>



--1800448838-1745946888-1365076875=:48060-- From adrian@olddog.co.uk Thu Apr 4 06:17:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C02A21F8BA6 for ; Thu, 4 Apr 2013 06:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t9BEBt2mX29 for ; Thu, 4 Apr 2013 06:17:42 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id AD6D821F8B96 for ; Thu, 4 Apr 2013 06:17:41 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r34DHeH4016915; Thu, 4 Apr 2013 14:17:40 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r34DHTIK016775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 14:17:37 +0100 From: "Adrian Farrel" To: Date: Thu, 4 Apr 2013 14:17:24 +0100 Message-ID: <003b01ce3136$c8585430$5908fc90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4xNgxSKIL374RmRwmtmMf0Kee6Jw== Content-Language: en-gb Cc: manet-chairs@tools.ietf.org, manet@ietf.org Subject: [manet] Mail regarding draft-ietf-manet-smf-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:17:42 -0000 Hi, I found this I-d languishing in limbo state. I have moved it into publication requested and will add it to my queue. Adrian From robert.g.cole.civ@mail.mil Thu Apr 4 11:14:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEC821F95E2 for ; Thu, 4 Apr 2013 11:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEYWfUJl9-vR for ; Thu, 4 Apr 2013 11:14:42 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D921F95E1 for ; Thu, 4 Apr 2013 11:14:41 -0700 (PDT) Received: from UCOLHP3D.easf.csd.disa.mil (131.64.100.143) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 4 Apr 2013 18:14:31 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.253]) by UCOLHP3D.easf.csd.disa.mil ([131.64.100.143]) with mapi id 14.03.0123.003; Thu, 4 Apr 2013 18:14:30 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "adrian@olddog.co.uk" , "draft-ietf-manet-smf-mib@tools.ietf.org" Thread-Topic: Mail regarding draft-ietf-manet-smf-mib (UNCLASSIFIED) Thread-Index: Ac4xNgxSKIL374RmRwmtmMf0Kee6JwAKhBBA Date: Thu, 4 Apr 2013 18:14:29 +0000 Message-ID: References: <003b01ce3136$c8585430$5908fc90$@olddog.co.uk> In-Reply-To: <003b01ce3136$c8585430$5908fc90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0071_01CE313E.B73C7890" MIME-Version: 1.0 Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] Mail regarding draft-ietf-manet-smf-mib (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:14:42 -0000 ------=_NextPart_000_0071_01CE313E.B73C7890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Adrian, Yes please. I should have been tracking more closely. Thanks for adding to your queue. Bob Robert G. Cole Comm: 443.395.8744 Email: robert.g.cole@us.army.mil -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Thursday, April 04, 2013 9:17 AM To: draft-ietf-manet-smf-mib@tools.ietf.org Cc: manet-chairs@tools.ietf.org; manet@ietf.org Subject: Mail regarding draft-ietf-manet-smf-mib Hi, I found this I-d languishing in limbo state. I have moved it into publication requested and will add it to my queue. Adrian Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0071_01CE313E.B73C7890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDMEEgMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTMwMjI2MDAwMDAwWhcN MTYwMjI1MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOqO /17DG7aYs9uSnP/+p6Gsq8VEWYasP2AFK4fLX6EddXT0Xbpl+6D65ocPNoVOejCt3xTUZTUpcujL ca/fkpqdpIgyqLY/TwXncfjejcKneIkXb9xAUfAfjIU1S+GVQCZx5qWrRwqhvGq5LHadRDZh5FN/ 71vZyqrqCAg/NqYEvn8O0WlQefyhCOnbBDS06o0Xs2MhNVmaoMq0+9owe0sc3Tom3TxE6FqsJ0lf 5D7BK5x7qyAE3OdbMCxHIIbFYfayGr43zucoJgx73fFYPlMhC1FL5tzWdoaudbJcS3CxgQo3xF+v 7LwtAscs1MnrTs0xR5WlUrGIYNYU7cIPZD8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPWwve21KZ20gQuIqDaDVMnON8uNMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyb2JlcnQu Zy5jb2xlQHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBABxQGaSlVFdP9mklREX71YtmZGbQcR8xvgT/VAWAS5wBtmAsQ6A9DWj3OoAqCBUk lqaxMyqsfIkVMRMOw+U5RSj5A8fDnnzMuvtooPbpb4gQxH9fQ8ELFluuMpD1cx/pZT+zARV3ClZX 6g2aZolBtk17r/2/dsRcvhO8uIOpI6IFYToCn6ZfnrXXSMKf74LAfigeXpsay23M8Vv9HTVPMUyg AVQl9uEyOApG9V10gNqUihZcJIOz6lpUG2xJ50npdKPBhAwcZLZXKqIHchthupFDFbKFbf3VGPV5 KVer+zC/5D0IUZzdUWtPSERWi+OFOfipi75Y5oIYHoY/U36HV1cwggUCMIID6qADAgECAgMwQR0w DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MzAyMjYwMDAwMDBaFw0xNjAyMjUyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHUNPTEUuUk9CRVJULkdSQU5PVC4xMzY2NTYwMzkwMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAq4oVK/5DQ8R/9nLb97oeOJPzP7qjER2TA2ue96H+4ZHs8GGFtiN1jciBqfKr ce0iINLWxbeeCUR62zPQCLxfp2EG0/C1zz6W7E7O7z5CnPPeDF+IpaeM4yB1kztkGx6ONNAJMJ+k oxbJxgEGE+RY51EQUYKwOSi8hq+IandF5hP6krnLHg16DARSr29h3NHmFrfCkkPIcrSMNXZLFI5X JIInqpfgQPeR9MxKPTh970N375hcZHY/uPZJQpydKVdolrmX0BbT5soL5dEZ3RAXlK4fzTCgyEK7 0c4IGbpqq/spzPztl7w64hN1sbbmM+mBKGmI7a/PfqFCotYKMlSpgQIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUUEcYiStZfaVzV72TgQ+2OA00 1jQwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJvYmVydC5nLmNvbGVAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMzY2NTYw MzkwQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAUIuG9wQM+L5Nn5s06siK fLFn1zTwubJzuQmWIKj0PeRhcXyEZtYdiR2p5YQWS7Z/g+WlsSCJGVjk4sK3UCYPQKV8xbEVh9Us SGOUuIDKP7GAswgy8h9XAFDJfSPa9Vtzl8AgNLZiTUJfsn7N6uIOFiwWsHLr5MlvH+kbeNhY6wQ/ SuXyoR6IXAjAbm657Rb4lgdITn85Uuetk4kvsP08Vct/LfFPoJEHVHliov5zuvtAFzYPfu9bsmr0 CZ2LT8oljcncGG3/Nxt1XfYZJCCkxbav5Dq+t5eFcT69lYbcbliG3Us3ztCp7edfgBs9mzSbkPjC tLPki80GqY4Uacrb5TCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggL+MIIC+gIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAzBBHTAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA0MDQxODE0MjdaMCMGCSqGSIb3DQEJBDEWBBT+hZty94QM60ACIty4hAtZ HJphrTAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMHMAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFm MGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDMEEgMHUGCyqGSIb3DQEJ EAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI5AgMwQSAwDQYJKoZI hvcNAQEBBQAEggEAhvGvengKuE7Hz5l/ff4YnjEPmsNr2sV6tuc6U2fEmDYpsSH8H19C2Ua44Zyh Q6Eg4JnfueGRXtzGZxS5DfEEC7jy2b66i0Wg1k3N+Wfz48GI1xPqH2KSPQ2WBwi2hWU9fZjjqSAi qZpXkIBEHSnTAFLY9c47PCNqgbGL7FB9ZeWOGxBf+0WiNgof7u0GNcyXhBoSSdNv5eCbL3HcIxQq 8ewqPqyGlCAJQM1uRlLbv9m0kN3lznHUHKAhkWPS3cRrNl1V6ARByC4ufC2weggxd3vPkEp9yPso mMJETdUesOQTxh+c31OhT4uxDOeC7p9Klt6P0ceLyuoMnz2j/ewxqwAAAAAAAA== ------=_NextPart_000_0071_01CE313E.B73C7890-- From yi.jiazi@gmail.com Fri Apr 5 02:23:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6604221F85DC for ; Fri, 5 Apr 2013 02:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.97 X-Spam-Level: * X-Spam-Status: No, score=1.97 tagged_above=-999 required=5 tests=[AWL=5.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrU8OeI6he-N for ; Fri, 5 Apr 2013 02:23:57 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id DE68021F85D9 for ; Fri, 5 Apr 2013 02:23:56 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so3588689wgh.27 for ; Fri, 05 Apr 2013 02:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=Ju0Y2kXt1yrkwGROgk68QegL04GddIp09Mq2CSsB/3Q=; b=ZiZe8Z2dNR0EGeZ/iDkrf2TT0EH3n4RXWwRrZP2Yy2pLZKwC6ROHZCCf/mD2R21J0x cO99cyxjX93D+ntK8vHDclD+4vm6NpDJWwDh2BH0NHf3nifDbYJe2hM3at9p4XRrNMDJ GCswmLlvkxrXSWL9oigY73mxX2vC5gIfLsInttgzyCW5QGmHRZjHLCPR+FVqdhtoTTU8 TlXYvmT3GiV/e78/2OrP8mZEroHWcdWuW89dQkhsf9m8mHbAAyut336FybD9xtU1adtq 4AT6lbsx4ajV5tfSOzl8djwdDIGZD2d2qRaPv6/7FS5+KDw6r49cO4jwLSMJlE4lHTfB QsWg== X-Received: by 10.194.60.195 with SMTP id j3mr14885020wjr.33.1365153835964; Fri, 05 Apr 2013 02:23:55 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id dp5sm2482472wib.1.2013.04.05.02.23.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 02:23:55 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> Date: Fri, 5 Apr 2013 11:23:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD538FC-A761-45FE-AF33-93622D6EA193@jiaziyi.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> To: "manet@ietf.org List" X-Mailer: Apple Mail (2.1503) Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:23:58 -0000 Hi, On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY = wrote: > Hi Jiazi, >=20 > Thank you for illustrating the difference between the IETF draft and = the scientific publications. Also, regarding the publications sent. I = have some questions about the results listed at the sent publications. >=20 > 1. What is the propagation delay set on evaluating the End-To-End = delay? as i know that the propagation delay affects largely the = end-to-end delay result. This is because , when you changed the = propagation delay of the channel (wireless or wired) you will gain = different results. The propagation delay depends on the lower-layer protocol used. In our = simulations for LOADng evaluation, it's 802.11b.=20 >=20 > 2. Regarding the overhead, I think that there are two points of view = related to the overhead: > A. Network Overhead (like the one mentioned at the = papers) > B. Processing Overhead (like memory usage and = required processing) > Did you estimate the factor *2.B*? if yes, what is its value? The "processing overhead" for an on-demand protocol like LOADng is = trivial, with O(n) complexity.=20 best Jiazi >=20 > =20 > Thanks, > =20 > Ahmed A. Elawamry, >=20 > From: Jiazi Yi > To: AHMED AWAMRY =20 > Cc: "manet@ietf.org" =20 > Sent: Thursday, April 4, 2013 12:14 PM > Subject: Re: [manet] LOADng Data Collection Cycle >=20 > Hi Ahmed,=20 >=20 > There is one important thing that I have to mention: some of those = publications introduce different options/extensions of LOADng, but most = of them are not part of LOADng draft (yet).=20 >=20 > This is generally because of the fundamental difference between = scientific publications and IETF Internet Draft (especially standard = track draft): >=20 > o The scientific publications is to investigate new approaches, and = explore *possible* ideas that can be introduced to an Internet Draft.=20 > o The IETF Internet Draft is to document clear, simple, and = well-understood technical approaches that can be implemented in the real = world.=20 >=20 > Therefore, for LOADng, while we are keeping exploring new ideas and = options, those options won't exist in the IETF draft until we are sure = that they can serve the real world (based on more operational = experiences and tests in different scenarios).=20 >=20 > best >=20 > Jiazi >=20 > On Apr 4, 2013, at 11:49 AM, Jiazi Yi wrote: >=20 > > Hi,=20 > >=20 > > I would be careful when talking about "session" in the network = layer. I think you are more talking about data transmission between two = nodes(routers)? > >=20 > > In fact, there have been several publications about the performance = of LOADng and its extensions. More publications are in the pipeline.=20 > > Please check: > >=20 > > LOADng: Towards AODV Version 2 > > IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Conference > > Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere > > = http://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID11410= 82.PDF > >=20 > > Smart Route Request for On-demand Route Discovery in Constrained = Environments > > IEEE ICWITS 2012, IEEE International Conference on Wireless = Information Technology and Systems > > Jiazi Yi, Thomas Clausen, Antonin Bas > > = http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb= 00ae8ff62c37d68175.pdf > >=20 > > Efficient Data Acquisition in Sensor Networks:Introducing (the) = LOADng Collection Tree Protocol > > IEEE WiCom 2012, The 8th IEEE International Conference on Wireless > > Communications, Networking and Mobile Computing. > > Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere > > = http://hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71= a44d49330f9d2e4ee5.pdf > >=20 > > Expanding Ring Search for Route Discovery in LOADng Routing Protocol > > The 1st International Workshop on Smart Technologies for Energy, = Information and Communication > > Antonin Bas, Jiazi Yi, Thomas Clausen > > = http://hipercom.thomasclausen.net/resteam/data/publications/0c54e160b9e3ab= a9e7c383f64c1fda03.pdf > >=20 > >=20 > > There is also a draft about interop test of LOADng: > >=20 > > Experience with the LOADng routing protocol for LLNs > > T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, = SATOH. H. Y. Morii > > = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= > >=20 > > best > >=20 > > Jiazi > >=20 > > On Apr 3, 2013, at 10:42 PM, AHMED AWAMRY = wrote: > >=20 > >> Hi, > >>=20 > >> Thank you for your answer. I mean by topology discovery that = finding routes to the required destination (constructing routing table). = As you know, this phase is implemented on demand and in case of RERR. I = want to mention that the data collection cycle is repeated a lot of = times (for example if there will be a session between two nodes) so, = it's good to mention the results and the test cases regarding the data = collection cycle because it will be very effective measurement for the = routing protocol behavior. > >>=20 > >>=20 > >> Thanks, > >> Ahmed A. Elawamry, > >>=20 > >> From: Jiazi Yi > >> To: Ahmed A. Elawamry =20 > >> Cc: manet@ietf.org=20 > >> Sent: Tuesday, April 2, 2013 10:56 PM > >> Subject: Re: [manet] LOADng Data Collection Cycle > >>=20 > >> Hi,=20 > >>=20 > >> I'm not sure what's your definition of "topology discovery" and = "data collection cycle".=20 > >> The control plan of LOADng is about "find the desired routes on = demand". The data plan/forwarding has no significant difference with = other routing protocols - it's simply hop-by-hop IP forwarding. The only = difference is that if there is no available route, LOADng needs to = trigger a route discovery (normal routing protocol do "best effort").=20 > >>=20 > >> best > >>=20 > >> Jiazi > >>=20 > >> On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry = wrote: > >>=20 > >>> Hello All, > >>>=20 > >>> I'm new to the MANET working group but i am following the mailing = list > >>> regarding the LOADng protocol. As mentioned at the LOADng drafts = that it is > >>> a reactive routing protocol extracted from the AODV; Thus, it has = two cycles > >>> (topology discovery and data collection cycle). Most of the = discussions and > >>> results are about the topology discovery cycle but i didn't found = the > >>> corresponding results at the data collection cycle as you know = that the most > >>> iterative operation is the data collection cycle not topology = discovery. Are > >>> there any justification about that?! > >>>=20 > >>> Thanks, > >>> Ahmed A. Elawamry > >>>=20 > >>>=20 > >>>=20 > >>> -- > >>> View this message in context: = http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html > >>> Sent from the IETF - manet mailing list archive at Nabble.com. > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>=20 > >>=20 > >>=20 > >=20 >=20 >=20 >=20 From abdussalambaryun@gmail.com Fri Apr 5 02:57:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4416721F96B6 for ; Fri, 5 Apr 2013 02:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oJ6MjFQnWbG for ; Fri, 5 Apr 2013 02:57:47 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id C81DC21F9681 for ; Fri, 5 Apr 2013 02:57:47 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id lj1so1955999pab.7 for ; Fri, 05 Apr 2013 02:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=K0rpVCy8dGz3RrCoVT//nu04tfhW1gBPKyXq/1/N/rw=; b=omzq0Dbmi6EjFfzBKNyLKExH1S1RL1NuKjq8UxkcYyC+0Fs9g4yQYoCCvHS5ARFRHE SSmIcAKzc69ZTwUDmmPM98BdirgENmml+MMJzjTnu3+6FFdq0iNnoVbax+sNAdWQ47eF 6YtDANMD35N9D/WKFv2K7DLoMPWt9e7XGV1RBvIcpYxLFXFVrc9fjbaza6gURVkBvXxj eaJf2SaGGEfz+YWccRUESKj9yOunAzZZT1A/DIevzz7mNqYJ/onGaKYpmXkH2tz3RATS T7gC1iUPetzUBam0FrbSsfz9pCPwzH9WjZ96N490WSrYJhFbxx+tQPLozmt9FKWr21aX Zhbg== MIME-Version: 1.0 X-Received: by 10.66.75.193 with SMTP id e1mr14458192paw.202.1365155867477; Fri, 05 Apr 2013 02:57:47 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Fri, 5 Apr 2013 02:57:47 -0700 (PDT) In-Reply-To: <7CD538FC-A761-45FE-AF33-93622D6EA193@jiaziyi.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <7CD538FC-A761-45FE-AF33-93622D6EA193@jiaziyi.com> Date: Fri, 5 Apr 2013 11:57:47 +0200 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:57:48 -0000 On 4/5/13, Jiazi Yi wrote: > The "processing overhead" for an on-demand protocol like LOADng is trivial, > with O(n) complexity. I thought memory overhead was O(d+h), d:network diameter, h:neighbors, but processing overhead depends on implementation, routing overhead and memory overhead (how to determine that?). However, I disagree that processing overhead is with O(n) for MANET-reactive protocol. If the LOADng is Light-manet-protocol then I assume it SHOULD have less processing than non-Light-manet-protocol. AB From yi.jiazi@gmail.com Sat Apr 6 07:29:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FA421F8CB5 for ; Sat, 6 Apr 2013 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.404 X-Spam-Level: ** X-Spam-Status: No, score=2.404 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHBFrfQ2FWzj for ; Sat, 6 Apr 2013 07:29:30 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5227F21F8C98 for ; Sat, 6 Apr 2013 07:29:30 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj8so1383031wib.1 for ; Sat, 06 Apr 2013 07:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vZOomKordo2SUBRd74HOK+N627bQFhkExhCdqpol9sc=; b=NIU0oWrElyoaF1ZcjrwKqphRcpVXJlrwIpbuBlV4E2VcOert7EMTuNXX64A6NZ/xII 2ueLx2GxauONM+E5lgcX3p0q9RNfKz1TM4iYuEJJToXwXcc7d5n3ldk01dl7AbnF5kCq MLPQ5F9fMS87BS6LjHrQVx51qGvKDs32+jiwte2bYJFI7+qaS0Fkt+7oYVwv9zwJPto0 cym+z2mzeqDiwn9vRmQNf/L6Pu1Ddtal8xw+/wQ/jT6wqZ6rhbhy880+VkfQWzpgTdVq QrQrylCkG+jDjjvbZSr8bMCaFYiCTG9EXmmO3YmV0E9xYzmZPYZSG6OurTSn4at24pla UWsw== X-Received: by 10.180.92.97 with SMTP id cl1mr4331749wib.19.1365258569506; Sat, 06 Apr 2013 07:29:29 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fv2sm10561607wib.6.2013.04.06.07.29.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Apr 2013 07:29:28 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: Date: Sat, 6 Apr 2013 16:29:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <7CD538FC-A761-45FE-AF33-93622D6EA193@jiaziyi.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1503) Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 14:29:31 -0000 Hi, On Apr 5, 2013, at 11:57 AM, Abdussalam Baryun = wrote: > On 4/5/13, Jiazi Yi wrote: >> The "processing overhead" for an on-demand protocol like LOADng is = trivial, >> with O(n) complexity. >=20 > I thought memory overhead was O(d+h), d:network diameter, h:neighbors, > but processing overhead depends on implementation, routing overhead > and memory overhead (how to determine that?). However, I disagree that > processing overhead is with O(n) for MANET-reactive protocol. >=20 I have no idea what's O(d+h) notation.=20 > If the LOADng is Light-manet-protocol then I assume it SHOULD have > less processing than non-Light-manet-protocol. >=20 I won't call other protocols "non-linght-manet-protocol", but there are = some differences between LOADng and AODV, which is listed in = introduction of LOADng draft. It illustrates how LOADng is simplified.=20= best Jiazi > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ahmed_awamry_86@yahoo.com Sun Apr 7 02:09:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB121F877A for ; Sun, 7 Apr 2013 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQA3a+h9cujv for ; Sun, 7 Apr 2013 02:09:43 -0700 (PDT) Received: from nm16.bullet.mail.ne1.yahoo.com (nm16.bullet.mail.ne1.yahoo.com [98.138.90.79]) by ietfa.amsl.com (Postfix) with ESMTP id D673E21F84E7 for ; Sun, 7 Apr 2013 02:09:42 -0700 (PDT) Received: from [98.138.90.49] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2013 09:09:42 -0000 Received: from [98.138.88.233] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2013 09:09:42 -0000 Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 07 Apr 2013 09:09:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 303673.82525.bm@omp1033.mail.ne1.yahoo.com Received: (qmail 87008 invoked by uid 60001); 7 Apr 2013 09:09:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365325782; bh=cJ5yskGXrB/TljdGe5OxYMU0IB473TMwJbcmutiJnRQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YlgyAd8JPiyQZ1Df/YkBMIpP2F7k1ktuMHEvVR5g7PcGP0ohbpN70M1z+aqXMyOHJBoWaau7duOEOs54AfIsz28vQqQF2eitW9JXnc96jGTBM/UcYL/6dY4DEU2R5Vsp8BtKJqSFk/TjvT4nyPOrddk1VWlWZ4vKRUPt0dU/5yQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jBvTBtzElyTVOurNLf3ppu+mdemNhApgpTGj4dYewaRBLCOuRnsMs/+IlePRmgQ75h26d7O/jA5BHm6cqVvGXimt9nAKNfvZHOPfHuXeApKm9aMTBV4yLr2xPS0tpOjeHDxVSz3HV3PoFILZ3XhpfJK9cvasWFRjm0+jYNvbplk=; X-YMail-OSG: 47uKc.QVM1nOwpwGoEek5GKR3zV9FTxWXLr0tWSC0rO5Aco XPB2BRXoAcxs2qc0K5oQ.EUCL0QcB586rs_skkl2BT0o272gaO0XfbBSSyzJ 2F56HdY_NeftBaCuwKiv8teg9SblRspU7wGvTsNTZvTvbPKlTSGaXKIJ6pnl CE9F5h286Od35KDQoxVnM0Bkqph7nBgHD0DR1RhA9twbD9zGdv_mWxJ.RXRb QWcFg4hHFCmo7.4fqzGCavREBTMxxAMJaWRmicZb3Y3mK1FjSMhH414pkQtC tCLq9Qnb2KUDyT3kNamvfnC4VCuJypqkGcfSlQrKrhY26ex2ob0M1G4c54cr YyXxSpfT8F.NSTnJ7R_2ILYnxYxcPIX1vwZXasKqxUPi_fwETmsGI0MDYGI4 XgYHn3Wlb9FbuFf3hVUcJ0SS563XR4XZ_NT63t_nGjqjBVlwjiUV_w95g44D YfJpfAUbFVfreZTnGofSc5_mkHe8d4GYSjVviQ3HsEtLyG2RBOm0bO4v.Sbe lFbcOMrSB8W6PIhvfEYxiFD6TwVbCPmLKft09indmo_VyCjXrObrZW7A31qo l9ODwBgb0JrX.u2zhdf_y3VD7ybfz.nJMDIEMmFXTTQWs5yDAOuQ2vpvrPFy MqbGweu7i240FwfwsR8SZH2GBMugpvrPHJpxmhZMhJZiYV3sd18ZU0H8Q1oT KBeauoYpZgZ2DUvNg9fB7cjz1Cq3orct68o4uofqawJNODaoYtE6t0j1gZLK keRr3rIOrrKKn9DBYnrtZSarRsRoV10quFgUUtSzelEM7O2Mg7jtMZUttQhk isUnKu30TAHbhVkAb4N_T8RmguMXjzTix3nfU56PHGrCELH03CuCt.BOZwJd wDihMY95jcsZvR3eYkVdIsU2DbmNmqnlIc6S.s06jf4YWHVw53OpH.gvmqaN lrJuVXKnjYumEFrnOQV0EAvWJKhQegOh5v_cf.6b_Oim9EtkP.csjy7GxRVT OocIIcu9TCUwwHNZmjk9OO5JK61V6KeMAXOmwgwTt6xsC5r9aB2kactQADyt gSm9Xkac- Received: from [197.222.16.198] by web122305.mail.ne1.yahoo.com via HTTP; Sun, 07 Apr 2013 02:09:41 PDT X-Rocket-MIMEInfo: 002.001, SGkgSmlhemksCgpQbGVhc2UgZmluZCBteSBiZWxvdyByZXBseSwKCsKgCgrCoAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKaWF6aSBZaSA8aWV0ZkBqaWF6aXlpLmNvbT4KVG86IEFITUVEIEFXQU1SWSA8YWhtZWRfYXdhbXJ5Xzg2QHlhaG9vLmNvbT4gCkNjOiAibWFuZXRAaWV0Zi5vcmciIDxtYW5ldEBpZXRmLm9yZz4gClNlbnQ6IEZyaWRheSwgQXByaWwgNSwgMjAxMyAxMToxOCBBTQpTdWJqZWN0OiBSZTogW21hbmV0XSBMT0FEbmcgRGF0YSBDb2xsZWN0aW9uIEN5Y2xlCiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> Message-ID: <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com> Date: Sun, 7 Apr 2013 02:09:41 -0700 (PDT) From: AHMED AWAMRY To: Jiazi Yi In-Reply-To: <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-947112896-553668440-1365325781=:85623" Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: AHMED AWAMRY List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 09:09:44 -0000 ---947112896-553668440-1365325781=:85623 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jiazi,=0A=0APlease find my below reply,=0A=0A=A0=0A=0A=A0=0A=0A=0A______= __________________________=0A From: Jiazi Yi =0ATo: AHMED= AWAMRY =0ACc: "manet@ietf.org" =0ASent: Friday, April 5, 2013 11:18 AM=0ASubject: Re: [manet] LOADng Dat= a Collection Cycle=0A =0AHi, =0A=0AOn Apr 4, 2013, at 2:01 PM, AHMED AWAMRY= wrote:=0A=0A> Hi Jiazi,=0A> =0A> Thank you for= illustrating the difference between the IETF draft and the scientific publ= ications. Also, regarding the publications sent. I have some questions abou= t the results listed at the sent publications.=0A> =0A> 1. What is the prop= agation delay set on evaluating the End-To-End delay? as i know that the pr= opagation delay affects largely the end-to-end delay result. This is becaus= e , when you changed the propagation delay of the channel (wireless or wire= d) you will gain different results.=0A=0AThe propagation delay depends on t= he lower-layer protocol used. In our simulations for LOADng evaluation, it'= s 802.11b. =0A=0A=0ASo, you use nodes of 250m range, Mesh topology connecte= d.We could=0Aconsider LOADng as Layer 3 protocol, is this right?=A0=A0=0A= =0A> =0A> 2. Regarding the overhead, I think=A0 that there are two points o= f view related to the overhead:=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = A. Network Overhead (like the one mentioned at the papers)=0A>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 B. Processing Overhead (like memory usage and = required processing)=0A> Did you estimate the factor *2.B*? if yes, what is= its value?=0A=0AThe "processing overhead" for an on-demand protocol like L= OADng is trivial, with O(n) complexity. =0A=0A=0A=A0I mean by processing ov= erhead,the overhead=0Aintroduced by the protocol to be implemented, (How ma= ny events executed to=0Aperform the protocol?) Also, the memory usage used = to implement or simulate the=0Aprotocol (I think the LOADng=A0interoperabil= ity-report=A0mentioned=0A6000-lines Java code, is it for implementation or = test?). This will be=0Avery efficient to select the suitable IC (MCU or DSP= ) to implement the protocol.=0Abest=0A=0AJiazi=0A=0ARegards,=0AAhmed A. Ela= wamry,=0A> =0A>=A0 =A0 =0A>=A0 =A0 Thanks,=0A>=A0 =0A> Ahmed A. Elawamry,= =0A> =0A> From: Jiazi Yi =0A> To: AHMED AWAMRY =0A> Cc: "manet@ietf.org" =0A> Sent: Thu= rsday, April 4, 2013 12:14 PM=0A> Subject: Re: [manet] LOADng Data Collecti= on Cycle=0A> =0A> Hi Ahmed, =0A> =0A> There is one important thing that I h= ave to mention: some of those publications introduce different options/exte= nsions of LOADng, but most of them are not part of LOADng draft (yet). =0A>= =0A> This is generally because of the fundamental difference between scien= tific publications and IETF Internet Draft (especially standard track draft= ):=0A> =0A>=A0 o The scientific publications is to investigate new approac= hes, and explore *possible* ideas that can be introduced to an Internet Dra= ft. =0A>=A0 o The IETF Internet Draft is to document clear, simple, and we= ll-understood technical approaches that can be implemented in the real worl= d. =0A> =0A> Therefore, for LOADng, while we are keeping exploring new idea= s and options, those options won't exist in the IETF draft until we are sur= e that they can serve the real world (based on more operational experiences= and tests in different scenarios). =0A> =0A> best=0A> =0A> Jiazi=0A> =0A> = On Apr 4, 2013, at 11:49 AM, Jiazi Yi wrote:=0A> =0A> > = Hi, =0A> > =0A> > I would be careful when talking about "session" in the ne= twork layer. I think you are more talking about data transmission between t= wo nodes(routers)?=0A> > =0A> > In fact, there have been several publicatio= ns about the performance of LOADng and its extensions. More publications ar= e in the pipeline. =0A> > Please check:=0A> > =0A> > LOADng: Towards AODV V= ersion 2=0A> > IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Conferenc= e=0A> > Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere=0A> > http://www-m= obile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID1141082.PDF=0A> > = =0A> > Smart Route Request for On-demand Route Discovery in Constrained Env= ironments=0A> > IEEE ICWITS 2012, IEEE International Conference on Wireless= Information Technology and Systems=0A> > Jiazi Yi, Thomas Clausen, Antonin= Bas=0A> > http://hipercom.thomasclausen.net/resteam/data/publications/1549= 42d0d353eb00ae8ff62c37d68175.pdf=0A> > =0A> > Efficient Data Acquisition in= Sensor Networks:Introducing (the) LOADng Collection Tree Protocol=0A> > IE= EE WiCom 2012, The 8th IEEE International Conference on Wireless=0A> > Comm= unications, Networking and Mobile Computing.=0A> > Jiazi Yi, Thomas Clausen= , Axel Colin de Verdiere=0A> > http://hipercom.thomasclausen.net/resteam/da= ta/publications/1b5774b6394c71a44d49330f9d2e4ee5.pdf=0A> > =0A> > Expanding= Ring Search for Route Discovery in LOADng Routing Protocol=0A> > The 1st I= nternational Workshop on Smart Technologies for Energy, Information and Com= munication=0A> > Antonin Bas, Jiazi Yi, Thomas Clausen=0A> > http://hiperco= m.thomasclausen.net/resteam/data/publications/0c54e160b9e3aba9e7c383f64c1fd= a03.pdf=0A> > =0A> > =0A> > There is also a draft about interop test of LOA= Dng:=0A> > =0A> > Experience with the LOADng routing protocol for LLNs=0A> = > T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, SATOH. = H. Y. Morii=0A> > http://tools.ietf.org/html/draft-lavenu-lln-loadng-intero= perability-report=0A> > =0A> > best=0A> > =0A> > Jiazi=0A> > =0A> > On Apr = 3, 2013, at 10:42 PM, AHMED AWAMRY wrote:=0A> >= =0A> >> Hi,=0A> >> =0A> >> Thank you for your answer. I mean by topology d= iscovery that finding routes to the required destination (constructing rout= ing table). As you know, this phase is implemented on demand and in case of= RERR. I want to mention that the data collection cycle is repeated a lot o= f times (for example if there will be a session between two nodes) so, it's= good to mention the results and the test cases regarding the data collecti= on cycle because it will be very effective measurement=A0 for the routing p= rotocol behavior.=0A> >> =0A> >> =0A> >> Thanks,=0A> >> Ahmed A. Elawamry,= =0A> >> =0A> >> From: Jiazi Yi =0A> >> To: Ahmed A. Elawa= mry =0A> >> Cc: manet@ietf.org =0A> >> Sent: Tu= esday, April 2, 2013 10:56 PM=0A> >> Subject: Re: [manet] LOADng Data Colle= ction Cycle=0A> >> =0A> >> Hi, =0A> >> =0A> >> I'm not sure what's your def= inition of "topology discovery" and "data collection cycle". =0A> >> The co= ntrol plan of LOADng is about "find the desired routes on demand". The data= plan/forwarding has no significant difference with other routing protocols= - it's simply hop-by-hop IP forwarding. The only difference is that if the= re is no available route, LOADng needs to trigger a route discovery (normal= routing protocol do "best effort"). =0A> >> =0A> >> best=0A> >> =0A> >> Ji= azi=0A> >> =0A> >> On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry wrote:=0A> >> =0A> >>> Hello All,=0A> >>> =0A> >>> I'm n= ew to the MANET working group but i am following the mailing list=0A> >>> r= egarding the LOADng protocol. As mentioned at the LOADng drafts that it is= =0A> >>> a reactive routing protocol extracted from the AODV; Thus, it has = two cycles=0A> >>> (topology discovery and data collection cycle). Most of = the discussions and=0A> >>> results are about the topology discovery cycle = but i didn't found the=0A> >>> corresponding results at the data collection= cycle as you know that the most=0A> >>> iterative operation is the data co= llection cycle not topology discovery. Are=0A> >>> there any justification = about that?!=0A> >>> =0A> >>> Thanks,=0A> >>> Ahmed A. Elawamry=0A> >>> =0A= > >>> =0A> >>> =0A> >>> --=0A> >>> View this message in context: http://iet= f.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html=0A> >>> Sent = from the IETF - manet mailing list archive at Nabble.com.=0A> >>> _________= ______________________________________=0A> >>> manet mailing list=0A> >>> m= anet@ietf.org=0A> >>> https://www.ietf.org/mailman/listinfo/manet=0A> >> = =0A> >> =0A> >> =0A> > =0A> =0A> =0A> ---947112896-553668440-1365325781=:85623 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jiazi,<= /span>

Please find my below rep= ly,
 

 
From: Jiazi Yi <= ;ietf@jiaziyi.com>
To:<= /b> AHMED AWAMRY <ahmed_awamry_86@yahoo.com>
Sent: Friday, April 5, 2013 11:18 AM Subject: Re: [manet] LOA= Dng Data Collection Cycle

=0AHi,

On Apr 4, 2= 013, at 2:01 PM, AHMED AWAMRY <ahmed_awamry_86@yahoo.com<= /a>> wrote:

> Hi Jiazi,
>
> Thank you for illustr= ating the difference between the IETF draft and the scientific publications= . Also, regarding the publications sent. I have some questions about the re= sults listed at the sent publications.
>
> 1. What is the prop= agation delay set on evaluating the End-To-End delay? as i know that the pr= opagation delay affects largely the end-to-end delay result. This is becaus= e , when you changed the propagation delay of the channel (wireless or wire= d) you will gain different results.

The propagation delay depends on= the lower-layer protocol used. In our simulations for LOADng evaluation, i= t's 802.11b.

=0A=0ASo, y= ou use nodes of 250m range, Mesh topology connected.We could=0Aconsider LOA= Dng as Layer 3 protocol, is this right?  
=0A=0A

>
> 2. Regarding the overhead, I think&nbs= p; that there are two points of view related to the overhead:
> =                   A. Network= Overhead (like the one mentioned at the papers)
>     = ;               B. Processing Overhead = (like memory usage and required processing)
> Did you estimate the fa= ctor *2.B*? if yes, what is its value?

The "processing overhead" for= an on-demand protocol like LOADng is trivial, with O(n) complexity.

=0A=0A
 I mean by processing overh= ead,the overhead=0Aintroduced by the protocol to be implemented, (How many = events executed to=0Aperform the protocol?) Also, the memory usage used to = implement or simulate the=0Aprotocol (I think the LOADng interoperability-re= port mentioned=0A6000-lines= Java code, is it for implementation or test?). This will be= =0Avery efficient to select the suitable IC (MCU or DSP) to implement the p= rotocol.
=0A=0A
best

Jiazi
<= br>Regards,
Ahmed A. Elawamry,
>
>   
>&n= bsp;   Thanks,
> 
> Ahmed A. Elawamry,
>
&= gt; From: Jiazi Yi <ietf@jiaziyi.com>
> To: AHMED AWAMRY <<= a ymailto=3D"mailto:ahmed_awamry_86@yahoo.com" href=3D"mailto:ahmed_awamry_= 86@yahoo.com">ahmed_awamry_86@yahoo.com>
> Cc: "manet@ietf.org" = <man= et@ietf.org>
> Sent: Thursday, April 4, 2013 12:14 PM
>= Subject: Re: [manet] LOADng Data Collection Cycle
>
> Hi Ahme= d,
>
> There is one important thing that I have to mention: s= ome of those publications introduce different options/extensions of LOADng,= but most of them are not part of LOADng draft (yet).
>
> This is generally because of the fundamental diff= erence between scientific publications and IETF Internet Draft (especially = standard track draft):
>
>  o The scientific publication= s is to investigate new approaches, and explore *possible* ideas that can b= e introduced to an Internet Draft.
>  o The IETF Internet Draf= t is to document clear, simple, and well-understood technical approaches th= at can be implemented in the real world.
>
> Therefore, for L= OADng, while we are keeping exploring new ideas and options, those options = won't exist in the IETF draft until we are sure that they can serve the rea= l world (based on more operational experiences and tests in different scena= rios).
>
> best
>
> Jiazi
>
> On Ap= r 4, 2013, at 11:49 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:
>
> > Hi,
> >
> > I would be ca= reful when talking about "session" in the network layer. I think you are mo= re talking about data transmission between two nodes(routers)?
> >=
> > In fact, there have been several publications about the perf= ormance of LOADng and its extensions. More publications are in the pipeline= .
> > Please check:
> >
> > LOADng: Towards AO= DV Version 2
> > IEEE VTC 2012 Fall, IEEE 76th Vehicular Technolog= y Conference
> > Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere<= br>> > http://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/D= ATA/PID1141082.PDF
> >
> > Smart Route Request for On-de= mand Route Discovery in Constrained Environments
> > IEEE ICWITS 2= 012, IEEE International Conference on Wireless Information Technology and S= ystems
> > Jiazi Yi, Thomas Clausen, Antonin Bas
> > http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d= 353eb00ae8ff62c37d68175.pdf
> >
> > Efficient Data Acqui= sition in Sensor Networks:Introducing (the) LOADng Collection Tree Protocol=
> > IEEE WiCom 2012, The 8th IEEE International Conference on Wir= eless
> > Communications, Networking and Mobile Computing.
>= > Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere
> > http://= hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71a44d4933= 0f9d2e4ee5.pdf
> >
> > Expanding Ring Search for Route D= iscovery in LOADng Routing Protocol
> > The 1st International Work= shop on Smart Technologies for Energy, Information and Communication
>= ; > Antonin Bas, Jiazi Yi, Thomas Clausen
> > http://hipercom.t= homasclausen.net/resteam/data/publications/0c54e160b9e3aba9e7c383f64c1fda03= .pdf
> >
> >
> > There is also a draft about interop test of LOADng:
> >
> > Experience with t= he LOADng routing protocol for LLNs
> > T. Clausen, A. Camacho, J.= Yi, A. Colin de Verdiere, Y. Igarashi, SATOH. H. Y. Morii
> > http://tools.ietf.org/html/draft-lavenu-lln-load= ng-interoperability-report
> >
> > best
> >=
> > Jiazi
> >
> > On Apr 3, 2013, at 10:42 PM= , AHMED AWAMRY <ahmed_awamry_86@yahoo.com> wrote:<= br>> >
> >> Hi,
> >>
> >> Thank= you for your answer. I mean by topology discovery that finding routes to t= he required destination (constructing routing table). As you know, this pha= se is implemented on demand and in case of RERR. I want to mention that the data collection cycle is repeated a lot of times (for example if there wil= l be a session between two nodes) so, it's good to mention the results and = the test cases regarding the data collection cycle because it will be very = effective measurement  for the routing protocol behavior.
> >= >
> >>
> >> Thanks,
> >> Ahmed A. = Elawamry,
> >>
> >> From: Jiazi Yi <ietf@jiaziyi.= com>
> >> To: Ahmed A. Elawamry <ahmed= _awamry_86@yahoo.com>
> >> Cc: manet@ietf.org
> >= ;> Sent: Tuesday, April 2, 2013 10:56 PM
> >> Subject: Re: [= manet] LOADng Data Collection Cycle
> >>
> >> Hi,
> >>
> >> I'm not sure what's your definition of= "topology discovery" and "data collection cycle".
> >> The co= ntrol plan of LOADng is about "find the desired routes on demand". The data= plan/forwarding has no significant difference with other routing protocols= - it's simply hop-by-hop IP forwarding. The only difference is that if the= re is no available route, LOADng needs to trigger a route discovery (normal= routing protocol do "best effort").
> >>
> >> be= st
> >>
> >> Jiazi
> >>
> >&= gt; On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry <ahmed= _awamry_86@yahoo.com> wrote:
> >>
> >>> = Hello All,
> >>>
> >>> I'm new to the MANET = working group but i am following the mailing list
> >>> regarding the LOADng protocol. As mentioned at the LOADng drafts that it i= s
> >>> a reactive routing protocol extracted from the AODV;= Thus, it has two cycles
> >>> (topology discovery and data = collection cycle). Most of the discussions and
> >>> results= are about the topology discovery cycle but i didn't found the
> >= >> corresponding results at the data collection cycle as you know tha= t the most
> >>> iterative operation is the data collection = cycle not topology discovery. Are
> >>> there any justificat= ion about that?!
> >>>
> >>> Thanks,
>= >>> Ahmed A. Elawamry
> >>>
> >>> =
> >>>
> >>> --
> >>> View th= is message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycl= e-tp363492.html
> >>> Sent from the IETF - manet mailing= list archive at Nabble.com.
> >>> _________________________= ______________________
> >>> manet mailing list
> >= >> manet@ietf.org
> >>> https://www.ietf.org/mailman/listi= nfo/manet
> >>
> >>
> >>
>= >
>
>
>



---947112896-553668440-1365325781=:85623-- From abdussalambaryun@gmail.com Mon Apr 8 11:35:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053FA21F8EDF for ; Mon, 8 Apr 2013 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qmAoqDKtkSB for ; Mon, 8 Apr 2013 11:35:42 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id F064C21F8E63 for ; Mon, 8 Apr 2013 11:35:41 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so6008192wgh.6 for ; Mon, 08 Apr 2013 11:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+CVpo4FPAiYzpOClH0siSIP1l1mjoqvguoEdiKV+osg=; b=DMw+93bjkpcA2O0EYuSzSOk8oVSsObaDbwmo7iMdgeafCTkf1Bp6VDBRkSr/2HlO7D nCK1tjIkfm9aQifS6GSuYY1iASvdKFYFaIGGzcFlRgrBY7aZpTc3KnZFPlzFJ9C5ED8u z70qj7mU7ZHuym+6FBo5Ki/169TH3maqIUc89pS43Vn+S2j+oVqieg0/aTlbMmxQofXf BmVl7bW0jrjuxRWJYKw4s4102Ho1Lo9KQphTi9ETnHoCBAuwEnQ0LISPzcFMgvid2GqM EueasVVQYGTV4cB+6g6tb6dTrV/d9arr572Edf3FowtjVvAbNNPhls+ZYxwG+B7uNa4F zkaA== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr33035786wjb.24.1365446140753; Mon, 08 Apr 2013 11:35:40 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Mon, 8 Apr 2013 11:35:40 -0700 (PDT) Date: Mon, 8 Apr 2013 20:35:40 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:35:44 -0000 This message Author: Abdussalam Baryun Classified: I-D Review Reply to your WGLC request dated 25/03/2013 The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 08/04/2013 Reviewer Comment AB#1: Objective and Introduction ++++++++++++++++++++++++++++++++++++ Copyright Notice: Copyright (c) 2012 IETF Trust and the person identified as the message author. All rights reserved. This message is to comment on the MANET WG work in progress I-D: draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message may contain parts/texts of the I-D under review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [I-D] Abstract: [I-D] This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. AB>question> What is the meaning of *common* security threats? Mentioned in the abstract, AB>question> How can I define threats when I don=92t know on which layer NHDP[RFC6130] is located in router, is it in L4 or L3. Please define that you concern with IP layer if it is the only you concern with. [I-D] Section 1.Introduction: [I-D] The information acquired by NHDP is used by other protocols, such as OLSRv2 [OLSRv2] and SMF [RFC6621]. AB> please add> AODVv2 as reactive protocol using NHDP, not only proactive, [I-D] As wireless radio waves can be captured as well as transmitted by any wireless device within radio range AB>confused> not true, different antennas have different waves/frequencies, please delete. [I-D] The document analyses possible attacks and mis-configurations on NHDP and outlines the consequences of such attacks/mis-configurations to the state maintained by NHDP in each router (and, thus, made available to protocols using this state). AB> I don=92t think it makes full analyses for NHDP threats? Please see threat analysis by Tsao et al (2013) [1]. AB> the doc should consider information exchanged attacks and network attacks as well. Section 2. Terminology: AB> you don=92t define *Threat*, and *Attack*, please do same definition as threat analysis draft in ROLL WG (or refer to it). [I-D] Compromised NHDP Router: An attacker, present in the network and which generates syntactically correct NHDP control messages. Control messages emitted by a Compromised NHDP router may contain additional information, or omit information, as compared to a control message generated by a non-compromized NHDP router located in the same topological position in the network. AB> you mention network position, or topological position, but why the document ignores the network domain(s) (just topology), could the NHDP threats affect the network domain policy/states? If not say so, The Message-References: [1] http://tools.ietf.org/html/draft-ietf-roll-security-threats-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is not the last comment, still under process, Regards AB ---------------------------------------------------------------------------= ------------ This message is not sent to private email boxes, but sent to IETF MANET mail box. This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. ---------------------------------------------------------------------------= ------------ On 3/25/13, Stan Ratliff (sratliff) wrote: > WG, > > I've re-started the WGLC on this document. There's a 2-week WGLC period, > ending on April 8, 2013. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Apr 8 12:01:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD221F9774 for ; Mon, 8 Apr 2013 12:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fUS+Z5YrYz5 for ; Mon, 8 Apr 2013 12:01:03 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8C21F9733 for ; Mon, 8 Apr 2013 12:01:02 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id w15so4063956vbf.18 for ; Mon, 08 Apr 2013 12:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=tqTxlfO4Jb8/ARppnK6yaJJ0zr+EjthWodThmzm8s5E=; b=zEJkE+0UT5YTtV0oKfJX2O0DxaVCJXjlUW2I1JhK7cGxT6bXEhQuhMn8m9WgBQuTxA ku7rMJdqnYa7aQxX+Duj/AvnDecoP0K1TfvkZDPq4NK4AMNkdsT6mKtyJfHO2N+SnuIG E1Zj1kex9ls7LTlOWwQVU7ObPt6KeyjpZ/Oes= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=tqTxlfO4Jb8/ARppnK6yaJJ0zr+EjthWodThmzm8s5E=; b=TJ9kRiWblxdvE30Ve7Q8KQU77pjp8JR5FOsZ0w3PVY4C79NaKxqohMKnCH3US9rJPg mXzVZttj85ut/8cEOawd9GMlG+QdcbHKnZMS4W04a2/PNfMdOIMQ3KtS6Ad7LEZK5HJj b26Ke4yO+jxBvQsXRP7gR3QQdzcz2ROT8Z91xNMO2oedaktcoAgxgn+qPAErx7io5D2O b4YDB6QRLOyaei1LmJbm0d6e2rchJq68+O1VGvLt7Z19BJKMqfJrgN+Z1M77r2wHkVIF E26yVsIOjBkhy/69Pk81uBnsFs1LV7k97O4+UnLAxtFH1wvJAUF0XwUU1U5Rn2U/KzHM gEBw== MIME-Version: 1.0 X-Received: by 10.220.137.145 with SMTP id w17mr10393065vct.73.1365447659565; Mon, 08 Apr 2013 12:00:59 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Mon, 8 Apr 2013 12:00:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 12:00:59 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnGS9JhF1HF0WPmZXi7anVUotznsH7PFxNi6/FzI5T2mnDm//7EnrglLHoJWqv4QGHNpB9H Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:01:06 -0000 AB, see my answer below (note my reply represents my individual opinion; I don't claim to speak for the whole author group): On Mon, Apr 8, 2013 at 11:35 AM, Abdussalam Baryun wrote: [...] > This message is to comment on the MANET WG work in progress I-D: > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > may contain parts/texts of the I-D under review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [I-D] Abstract: > [I-D] This document analyses common security threats of the Neighborhood > Discovery Protocol (NHDP), and describes their potential impacts on > MANET routing protocols using NHDP. > > AB>question> What is the meaning of *common* security threats? > Mentioned in the abstract, I think the word is fairly clear. See http://dictionary.reference.com/browse/common (definition 4/5) > > AB>question> How can I define threats when I don=92t know on which layer > NHDP[RFC6130] is located in router, is it in L4 or L3. Please define > that you concern with IP layer if it is the only you concern with. That is given by RFC6130, which is running on the IP layer. I think this is not a task of NHDP-sec-threats to define. > > [I-D] Section 1.Introduction: > > [I-D] The information acquired by NHDP is used by other protocols, such a= s > OLSRv2 [OLSRv2] and SMF [RFC6621]. > > AB> please add> AODVv2 as reactive protocol using NHDP, not only proactiv= e, AODVv2 has no normative reference to RFC6130. In many cases of AODVv2 deployments, I don't think that RFC6130 would be used (whereas it must be used for OLSRv2 and SMF). I am against adding a reference. Anyway, the sentence just lists some example protocols ("such as..."). > > [I-D] As wireless radio waves can be captured as well as transmitted > by any wireless > device within radio range > > AB>confused> not true, different antennas have different > waves/frequencies, please delete. I think that this is fairly clear; it's about contrasting communication over cable vs wireless, where the access to the channel is much easier, i.e., security threats can be exploited more easily since there is no physical access protection (read: cable). > > [I-D] The document analyses possible attacks and mis-configurations on > NHDP and outlines the consequences of such attacks/mis-configurations > to the state > maintained by NHDP in each router (and, thus, made available to > protocols using this state). > > AB> I don=92t think it makes full analyses for NHDP threats? Please see > threat analysis by Tsao et al (2013) [1]. > > AB> the doc should consider information exchanged attacks and network > attacks as well. I think that this is exactly what NHDP-sec-threats does; section 4 describes the possible exploits when using no protection of NHDP. Section 5 outlines the consequences for protocols using NHDP. > > Section 2. Terminology: > > AB> you don=92t define *Threat*, and *Attack*, please do same definition > as threat analysis draft in ROLL WG (or refer to it). The words "threat" and "attack" are pretty well known; I don't see any reason why they are ambiguous. I don't see any reason to cite the ROLL draft; why is that related in any way to NHDP? It describes security threats to a completely different protocol. > > [I-D] Compromised NHDP Router: An attacker, present in the network and > which generates syntactically correct NHDP control messages. > Control messages emitted by a Compromised NHDP router may contain > additional information, or omit information, as compared to a > control message generated by a non-compromized NHDP router located > in the same topological position in the network. > > AB> you mention network position, or topological position, but why the > document ignores the network domain(s) (just topology), could the NHDP > threats affect the network domain policy/states? If not say so, I don't understand your point. What do you mean? Best regards Ulrich > > The Message-References: > [1] http://tools.ietf.org/html/draft-ietf-roll-security-threats-01 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This is not the last comment, still under process, > > Regards > AB > > -------------------------------------------------------------------------= -------------- > This message is not sent to private email boxes, but sent to IETF > MANET mail box. > This message and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > This message is in compliance with the IETF regulations. > -------------------------------------------------------------------------= -------------- > > On 3/25/13, Stan Ratliff (sratliff) wrote: >> WG, >> >> I've re-started the WGLC on this document. There's a 2-week WGLC period, >> ending on April 8, 2013. >> >> Regards, >> Stan >> _______________________________________________ >> 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 internet-drafts@ietf.org Mon Apr 8 15:13:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223AA21F92EF; Mon, 8 Apr 2013 15:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXuwB7v5faNp; Mon, 8 Apr 2013 15:13:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E429F21F8FFA; Mon, 8 Apr 2013 15:13:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130408221343.9421.13767.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 15:13:43 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:13:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Optimized Link St= ate Routing Protocol version 2 Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-mib-06.txt Pages : 76 Date : 2013-04-08 Abstract: This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ulrich@herberg.name Mon Apr 8 15:20:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF021F918C for ; Mon, 8 Apr 2013 15:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8w9s7FUhTIr for ; Mon, 8 Apr 2013 15:20:47 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAA21F9184 for ; Mon, 8 Apr 2013 15:20:46 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so5876373veb.18 for ; Mon, 08 Apr 2013 15:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K47Hyp2BPkQLR3Ok6CPNWPNdMA7S5RMu+weQcnQBo3s=; b=fnYCqiX/q/MMljWaxWGw4eXyqNCrLj5u8yIC3DWhrN+rSgqMNXZ7jJIlCc89MFxayc 0iRSEueWQqb4GP73b7UMdbv9s3SKdy0xHLTaU+aHUbS8aTnayIYOUriSJFoGUFQ+TpjR Zj6AZlW/BYdxYw2tejEZQUk4E4+5dg5H4Vibw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=K47Hyp2BPkQLR3Ok6CPNWPNdMA7S5RMu+weQcnQBo3s=; b=Y8s1qZ3ds9BpD2GXjj3mcr8P4MWnNczEi8qUN8JidnEYTnIz6Rv2q5uFnRKn4DEj5a eT29nuj8Y9xPNRQ3qFf1Jc+EV3eftHwkmUElZRrFpDZXdvaVpvFWB+beiVj7Rj2fT3s0 XqpEaPnEd6hm+Q9FtKNwMOXbEsvO1FLLvx6o2RPPqqof/v29iIbFqgPr1SDFfNDLNBLR vq/WAFBfbdAh45e5hH4Rf/nw2u9tessJokeYgNugRYA+s3ITkWlRCkC12ppqMFGR5QgD Oqw6n/CrsBFOXfeE0U7IWN9lOoM/ZBjv23IR92Gnh4aeB/6oaJtmL5ohWmf8TbwxJqrd G7cw== MIME-Version: 1.0 X-Received: by 10.52.89.68 with SMTP id bm4mr14703703vdb.123.1365459646408; Mon, 08 Apr 2013 15:20:46 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Mon, 8 Apr 2013 15:20:46 -0700 (PDT) In-Reply-To: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> References: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> Date: Mon, 8 Apr 2013 15:20:46 -0700 Message-ID: From: Ulrich Herberg To: "adrian@olddog.co.uk" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQml3hvXjEGDgacRhCAImfQ1ve4zUP/uJye1xzKzGTtT+s0nnBDCtJEjyuTTrsrJtutwS8mo Cc: manet@ietf.org, "draft-ietf-manet-olsrv2-mib@tools.ietf.org" Subject: Re: [manet] AD review of draft-ietf-manet-olsrv2-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:20:48 -0000 Adrian, thank you for your review. We have submitted a new revision -06. See below: On Tue, Apr 2, 2013 at 1:46 PM, Adrian Farrel wrote: > Thanks for your work on this document, and sorry for the long time it > has taken me to review it. It looks like you have done a really > thorough job - I can normally pick a few holes in a MIB Thank you :-) > > I think the only big question we are going to get (again) is about the > level of write (and create) access. Do you think that it would be > helpful to add an Informational reference to > draft-nguyen-manet-management-00 and some discussion in the document > about why you have some level of write access? Maybe this is just a > little more text in Section 9. We have changed the section. Like I said in the last MANET meeting, I believe that OLSRv2-MIB (and SNMP in general) will only be used in a sub-set of MANET deployments. This subset has characteristics that don't differ as much from the Internet and deployment in which OSPF-MIB is used (in terms of centralized infrastructure, topology dynamicity, bandwidth etc). In cases where routers are fully distributed, have too little resources to run SNMP, bandwidth/loss rates are unsuitable, etc, I think that SNMP is not suitable, and that the IETF should come up with different approaches (cf COMAN). > > I think you should think about this while I run the IETF last call. > That will attract an OPS Dir review that may dwell on the point further. Yes, indeed. > --- > > My other comments are quite small and can all be taken as IETF last call > comments to be fixed later... Since we uploaded a new revision anyway, we have addressed these comments. > > > > The RFC Editor might become confused by the different uses of "XXXX" > in the document. It would be worth sorting them out just to make life > easier. See revision -06. > > --- > > Tiny point... > > In olsrv2AHoldTime you have... > a value = 3 x olsrv2TcInterval is > recommended. > But in draft-ietf-manet-olsrv2-15 you have > a value >= 3 x > TC_INTERVAL is RECOMMENDED. > > --- Good catch! Thanks! > > I think olsrv2LinkMetricType needs to be mentioned in Section 8 because, > according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences > of a change are quite significant. I added the following text: - olsrv2LinkMetricType - defines the type of the link metric that a router uses (e.g., ETX or hop-count). Whenever this value changes, all link metric information recorded by the router is invalid, causing a reset of information acquired from other routers in the MANET. Moreover, if olsrv2LinkMetricType on a router is set to a value that is not known to other routers in the MANET, these routers will not be able to establish routes to that router or transiting that router. Existing routes to the router with a olsrv2LinkMetricType unknown to other routers in the MANET will be removed. > > --- > > Possibly just me being puzzled: > > Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be > limited to Integer32 (0..65535)? I agree that larger would be a great > validation of OLSRv2, but I wondered how quickly we might reach that > threshold. > > Ditto olsrv2TibRouterTopologySetIndex Fixed in -06. We also fixed the wrong reference to OLSRv2 and removed the downref. Best regards Ulrich From abdussalambaryun@gmail.com Mon Apr 8 20:47:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2764C21F8F4D for ; Mon, 8 Apr 2013 20:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTpnK-jZfOXZ for ; Mon, 8 Apr 2013 20:47:08 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id E52F521F8F4A for ; Mon, 8 Apr 2013 20:47:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so3221297wib.6 for ; Mon, 08 Apr 2013 20:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=wcommXRClPXDNa0//0VrcLmYVpesRYIIYNYwbC0lPLo=; b=WqnCE35nHJ5/e3pyGQGMtF10D2dH4NBo33PPbQSkWT4Sm3VDh8tbdLWFXO8p0ex5Ui B5DNt+m6ukgUzTI5yw1vtlt12NaW9oMjGaiajG4KL6bG2Ucaqcor0la5XvmX1J5MCPsC y5wWtzI4lits0gyV3a0tSTYaCjkDzpRSI9tUEV5pVeP8E/IIt6OsY7ydIapGZZxQvgUp ZZQLCtsmvWti+LQOiXOUv+vkXa65AlBGnj0kPPTqEJhTWEUWiSjTywJ2YIxx5kEUQfef T7PEhDgymZZiq375Tpg0r3sHJKKmsgUa7Hv0bVv3FKxpNTfzdAOqbKJT1izKRw9cYX0g JuOQ== MIME-Version: 1.0 X-Received: by 10.180.187.129 with SMTP id fs1mr16784886wic.5.1365479226959; Mon, 08 Apr 2013 20:47:06 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Mon, 8 Apr 2013 20:47:06 -0700 (PDT) Date: Tue, 9 Apr 2013 05:47:06 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org Subject: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:47:09 -0000 This message Author: Abdussalam Baryun Classified: I-D Review Second Message Reply to your WGLC request dated 25/03/2013 The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 08/04/2013 Reviewer Comment AB#2: Questions and Comments ++++++++++++++++++++++++++++++++++++ Copyright Notice: Copyright (c) 2012 IETF Trust and the person identified as the message author. All rights reserved. This message is to comment on the MANET WG work in progress I-D: draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message may contain parts/texts of the I-D under review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Overall] AB> The I-D structure approach is a little not clear, because it states threats, but mostly describes the attacker possibility not the way attacker uses the NHDP to make threat. I suggest focus on: 1) NHDP messages, 2)IIB and NIB, then 3)Impact routing using NHDP (as you mentioned in section-5). Both point 1 and 2 are not clear in I-D (they were mentioned in RFC6130 security consideration section). I don=92t find in I-D about; threats against NHDP confidentiality, integrity, Info-Freshness, and availability (may be in other words or meanings, but these words are mostly used). AB> Using the words *Exploits Allowed by protocol* by Sanzgiri et al. (2002)[2] is better to clarify threats. In your approach you describe attacks as the threats. They are not the same thing. Please read to compare this I-D approach with [2]. I recommend editing *Exploits Allowed by NHDP* into the work to clarify threats, making it easier to read. [I-D][section 4.3] Eavesdropping does not pose a direct threat to the network nor to NHDP, AB> From above text, what is an *indirect threat* mentioned? How can we know if direct or indirect while information was accessed (lost privacy), means a threat, don=92t you think? Elsewhere you mention passive threat/attack where is that definition? AB> section 4.8 mentions my comments on the list before regarding attacks on sequence number, just you named it attack on link quality. It is ok. ------------------------ [Layer Protocol affects] AB> Does attacks on IP layer increase threats to NHDP? Not understood from = I-D. AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP? Does/Can NHDP possible depend on the lower layers, if yes, what are the threats? Please note that these issues mentioned in RFC6130 but not in this I-D. ---------------------- [The use of NHDP] AB> If there is an attack on NHDP does that mostly mean that its users are attacked as well? AB> In AODVv2 mentions that NHDP used to monitor and assure bi-directional links, does that use have threats, why not mentioned, please do. AB> Does the NHDP detect the attack neighbor? IMO, it can, please mention t= his. AB> Is the NHDP using an unreliable communication? If yes then should explain the threats of that. In high density of neighbors/malicious what is the threat? AB> Does the threat increase if packets have more neighbor messages packed in one packet? [I-D] [section 3] An Attacker has several ways of harming this neighbor discovery process: It can announce "wrong" information about its identity, postulate non-existent links, and replay HELLO messages. AB> wrong identity!, what about interface address, network address? ----------------------------- [NHDP-Messaging] AB> This I-D does not distinguish between IP packets and RFC5444 Packets, as to describe the influence of the attacks on both packets. AB> Regarding Invalid Hello Messages of: interface addresses or its IP addresses, and network addresses relate to threats, what are their influences to NHDP threats? AB> Please consider the Scenarios of RFC6130 Appendix F [Topology Picture] (from 1 to 11, if related). You need to explain how the threats in different topologies, as mentioned topology positions in introduction of this I-D. If no NHDP threats due to those different topologies then please mention no threats. IMHO, is important to mention, they are same number of neighbors, but different topologies with different NHDP threat levels. [RFC6130] This is acquired through HELLO message exchange between neighboring routers. This information is made available through the Interface Information Bases and Neighbor Information Base, describing the router=92s 1-hop neighborhood and symmetric 2-hop neighborhood. AB> As per above text of 6130, please explain threats of invalid IIB and NIB in the I-D. AB> In the I-D security consideration, you mention that you in this I-D make security consideration for NHDP, but in RFC6130 one of its security consideration mentions invalid messages. I expected to see Invalid Hello Messages as mentioned in RFC6130 security section 17.1, why not consider as an NHDP threat? AB> If a node receives the NHDP messages that are not as specified in procedure of RFC6130 section 10 and 10.1, then is that a threat? IMO, yes it is, please mention it. ------------------------------- [NHDP Security Considerations] [RFC6622][section 4] security in MANETs, "one size rarely fits all" and that MANET routing protocol deployment domains have varying security requirements ranging from "unbreakable" to "virtually none". AB> Different deployment domains, which make the security requirement different. So could we say threats are different also in different deployment domains. Please mention in this I-D. AB> wrong behavior can come from a malicious node, but it can also come from a neighbor that is malfunctioning. Do you consider both as same threats? This should be clear in I-D. This Message Reference: ------------------------------------ [2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc Network, IEEE ICNP, 2002. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is last message comment, I really hope this is useful, thanking you. Best Regards, Abdussalam Baryun ---------------------------------------------------------------------------= ------------ This message is not sent to private email boxes, but sent to IETF MANET mail box. This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. ---------------------------------------------------------------------------= ------------ > On 3/25/13, Stan Ratliff (sratliff) wrote: >> WG, >> >> I've re-started the WGLC on this document. There's a 2-week WGLC period, >> ending on April 8, 2013. >> >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Mon Apr 8 20:52:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB28821F8F4D for ; Mon, 8 Apr 2013 20:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cit0eSFob340 for ; Mon, 8 Apr 2013 20:52:43 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3621F8F4A for ; Mon, 8 Apr 2013 20:52:42 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so3222508wib.15 for ; Mon, 08 Apr 2013 20:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C7Ox81JK+J7iOApTgutiYuczdu2tQC5XqjAqNv9iiqQ=; b=KtHtjtkiS23NEZXsHBa0Xyf+O0fzPgiKbtVQlG75dUIIsgc/GkxmIxbvp6roiM/eWj 6xbL73f/pqpZfcsiMZESDeCeBVMnl6TSOx1HUCBuLGAvPDWMkhdIK2iJ8Nwwq4Cg1UHp qOOeK82nznfp78OQFz5kiKNEEVyFvGQYOT5k8PVICBA1KTvQreri28Rpu4HRyZ0hNPNA Pss09rfUxyEqgpaHJfx3YE3tC7bxuyjcxtpaLEn6KD6h+ySPnM9fc6v6YchqIUeOFvfP m7HzAOf0ymWGppVCI5uGHtddbN9iR1UopWPTZyb4Mr3A44Jr1OCYyrVDmO3/8DxM0t5I bMTg== MIME-Version: 1.0 X-Received: by 10.181.11.196 with SMTP id ek4mr16688833wid.30.1365479561385; Mon, 08 Apr 2013 20:52:41 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Mon, 8 Apr 2013 20:52:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 05:52:41 +0200 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:52:44 -0000 Just prefered to mention that NHDP is useful for both manet routing standards, because the threats is not about proactive or reactive, but threats around NHDP and its informations uses. AB On 4/8/13, Christopher Dearlove wrote: > On 8 Apr 2013, at 20:00, Ulrich Herberg wrote: >>> >>> [I-D] The information acquired by NHDP is used by other protocols, such >>> as >>> OLSRv2 [OLSRv2] and SMF [RFC6621]. >>> >>> AB> please add> AODVv2 as reactive protocol using NHDP, not only >>> proactive, >> >> AODVv2 has no normative reference to RFC6130. In many cases of AODVv2 >> deployments, I don't think that RFC6130 would be used (whereas it must >> be used for OLSRv2 and SMF). I am against adding a reference. Anyway, >> the sentence just lists some example protocols ("such as..."). > > Also, when an AODVv2 option or variant (AODVv2 is not final, so not clear > which yet) uses NHDP, it is not acting as a purely reactive protocol, but > has some proactive behaviour - its NHDP part in fact. From abdussalambaryun@gmail.com Mon Apr 8 21:33:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6142E21F907E for ; Mon, 8 Apr 2013 21:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcYLK4mQz4A1 for ; Mon, 8 Apr 2013 21:33:10 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96021F905A for ; Mon, 8 Apr 2013 21:33:09 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so4437473wgh.1 for ; Mon, 08 Apr 2013 21:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=1wjiJBU4U5DzDq9PjduZ5yno292xuUGFgfSwJbvGRqA=; b=tEwmVEUt75CphNAsQsWQccB7u5pjNkNtrDWfaJTM//S5WTTxPEpf1oq8e722zQ6Exe DS2vKvUbJPFKfMdAiPnpjZ95viwfKEY+dTVZmkdDHozQGN5vjxZn9OBnW0JIwgkUPyzP CbdcQcu+ki3jViBMrePhdjZj9twMD/1brAWp5208X0TNHBnLfSbvHUItbofOL+V9b8xl QkTNzLIQAw7k4y52V+7zARSdBRR+jhM3tpmBYDx1AGe0NAIG1awDCwtHpSLD3gYWblDd nMJH0F1SjZ0Hh6cgESOJAD7cCNgRziEsHlSvBzsGu97weS3XbWLWM+Qw8wKJOi3KrvQM 59XQ== MIME-Version: 1.0 X-Received: by 10.180.11.148 with SMTP id q20mr16875095wib.18.1365481988714; Mon, 08 Apr 2013 21:33:08 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Mon, 8 Apr 2013 21:33:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 06:33:08 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 04:33:11 -0000 Hi Ulrich, comments for the best of the draft, On 4/8/13, Ulrich Herberg wrote: > AB, > > see my answer below (note my reply represents my individual opinion; I > don't claim to speak for the whole author group): I understand that, > > On Mon, Apr 8, 2013 at 11:35 AM, Abdussalam Baryun > wrote: > [...] >> This message is to comment on the MANET WG work in progress I-D: >> draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message >> may contain parts/texts of the I-D under review >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> [I-D] Abstract: >> [I-D] This document analyses common security threats of the Neighborhood >> Discovery Protocol (NHDP), and describes their potential impacts on >> MANET routing protocols using NHDP. >> >> AB>question> What is the meaning of *common* security threats? >> Mentioned in the abstract, > > I think the word is fairly clear. See > http://dictionary.reference.com/browse/common > (definition 4/5) I mean why common why not ALL threats, or the explaining the *Exploits Allowed by the NHDP* as per the reference [2] I gave in my AB#2 message. > > >> >> AB>question> How can I define threats when I don=92t know on which layer >> NHDP[RFC6130] is located in router, is it in L4 or L3. Please define >> that you concern with IP layer if it is the only you concern with. > > That is given by RFC6130, which is running on the IP layer. I think > this is not a task of NHDP-sec-threats to define. I don't find that defined, but if so, does IP threats affect the NHDP threa= ts? > > >> >> [I-D] Section 1.Introduction: >> >> [I-D] The information acquired by NHDP is used by other protocols, such >> as >> OLSRv2 [OLSRv2] and SMF [RFC6621]. >> >> AB> please add> AODVv2 as reactive protocol using NHDP, not only >> proactive, > > AODVv2 has no normative reference to RFC6130. In many cases of AODVv2 > deployments, I don't think that RFC6130 would be used (whereas it must > be used for OLSRv2 and SMF). I am against adding a reference. Anyway, > the sentence just lists some example protocols ("such as..."). > Just I prefered showing that NHDP explains all its threats when used by different MANET routings, if we explain one only then we don't explain all threats. > >> >> [I-D] As wireless radio waves can be captured as well as transmitted >> by any wireless >> device within radio range >> >> AB>confused> not true, different antennas have different >> waves/frequencies, please delete. > > I think that this is fairly clear; it's about contrasting > communication over cable vs wireless, where the access to the channel > is much easier, i.e., security threats can be exploited more easily > since there is no physical access protection (read: cable). > Please delete word *any* and change to *some*, because think it is not clear to me, >> >> [I-D] The document analyses possible attacks and mis-configurations on >> NHDP and outlines the consequences of such attacks/mis-configurations >> to the state >> maintained by NHDP in each router (and, thus, made available to >> protocols using this state). >> >> AB> I don=92t think it makes full analyses for NHDP threats? Please see >> threat analysis by Tsao et al (2013) [1]. >> >> AB> the doc should consider information exchanged attacks and network >> attacks as well. > > > I think that this is exactly what NHDP-sec-threats does; section 4 > describes the possible exploits when using no protection of NHDP. > Section 5 outlines the consequences for protocols using NHDP. I need analysis which was mentioned but not done. I mean what is exploited by the NHDP messages and the NHDP IIB and NIB, don't see much explaining about those information and the exploitation. Yes in section 4 explains but in the point of view of the attacker, and no possibility of malfunctions or other issues, > > >> >> Section 2. Terminology: >> >> AB> you don=92t define *Threat*, and *Attack*, please do same definition >> as threat analysis draft in ROLL WG (or refer to it). > > The words "threat" and "attack" are pretty well known; I don't see any > reason why they are ambiguous. I don't see any reason to cite the ROLL > draft; why is that related in any way to NHDP? It describes security > threats to a completely different protocol. In the I-D the titles of section make me feel that authors made; threats =3D attacks, so I need that to be answered in the doc. > > >> >> [I-D] Compromised NHDP Router: An attacker, present in the network and >> which generates syntactically correct NHDP control messages. >> Control messages emitted by a Compromised NHDP router may contain >> additional information, or omit information, as compared to a >> control message generated by a non-compromized NHDP router located >> in the same topological position in the network. >> >> AB> you mention network position, or topological position, but why the >> document ignores the network domain(s) (just topology), could the NHDP >> threats affect the network domain policy/states? If not say so, > > > I don't understand your point. What do you mean? Is the NHDP threats affecting the network domains? as it was mentioned in the RFC6130 the different deployments and low-value WSN. Does different deployments mean different NHDP threats. Regards AB From stbryant@cisco.com Tue Apr 9 00:20:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D97C21F8E77 for ; Tue, 9 Apr 2013 00:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtIpTf3idswX for ; Tue, 9 Apr 2013 00:20:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 89BE221F8F39 for ; Tue, 9 Apr 2013 00:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1365492022; x=1366701622; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=QoMy1EEbyj56p2u8vtEP10LBU7IZ5XghYWP9uPIqK28=; b=E98zXgdNOAFlAtdpEYeZjNWBjK5qTkVKDCKqC8kfPcKqo9OTHN9AdcJH dGOnYjWGuAS68j2pf56XvwCIzJ4Oy2XhRin2VH5XsjAGhYagQva9gGopu 0d5m0ako3C3Gvm/1fwiJWqzMYrdExKYp7opG+bwCWqMarHLJFDT1Ou3CA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMFAA/AY1GQ/khN/2dsb2JhbABRgwaBfr0TgmWBERZ0gh8BAQEDAThAEQsYCRYPCQMCAQIBRRMIAQGICgata5AvjykWgysDlnSRDYMM X-IronPort-AV: E=Sophos;i="4.87,436,1363132800"; d="scan'208";a="152671415" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2013 07:20:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r397KFsb005001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Apr 2013 07:20:15 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r397KEnh004073; Tue, 9 Apr 2013 08:20:15 +0100 (BST) Message-ID: <5163C12E.1090205@cisco.com> Date: Tue, 09 Apr 2013 08:20:14 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:20:23 -0000 I respond somewhat out of contest to the radio systems text below. On 08/04/2013 19:35, Abdussalam Baryun wrote: > > [I-D] As wireless radio waves can be captured as well as transmitted > by any wireless > device within radio range I think the text should surely be As radio signals can be received as well as transmitted by any compatible wireless device within radio range > > AB>confused> not true, different antennas have different > waves/frequencies, please delete. Hm, the antennas are normally the least discriminatory part of a radio system. Stewart From ulrich@herberg.name Tue Apr 9 00:31:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC021F9120 for ; Tue, 9 Apr 2013 00:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c54yK-lX-rzH for ; Tue, 9 Apr 2013 00:31:51 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5021F907E for ; Tue, 9 Apr 2013 00:31:51 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ht10so275740vcb.41 for ; Tue, 09 Apr 2013 00:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=e+0OlZyh4sQfloBBxI06jT0A7F9z4DBFn1Q1EFCR5uA=; b=UMCAwE2kEk5Fz6fK/FmYagxpIdV9ewT1W5aYVcCDZ9tUyQWFFeqJFgh/BlFfltQxul LimCkLudSb5hQ9QDRuT7TBeO9iyLOomk90Un38+500dETmf3awtPSW0Sqf87A6uyzgNz OjCiH9qwoCpDrcI9kBQFm7A++/U1MelBE4ur4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=e+0OlZyh4sQfloBBxI06jT0A7F9z4DBFn1Q1EFCR5uA=; b=IWM8uqov5tgeMFxJlvWhLkTsrDYS78VUsEd+NJdAj61UhLwX3b8J9UmmxLHrcNxqC9 4s/IWmNR+8WrWld8n1gvIOce0K3VqWXG0y8uhhcSgYt8HWbYs18jf5Lsy1JtES9zO+XJ ZOuJE2nnMrQdwK7gkmlcPvm6tcT54gMqrSSwHesQvyeEc/yha88Fp2MPhBhqqRtcf1sv xcgePi7zG23Jy4qIp0KjWe9b+OpkHJ9Z07r7eqkBvZkT4k4oJ21KxUboS1Nxiyo5mjT0 dELX6JcdcSZZbDSGldTfI4EKmmPOax4gj7ocIRAXKkvtGKg/+8DkYAloAIOt6pfEh/Cg tzJg== MIME-Version: 1.0 X-Received: by 10.220.153.143 with SMTP id k15mr18560136vcw.13.1365492710918; Tue, 09 Apr 2013 00:31:50 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 00:31:50 -0700 (PDT) In-Reply-To: <5163C12E.1090205@cisco.com> References: <5163C12E.1090205@cisco.com> Date: Tue, 9 Apr 2013 00:31:50 -0700 Message-ID: From: Ulrich Herberg To: Bryant Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmVRgomxDzhyAzuoykeQgfNmnVj3TON2LbBmhVvooJBRTvHUAmZR32TKnbkbsLCmEwazWZX Cc: manet@ietf.org Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:31:54 -0000 Stewart, On Tue, Apr 9, 2013 at 12:20 AM, Stewart Bryant wrote: [...] >> [I-D] As wireless radio waves can be captured as well as transmitted >> by any wireless >> device within radio range > > > I think the text should surely be > > As radio signals can be received as well as transmitted > by any compatible wireless device within radio range Thanks, I think this sentence is better than the one in the draft. We will update it. Ulrich > > >> >> AB>confused> not true, different antennas have different >> waves/frequencies, please delete. > > > Hm, the antennas are normally the least discriminatory part of a > radio system. > > Stewart From Chris.Dearlove@baesystems.com Tue Apr 9 01:57:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D49221F8F24 for ; Tue, 9 Apr 2013 01:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fejCEQxac6j1 for ; Tue, 9 Apr 2013 01:57:48 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 60E6A21F9026 for ; Tue, 9 Apr 2013 01:57:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,437,1363132800"; d="scan'208";a="327411058" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Apr 2013 09:57:46 +0100 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r398vjBl006210 for ; Tue, 9 Apr 2013 09:57:46 +0100 X-IronPort-AV: E=Sophos;i="4.87,437,1363132800"; d="scan'208";a="12969087" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 09 Apr 2013 09:57:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 09:57:44 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 Thread-Index: AQHONIf0T2AOoQ2B8kigZbEM19PMx5jNlXCQ Date: Tue, 9 Apr 2013 08:57:43 +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=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 08:57:49 -0000 AB> you don't define *Threat*, and *Attack* Personally, I would start with ISO 27000 which has: =3D=3D=3D=3D=3D 2.45 threat potential cause of an unwanted incident, which may result in harm to a syst= em or organization 2.4 attack attempt to destroy, expose, alter, disable, steal or gain unauthorized acce= ss to or make unauthorized use of an asset (2.3) 2.3 asset anything that has value to the organization NOTE There are many types of assets, including: a) information (2.18); b) software, such as a computer program; c) physical, such as computer; d) services; e) people, and their qualifications, skills, and experience; and f) intangibles, such as reputation and image. 2.18 information asset knowledge or data that has value to the organization =3D=3D=3D=3D=3D (The rules are that you may substitute in the definition, so attack may be = parsed as "attempt to destroy, expose, alter, disable, steal or gain unauth= orized access to or make unauthorized use of anything that has value to the= organization".) [There is also an overlapping set of definitions in ISO 27032, but 27000 is= more relevant here.] I don't know if there are any RFCs that reference ISO 27000. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From yi.jiazi@gmail.com Tue Apr 9 02:52:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D421F9354 for ; Tue, 9 Apr 2013 02:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.58 X-Spam-Level: **** X-Spam-Status: No, score=4.58 tagged_above=-999 required=5 tests=[AWL=-2.610, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zploXgeVPuf9 for ; Tue, 9 Apr 2013 02:52:57 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6181321F934C for ; Tue, 9 Apr 2013 02:52:56 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so3456860wib.8 for ; Tue, 09 Apr 2013 02:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=CkS9wcf6+oCSfbJh+KKMvBDogZhwOdpKkNX/eYlgCG8=; b=XJ/HLcrq6txOAbYGDHXuTyE6lJ9dTPzA8zGV9vcdYaatMak+GlmLImNE0tnXH7Y5Dy wfvZH6Lxhy+SGW5I7K960NTqNpWCWL8QfEuOoGdx5R2LqhOo09COvcRAj6u6tyezdw7z vg41Egc58eD0a1vAibQ//dmApyU3ojykzpqC7Yuncu0m/QDleSACWSh3kY/cgDGJNKyV 9MxBy5skrAlEUvtSIK89XaBxJuZmbIzmeL7ixOBHm91OXlDXH6BwFKFBHy1+3Ksz/oMr U2FIzMwL8q45rrrXdEXOTfh7xCvWAbRxLq/r9bkpPLUPFb9gEWoCFqWKnzg+nepz4P6t PFww== X-Received: by 10.194.235.196 with SMTP id uo4mr37084842wjc.30.1365501175340; Tue, 09 Apr 2013 02:52:55 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id s2sm27670236wib.4.2013.04.09.02.52.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 02:52:54 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: Date: Tue, 9 Apr 2013 11:52:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1503) Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:52:58 -0000 I agree with Ulrich's reply.=20 We can change=20 >> [I-D] As wireless radio waves can be captured as well as transmitted >> by any wireless >> device within radio range to=20 > As radio signals can be received as well as transmitted > by any compatible wireless device within radio range It would be clearer.=20 best Jiazi On Apr 8, 2013, at 9:00 PM, Ulrich Herberg wrote: > AB, >=20 > see my answer below (note my reply represents my individual opinion; I > don't claim to speak for the whole author group): >=20 > On Mon, Apr 8, 2013 at 11:35 AM, Abdussalam Baryun > wrote: > [...] >> This message is to comment on the MANET WG work in progress I-D: >> draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message >> may contain parts/texts of the I-D under review >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> [I-D] Abstract: >> [I-D] This document analyses common security threats of the = Neighborhood >> Discovery Protocol (NHDP), and describes their potential impacts on >> MANET routing protocols using NHDP. >>=20 >> AB>question> What is the meaning of *common* security threats? >> Mentioned in the abstract, >=20 > I think the word is fairly clear. See > http://dictionary.reference.com/browse/common > (definition 4/5) >=20 >=20 >>=20 >> AB>question> How can I define threats when I don=92t know on which = layer >> NHDP[RFC6130] is located in router, is it in L4 or L3. Please define >> that you concern with IP layer if it is the only you concern with. >=20 > That is given by RFC6130, which is running on the IP layer. I think > this is not a task of NHDP-sec-threats to define. >=20 >=20 >>=20 >> [I-D] Section 1.Introduction: >>=20 >> [I-D] The information acquired by NHDP is used by other protocols, = such as >> OLSRv2 [OLSRv2] and SMF [RFC6621]. >>=20 >> AB> please add> AODVv2 as reactive protocol using NHDP, not only = proactive, >=20 > AODVv2 has no normative reference to RFC6130. In many cases of AODVv2 > deployments, I don't think that RFC6130 would be used (whereas it must > be used for OLSRv2 and SMF). I am against adding a reference. Anyway, > the sentence just lists some example protocols ("such as..."). >=20 >=20 >>=20 >> [I-D] As wireless radio waves can be captured as well as transmitted >> by any wireless >> device within radio range >>=20 >> AB>confused> not true, different antennas have different >> waves/frequencies, please delete. >=20 > I think that this is fairly clear; it's about contrasting > communication over cable vs wireless, where the access to the channel > is much easier, i.e., security threats can be exploited more easily > since there is no physical access protection (read: cable). >=20 >=20 >>=20 >> [I-D] The document analyses possible attacks and mis-configurations = on >> NHDP and outlines the consequences of such attacks/mis-configurations >> to the state >> maintained by NHDP in each router (and, thus, made available to >> protocols using this state). >>=20 >> AB> I don=92t think it makes full analyses for NHDP threats? Please = see >> threat analysis by Tsao et al (2013) [1]. >>=20 >> AB> the doc should consider information exchanged attacks and network >> attacks as well. >=20 >=20 > I think that this is exactly what NHDP-sec-threats does; section 4 > describes the possible exploits when using no protection of NHDP. > Section 5 outlines the consequences for protocols using NHDP. >=20 >=20 >>=20 >> Section 2. Terminology: >>=20 >> AB> you don=92t define *Threat*, and *Attack*, please do same = definition >> as threat analysis draft in ROLL WG (or refer to it). >=20 > The words "threat" and "attack" are pretty well known; I don't see any > reason why they are ambiguous. I don't see any reason to cite the ROLL > draft; why is that related in any way to NHDP? It describes security > threats to a completely different protocol. >=20 >=20 >>=20 >> [I-D] Compromised NHDP Router: An attacker, present in the network = and >> which generates syntactically correct NHDP control messages. >> Control messages emitted by a Compromised NHDP router may contain >> additional information, or omit information, as compared to a >> control message generated by a non-compromized NHDP router located >> in the same topological position in the network. >>=20 >> AB> you mention network position, or topological position, but why = the >> document ignores the network domain(s) (just topology), could the = NHDP >> threats affect the network domain policy/states? If not say so, >=20 >=20 > I don't understand your point. What do you mean? >=20 > Best regards > Ulrich >=20 >=20 >>=20 >> The Message-References: >> [1] http://tools.ietf.org/html/draft-ietf-roll-security-threats-01 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> This is not the last comment, still under process, >>=20 >> Regards >> AB >>=20 >> = --------------------------------------------------------------------------= ------------- >> This message is not sent to private email boxes, but sent to IETF >> MANET mail box. >> This message and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> This message is in compliance with the IETF regulations. >> = --------------------------------------------------------------------------= ------------- >>=20 >> On 3/25/13, Stan Ratliff (sratliff) wrote: >>> WG, >>>=20 >>> I've re-started the WGLC on this document. There's a 2-week WGLC = period, >>> ending on April 8, 2013. >>>=20 >>> Regards, >>> Stan >>> _______________________________________________ >>> 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 internet-drafts@ietf.org Tue Apr 9 03:00:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40321F93C4; Tue, 9 Apr 2013 03:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXL5C3XTFTSv; Tue, 9 Apr 2013 03:00:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AB21F93B2; Tue, 9 Apr 2013 03:00:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409100047.27570.53864.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 03:00:47 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 10:00:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routi= ng Protocol OLSRv2 - Rationale Author(s) : Christopher Dearlove Thomas Heide Clausen Philippe Jacquet Filename : draft-ietf-manet-olsrv2-metrics-rationale-03.txt Pages : 29 Date : 2013-04-09 Abstract: OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Tue Apr 9 04:07:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEDE21F9138 for ; Tue, 9 Apr 2013 04:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ToQkscMoCgs for ; Tue, 9 Apr 2013 04:07:06 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 44E4621F9104 for ; Tue, 9 Apr 2013 04:07:06 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id e12so23008wgh.16 for ; Tue, 09 Apr 2013 04:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7df4bGD+ws1KGbq2mshRvm8F1/Xr6ox5smyFl00ym3c=; b=XhEmkeI5623fMcLfyJh/v3zWWPdX8h0PklldwxkU4ZHTRQXDc6wvNWeicl+k0Zbnu0 UXZHsaIvf9GJVkhVahBxhxXD8Ew/gQK33GL/NsicgqE8gjvNIJnav1GqXp6IHVILjpeF yn/BYW4Gfye0Fzk3EbyXpYrMPB3J59RqPdRSAovLTpsq3M+i2WifaxnLcUQjRQnj82W9 Jm6idH3vOObEkcicVx+wJu+Ql7ATHLg4UhLqMU1YQfoOZvFJpXsh9Z/2c5agCexICvmo WQgIzVcj00HDsBYaYYrtIFzhDtw58NaSqSHrhZSXUj9WTpcDW555BQTMZnvdK/I0o76W IJ2A== MIME-Version: 1.0 X-Received: by 10.180.187.129 with SMTP id fs1mr18901814wic.5.1365505625374; Tue, 09 Apr 2013 04:07:05 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 04:07:05 -0700 (PDT) In-Reply-To: <5163C12E.1090205@cisco.com> References: <5163C12E.1090205@cisco.com> Date: Tue, 9 Apr 2013 13:07:05 +0200 Message-ID: From: Abdussalam Baryun To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:07:07 -0000 Hi Stewart, The antennas are responsible for the radio range or coverage, there are directional antennas as well, but range is a distance not region, On 4/9/13, Stewart Bryant wrote: > I respond somewhat out of contest to the radio systems > text below. > > On 08/04/2013 19:35, Abdussalam Baryun wrote: >> >> [I-D] As wireless radio waves can be captured as well as transmitted >> by any wireless >> device within radio range > > I think the text should surely be > > As radio signals can be received as well as transmitted > by any compatible wireless device within radio range Thanks that you agreed that the first text was not clear, so I spoted that it was not true. I hove no objection to your text as it has same of my meaning, > >> >> AB>confused> not true, different antennas have different >> waves/frequencies, please delete. > > Hm, the antennas are normally the least discriminatory part of a > radio system. What you mean by normally? however, if we read any antenna communication book I don't think your above assumption is correct. Please don't ignore the wrods *radio-range* in the I-D text, so who is responsible for the radio range do you think? I know that there are other discriminatory in the PHY layer other than antenna but not for radio range. AB From abdussalambaryun@gmail.com Tue Apr 9 04:43:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0821F854F for ; Tue, 9 Apr 2013 04:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SI49hAX0FYX for ; Tue, 9 Apr 2013 04:43:49 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 24E6121F8651 for ; Tue, 9 Apr 2013 04:43:47 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so3552197wib.10 for ; Tue, 09 Apr 2013 04:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fw5Tf+LyjNLV7DfYJf0F7Wx7vU0CFvg42aKG9/oFiOQ=; b=yp+xyQDOqXhn82FQequj0ulcQEuxXo52ouJtwBvRH5BMPa+UhpNrrHAUH5M6LZrRwF APiJF2Kse3l19UfzVOC/kn/5bIsurFXLdsCRiQMOOgPHcHHKjahYZiE/cx7UiG0OJ1m/ Ohp+gPOqTP+QIp7/K56O9or35jVp5zJq823+QxzlVlyBzjDTAlgGXpcM2q1ol1uIQYIT 4jemZAr7Tytg+Od+n++8PTh4O5DvN3euzYQj7O2fiLpFEaJp2R/CsWRMxJn/aQHC248L 69eo49kzZdccgUIS4kOO4UW+a96fnDY7dI0hBec/vazNo8eBdotDWd2f0C24jqP0wh/F ODzA== MIME-Version: 1.0 X-Received: by 10.180.36.48 with SMTP id n16mr19053569wij.30.1365507827231; Tue, 09 Apr 2013 04:43:47 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 04:43:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 13:43:47 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:43:49 -0000 Hi Chris, The I-D seems not to define physical attacks (my understanding), which I was not sure of but [1] (mentioned in first AB#1 message) did include, but I think your input is prefered to include in the I-D or used, AB On 4/9/13, Dearlove, Christopher (UK) wrote: > AB> you don't define *Threat*, and *Attack* > > Personally, I would start with ISO 27000 which has: > > ===== > 2.45 > threat > potential cause of an unwanted incident, which may result in harm to a > system or organization > > 2.4 > attack > attempt to destroy, expose, alter, disable, steal or gain unauthorized > access to or make unauthorized use of > an asset (2.3) > > 2.3 > asset > anything that has value to the organization > NOTE There are many types of assets, including: > a) information (2.18); > b) software, such as a computer program; > c) physical, such as computer; > d) services; > e) people, and their qualifications, skills, and experience; and > f) intangibles, such as reputation and image. > > 2.18 > information asset > knowledge or data that has value to the organization > ===== > > (The rules are that you may substitute in the definition, so attack may be > parsed as "attempt to destroy, expose, alter, disable, steal or gain > unauthorized access to or make unauthorized use of anything that has value > to the organization".) > > [There is also an overlapping set of definitions in ISO 27032, but 27000 is > more relevant here.] > > I don't know if there are any RFCs that reference ISO 27000. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From Chris.Dearlove@baesystems.com Tue Apr 9 05:13:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4921F8DBF for ; Tue, 9 Apr 2013 05:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaN848AgiiLG for ; Tue, 9 Apr 2013 05:13:04 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7DE21F8D8E for ; Tue, 9 Apr 2013 05:13:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,438,1363132800"; d="scan'208";a="327508551" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Apr 2013 13:13:02 +0100 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r39CD0Fj005695 for ; Tue, 9 Apr 2013 13:13:00 +0100 X-IronPort-AV: E=Sophos;i="4.87,438,1363132800"; d="scan'208";a="13002027" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 09 Apr 2013 13:12:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 13:12:42 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 Thread-Index: AQHONIf0T2AOoQ2B8kigZbEM19PMx5jNlXCQgAAfuoCAABcFsA== Date: Tue, 9 Apr 2013 12:12:41 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 12:13:04 -0000 I'm neither recommending that a reference is included or excluded, I'm just= providing here where one good source of definitions. Whether to reference = it is a judgement call as to what is considered widely known, and what isn'= t. But that definition is not limited to physical attack. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: 09 April 2013 12:44 To: Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threa= ts-02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, The I-D seems not to define physical attacks (my understanding), which I was not sure of but [1] (mentioned in first AB#1 message) did include, but I think your input is prefered to include in the I-D or used, AB On 4/9/13, Dearlove, Christopher (UK) wrote= : > AB> you don't define *Threat*, and *Attack* > > Personally, I would start with ISO 27000 which has: > > =3D=3D=3D=3D=3D > 2.45 > threat > potential cause of an unwanted incident, which may result in harm to a > system or organization > > 2.4 > attack > attempt to destroy, expose, alter, disable, steal or gain unauthorized > access to or make unauthorized use of > an asset (2.3) > > 2.3 > asset > anything that has value to the organization > NOTE There are many types of assets, including: > a) information (2.18); > b) software, such as a computer program; > c) physical, such as computer; > d) services; > e) people, and their qualifications, skills, and experience; and > f) intangibles, such as reputation and image. > > 2.18 > information asset > knowledge or data that has value to the organization > =3D=3D=3D=3D=3D > > (The rules are that you may substitute in the definition, so attack may b= e > parsed as "attempt to destroy, expose, alter, disable, steal or gain > unauthorized access to or make unauthorized use of anything that has valu= e > to the organization".) > > [There is also an overlapping set of definitions in ISO 27032, but 27000 = is > more relevant here.] > > I don't know if there are any RFCs that reference ISO 27000. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From abdussalambaryun@gmail.com Tue Apr 9 06:14:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8F921F8B18 for ; Tue, 9 Apr 2013 06:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz8zZa0B5AqS for ; Tue, 9 Apr 2013 06:14:39 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2983E21F8526 for ; Tue, 9 Apr 2013 06:14:38 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so5372132wey.19 for ; Tue, 09 Apr 2013 06:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=90FBcHBtPutYt5B2Ca6oY/angUIigwPMGV0S1mCIrSo=; b=BpuE3C5e+TFdTdyD+TvDZOLNU1mDNktrNbVnQ0FscHvP6bedgEa655QU3WT66XvIAU 96uz8CGenQu10Mz/PCdX6stHqzafoDeZEe7xs+WOKXwkAN86KYB798iJpoQyrOMtjVub yOzMMbw+7HGQ7H6RYB7Wk8nWYkOefC7UaVMX+kXtUZBmKDYSgpuDAmlK08lfTuTnNjZp 5HQkF9sCb4yrRID+wutTMskYlje7ydbjtiJ90OVudI/vvKjQE8miS59wN+KTKdKqjGIb wuB7q/9e4G3ePi69DGlTfDzzfHdw0R3KJMKrdVkZxiazTH2uijZvweXCSkPSCRJwGloS iN4g== MIME-Version: 1.0 X-Received: by 10.180.89.243 with SMTP id br19mr19654103wib.5.1365513278320; Tue, 09 Apr 2013 06:14:38 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 06:14:38 -0700 (PDT) In-Reply-To: <20130312125139.8418.20659.idtracker@ietfa.amsl.com> References: <20130312125139.8418.20659.idtracker@ietfa.amsl.com> Date: Tue, 9 Apr 2013 15:14:38 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:14:40 -0000 Classified: Review of I-D Hi AODVv2 Editors, Why AODVv2-00 I-D has no normative reference to RFC6130? If it uses (optionally) it then SHOULD be normative (never felt I understood how we know when or when not normative). Regarding security consideration section, I recommend considering RFC6130 threats [1] and AODV threats [2]. Please read the message AB#2 [3]. [1] Herberg, U., et al. draft-ietf-manet-nhdp-sec-threats-02, work in progress, 2013. [2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc Network, IEEE ICNP, 2002. [3] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB --------------------------------------------------------------------------------------- This message is not sent to private email boxes, but sent to IETF MANET mail box. This message is owned by the sender. This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. --------------------------------------------------------------------------------------- On 3/12/13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-aodvv2-00.txt > Pages : 60 > Date : 2013-03-11 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-aodvv2-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Apr 9 06:25:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC521F8FC6 for ; Tue, 9 Apr 2013 06:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BPa29mJHlqB for ; Tue, 9 Apr 2013 06:25:13 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CCAE121F8F69 for ; Tue, 9 Apr 2013 06:25:12 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so5336660wer.12 for ; Tue, 09 Apr 2013 06:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=glhKN75RNtPiF4VxQ2cIpq2joG6T6/u4qDh98VHHt70=; b=FYq0sF1AovBXG1kyIkYXeCSUWVu5IU+nTHGLjHU0VO7uVIY+r6ZUbVbyNAG20VHIGm RJEvYQ93POnkIw6mLTkpcGTHFQ361y19x6F2L51KeQMYOUlINZUnc92doTte+P//yf9b qOhatOzuhYebrCqT4XFCBBgSK9X2/XOR7eMJBFCzcUwi4mRQLg9Ykx1bdYY8Q4LokAsv RctVdj1mk1WFssImbj6xt+j4tjeqilxB3bZNzgf1AynUFASK/FgmOUfHetqz5+XxrKwN jw6qJHvw3Ofx1YkSl53CCU1Wu78skZhLjpQx164S4o9msiAskcl4ty1rD+sKgrp+E6Tz p43A== MIME-Version: 1.0 X-Received: by 10.194.143.50 with SMTP id sb18mr8809032wjb.44.1365513907897; Tue, 09 Apr 2013 06:25:07 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 06:25:07 -0700 (PDT) In-Reply-To: <2B9D3349-4D89-4CE1-B3D5-9C1CB51A7BD8@jiaziyi.com> References: <2B9D3349-4D89-4CE1-B3D5-9C1CB51A7BD8@jiaziyi.com> Date: Tue, 9 Apr 2013 15:25:07 +0200 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet List Subject: Re: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:25:13 -0000 On 4/9/13, Jiazi Yi wrote: > Hi, > > On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun > wrote: > >> This message Author: Abdussalam Baryun >> Classified: I-D Review >> >> Second Message Reply to your WGLC request dated 25/03/2013 >> The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 08/04/2013 >> Reviewer Comment AB#2: Questions and Comments >> ++++++++++++++++++++++++++++++++++++ >> >> Copyright Notice: >> Copyright (c) 2012 IETF Trust and the person identified as the >> message author. All rights reserved. >> This message is to comment on the MANET WG work in progress I-D: >> draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message >> may contain parts/texts of the I-D under review >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> [Overall] >> >> AB> The I-D structure approach is a little not clear, because it >> states threats, but mostly describes the attacker possibility not the >> way attacker uses the NHDP to make threat. I suggest focus on: 1) NHDP >> messages, 2)IIB and NIB, then 3)Impact routing using NHDP (as you >> mentioned in section-5). Both point 1 and 2 are not clear in I-D (they >> were mentioned in RFC6130 security consideration section). I don=92t >> find in I-D about; threats against NHDP confidentiality, integrity, >> Info-Freshness, and availability (may be in other words or meanings, >> but these words are mostly used). > > I don't know what's IIB and NIB. But this draft mainly focus on the > threats/attacks to NHDP, not impacts to the routing protocol using NHDP - > because we can't assume how NDHP used, but just illustrate some examples > like MPR selection, etc. > sorry thought is was denoted in RFC6130, Interface Information Bases=3D IIB Neighbor Information Base=3D NIB These information are important to RFC6130, not sure about their threats by reading the I-D under-review. AB From john.dowdell@cassidian.com Tue Apr 9 06:30:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B1421F84E3 for ; Tue, 9 Apr 2013 06:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzsRfQWuOTwY for ; Tue, 9 Apr 2013 06:30:51 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77521F85A1 for ; Tue, 9 Apr 2013 06:30:50 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 09 Apr 2013 15:30:49 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 9 Apr 2013 15:30:48 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Apr 2013 15:30:48 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Apr 2013 15:30:48 +0200 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 14:30:47 +0100 From: "Dowdell, John" To: Abdussalam Baryun , manet Thread-Topic: [manet] I-D Action: draft-ietf-manet-aodvv2-00.txt Thread-Index: AQHONSQv+WtlBhqfc0mWrUaGchXE0JjN4YHw Date: Tue, 9 Apr 2013 13:30:47 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB09FE5A38@SUCNPTEXM02.com.ad.uk.ds.corp> References: <20130312125139.8418.20659.idtracker@ietfa.amsl.com> <645c731c-f923-4a4c-b35b-82acba20bec9@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <645c731c-f923-4a4c-b35b-82acba20bec9@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Apr 2013 13:30:48.0444 (UTC) FILETIME=[7262F3C0:01CE3526] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19784.007 X-TM-AS-Result: No--22.889500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:30:52 -0000 Abdussalam Thanks for your email. I have been very busy since the last meeting and hav= e not been able to progress AODVv2, and that situation will not improve unt= il at least next week. I have not had any contact with Stan or Charlie so I= guess they have been busy too. We will get round to considering your email, but please have patience. Regards John -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 09 April 2013 14:15 To: manet Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-00.txt Classified: Review of I-D Hi AODVv2 Editors, Why AODVv2-00 I-D has no normative reference to RFC6130? If it uses (optionally) it then SHOULD be normative (never felt I understood how we know when or when not normative). Regarding security consideration section, I recommend considering RFC6130 threats [1] and AODV threats [2]. Please read the message AB#2 [3]. [1] Herberg, U., et al. draft-ietf-manet-nhdp-sec-threats-02, work in progress, 2013. [2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc Network, IEEE ICNP, 2002. [3] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB ---------------------------------------------------------------------------= ------------ This message is not sent to private email boxes, but sent to IETF MANET mail box. This message is owned by the sender. This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. ---------------------------------------------------------------------------= ------------ On 3/12/13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-aodvv2-00.txt > Pages : 60 > Date : 2013-03-11 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-aodvv2-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From stbryant@cisco.com Tue Apr 9 07:18:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46221F9334 for ; Tue, 9 Apr 2013 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6kpVjGTwVgH for ; Tue, 9 Apr 2013 07:18:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A00D221F9346 for ; Tue, 9 Apr 2013 07:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1365517123; x=1366726723; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zwQhwY4E/HQT2bjQkBFlK5+wbLw3ymlRlGqiWbHRODs=; b=OiWqa0eTJrOd+uUBilwWIlNwCB2LnFLlYUWopTXC0E/2liPGGoC5t7qp GmMDToQHxSfY7qf793gi9G+APlHLxB9xQp7FkG//nQMftGToP9hPOZYZ1 ThJssdPaMXCzx/Szu7qwdmAjlKojzgt6QSgfbTk74i6ei0Z5vY40CIVjX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFALUiZFGQ/khR/2dsb2JhbABLBoMGgX6/eoEUFnSCHwEBAQQ4QAEQCxgJFg8JAwIBAgFFBg0BBQIBAYgQrliQO418gSYHg0EDlnSRDYMM X-IronPort-AV: E=Sophos;i="4.87,439,1363132800"; d="scan'208";a="152691069" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2013 14:18:42 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r39EIeqc032271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 14:18:40 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r39EIdPN029282; Tue, 9 Apr 2013 15:18:40 +0100 (BST) Message-ID: <5164233F.5010802@cisco.com> Date: Tue, 09 Apr 2013 15:18:39 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Abdussalam Baryun References: <5163C12E.1090205@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet@ietf.org Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:18:44 -0000 On 09/04/2013 12:07, Abdussalam Baryun wrote: > Hi Stewart, > > The antennas are responsible for the radio range or coverage, there > are directional antennas as well, but range is a distance not region, > > On 4/9/13, Stewart Bryant wrote: >> I respond somewhat out of contest to the radio systems >> text below. >> >> On 08/04/2013 19:35, Abdussalam Baryun wrote: >>> [I-D] As wireless radio waves can be captured as well as transmitted >>> by any wireless >>> device within radio range >> I think the text should surely be >> >> As radio signals can be received as well as transmitted >> by any compatible wireless device within radio range > Thanks that you agreed that the first text was not clear, so I spoted > that it was not true. I hove no objection to your text as it has same > of my meaning, > >>> AB>confused> not true, different antennas have different >>> waves/frequencies, please delete. >> Hm, the antennas are normally the least discriminatory part of a >> radio system. > What you mean by normally? Apart from ceramic antennas such as those used in GPS receivers antennas are normally much broader band than the front end filters in the radio or the channel discrimination filters further back in the receiver. Of course it may be that you have some special type of broadband receiver in mind here, where the two bandwidths are matched. I was just responding to the implication in your comment that antennas were the dominant frequency element in a receiver system which would be quite unusual. Stewart/G3YSX/AF6XD From adrian@olddog.co.uk Tue Apr 9 07:47:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964DE21F8DA0 for ; Tue, 9 Apr 2013 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWv3z8lYa+PE for ; Tue, 9 Apr 2013 07:47:07 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id BB12021F89CF for ; Tue, 9 Apr 2013 07:47:03 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39El1Qx029913; Tue, 9 Apr 2013 15:47:01 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39EkxLp029903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 15:47:00 +0100 From: "Adrian Farrel" To: "'Ulrich Herberg'" References: <04af01ce2fe3$2f458550$8dd08ff0$@olddog.co.uk> In-Reply-To: Date: Tue, 9 Apr 2013 15:46:59 +0100 Message-ID: <012c01ce3531$17382c30$45a88490$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHFFr3EKr0BpdW5/JEhJPoIRcLNlACfSt7ZmNs5TzA= Content-Language: en-gb Cc: manet@ietf.org, draft-ietf-manet-olsrv2-mib@tools.ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-olsrv2-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:47:07 -0000 Good job. Will move forward. A > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name] > Sent: 08 April 2013 23:21 > To: adrian@olddog.co.uk > Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; manet@ietf.org > Subject: Re: AD review of draft-ietf-manet-olsrv2-mib > > Adrian, > > thank you for your review. We have submitted a new revision -06. See below: > > On Tue, Apr 2, 2013 at 1:46 PM, Adrian Farrel wrote: > > Thanks for your work on this document, and sorry for the long time it > > has taken me to review it. It looks like you have done a really > > thorough job - I can normally pick a few holes in a MIB > > Thank you :-) > > > > > I think the only big question we are going to get (again) is about the > > level of write (and create) access. Do you think that it would be > > helpful to add an Informational reference to > > draft-nguyen-manet-management-00 and some discussion in the document > > about why you have some level of write access? Maybe this is just a > > little more text in Section 9. > > We have changed the section. Like I said in the last MANET meeting, I > believe that OLSRv2-MIB (and SNMP in general) will only be used in a > sub-set of MANET deployments. This subset has characteristics that > don't differ as much from the Internet and deployment in which > OSPF-MIB is used (in terms of centralized infrastructure, topology > dynamicity, bandwidth etc). In cases where routers are fully > distributed, have too little resources to run SNMP, bandwidth/loss > rates are unsuitable, etc, I think that SNMP is not suitable, and that > the IETF should come up with different approaches (cf COMAN). > > > > > > I think you should think about this while I run the IETF last call. > > That will attract an OPS Dir review that may dwell on the point further. > > Yes, indeed. > > > > --- > > > > My other comments are quite small and can all be taken as IETF last call > > comments to be fixed later... > > Since we uploaded a new revision anyway, we have addressed these comments. > > > > > > > > > The RFC Editor might become confused by the different uses of "XXXX" > > in the document. It would be worth sorting them out just to make life > > easier. > > See revision -06. > > > > > --- > > > > Tiny point... > > > > In olsrv2AHoldTime you have... > > a value = 3 x olsrv2TcInterval is > > recommended. > > But in draft-ietf-manet-olsrv2-15 you have > > a value >= 3 x > > TC_INTERVAL is RECOMMENDED. > > > > --- > > Good catch! Thanks! > > > > > > I think olsrv2LinkMetricType needs to be mentioned in Section 8 because, > > according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences > > of a change are quite significant. > > I added the following text: > - olsrv2LinkMetricType - defines the type of the link metric that a > router uses (e.g., ETX or hop-count). Whenever this value changes, all > link metric information recorded by the router is invalid, causing a > reset of information acquired from other routers in the MANET. > Moreover, if olsrv2LinkMetricType on a router is set to a value that > is not known to other routers in the MANET, these routers will not be > able to establish routes to that router or transiting that router. > Existing routes to the router with a olsrv2LinkMetricType unknown to > other routers in the MANET will be removed. > > > > > > --- > > > > Possibly just me being puzzled: > > > > Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be > > limited to Integer32 (0..65535)? I agree that larger would be a great > > validation of OLSRv2, but I wondered how quickly we might reach that > > threshold. > > > > Ditto olsrv2TibRouterTopologySetIndex > > Fixed in -06. > > > We also fixed the wrong reference to OLSRv2 and removed the downref. > > Best regards > Ulrich From iesg-secretary@ietf.org Tue Apr 9 08:05:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E304121F93C8; Tue, 9 Apr 2013 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.552 X-Spam-Level: X-Spam-Status: No, score=-98.552 tagged_above=-999 required=5 tests=[AWL=1.450, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJD8Yjy7mEON; Tue, 9 Apr 2013 08:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8621F93BB; Tue, 9 Apr 2013 08:05:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409150529.8128.9078.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 08:05:29 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (Definition of Managed Objects for the Optimized Link State Routing Protocol version 2) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:05:30 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Apr 9 08:05:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBFF21F93DB for ; Tue, 9 Apr 2013 08:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.552 X-Spam-Level: X-Spam-Status: No, score=-98.552 tagged_above=-999 required=5 tests=[AWL=1.450, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugtNgesaWIJJ; Tue, 9 Apr 2013 08:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAC221F93BD; Tue, 9 Apr 2013 08:05:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-manet-olsrv2-mib X-IETF-Draft-revision: 06 Message-ID: <20130409150529.8128.54837.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 08:05:29 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (Definition of Managed Objects for the Optimized Link State Routing Protocol version 2) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:05:30 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From abdussalambaryun@gmail.com Tue Apr 9 08:20:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9E21F9381 for ; Tue, 9 Apr 2013 08:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uJMZXkw5eF9 for ; Tue, 9 Apr 2013 08:20:51 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10B2A21F95EC for ; Tue, 9 Apr 2013 08:20:49 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id z11so344171wgg.35 for ; Tue, 09 Apr 2013 08:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/dQoUR5CGmBrcVZxY10adfmRI6tKhSAIReNTfln8xW8=; b=QJ8UF0NQtfFO/8lpY96fnw7HyERWhVYKj3r5KYb8Q3Cxm/PVZfRbKS1ShEAH3dj6c8 umh1PUYYTpIySPYujNgSEbObliQVeUSSw39fV7iN/ICPtjGjRI9QMDfO4q8aDKIvMmAf OnQsaD6RTyKoUWyBvAnYPNL8phfhTTk6G+2QNo1rXKz+84LRrl8CnnW3Gb7H5VNC2PTk 6eKtpgBKJZzFYc+Xsphu+HfWJ8bvBAGY2WeY7+AQs8O0WSeCN1MFWv84xCQhhU6X0/AD ShiKyEzL9htyYy97EchvWclv8WafkDbncrqq7wz2bNtr+PbetkFLEasQdD9AN+qDqBdU p+GA== MIME-Version: 1.0 X-Received: by 10.180.11.136 with SMTP id q8mr20518622wib.18.1365520840164; Tue, 09 Apr 2013 08:20:40 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 08:20:40 -0700 (PDT) Date: Tue, 9 Apr 2013 17:20:40 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-sec-threats Subject: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:20:53 -0000 This message Author: Abdussalam Baryun Classified: I-D Review Second Message Reply to your WGLC request dated 25/03/2013 The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 09/04/2013 Reviewer Comment AB#3: Example Scenario Threat ++++++++++++++++++++++++++++++++++++ Copyright Notice: Copyright (c) 2012 IETF Trust and the person identified as the message author. All rights reserved. This message is to comment on the MANET WG work in progress I-D: draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message may contain parts/texts of the I-D under review ======================================= As a respond to my first to AB#1, AB#2 messages, and to [1] message. The NHDP threat related to physical attacks were ignored by the I-D. The I-D describes non-physical attacks in section 4 but does not for physical attacks, which has threats. The neighbors may get both together non-physical and physical, as if two or more neighbors are in radio range coverage. I don't think this was introduced in the I-D, which I hope editors follow. Military Scenario Example: Identity or link spoof can occur in other scenarios mentioned in I-D (i.e. spoofed the address while attacker is out of that neighbor radio coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not identity-spoof attack only after the neighbor is physically attacked, then M takes over that neighbor identity and responsibilities, even if they were in same radio coverage. This is a threat because these neighbors are in range of each other, and the node disapers from the network. The I-D does not consider the situation where the neighbor disapears from the network but replaced by an attacker M. This example scenario assumes that neighbors are in range but not aware of the physical attack, and the malicious node is aware. AB> Please editors of the I-D, consider in section 4.4.1 to add the threat described, if not clear for you, please reply, Best Regards Abdussalam Baryun This message is owned by the author, and was not sent to any private email box, just IETF emails. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** References: [1] The message below, by Dearlove, C., (2013), IETF MANET WG Discussion list, Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. On 4/9/13, Dearlove, Christopher (UK) wrote: > I'm neither recommending that a reference is included or excluded, I'm just > providing here where one good source of definitions. Whether to reference it > is a judgement call as to what is considered widely known, and what isn't. > > But that definition is not limited to physical attack. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 09 April 2013 12:44 > To: Dearlove, Christopher (UK) > Cc: manet > Subject: Re: [manet] AB#1 Comments for WGLC > draft-ietf-manet-nhdp-sec-threats-02 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Chris, > > The I-D seems not to define physical attacks (my understanding), which > I was not sure of but [1] (mentioned in first AB#1 message) did > include, but I think your input is prefered to include in the I-D or > used, > > AB > > On 4/9/13, Dearlove, Christopher (UK) > wrote: >> AB> you don't define *Threat*, and *Attack* >> >> Personally, I would start with ISO 27000 which has: >> >> ===== >> 2.45 >> threat >> potential cause of an unwanted incident, which may result in harm to a >> system or organization >> >> 2.4 >> attack >> attempt to destroy, expose, alter, disable, steal or gain unauthorized >> access to or make unauthorized use of >> an asset (2.3) >> >> 2.3 >> asset >> anything that has value to the organization >> NOTE There are many types of assets, including: >> a) information (2.18); >> b) software, such as a computer program; >> c) physical, such as computer; >> d) services; >> e) people, and their qualifications, skills, and experience; and >> f) intangibles, such as reputation and image. >> >> 2.18 >> information asset >> knowledge or data that has value to the organization >> ===== >> >> (The rules are that you may substitute in the definition, so attack may >> be >> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> unauthorized access to or make unauthorized use of anything that has >> value >> to the organization".) >> >> [There is also an overlapping set of definitions in ISO 27032, but 27000 >> is >> more relevant here.] >> >> I don't know if there are any RFCs that reference ISO 27000. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> > > From abdussalambaryun@gmail.com Tue Apr 9 08:23:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11BF21F9423 for ; Tue, 9 Apr 2013 08:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvUOOFhqzjBE for ; Tue, 9 Apr 2013 08:23:44 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA821F9409 for ; Tue, 9 Apr 2013 08:23:41 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hr17so3822816wib.17 for ; Tue, 09 Apr 2013 08:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=wTW3/buoSzs9m5L+VEUbhKcdrXHiHFdxQYpa4gsXJp8=; b=zKJOAdcXnIDiFQBYjQS4MXD/PDQYECtJXBClFBixF19AaOLzY/YLQcUpXveweKzdqP GsYQN/na18cWRidNR6xkntfEEfCnGkzi0+E3Q9SYQw/0rjrIbJJI9CVyATR1s8XZWb6w LHnrtpadNEY6Q6/+uI/oQ+JREZJsl3Dnq5EZBYZf0Ul91Br2pjUUSAch4tsGoMe/gKXK /gOZvmKjG6kYmrnNswtGp9yx9K/10t/pMl8niPvvDbXwGfIv1tbpkLU+s6mOYaOSz95o 1eJNssw53JL4vuLErZseCOr0nWWR3oWvZj9vSrR25Q/f9NYFrq0hUrKxOqPnq38OnXt5 x/hw== MIME-Version: 1.0 X-Received: by 10.194.143.50 with SMTP id sb18mr9645926wjb.44.1365521020361; Tue, 09 Apr 2013 08:23:40 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 08:23:40 -0700 (PDT) Date: Tue, 9 Apr 2013 17:23:40 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-olsrv2-sec@tools.ietf.org Subject: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:23:48 -0000 Please consider the below threat scenario, AB ---------- Forwarded message ---------- From: Abdussalam Baryun Date: Tue, 9 Apr 2013 17:20:40 +0200 Subject: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 To: manet Cc: draft-ietf-manet-nhdp-sec-threats This message Author: Abdussalam Baryun Classified: I-D Review Second Message Reply to your WGLC request dated 25/03/2013 The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 09/04/2013 Reviewer Comment AB#3: Example Scenario Threat ++++++++++++++++++++++++++++++++++++ Copyright Notice: Copyright (c) 2012 IETF Trust and the person identified as the message author. All rights reserved. This message is to comment on the MANET WG work in progress I-D: draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message may contain parts/texts of the I-D under review ======================================= As a respond to my first to AB#1, AB#2 messages, and to [1] message. The NHDP threat related to physical attacks were ignored by the I-D. The I-D describes non-physical attacks in section 4 but does not for physical attacks, which has threats. The neighbors may get both together non-physical and physical, as if two or more neighbors are in radio range coverage. I don't think this was introduced in the I-D, which I hope editors follow. Military Scenario Example: Identity or link spoof can occur in other scenarios mentioned in I-D (i.e. spoofed the address while attacker is out of that neighbor radio coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not identity-spoof attack only after the neighbor is physically attacked, then M takes over that neighbor identity and responsibilities, even if they were in same radio coverage. This is a threat because these neighbors are in range of each other, and the node disapers from the network. The I-D does not consider the situation where the neighbor disapears from the network but replaced by an attacker M. This example scenario assumes that neighbors are in range but not aware of the physical attack, and the malicious node is aware. AB> Please editors of the I-D, consider in section 4.4.1 to add the threat described, if not clear for you, please reply, Best Regards Abdussalam Baryun This message is owned by the author, and was not sent to any private email box, just IETF emails. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** References: [1] The message below, by Dearlove, C., (2013), IETF MANET WG Discussion list, Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. On 4/9/13, Dearlove, Christopher (UK) wrote: > I'm neither recommending that a reference is included or excluded, I'm just > providing here where one good source of definitions. Whether to reference it > is a judgement call as to what is considered widely known, and what isn't. > > But that definition is not limited to physical attack. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 09 April 2013 12:44 > To: Dearlove, Christopher (UK) > Cc: manet > Subject: Re: [manet] AB#1 Comments for WGLC > draft-ietf-manet-nhdp-sec-threats-02 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Chris, > > The I-D seems not to define physical attacks (my understanding), which > I was not sure of but [1] (mentioned in first AB#1 message) did > include, but I think your input is prefered to include in the I-D or > used, > > AB > > On 4/9/13, Dearlove, Christopher (UK) > wrote: >> AB> you don't define *Threat*, and *Attack* >> >> Personally, I would start with ISO 27000 which has: >> >> ===== >> 2.45 >> threat >> potential cause of an unwanted incident, which may result in harm to a >> system or organization >> >> 2.4 >> attack >> attempt to destroy, expose, alter, disable, steal or gain unauthorized >> access to or make unauthorized use of >> an asset (2.3) >> >> 2.3 >> asset >> anything that has value to the organization >> NOTE There are many types of assets, including: >> a) information (2.18); >> b) software, such as a computer program; >> c) physical, such as computer; >> d) services; >> e) people, and their qualifications, skills, and experience; and >> f) intangibles, such as reputation and image. >> >> 2.18 >> information asset >> knowledge or data that has value to the organization >> ===== >> >> (The rules are that you may substitute in the definition, so attack may >> be >> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> unauthorized access to or make unauthorized use of anything that has >> value >> to the organization".) >> >> [There is also an overlapping set of definitions in ISO 27032, but 27000 >> is >> more relevant here.] >> >> I don't know if there are any RFCs that reference ISO 27000. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> > > From yi.jiazi@gmail.com Tue Apr 9 09:00:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686E821F9736 for ; Tue, 9 Apr 2013 09:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NhxAPDFENRM for ; Tue, 9 Apr 2013 09:00:28 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7FD21F95DF for ; Tue, 9 Apr 2013 09:00:27 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so7261323wgh.22 for ; Tue, 09 Apr 2013 09:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=/wDdbxoJE4OUfCTw72HLPWMujiA1Nhprr13OMtjz2o8=; b=OISUpF8RuGGSgJh2qS2ta9LKvWxI6R/PceaUu6VFwp/hW+ADfrWSUGUK90l41AUnf6 ZEJGD3ZPZlA7kGpQ42h6wWDuXGe0rO9Prr8zpyckDEPd8kxlEqQ/xTFN5z8510cYmmMG xs6KUBx2tRs+URQldoeb1BCyx3/WtcYVOLdFzyBfFL5hGFM9Hw06NDzQy0P2Nxcl8315 K3YAlJj7ktLuQuy4yLcYVXkiHsQtK3GxpZJlrlNFh7ZjYFlmapYWaaOaLHms5s8HVQ1o fcki+ltYwJo2dH4u+0r9a9wWu6x5+zKqjBrzGmfqT/h31NyvnPnh1jsTc7kGGUHKpfxj 5Q2Q== X-Received: by 10.180.76.84 with SMTP id i20mr21060389wiw.9.1365523226049; Tue, 09 Apr 2013 09:00:26 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id bk1sm29757410wib.2.2013.04.09.09.00.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 09:00:25 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: Date: Tue, 9 Apr 2013 18:00:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E25BD56-9309-4D7B-A12B-778F60ACB173@jiaziyi.com> References: To: manet X-Mailer: Apple Mail (2.1503) Subject: Re: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:00:31 -0000 Hi,=20 (AB, sorry if you received multiple copies of this reply. My previous = message was rejected by the mailing list because of some technical = reasons).=20 On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun = wrote: > This message Author: Abdussalam Baryun > Classified: I-D Review >=20 > Second Message Reply to your WGLC request dated 25/03/2013 > The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 08/04/2013 > Reviewer Comment AB#2: Questions and Comments > ++++++++++++++++++++++++++++++++++++ >=20 > Copyright Notice: > Copyright (c) 2012 IETF Trust and the person identified as the > message author. All rights reserved. > This message is to comment on the MANET WG work in progress I-D: > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > may contain parts/texts of the I-D under review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > [Overall] >=20 > AB> The I-D structure approach is a little not clear, because it > states threats, but mostly describes the attacker possibility not the > way attacker uses the NHDP to make threat. I suggest focus on: 1) NHDP > messages, 2)IIB and NIB, then 3)Impact routing using NHDP (as you > mentioned in section-5). Both point 1 and 2 are not clear in I-D (they > were mentioned in RFC6130 security consideration section). I don=92t > find in I-D about; threats against NHDP confidentiality, integrity, > Info-Freshness, and availability (may be in other words or meanings, > but these words are mostly used). I don't know what's IIB and NIB. But this draft mainly focus on the = threats/attacks to NHDP, not impacts to the routing protocol using NHDP = - because we can't assume how NDHP used, but just illustrate some = examples like MPR selection, etc. This issue has been fully discussed in = previous sessions, and I believe the WG consensus is clear.=20 >=20 > AB> Using the words *Exploits Allowed by protocol* by Sanzgiri et al. > (2002)[2] is better to clarify threats. In your approach you describe > attacks as the threats. They are not the same thing. Please read to > compare this I-D approach with [2]. I recommend editing *Exploits > Allowed by NHDP* into the work to clarify threats, making it easier to > read. I think Chris' post = http://www.ietf.org/mail-archive/web/manet/current/msg15259.html gives a very good definition of threat/attack. They are not the same, = but highly related. I don't see there is misuse of those two words in = the draft.=20 >=20 > [I-D][section 4.3] Eavesdropping does not pose a direct threat to the > network nor to NHDP, >=20 > AB> =46rom above text, what is an *indirect threat* mentioned? How can > we know if direct or indirect while information was accessed (lost > privacy), means a threat, don=92t you think? Elsewhere you mention > passive threat/attack where is that definition? "Passive attack" is well-known term in network security, and is used in = numerous articles. Personally, I don't see there is need to define every word like = "direct", "passive", "common", "range" in the ID. They have no different = means than in the dictionary.=20 >=20 > AB> section 4.8 mentions my comments on the list before regarding > attacks on sequence number, just you named it attack on link quality. > It is ok. > ------------------------ No, it's different from your comments.=20 >=20 > [Layer Protocol affects] >=20 > AB> Does attacks on IP layer increase threats to NHDP? Not understood = from I-D. > AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP? > Does/Can NHDP possible depend on the lower layers, if yes, what are > the threats? Please note that these issues mentioned in RFC6130 but > not in this I-D. > ---------------------- We don't even know what L2 L2.5 will be used with NHDP, so it's = impossible to have further discussions on it.=20 >=20 > [The use of NHDP] >=20 > AB> If there is an attack on NHDP does that mostly mean that its users > are attacked as well? The consequence of the attacks has been introduced in the ID.=20 > AB> In AODVv2 mentions that NHDP used to monitor and assure > bi-directional links, does that use have threats, why not mentioned, > please do. No. AODVv2 has no normative reference to NHDP.=20 > AB> Does the NHDP detect the attack neighbor? IMO, it can, please = mention this. It's not relevant to this draft.=20 > AB> Is the NHDP using an unreliable communication? If yes then should > explain the threats of that. In high density of neighbors/malicious > what is the threat? NHDP is for ad hoc networks, i.e., it would be through unreliable = medium. The whole ID is based on this assumption. I didn't see there is = need to mention it -- because it has been included.=20 > AB> Does the threat increase if packets have more neighbor messages > packed in one packet? I can't see it.=20 >=20 > [I-D] [section 3] An Attacker has several ways of harming this > neighbor discovery process: It can announce "wrong" information about > its identity, > postulate non-existent links, and replay HELLO messages. >=20 > AB> wrong identity!, what about interface address, network address? They are identities.=20 > ----------------------------- >=20 > [NHDP-Messaging] > AB> This I-D does not distinguish between IP packets and RFC5444 > Packets, as to describe the influence of the attacks on both packets. This I-D is about RFC 5444 message.=20 >=20 > AB> Regarding Invalid Hello Messages of: interface addresses or its > IP addresses, and network addresses relate to threats, what are their > influences to NHDP threats? I'm not sure you understand interface/IP/network addresses.=20 > AB> Please consider the Scenarios of RFC6130 Appendix F [Topology > Picture] (from 1 to 11, if related). You need to explain how the > threats in different topologies, as mentioned topology positions in > introduction of this I-D. If no NHDP threats due to those different > topologies then please mention no threats. IMHO, is important to > mention, they are same number of neighbors, but different topologies > with different NHDP threat levels. The appendix F of rfc6130 is just a set of examples, not a normative = part of NHDP.=20 It's impossible/unnecessary to illustrate all different topologies.=20 > [RFC6130] This is acquired through HELLO message exchange between > neighboring routers. This information is made available through the > Interface Information Bases and Neighbor Information Base, describing > the router=92s 1-hop neighborhood and symmetric 2-hop neighborhood. >=20 > AB> As per above text of 6130, please explain threats of invalid IIB > and NIB in the I-D. >=20 > AB> In the I-D security consideration, you mention that you in this > I-D make security consideration for NHDP, but in RFC6130 one of its > security consideration mentions invalid messages. I expected to see > Invalid Hello Messages as mentioned in RFC6130 security section 17.1, > why not consider as an NHDP threat? In fact, it has been documented in the ID, like link spoofing/identity = spoofing.=20 >=20 > AB> If a node receives the NHDP messages that are not as specified in > procedure of RFC6130 section 10 and 10.1, then is that a threat? IMO, > yes it is, please mention it. > ------------------------------- NHDP will verify the message in section 12.1 Invalid Message >=20 > [NHDP Security Considerations] >=20 > [RFC6622][section 4] security in MANETs, "one size rarely fits all" > and that MANET routing protocol deployment domains have varying > security requirements ranging from "unbreakable" to "virtually none". >=20 > AB> Different deployment domains, which make the security requirement > different. So could we say threats are different also in different > deployment domains. Please mention in this I-D. The assumption of the document is in section 1 Introduction. That's one = of reasons why we call it "common" threats.=20 > AB> wrong behavior can come from a malicious node, but it can also > come from a neighbor that is malfunctioning. Do you consider both as > same threats? This should be clear in I-D. It is already in the I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The document analyses possible attacks and mis-configurations on NHDP = and... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D since -01 revision=20 http://www.ietf.org/mail-archive/web/manet/current/msg13831.html best Jiazi > This Message Reference: > ------------------------------------ > [2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc > Network, IEEE ICNP, 2002. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This is last message comment, I really hope this is useful, thanking = you. >=20 > Best Regards, >=20 > Abdussalam Baryun >=20 > = --------------------------------------------------------------------------= ------------- > This message is not sent to private email boxes, but sent to IETF > MANET mail box. > This message and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > This message is in compliance with the IETF regulations. > = --------------------------------------------------------------------------= ------------- >=20 >> On 3/25/13, Stan Ratliff (sratliff) wrote: >>> WG, >>>=20 >>> I've re-started the WGLC on this document. There's a 2-week WGLC = period, >>> ending on April 8, 2013. >>>=20 >>> Regards, >>> Stan >>> _______________________________________________ >>> 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 Jiazi From yi.jiazi@gmail.com Tue Apr 9 09:11:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F121F8EEB for ; Tue, 9 Apr 2013 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.27 X-Spam-Level: ** X-Spam-Status: No, score=2.27 tagged_above=-999 required=5 tests=[AWL=-5.519, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, J_CHICKENPOX_83=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cajK5SNDIOfS for ; Tue, 9 Apr 2013 09:11:17 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5056A21F9104 for ; Tue, 9 Apr 2013 09:11:17 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s43so5345457wey.21 for ; Tue, 09 Apr 2013 09:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=MAfhwGctBMCIcRw6zMYCvd+eZJGVGU4NQi0xIBePiXc=; b=oHf84IT1RXWi6Xf/D9MjI5V/z6XYATxSfgvnv99qVIkDy4/WeCC+PoCpSFTBrUV/SS yW/c42hUBeWbBbNtZNMWG8eonaf9YnintdYYP7KzBtuEkLKEaKp0ktAehkPlncOKhO2O WxYgk6FD+B0VtDogB7EDAZx2iP2UZiR2hBlSDbgIOSbsnKERfu9ssPXMzqiW1QVzXIbe nCHBQPpcrtnluEY+jWOj3CZZD7Qc6bbrgWGLJiY/KtkMQmV+jVOoUy4QEHna0jDfsu1y 44PuIvlPQSkswTOn9AmtxjVmyl66/3uJ7NluTmi8iaEDk5Zg22ceys5BOq5rzyTfRnKP ucfw== X-Received: by 10.194.173.228 with SMTP id bn4mr39784384wjc.20.1365523875839; Tue, 09 Apr 2013 09:11:15 -0700 (PDT) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id fv2sm29786411wib.6.2013.04.09.09.11.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 09:11:15 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com> Date: Tue, 9 Apr 2013 18:11:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com> To: manet@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:11:19 -0000 Hi,=20 On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY = wrote: > Hi,=20 >=20 > On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY = wrote: >=20 >> Hi Jiazi, >>=20 >> Thank you for illustrating the difference between the IETF draft and = the scientific publications. Also, regarding the publications sent. I = have some questions about the results listed at the sent publications. >>=20 >> 1. What is the propagation delay set on evaluating the End-To-End = delay? as i know that the propagation delay affects largely the = end-to-end delay result. This is because , when you changed the = propagation delay of the channel (wireless or wired) you will gain = different results. >=20 > The propagation delay depends on the lower-layer protocol used. In our = simulations for LOADng evaluation, it's 802.11b.=20 >=20 > So, you use nodes of 250m range, Mesh topology connected.We could = consider LOADng as Layer 3 protocol, is this right?=20 LOADng can be used in both layer 2 and layer 3. In IETF, we care more = about its application in layer 3. =20 In our tests/simulations, it's in layer 3.=20 >>=20 >> 2. Regarding the overhead, I think that there are two points of view = related to the overhead: >> A. Network Overhead (like the one mentioned at the = papers) >> B. Processing Overhead (like memory usage and = required processing) >> Did you estimate the factor *2.B*? if yes, what is its value? >=20 > The "processing overhead" for an on-demand protocol like LOADng is = trivial, with O(n) complexity.=20 >=20 > I mean by processing overhead,the overhead introduced by the protocol = to be implemented, (How many events executed to perform the protocol?) = Also, the memory usage used to implement or simulate the protocol (I = think the LOADng interoperability-report mentioned 6000-lines Java code, = is it for implementation or test?). This will be very efficient to = select the suitable IC (MCU or DSP) to implement the protocol. In fact, the 6000-line java code is with functions like network = simulation, test, different extensions. For a "pure" LOADng = implementation, it can be greatly reduced.=20 For example, the implementations of Hitachi is with 1589 C code, or 1987 = C++ code.=20 For the moment, all the implementations that I'm aware of, are in = software. Because the protocol is fairly simple, I think it would be = enough to have software implementation, which also has the advantage of = flexibility.=20 best Jiazi= From jvasseur@cisco.com Tue Apr 9 09:43:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9221521F9173 for ; Tue, 9 Apr 2013 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtGohIeHoM-T for ; Tue, 9 Apr 2013 09:43:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C652721F9157 for ; Tue, 9 Apr 2013 09:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3027; q=dns/txt; s=iport; t=1365525836; x=1366735436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nYUfV5U0Z1KU5DFy6thH6udg5d++IYuL5X44lfa/+MI=; b=Mxp7g2aXXV3Phpn46u00KHVh1UKIZZwJU3TLyCIYoLG3ZIybxcw7uebd T/GjfnYHEN+1YQj9Cec1l937JxHTMbkrHW/Rcvz9euM8DjqYPqhzrLJlK 8gpooC19GhhAMwMDU2i24A3eo7LIMXt9XoOprZGG+4EEb4B07viVi/goo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAABEZFGtJV2Y/2dsb2JhbABRgwY2rxaSGYEVFnSCHwEBAQMBAQEBNzICCAMFCwIBCA4KHhAnCxMSAgQOBYgCAwkGDK48kDQEjEGCIDMHgmBhA5UbgV6Lc4Ucgws X-IronPort-AV: E=Sophos;i="4.87,439,1363132800"; d="scan'208";a="196773675" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 09 Apr 2013 16:43:56 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r39Ghuxk003772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 16:43:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.252]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 11:43:56 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi Yi Thread-Topic: [manet] LOADng Data Collection Cycle Thread-Index: AQHONTzoVxhfjUkAQkaxci/B/JCVDZjOGF+0 Date: Tue, 9 Apr 2013 16:43:55 +0000 Message-ID: <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:43:57 -0000 Why are we still discussing loadng on this mailing list as opposed to the W= G Manet reactive routing protocol ? JP Vasseur Cisco Fellow Sent from my iPhone On 9 avr. 2013, at 09:11, "Jiazi Yi" wrote: > Hi,=20 >=20 > On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY wro= te: >=20 >> Hi,=20 >>=20 >> On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY wro= te: >>=20 >>> Hi Jiazi, >>>=20 >>> Thank you for illustrating the difference between the IETF draft and th= e scientific publications. Also, regarding the publications sent. I have so= me questions about the results listed at the sent publications. >>>=20 >>> 1. What is the propagation delay set on evaluating the End-To-End delay= ? as i know that the propagation delay affects largely the end-to-end delay= result. This is because , when you changed the propagation delay of the ch= annel (wireless or wired) you will gain different results. >>=20 >> The propagation delay depends on the lower-layer protocol used. In our s= imulations for LOADng evaluation, it's 802.11b.=20 >>=20 >> So, you use nodes of 250m range, Mesh topology connected.We could consid= er LOADng as Layer 3 protocol, is this right? >=20 > LOADng can be used in both layer 2 and layer 3. In IETF, we care more abo= ut its application in layer 3. =20 > In our tests/simulations, it's in layer 3.=20 >=20 >>>=20 >>> 2. Regarding the overhead, I think that there are two points of view r= elated to the overhead: >>> A. Network Overhead (like the one mentioned at the pap= ers) >>> B. Processing Overhead (like memory usage and required= processing) >>> Did you estimate the factor *2.B*? if yes, what is its value? >>=20 >> The "processing overhead" for an on-demand protocol like LOADng is trivi= al, with O(n) complexity.=20 >>=20 >> I mean by processing overhead,the overhead introduced by the protocol to= be implemented, (How many events executed to perform the protocol?) Also, = the memory usage used to implement or simulate the protocol (I think the LO= ADng interoperability-report mentioned 6000-lines Java code, is it for impl= ementation or test?). This will be very efficient to select the suitable IC= (MCU or DSP) to implement the protocol. >=20 > In fact, the 6000-line java code is with functions like network simulatio= n, test, different extensions. For a "pure" LOADng implementation, it can b= e greatly reduced.=20 > For example, the implementations of Hitachi is with 1589 C code, or 1987 = C++ code.=20 >=20 > For the moment, all the implementations that I'm aware of, are in softwar= e. Because the protocol is fairly simple, I think it would be enough to hav= e software implementation, which also has the advantage of flexibility.=20 >=20 > best >=20 > Jiazi > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Apr 9 09:46:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8221F8EEB for ; Tue, 9 Apr 2013 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YXfupj+tK1n for ; Tue, 9 Apr 2013 09:46:46 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0521F8A52 for ; Tue, 9 Apr 2013 09:46:46 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id s10so6951758lbi.5 for ; Tue, 09 Apr 2013 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=iOhV4m8AHt9cZqEVcsh+4Al4hWAYl/4UJHwonO54Inc=; b=QpV3XmFo75jMYuekYnfu1KKyygOsOD10W2sLKfS61OCwSmve4m3bVUOZN1z9Bg0VW4 pKgB1yXBSdgqyXdv7NnfLdOw6TkFt94Px5o8vG2rO2hYtoXu6VjhkteWCee1sgSf+4v7 utE5Vwbyt87+o4XRXeHyXHbi0DRuZK79bSZ03FJxBtmkpk4oLRzSMKdsHBECdfuxbV3G tTPh4Xw1OL+QenVRt18oegVJMVqw5HV4zoBPHXMogRlgCI2ttX1CcGaHEDiO2Gm7arFH W7K3OK3MGs7lIG9PoGmBIfPYgBZNqu57pCto54Cb2srLdHFLZpJ2TbWJQyuaQOY3t6jL GMNw== X-Received: by 10.152.133.133 with SMTP id pc5mr14449690lab.32.1365526005119; Tue, 09 Apr 2013 09:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.11.97 with HTTP; Tue, 9 Apr 2013 09:46:24 -0700 (PDT) In-Reply-To: <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com> <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> From: Henning Rogge Date: Tue, 9 Apr 2013 18:46:24 +0200 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:46:47 -0000 Most likely because people are interested in it and its on topic. We have to look over ALL parts of the aodv2-00 document in the next months and decide what to keep, what to change and what to remove... discussing the details of other reactive manet protocols will surely help with this. Henning Rogge On Tue, Apr 9, 2013 at 6:43 PM, JP Vasseur (jvasseur) wrote: > Why are we still discussing loadng on this mailing list as opposed to the= WG Manet reactive routing protocol ? > > JP Vasseur > Cisco Fellow > > Sent from my iPhone > > On 9 avr. 2013, at 09:11, "Jiazi Yi" wrote: > >> Hi, >> >> On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY wr= ote: >> >>> Hi, >>> >>> On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY wr= ote: >>> >>>> Hi Jiazi, >>>> >>>> Thank you for illustrating the difference between the IETF draft and t= he scientific publications. Also, regarding the publications sent. I have s= ome questions about the results listed at the sent publications. >>>> >>>> 1. What is the propagation delay set on evaluating the End-To-End dela= y? as i know that the propagation delay affects largely the end-to-end dela= y result. This is because , when you changed the propagation delay of the c= hannel (wireless or wired) you will gain different results. >>> >>> The propagation delay depends on the lower-layer protocol used. In our = simulations for LOADng evaluation, it's 802.11b. >>> >>> So, you use nodes of 250m range, Mesh topology connected.We could consi= der LOADng as Layer 3 protocol, is this right? >> >> LOADng can be used in both layer 2 and layer 3. In IETF, we care more ab= out its application in layer 3. >> In our tests/simulations, it's in layer 3. >> >>>> >>>> 2. Regarding the overhead, I think that there are two points of view = related to the overhead: >>>> A. Network Overhead (like the one mentioned at the pa= pers) >>>> B. Processing Overhead (like memory usage and require= d processing) >>>> Did you estimate the factor *2.B*? if yes, what is its value? >>> >>> The "processing overhead" for an on-demand protocol like LOADng is triv= ial, with O(n) complexity. >>> >>> I mean by processing overhead,the overhead introduced by the protocol t= o be implemented, (How many events executed to perform the protocol?) Also,= the memory usage used to implement or simulate the protocol (I think the L= OADng interoperability-report mentioned 6000-lines Java code, is it for imp= lementation or test?). This will be very efficient to select the suitable I= C (MCU or DSP) to implement the protocol. >> >> In fact, the 6000-line java code is with functions like network simulati= on, test, different extensions. For a "pure" LOADng implementation, it can = be greatly reduced. >> For example, the implementations of Hitachi is with 1589 C code, or 1987= C++ code. >> >> For the moment, all the implementations that I'm aware of, are in softwa= re. Because the protocol is fairly simple, I think it would be enough to ha= ve software implementation, which also has the advantage of flexibility. >> >> best >> >> Jiazi >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From sratliff@cisco.com Tue Apr 9 10:43:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE20121F93E4 for ; Tue, 9 Apr 2013 10:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 025IK8TLN-Ok for ; Tue, 9 Apr 2013 10:43:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 23FAD21F9399 for ; Tue, 9 Apr 2013 10:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1562; q=dns/txt; s=iport; t=1365529431; x=1366739031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zQlQ+eKBa3MYz7oZ3VseqslQS6RgLu3BkqxBsRlVbws=; b=SKKiFOGqxVknsAXTE9B6WDVJJnVVrCxiEgK0bKu//IQvpTb2290CkclM tSMVT6h6+qribUm7r4606GHMHLNiCMNwOUQ4jgOATVDquCa067V63XndG GbiA76wIMl0i1V9X5ZTcoiIrM2iUq8l0c/LUk7sSlaOnwcjY9ola5z/UQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANVRZFGtJXG9/2dsb2JhbABRgwbBbIEWFnSCIAEBBDo/EAIBCCIUEDIlAgQODYgMrjmQN41HC4EPAjEHgmBhA6gIgwuBczU X-IronPort-AV: E=Sophos;i="4.87,441,1363132800"; d="scan'208";a="196584004" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 09 Apr 2013 17:43:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r39HhoEN013766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 17:43:50 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 12:43:50 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 Thread-Index: AQHONTZHR8fwyE5kTUaLgGk3ChNBpJjOfPqA Date: Tue, 9 Apr 2013 17:43:50 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10098A68@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.113] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C739CC8CE07284B86793BA111FC8204@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "" Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:43:52 -0000 AB,=20 On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: [snip] >=20 > ++++++++++++++++++++++++++++++++++++ >=20 > Copyright Notice: > Copyright (c) 2012 IETF Trust and the person identified as the > message author. All rights reserved. > This message is to comment on the MANET WG work in progress I-D: > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > may contain parts/texts of the I-D under review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 [snip] >=20 > This message is owned by the author, and was not sent to any private > email box, just IETF emails. > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** [snip] I'm somewhat concerned by these 3 blocks of text in your emails. The IETF h= ave quite a few rules & regs about intellectual property rights; some of th= e above text, if taken in the most stringent manner, could be seen to precl= ude use of any of your ideas into the associated documents. Please explain = the motivation behind the text I've highlighted above.=20 Regards, Stan From adrian@olddog.co.uk Tue Apr 9 11:04:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B1021F9132 for ; Tue, 9 Apr 2013 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJV7WKOeC58v for ; Tue, 9 Apr 2013 11:04:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C921F9130 for ; Tue, 9 Apr 2013 11:04:51 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39I4khV002708; Tue, 9 Apr 2013 19:04:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39I4jEc002696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 19:04:45 +0100 From: "Adrian Farrel" To: "'Stan Ratliff \(sratliff\)'" , "'Abdussalam Baryun'" Date: Tue, 9 Apr 2013 19:04:44 +0100 Message-ID: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac41TK8ANyoFLbILT+uoqHkr+c1Zww== Content-Language: en-gb Cc: 'manet' Subject: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:04:53 -0000 Hi Stan, I wouldn't worry about this text. In my opinion it is at best purposeless and confusing. The IETF Trust deems all emails to IETF mailing lists to be contributions to the IETF. This should be clear from the Note Well that all participants see whenever they sign up to an IETF mailing list and whenever they bother to look more closely (for example, at RFC 5378). In my opinion, no amount of added verbiage to an email can change the copyright that applies to it under the IETF Trust rules. Of course, everyone is entitled to their own opinion and the opinions of their paid or bar-room lawyers. I tend to think that admonitions in email footers to not read an email that was not intended for me are kind of amusing. I usually read emails from top down, so I don't get to that bit until it is too late. But, in any case, if an email comes to me via a mailing list, how do I know whether I was supposed to receive it or not? I know some people automatically throw away any email with that kind of footnote just to be on the safe side, so including the note seems counter-productive to IETF work. Maybe, however, this is just another distraction on the MANET list? What is the next technical topic? Cheers, Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Stan Ratliff (sratliff) > Sent: 09 April 2013 18:44 > To: Abdussalam Baryun > Cc: manet; > Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 > > AB, > > On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: > > [snip] > > > > ++++++++++++++++++++++++++++++++++++ > > > > Copyright Notice: > > Copyright (c) 2012 IETF Trust and the person identified as the > > message author. All rights reserved. > > This message is to comment on the MANET WG work in progress I-D: > > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > > may contain parts/texts of the I-D under review > > ======================================= > > > [snip] > > > > This message is owned by the author, and was not sent to any private > > email box, just IETF emails. > > > ************************************************************** > ****** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > > ************************************************************** > ****** > > [snip] > > > I'm somewhat concerned by these 3 blocks of text in your emails. The IETF have > quite a few rules & regs about intellectual property rights; some of the above > text, if taken in the most stringent manner, could be seen to preclude use of any > of your ideas into the associated documents. Please explain the motivation > behind the text I've highlighted above. > > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Apr 9 11:14:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE28B21F930C for ; Tue, 9 Apr 2013 11:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kguxSPR95-Cy for ; Tue, 9 Apr 2013 11:14:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC6821F91D9 for ; Tue, 9 Apr 2013 11:14:38 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so7173328lbi.31 for ; Tue, 09 Apr 2013 11:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cAnTsu8EwIgJ9dQ3WikEOjVj4xE64pMXcOHiSJ1nAOo=; b=wCBRMvqzCvyNrx/TbjFndEJz4kgFCdyarFC5Q1qBSJKyOtq7GmeNzI9dSQ49k9sfks LkY8efrxXZ4vD48GzHHRgDekKxl8adoPgCvhuhsHgfRR9O7ZWfTy9vTxskskn/EGYSHV U9pdHpxUE272TRVnnziqIyA56HyNBK+YXO+V7KhIIf8KiiPak9k2ljV86N1kF+MIFtxA 1QLObtupGcfjXTprFg10klhH7BTIkaHqkdONLqP7DAIWx3gYNYr8fKTj+R6+T1sBP6MM GfiRr7hkC48lRIMKv8XnKr2u4zhYA5WDa5oV9xjyya0CdHua10Lukra8EefBfYkItWUf 3CuQ== X-Received: by 10.152.20.193 with SMTP id p1mr8753310lae.33.1365531277333; Tue, 09 Apr 2013 11:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.11.97 with HTTP; Tue, 9 Apr 2013 11:14:17 -0700 (PDT) In-Reply-To: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> References: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> From: Henning Rogge Date: Tue, 9 Apr 2013 20:14:17 +0200 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:14:39 -0000 I would say that DLEP should become an important topic.. I hope that I have time to implement it in the near future, which hopefully will give us new insights about the current draft. (at the moment I am busy with my OLSRv2 code) Henning Rogge On Tue, Apr 9, 2013 at 8:04 PM, Adrian Farrel wrote: > Hi Stan, > > I wouldn't worry about this text. In my opinion it is at best purposeless and > confusing. > > The IETF Trust deems all emails to IETF mailing lists to be contributions to the > IETF. This should be clear from the Note Well that all participants see whenever > they sign up to an IETF mailing list and whenever they bother to look more > closely (for example, at RFC 5378). > > In my opinion, no amount of added verbiage to an email can change the copyright > that applies to it under the IETF Trust rules. Of course, everyone is entitled > to their own opinion and the opinions of their paid or bar-room lawyers. > > I tend to think that admonitions in email footers to not read an email that was > not intended for me are kind of amusing. I usually read emails from top down, so > I don't get to that bit until it is too late. But, in any case, if an email > comes to me via a mailing list, how do I know whether I was supposed to receive > it or not? I know some people automatically throw away any email with that kind > of footnote just to be on the safe side, so including the note seems > counter-productive to IETF work. > > Maybe, however, this is just another distraction on the MANET list? What is the > next technical topic? > > Cheers, > Adrian > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Stan Ratliff (sratliff) >> Sent: 09 April 2013 18:44 >> To: Abdussalam Baryun >> Cc: manet; >> Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 >> >> AB, >> >> On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: >> >> [snip] >> > >> > ++++++++++++++++++++++++++++++++++++ >> > >> > Copyright Notice: >> > Copyright (c) 2012 IETF Trust and the person identified as the >> > message author. All rights reserved. >> > This message is to comment on the MANET WG work in progress I-D: >> > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message >> > may contain parts/texts of the I-D under review >> > ======================================= >> > >> [snip] >> > >> > This message is owned by the author, and was not sent to any private >> > email box, just IETF emails. >> > >> ************************************************************** >> ****** >> > This email and any attachments are confidential to the intended >> > recipient and may also be privileged. If you are not the intended >> > recipient please delete it from your system and notify the sender. >> > You should not copy it or use it for any purpose nor disclose or >> > distribute its contents to any other person. >> > >> ************************************************************** >> ****** >> >> [snip] >> >> >> I'm somewhat concerned by these 3 blocks of text in your emails. The IETF have >> quite a few rules & regs about intellectual property rights; some of the above >> text, if taken in the most stringent manner, could be seen to preclude use of > any >> of your ideas into the associated documents. Please explain the motivation >> behind the text I've highlighted above. >> >> Regards, >> Stan >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From james.huy.nguyen@gmail.com Tue Apr 9 11:23:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0D21F9423 for ; Tue, 9 Apr 2013 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLSKBz2aM+TR for ; Tue, 9 Apr 2013 11:22:59 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 14DED21F9425 for ; Tue, 9 Apr 2013 11:22:58 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gw10so754577lab.32 for ; Tue, 09 Apr 2013 11:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=/V+u0sDxz8ixsKJqSjVwvnEfJZrPCSzTEdOfbGSRKq4=; b=FOCerXaAcftvBSbcrLJg8pFLBGaOV1Kgo/lvpwe7STE2vPRY9Ls9OgXXDx/D2OUMG+ g7s9yyS6lcXe4lzgQ03M7+qPoTfBuQMmg9vKTAbrHt3faXY9+i/xxHDIyhI/CI7eAaKc V520g60zyojzWgMkxK5N8kPI355NnbFquPVwsAcIaYKSZJaAlxGKBKVKrQhltgRJLsZo x/hH/+qh1nX5LpAiFRyVnk6n+6Qv7Fw+fcYYGNiGtKS/5efEDw9MStj+RofwCveykOt+ x+vbIylehA8ehiMAHeMwFAmCu2AEyOQYVITUa2e0bn/2kCcC8gU7ZksrzB+3jATn6DVS CQGw== MIME-Version: 1.0 X-Received: by 10.112.180.193 with SMTP id dq1mr14050748lbc.60.1365531777833; Tue, 09 Apr 2013 11:22:57 -0700 (PDT) Received: by 10.112.24.70 with HTTP; Tue, 9 Apr 2013 11:22:57 -0700 (PDT) In-Reply-To: <515A977C.6050500@fkie.fraunhofer.de> References: <515A977C.6050500@fkie.fraunhofer.de> Date: Tue, 9 Apr 2013 14:22:57 -0400 Message-ID: From: James Nguyen To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c37b3c8c20e104d9f1a412 Subject: Re: [manet] rfc6622-bis-01 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:23:01 -0000 --001a11c37b3c8c20e104d9f1a412 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC6622-bis authors, Overall, I think this draft is good. A few editorials (to make it clearer) would complete its purpose. Please find my comments starting with [JN]. > Section 5 For example, and as defined in this document, an ICV TLV with type extension =3D 0 specifies that the field has no pre-defined internal structure but is simply a sequence of octets. An ICV TLV with type extension =3D 1 specifies that the field has a pre- defined internal structure and defines its interpretation. An ICV TLV with type extension =3D 2 specifies a modified version of this definition. (Specifically, with type extension =3D 1 or type extension =3D 2, the field contains the result of combining a cryptographic function and a hash function, calculated over the contents of the packet, message or address block, with sub-fields indicating which hash function and cryptographic function have been used; this is specified in Section 12. The difference between the two type extensions is that the ICV TLV with type extension =3D 2 is calculated also over the source address of the IP datagram carrying the packet, message, or address block.) [JN] I would break this block of text into a simpler or less text one or an if-else statement pseudo code. J Same as for the following sections: 12.2.1. Packet ICV TLV 12.2.2. Message ICV TLV 12.2.3. Address Block ICV TLV > Section 7 Timestamp TLV Structure [JN] time synchronization is an issue in one of my emulation tools. It would be an interesting topic to discuss how to sync timestamp in MANET, but it would be addressed or discussed outside the scope of this draft. James On Tue, Apr 2, 2013 at 4:31 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 03/25/2013 10:01 PM, Justin Dean wrote: > >> Below I have included my comments in-line tagged with JD. The new TLV >> subtype assignment confuses the issue of replacement of 6622. Are there >> situations where ICV TLVs with subtype 1 as defined in 6622 are >> >> more appropriate? My guess is No. In any case I shouldn't be guessing, >> so that should be made more clear. >> > > I think subtype 2 does only apply to RFC5444 messages that must not be > forwarded. > > The Source-IP of the UDP-packets forwarding the message do change every > hop, so OLSRv2 TCs (as an example) must use subtype 1. > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a11c37b3c8c20e104d9f1a412 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC6622-bis authors,
Overall, I think this draft is good.=C2=A0 A few editorials (to make it clearer) would complete its purpose.
Please find my comme= nts starting with [JN].

> Section 5

= =C2=A0=C2=A0 For example, and as defined in this document, an ICV TL= V with type

= =C2=A0=C2=A0 extension =3D 0 specifies that the <value> field = has no pre-defined

= =C2=A0=C2=A0 internal structure but is simply a sequence of octets.<= span style>=C2=A0 An ICV TLV

= =C2=A0=C2=A0 with type extension =3D 1 specifies that the <value&= gt; field has a pre-

= =C2=A0=C2=A0 defined internal structure and defines its interpretati= on.=C2=A0 An ICV

= =C2=A0=C2=A0 TLV with type extension =3D 2 specifies a modified vers= ion of this

= =C2=A0=C2=A0 definition.=C2=A0 (Specifically, wit= h type extension =3D 1 or type extension

= =C2=A0=C2=A0 =3D 2, the <value> field contains the result of c= ombining a

= =C2=A0=C2=A0 cryptographic function and a hash function, calculated = over the

= =C2=A0=C2=A0 contents of the packet, message or address block, with = sub-fields

= =C2=A0=C2=A0 indicating which hash function and cryptographic functi= on have been

= =C2=A0=C2=A0 used; this is specified in Section 12.=C2= =A0 The difference between the

= =C2=A0=C2=A0 two type extensions is that the ICV TLV with type exten= sion =3D 2 is

= =C2=A0=C2=A0 calculated also over the source address of the IP datag= ram carrying

= =C2=A0=C2=A0 the packet, message, or address block.)

=C2=A0<= /p>

[JN]=C2=A0 I would break this block of= text into a simpler or less text one or an if-else statement pseudo code.<= span style>=C2=A0 J=C2=A0

Same as for the following sections:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.2.1.=C2=A0 Packet ICV TLV

= =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.2.2.=C2=A0 Message ICV TLV

= =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.2.3.=C2=A0 Address Block ICV TLV

=C2= =A0
> Section= 7 Timestamp TLV Structure

=C2=A0<= /p>

[JN] time sync= hronization is an issue in one of my emulation tools.=C2=A0 It would be an interesting topic to discuss how to sync timestamp in MA= NET, but it would be addressed or discussed outside the scope of this draft= .

=C2=A0<= /p>James

On Tue, Apr 2, 2013 at 4:31 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 03/25/2013 10:01 PM, Justin Dean wrote:
Below I have included my comments in-= line tagged with JD. =C2=A0The new TLV
subtype assignment confuses the i= ssue of replacement of 6622. =C2=A0Are there
situations where ICV TLVs with subtype 1 as defined in 6622 are

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

I think s= ubtype 2 does only apply to RFC5444 messages that must not be forwarded.
The Source-IP of the UDP-packets forwarding the message do change every= hop, so OLSRv2 TCs (as an example) must use subtype 1.

Henning Rogge


--
Diplom-I= nformatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikation= ssysteme (KOM)
Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany
Te= lefon +49 228 9435-961, =C2=A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/m= ailman/listinfo/manet




--
James Nguyen
Ema= il: james.huy.nguyen@gmail.co= m=20 --001a11c37b3c8c20e104d9f1a412-- From ulrich@herberg.name Tue Apr 9 11:50:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6625A21F9485 for ; Tue, 9 Apr 2013 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsXLYY8lVzQp for ; Tue, 9 Apr 2013 11:50:29 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 313A921F9446 for ; Tue, 9 Apr 2013 11:50:28 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e12so4970983vbg.17 for ; Tue, 09 Apr 2013 11:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l8d+YsjxGLSIh62cXMJst4/HZ93amHx5AN7oNKzDQPQ=; b=SbeMY9bynGV3UGDzwZiQPBMyWdQSVVOs3EqJZddOKoY8RobHXPiyt0/NSxBehharv3 rSpWwncL/vCwy49yD3yfIjFhXfz5QvEJxgHwxVUGpXFJZ76w6MzfRJ16VxIplV3jU2TL roBaVVCkVdhaVwXVzKrSjxxQMJyTVKwNXrkWY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=l8d+YsjxGLSIh62cXMJst4/HZ93amHx5AN7oNKzDQPQ=; b=m8HgDaCA6xSbKj2BkBZ7AGCsGIYR5LGHXY+46SeLNDBVICpFy/K4r3Cgk7K6duohQn cTDNurkIwTvZgomaGwEiRW7axXgPnb3yp0RlgM38ThQ4RK1N9sTn0fdakLDhE2yRUyVm exoA77Zf4kVsfM9b7Lni6BwQDhfU2ID8aAliK32D1TAt6pJNupljWjB+JJKCbYeguMPx wrDcXm5GWan2FnGew2LjUoXJc0d0inYeVEE+w8RKupeZpq3C6xoax3JwpQnXOe6Z0ntX ylRElR7lBiK8TdbGSr6q+kyC76+J4mwcdTMKqwoGACyd8tRCQtwPFdXntGeYEzIdtNwX br3g== MIME-Version: 1.0 X-Received: by 10.59.9.39 with SMTP id dp7mr5690462ved.36.1365533427572; Tue, 09 Apr 2013 11:50:27 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 11:50:27 -0700 (PDT) In-Reply-To: References: <5163C12E.1090205@cisco.com> Date: Tue, 9 Apr 2013 11:50:27 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQldJ/XqROFDrUbiTHkERzPdD9T9yWj2gIjvPF6ODB3Oi0IcKZ7+Z+d2dcD3JDbT80B3BJl1 Cc: manet@ietf.org Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:50:32 -0000 AB, I think this discussion diverges from the point that the paragraph makes. Really what the paragraph says is that security threats may be easier to exploit in a wireless environment than in a wired scenario. This does not mean that the security threats do not exist in the wired Internet. Just that it may be a first obstacle for me to break into my competitor's company building in order to plug my laptop into their Ethernet, rather than just sitting in the coffee shop next to the company connecting to their Wifi (and potentially having the time to drink 10 Venti Cappuccinos while breaking into their network). I think that Stewart's sentence makes that intention clearer. Ulrich On Tue, Apr 9, 2013 at 4:07 AM, Abdussalam Baryun wrote: > Hi Stewart, > > The antennas are responsible for the radio range or coverage, there > are directional antennas as well, but range is a distance not region, > > On 4/9/13, Stewart Bryant wrote: >> I respond somewhat out of contest to the radio systems >> text below. >> >> On 08/04/2013 19:35, Abdussalam Baryun wrote: >>> >>> [I-D] As wireless radio waves can be captured as well as transmitted >>> by any wireless >>> device within radio range >> >> I think the text should surely be >> >> As radio signals can be received as well as transmitted >> by any compatible wireless device within radio range > > Thanks that you agreed that the first text was not clear, so I spoted > that it was not true. I hove no objection to your text as it has same > of my meaning, > >> >>> >>> AB>confused> not true, different antennas have different >>> waves/frequencies, please delete. >> >> Hm, the antennas are normally the least discriminatory part of a >> radio system. > > What you mean by normally? however, if we read any antenna > communication book I don't think your above assumption is correct. > Please don't ignore the wrods *radio-range* in the I-D text, so who is > responsible for the radio range do you think? I know that there are > other discriminatory in the PHY layer other than antenna but not for > radio range. > > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue Apr 9 11:53:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D9B21F9030 for ; Tue, 9 Apr 2013 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZst0M6uospP for ; Tue, 9 Apr 2013 11:53:44 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0269A21F9068 for ; Tue, 9 Apr 2013 11:53:43 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so6642535veb.26 for ; Tue, 09 Apr 2013 11:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tcdgXK9K2zxm89miDyOXofqUedT+omgFzs8gMkZfNGs=; b=zTPSmKc/ql3AskrNpcx6dYCMq2cE0Hhu6TagGDeEEKTsz0gXcdQHavmctQ/NExlMs+ y1cGwvJrt+UG1UGez4HBMsV32/Op6d6qsbu2mKbLJZ8AolsYaD0XbM68ljqmMVdS6OCR 4IgG5mamTVE5M/cqrZOySZecudFVry4MHoGtg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=tcdgXK9K2zxm89miDyOXofqUedT+omgFzs8gMkZfNGs=; b=fsZHBOEg4EtaDm6ZClL8Tr6yQdSyAYigt6na0fGwbg1hEosdFuWQKBHYSO29cPPEYW sRe2x+NJTViOWxL0Mfci1aYinPwVGvelkCVnYSatU1TVSUk/hHXaSJPAql9JBB9TDqEb zHMaBDdTeBv9YHec0KTsSWDzwNo3LQSzftdixiFbXq6rhTX+EcokD+YxHPvcZfKKiNcZ 5TB6ySEUMISaPqs0PBPFxZ8+62sLODU96wvVIfVGUIo4oTa0aScq/lV+9UlD0FKw2gRh 8nWNI5/TSMRtYYudF3PZhMVoewUHa+94iyJRy8TeQoq/6FVx+deBXW7Ax0ATXgcHlzbZ Yl6w== MIME-Version: 1.0 X-Received: by 10.59.2.199 with SMTP id bq7mr19922173ved.51.1365533615962; Tue, 09 Apr 2013 11:53:35 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 11:53:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 11:53:35 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQke+N39vsPRksJdIXdfKErI0RUfOkk4vPImsNgRt44g56bPWXqXEUzDZimDSso0b9R4kMMv Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:53:45 -0000 Thanks Chris for providing these links. My personal opinion is that these words are fairly well-understand and used in probably every RFC that contains a Security Considerations section (and therefore do not need a reference). AB, do you think that anywhere in the text any of these words is wrongly used or ambiguous? Ulrich On Tue, Apr 9, 2013 at 5:12 AM, Dearlove, Christopher (UK) wrote: > I'm neither recommending that a reference is included or excluded, I'm just providing here where one good source of definitions. Whether to reference it is a judgement call as to what is considered widely known, and what isn't. > > But that definition is not limited to physical attack. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 09 April 2013 12:44 > To: Dearlove, Christopher (UK) > Cc: manet > Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Chris, > > The I-D seems not to define physical attacks (my understanding), which > I was not sure of but [1] (mentioned in first AB#1 message) did > include, but I think your input is prefered to include in the I-D or > used, > > AB > > On 4/9/13, Dearlove, Christopher (UK) wrote: >> AB> you don't define *Threat*, and *Attack* >> >> Personally, I would start with ISO 27000 which has: >> >> ===== >> 2.45 >> threat >> potential cause of an unwanted incident, which may result in harm to a >> system or organization >> >> 2.4 >> attack >> attempt to destroy, expose, alter, disable, steal or gain unauthorized >> access to or make unauthorized use of >> an asset (2.3) >> >> 2.3 >> asset >> anything that has value to the organization >> NOTE There are many types of assets, including: >> a) information (2.18); >> b) software, such as a computer program; >> c) physical, such as computer; >> d) services; >> e) people, and their qualifications, skills, and experience; and >> f) intangibles, such as reputation and image. >> >> 2.18 >> information asset >> knowledge or data that has value to the organization >> ===== >> >> (The rules are that you may substitute in the definition, so attack may be >> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> unauthorized access to or make unauthorized use of anything that has value >> to the organization".) >> >> [There is also an overlapping set of definitions in ISO 27032, but 27000 is >> more relevant here.] >> >> I don't know if there are any RFCs that reference ISO 27000. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue Apr 9 12:10:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFA21F98BF for ; Tue, 9 Apr 2013 12:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa+7TFOi2uAS for ; Tue, 9 Apr 2013 12:10:42 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 42DB221F98BC for ; Tue, 9 Apr 2013 12:10:42 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id f13so4950171vbg.14 for ; Tue, 09 Apr 2013 12:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ix9tOeEWgiOk6F3vy76VnRes/iLppJYsas0U5Rw3lME=; b=y3QtMAxN2VDULblUmAZoXq29sPWcKGebw/ZsdeHHrCKx4x2+FlL+fSSJKp/LcJ2ETS UT2jHdlSAhO8p8VMMccgAh78kc3ZL3YcLThdTp5MxrTotaVtJkONSei02QsZ54tSb442 MafbpPHhGTrEJZ+mFVug18DmKaE1lMxaB3MJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ix9tOeEWgiOk6F3vy76VnRes/iLppJYsas0U5Rw3lME=; b=V7UN4IlaDBqf3oAr7EMrSfApGzO4QGTR3wtBJYRUA65edE1OtszEAi7pprWIp2Dfxw gq7pTyJZqag3kiMu8aAzIzJT1W5MXahGMw5rBP034E30i1Lwn0EP8M9y6a4Jl0BTu6L7 n4B4srmxFBIcOlNyuzldRFu714ZUbHquvds+Rt2qS4gBtZDS+Ir8G93yjSlrfEqbA7P+ 2cWn9nUK14y434l6JhdD4e9KgO55kfjSHXhHQZjeNG2Cata0YDq3jFsEs9by31eHS6Br EvH1X/qvCpQ2/O26cUbG97Mpuw3JQ3cei58ttHEp2K/NK1QiOMYW0uuN0RDXwpfixK0t l+iQ== MIME-Version: 1.0 X-Received: by 10.52.94.174 with SMTP id dd14mr1052432vdb.14.1365534641482; Tue, 09 Apr 2013 12:10:41 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 12:10:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 12:10:41 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnLvv3NybznmhyUlWJW+dHA9m7igcnsVOXb7uBcMDbzosTNPqZr6kVxTBV5OIveVukxEFPf Cc: manet Subject: Re: [manet] AB#1 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:10:43 -0000 AB, On Mon, Apr 8, 2013 at 9:33 PM, Abdussalam Baryun wrote: [...] >>> [I-D] Abstract: >>> [I-D] This document analyses common security threats of the Neighborhoo= d >>> Discovery Protocol (NHDP), and describes their potential impacts on >>> MANET routing protocols using NHDP. >>> >>> AB>question> What is the meaning of *common* security threats? >>> Mentioned in the abstract, >> >> I think the word is fairly clear. See >> http://dictionary.reference.com/browse/common >> (definition 4/5) > > I mean why common why not ALL threats, or the explaining the *Exploits > Allowed by the NHDP* as per the reference [2] I gave in my AB#2 > message. Because we cannot know if we listed ALL threats that could potentially exist. It may be that we overlooked one, or that a future threat may be thought of (I assume that when MD5 was standardized, they would have loved to know about the threat that led to its obsoletion) > >> >> >>> >>> AB>question> How can I define threats when I don=92t know on which laye= r >>> NHDP[RFC6130] is located in router, is it in L4 or L3. Please define >>> that you concern with IP layer if it is the only you concern with. >> >> That is given by RFC6130, which is running on the IP layer. I think >> this is not a task of NHDP-sec-threats to define. > > I don't find that defined, but if so, does IP threats affect the NHDP thr= eats? RFC6130 runs either on UDP or directly on IP (see section 5.1 of RFC6130), and uses a multicast LL address (section 5.2). In multiple occasions of the text in RFC6130 it is mentioned that either IPv4 or IPv6 can be used. It is true that there is no sentence in the beginning of RFC6130 "This is an IP protocol and all addresses used in this specification are either IPv4 or IPv6 addresses". But whether or not that would be a good idea to mention as clarification in RFC6130 is irrelevant because it's already completed. [...] >> >> AODVv2 has no normative reference to RFC6130. In many cases of AODVv2 >> deployments, I don't think that RFC6130 would be used (whereas it must >> be used for OLSRv2 and SMF). I am against adding a reference. Anyway, >> the sentence just lists some example protocols ("such as..."). >> > > Just I prefered showing that NHDP explains all its threats when used > by different MANET routings, if we explain one only then we don't > explain all threats. As said above, we cannot assure to discuss *all* threats. I also don't see how the draft would improve by citing AODVv2 here, as in its current form, it does not mandate to use RFC6130. And AODVv2 is only a -00 draft, so there could be many changes to it yet, so we don't even know what will be included in it (whereas SMF and OLSRv2 are completed). > >> >>> >>> [I-D] As wireless radio waves can be captured as well as transmitted >>> by any wireless >>> device within radio range >>> >>> AB>confused> not true, different antennas have different >>> waves/frequencies, please delete. >> >> I think that this is fairly clear; it's about contrasting >> communication over cable vs wireless, where the access to the channel >> is much easier, i.e., security threats can be exploited more easily >> since there is no physical access protection (read: cable). >> > > Please delete word *any* and change to *some*, because think it is not > clear to me, See the other email and suggestion from Stewart. > >>> >>> [I-D] The document analyses possible attacks and mis-configurations on >>> NHDP and outlines the consequences of such attacks/mis-configurations >>> to the state >>> maintained by NHDP in each router (and, thus, made available to >>> protocols using this state). >>> >>> AB> I don=92t think it makes full analyses for NHDP threats? Please see >>> threat analysis by Tsao et al (2013) [1]. >>> >>> AB> the doc should consider information exchanged attacks and network >>> attacks as well. >> >> >> I think that this is exactly what NHDP-sec-threats does; section 4 >> describes the possible exploits when using no protection of NHDP. >> Section 5 outlines the consequences for protocols using NHDP. > > I need analysis which was mentioned but not done. I mean what is > exploited by the NHDP messages and the NHDP IIB and NIB, don't see > much explaining about those information and the exploitation. Yes in > section 4 explains but in the point of view of the attacker, and no > possibility of malfunctions or other issues, I don't understand which attacks you would like to see in the draft. >> >> >>> >>> Section 2. Terminology: >>> >>> AB> you don=92t define *Threat*, and *Attack*, please do same definitio= n >>> as threat analysis draft in ROLL WG (or refer to it). >> >> The words "threat" and "attack" are pretty well known; I don't see any >> reason why they are ambiguous. I don't see any reason to cite the ROLL >> draft; why is that related in any way to NHDP? It describes security >> threats to a completely different protocol. > > In the I-D the titles of section make me feel that authors made; > threats =3D attacks, so I need that to be answered in the doc. I don't see how this would improve the draft. Anyone else thinking this is a problem? > >> >> >>> >>> [I-D] Compromised NHDP Router: An attacker, present in the network and >>> which generates syntactically correct NHDP control messages. >>> Control messages emitted by a Compromised NHDP router may contain >>> additional information, or omit information, as compared to a >>> control message generated by a non-compromized NHDP router located >>> in the same topological position in the network. >>> >>> AB> you mention network position, or topological position, but why the >>> document ignores the network domain(s) (just topology), could the NHDP >>> threats affect the network domain policy/states? If not say so, >> >> >> I don't understand your point. What do you mean? > > Is the NHDP threats affecting the network domains? as it was mentioned > in the RFC6130 the different deployments and low-value WSN. Does > different deployments mean different NHDP threats. The draft describes potential threats to NHDP; whether they are always feasible for an attacker cannot be answered in this document, I think (and also irrelevant). Ulrich From ulrich@herberg.name Tue Apr 9 12:23:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE21221F98A1 for ; Tue, 9 Apr 2013 12:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYb3SqzLf5iP for ; Tue, 9 Apr 2013 12:23:07 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3DA321F9897 for ; Tue, 9 Apr 2013 12:23:06 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so6945260veb.3 for ; Tue, 09 Apr 2013 12:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4tnmNqh0OokGZ+R/vfuAw4tKazIhteQWzcpWL5SNKYI=; b=20/GfXrwaQaxDaxowrWtpOMPj9k4rXbToI5L6mRLdXynHPI/OLltpslWxA50B9V1vr MBHc5EOa68/p7iW2xYaOwKxCie+C0Nr3tHD3YHd/IalQ9wnGWwKAKwQq+oLKrReQnS0g x3uS9SuStL8oJ82bA2TNqQPaff7r34fnq/jVI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=4tnmNqh0OokGZ+R/vfuAw4tKazIhteQWzcpWL5SNKYI=; b=i9zt69gwwaeSv7RFnYVvTSXpk8c5KpULTGJy0juhf8WrOkgpwSgKA6Y4XNmoRJsq0S RlBwhjp3iNh9OR2ow6h18n7gduwcfEP+qkGYXtx7uI3VieLtChjsLChtm6TXLb1kuhXr Ee10otVyYhh4jdhnfXzSgdTKfKi7Vpj3YbDmE48j1AOtzu3TCHT8RiCA1bCTVlpwhE9D JN2WCd4RAi1xJ2UiPxbUqtrZ0P79M7hDpgKYn4tpNLky7xmJbietapaO5gt5lm71wvlv eHNmMh0UDCGDbdVcsXIrIj4dRQ134t4lRVDbpEzoBYvbIF5VGBsX33rQ1RQV1H3nkOWp 0/vg== MIME-Version: 1.0 X-Received: by 10.52.89.68 with SMTP id bm4mr17310279vdb.123.1365535382305; Tue, 09 Apr 2013 12:23:02 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 12:23:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 12:23:02 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmr14W7wlJRei1nC9yznsVtM0rsf8wWWY78+oj2gtHO/gn+Zzf+UdSePf0+EXbHjWvXUFmc Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:23:09 -0000 AB, On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun wrote: >[...] > > As a respond to my first to AB#1, AB#2 messages, and to [1] message. > The NHDP threat related to physical attacks were ignored by the I-D. > The I-D describes non-physical attacks in section 4 but does not for > physical attacks, which has threats. The neighbors may get both > together non-physical and physical, as if two or more neighbors are in > radio range coverage. I don't think this was introduced in the I-D, > which I hope editors follow. > > Military Scenario Example: > > Identity or link spoof can occur in other scenarios mentioned in I-D > (i.e. spoofed the address while attacker is out of that neighbor radio > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > identity-spoof attack only after the neighbor is physically attacked, > then M takes over that neighbor identity and responsibilities, even if > they were in same radio coverage. This is a threat because these > neighbors are in range of each other, and the node disapers from the > network. The I-D does not consider the situation where the neighbor > disapears from the network but replaced by an attacker M. This example > scenario assumes that neighbors are in range but not aware of the > physical attack, and the malicious node is aware. > > AB> Please editors of the I-D, consider in section 4.4.1 to add the > threat described, if not clear for you, please reply, What do you mean by physical attacks? Tampering with the hardware of the router running NHDP? I think that this is not the scope of the draft (and also irrelevant); the draft purely looks at security threats of misconfigured or malicious NHDP routers that misbehave when using NHDP. It could be that such a router has been hacked via an implementation flaw or physically exchanged some parts of the hardware; that does not matter. For the case you describe, how does it matter if the router disappears and comes back later? (whether or not it is physically exchanged, or just stopped sending HELLOs for a while). Regards Ulrich > [...] > > References: > [1] The message below, by Dearlove, C., (2013), IETF MANET WG > Discussion list, Re: [manet] AB#1 Comments for WGLC > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > > > On 4/9/13, Dearlove, Christopher (UK) wrote: >> I'm neither recommending that a reference is included or excluded, I'm just >> providing here where one good source of definitions. Whether to reference it >> is a judgement call as to what is considered widely known, and what isn't. >> >> But that definition is not limited to physical attack. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 09 April 2013 12:44 >> To: Dearlove, Christopher (UK) >> Cc: manet >> Subject: Re: [manet] AB#1 Comments for WGLC >> draft-ietf-manet-nhdp-sec-threats-02 >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Hi Chris, >> >> The I-D seems not to define physical attacks (my understanding), which >> I was not sure of but [1] (mentioned in first AB#1 message) did >> include, but I think your input is prefered to include in the I-D or >> used, >> >> AB >> >> On 4/9/13, Dearlove, Christopher (UK) >> wrote: >>> AB> you don't define *Threat*, and *Attack* >>> >>> Personally, I would start with ISO 27000 which has: >>> >>> ===== >>> 2.45 >>> threat >>> potential cause of an unwanted incident, which may result in harm to a >>> system or organization >>> >>> 2.4 >>> attack >>> attempt to destroy, expose, alter, disable, steal or gain unauthorized >>> access to or make unauthorized use of >>> an asset (2.3) >>> >>> 2.3 >>> asset >>> anything that has value to the organization >>> NOTE There are many types of assets, including: >>> a) information (2.18); >>> b) software, such as a computer program; >>> c) physical, such as computer; >>> d) services; >>> e) people, and their qualifications, skills, and experience; and >>> f) intangibles, such as reputation and image. >>> >>> 2.18 >>> information asset >>> knowledge or data that has value to the organization >>> ===== >>> >>> (The rules are that you may substitute in the definition, so attack may >>> be >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >>> unauthorized access to or make unauthorized use of anything that has >>> value >>> to the organization".) >>> >>> [There is also an overlapping set of definitions in ISO 27032, but 27000 >>> is >>> more relevant here.] >>> >>> I don't know if there are any RFCs that reference ISO 27000. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>> >>> >> >> From ulrich@herberg.name Tue Apr 9 12:28:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E7021F982C for ; Tue, 9 Apr 2013 12:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L234FWgjUzB for ; Tue, 9 Apr 2013 12:28:27 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE0A21F9821 for ; Tue, 9 Apr 2013 12:28:27 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ha11so6172371vcb.2 for ; Tue, 09 Apr 2013 12:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dWKf5uwdJwdPF0iRASC/E595HwlBIwlTgonMDebpqNk=; b=05M44rBWEW4/DMkAm0tsKkCePYUw/MYT+p//9mc/GAVvToAv9ifpG35eCrHn3wEDuD 8zIUzDKcASby6+xEc/Y4sOuMOdTM57a2VOF9ynVnsxJ/BK12wGdLkjsqlu6J/w9IM0YG Wxj27wvzz9Tk7t0mWNW6jrH/g1dEoAnc009TU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=dWKf5uwdJwdPF0iRASC/E595HwlBIwlTgonMDebpqNk=; b=gHz6ek/2lDoVchzKfvxE3cvdcR2u/pBDHdZR3EQHltQYQvzq1zmf97yB6w+6l+GAeL EtVvZyFrPAaKs/Amh4XPTs0sFBBk56cDspxY0VA3hCBgEe53gLPeltZnmA+ohICccgf7 MELt3UMIWR1VU4ipk+fGyj++fq+LaD6Q9Ll3D1OVp7+L0wErT/2HjkPGen+spW8iuKt3 dIYuizZJXAomN0uV8NmHRv375shY/zi6HSMHqRwGVGrE0CDM6gkGqESgvFORYFxLxDIR 6jmnLw7MA4JxJVBDufE2nQKCPPajrDPS+Ysgfh3up9vpvoYdCybF3YSVs8rwOCzx3dnE bU3Q== MIME-Version: 1.0 X-Received: by 10.59.2.199 with SMTP id bq7mr20021320ved.51.1365535706425; Tue, 09 Apr 2013 12:28:26 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 12:28:26 -0700 (PDT) In-Reply-To: References: <515A977C.6050500@fkie.fraunhofer.de> Date: Tue, 9 Apr 2013 12:28:26 -0700 Message-ID: From: Ulrich Herberg To: James Nguyen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkWQePdUeSgF6+KtSd1RfrzV6LYofUQLaCiiHNqgm5hehU9Zj2I0pSsu0vqzFdEvIjJPxgX Cc: manet@ietf.org Subject: Re: [manet] rfc6622-bis-01 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:28:28 -0000 James, thank you for your comments and your support of this document. See below: On Tue, Apr 9, 2013 at 11:22 AM, James Nguyen wrote: > RFC6622-bis authors, > Overall, I think this draft is good. A few editorials (to make it cleare= r) > would complete its purpose. > Please find my comments starting with [JN]. > >> Section 5 > [...] > > > [JN] I would break this block of text into a simpler or less text one or= an > if-else statement pseudo code. J I agree that some of the sentences are a bit long and hard to read. I think we can slightly rewrite it so that it is easier to read. > > Same as for the following sections: > > 12.2.1. Packet ICV TLV > > > > 12.2.2. Message ICV TLV > > > > 12.2.3. Address Block ICV TLV Okay, I will look at these sentences. > > >> Section 7 Timestamp TLV Structure > > > > [JN] time synchronization is an issue in one of my emulation tools. It > would be an interesting topic to discuss how to sync timestamp in MANET, = but > it would be addressed or discussed outside the scope of this draft. Time synchronization is indeed not easy in MANETs. I agree that it should not be addressed inside this document. Regards Ulrich > > > > James > > On Tue, Apr 2, 2013 at 4:31 AM, Henning Rogge > wrote: >> >> On 03/25/2013 10:01 PM, Justin Dean wrote: >>> >>> Below I have included my comments in-line tagged with JD. The new TLV >>> subtype assignment confuses the issue of replacement of 6622. Are ther= e >>> situations where ICV TLVs with subtype 1 as defined in 6622 are >>> >>> more appropriate? My guess is No. In any case I shouldn't be guessing, >>> so that should be made more clear. >> >> >> I think subtype 2 does only apply to RFC5444 messages that must not be >> forwarded. >> >> The Source-IP of the UDP-packets forwarding the message do change every >> hop, so OLSRv2 TCs (as an example) must use subtype 1. >> >> Henning Rogge >> >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From adrian@olddog.co.uk Tue Apr 9 13:26:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3635C21F9850 for ; Tue, 9 Apr 2013 13:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tutslf4CYNB6 for ; Tue, 9 Apr 2013 13:26:25 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9723121F982F for ; Tue, 9 Apr 2013 13:26:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39KQLAt021274; Tue, 9 Apr 2013 21:26:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39KQKlC021264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 21:26:20 +0100 From: "Adrian Farrel" To: "'Ulrich Herberg'" , "'Abdussalam Baryun'" Date: Tue, 9 Apr 2013 21:26:19 +0100 Message-ID: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac41YHmsQtOwcXf3R/m2xjp82EuUYA== Content-Language: en-gb Cc: 'draft-ietf-manet-nhdp-sec-threats' , 'manet' Subject: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:26:26 -0000 Hi, I think that some of these comments relate to subversion of nodes. This topic often comes up in discussion of routing protocol security (although strangely not in the discussion of application level security - maybe they have more security clue than we do!) There are two types of subversion: 1. Installing new software on existing hardware 2. Replacing in-the-field hardware The second of these is usually protectable by security associations since physically replacing one node will not replicate the security credentials and so the node will not be able to participate in the security relationships necessary for the protocol. The first is usually regarded as faintly amusing! The idea that your main problem with a subverted node is harm to the routing infrastructure is wrong. If a node that routes packets has been subverted then *anything* may happen in your network. Protection against software subversion varies from nodes that physically self-destruct if tampered with, to nodes that require security checks before software can be modified. But, in both cases, there is nothing that the routing protocol can do. If a routing peer has the security credentials but decides to act badly, so be it! (There were a number of attempts to characterise the on-wire behavior of bad-actors, but - perhaps, of course - such attempts are self-defeating). Another view of a physical attack is one that degrades the performance of a node or link, perhaps through radio interference. I would argue that the only thing that a routing protocol can do in this case is to observe the degraded performance and to adjust metrics accordingly. However, I would also say that this is not actually the responsibility of the routing protocol, but of the management system in the network. Thus, I would say that physical attacks on notes are out of scope. Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Ulrich Herberg > Sent: 09 April 2013 20:23 > To: Abdussalam Baryun > Cc: draft-ietf-manet-nhdp-sec-threats; manet > Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- > threats-02 > > AB, > > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > wrote: > >[...] > > > > As a respond to my first to AB#1, AB#2 messages, and to [1] message. > > The NHDP threat related to physical attacks were ignored by the I-D. > > The I-D describes non-physical attacks in section 4 but does not for > > physical attacks, which has threats. The neighbors may get both > > together non-physical and physical, as if two or more neighbors are in > > radio range coverage. I don't think this was introduced in the I-D, > > which I hope editors follow. > > > > Military Scenario Example: > > > > Identity or link spoof can occur in other scenarios mentioned in I-D > > (i.e. spoofed the address while attacker is out of that neighbor radio > > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > > identity-spoof attack only after the neighbor is physically attacked, > > then M takes over that neighbor identity and responsibilities, even if > > they were in same radio coverage. This is a threat because these > > neighbors are in range of each other, and the node disapers from the > > network. The I-D does not consider the situation where the neighbor > > disapears from the network but replaced by an attacker M. This example > > scenario assumes that neighbors are in range but not aware of the > > physical attack, and the malicious node is aware. > > > > AB> Please editors of the I-D, consider in section 4.4.1 to add the > > threat described, if not clear for you, please reply, > > What do you mean by physical attacks? Tampering with the hardware of > the router running NHDP? I think that this is not the scope of the > draft (and also irrelevant); the draft purely looks at security > threats of misconfigured or malicious NHDP routers that misbehave when > using NHDP. It could be that such a router has been hacked via an > implementation flaw or physically exchanged some parts of the > hardware; that does not matter. For the case you describe, how does it > matter if the router disappears and comes back later? (whether or not > it is physically exchanged, or just stopped sending HELLOs for a > while). > > Regards > Ulrich > > > > > > [...] > > > > References: > > [1] The message below, by Dearlove, C., (2013), IETF MANET WG > > Discussion list, Re: [manet] AB#1 Comments for WGLC > > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > > > > > > On 4/9/13, Dearlove, Christopher (UK) > wrote: > >> I'm neither recommending that a reference is included or excluded, I'm just > >> providing here where one good source of definitions. Whether to reference it > >> is a judgement call as to what is considered widely known, and what isn't. > >> > >> But that definition is not limited to physical attack. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, > >> Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> -----Original Message----- > >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > >> Sent: 09 April 2013 12:44 > >> To: Dearlove, Christopher (UK) > >> Cc: manet > >> Subject: Re: [manet] AB#1 Comments for WGLC > >> draft-ietf-manet-nhdp-sec-threats-02 > >> > >> ----------------------! WARNING ! ---------------------- > >> This message originates from outside our organisation, > >> either from an external partner or from the internet. > >> Keep this in mind if you answer this message. > >> Follow the 'Report Suspicious Emails' link on IT matters > >> for instructions on reporting suspicious email messages. > >> -------------------------------------------------------- > >> > >> Hi Chris, > >> > >> The I-D seems not to define physical attacks (my understanding), which > >> I was not sure of but [1] (mentioned in first AB#1 message) did > >> include, but I think your input is prefered to include in the I-D or > >> used, > >> > >> AB > >> > >> On 4/9/13, Dearlove, Christopher (UK) > >> wrote: > >>> AB> you don't define *Threat*, and *Attack* > >>> > >>> Personally, I would start with ISO 27000 which has: > >>> > >>> ===== > >>> 2.45 > >>> threat > >>> potential cause of an unwanted incident, which may result in harm to a > >>> system or organization > >>> > >>> 2.4 > >>> attack > >>> attempt to destroy, expose, alter, disable, steal or gain unauthorized > >>> access to or make unauthorized use of > >>> an asset (2.3) > >>> > >>> 2.3 > >>> asset > >>> anything that has value to the organization > >>> NOTE There are many types of assets, including: > >>> a) information (2.18); > >>> b) software, such as a computer program; > >>> c) physical, such as computer; > >>> d) services; > >>> e) people, and their qualifications, skills, and experience; and > >>> f) intangibles, such as reputation and image. > >>> > >>> 2.18 > >>> information asset > >>> knowledge or data that has value to the organization > >>> ===== > >>> > >>> (The rules are that you may substitute in the definition, so attack may > >>> be > >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain > >>> unauthorized access to or make unauthorized use of anything that has > >>> value > >>> to the organization".) > >>> > >>> [There is also an overlapping set of definitions in ISO 27032, but 27000 > >>> is > >>> more relevant here.] > >>> > >>> I don't know if there are any RFCs that reference ISO 27000. > >>> > >>> -- > >>> Christopher Dearlove > >>> Senior Principal Engineer, Communications Group > >>> Communications, Networks and Image Analysis Capability > >>> BAE Systems Advanced Technology Centre > >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>> > >>> BAE Systems (Operations) Limited > >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >>> Centre, > >>> Farnborough, Hants, GU14 6YU, UK > >>> Registered in England & Wales No: 1996687 > >>> > >>> > >>> > ************************************************************** > ****** > >>> This email and any attachments are confidential to the intended > >>> recipient and may also be privileged. If you are not the intended > >>> recipient please delete it from your system and notify the sender. > >>> You should not copy it or use it for any purpose nor disclose or > >>> distribute its contents to any other person. > >>> > ************************************************************** > ****** > >>> > >>> > >> > >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue Apr 9 13:37:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564FD21F98E2 for ; Tue, 9 Apr 2013 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOxDDGkXb01E for ; Tue, 9 Apr 2013 13:37:51 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CF6EB21F9887 for ; Tue, 9 Apr 2013 13:37:50 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so5720922wea.24 for ; Tue, 09 Apr 2013 13:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z1+74/PMgSvY0Ut5HhA9dvpNYfcHfcN1iVW4R/Z3kKQ=; b=uD47pM3mLaAuOO7/f5t9Z2jqZEZq1vHuiVCzocY88l4GXxC71AWz6xMTlduX0MBjtT bi+qAt4523E2tZikEq3j6q1c3Ua/uW85jkeLovSAM5S1UlHWQda4XpsLiolKgqE6osSS BgSQMrox7BKcM9Vqd/U+JV+FN0C0OIfrWnl9YiEkLb2+n7g6ahLYKLhs1gXT+gOg+4zt uqsdqM2vyz47gDiwOO+rvv7WTKR2vFuzKw7lkPhbQKqzP/EDLAPAKNke12zhsrulH+cD tu0fLnRTC0WRfM3+kTyeAmXMV3AND6kDL1WOc+tDpYTqRLfZmICtpMDgzw/ubsG/TBKR J8kQ== MIME-Version: 1.0 X-Received: by 10.180.11.136 with SMTP id q8mr22182907wib.18.1365539869925; Tue, 09 Apr 2013 13:37:49 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 13:37:49 -0700 (PDT) In-Reply-To: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> Date: Tue, 9 Apr 2013 22:37:49 +0200 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:37:52 -0000 Hi Adrian, I asked the editors to define *attack* but they don't want to, so if it was out of the scope, So I need editors to make it clearly defined in the document, IMHO, excluding that attack or including SHOULD be informed in this informational I-D AB On 4/9/13, Adrian Farrel wrote: > Hi, > > I think that some of these comments relate to subversion of nodes. This > topic > often comes up in discussion of routing protocol security (although > strangely > not in the discussion of application level security - maybe they have more > security clue than we do!) > > There are two types of subversion: > 1. Installing new software on existing hardware > 2. Replacing in-the-field hardware > > The second of these is usually protectable by security associations since > physically replacing one node will not replicate the security credentials > and so > the node will not be able to participate in the security relationships > necessary > for the protocol. > > The first is usually regarded as faintly amusing! The idea that your main > problem with a subverted node is harm to the routing infrastructure is > wrong. If > a node that routes packets has been subverted then *anything* may happen in > your > network. Protection against software subversion varies from nodes that > physically self-destruct if tampered with, to nodes that require security > checks > before software can be modified. > > But, in both cases, there is nothing that the routing protocol can do. If a > routing peer has the security credentials but decides to act badly, so be > it! > (There were a number of attempts to characterise the on-wire behavior of > bad-actors, but - perhaps, of course - such attempts are self-defeating). > > > Another view of a physical attack is one that degrades the performance of a > node > or link, perhaps through radio interference. I would argue that the only > thing > that a routing protocol can do in this case is to observe the degraded > performance and to adjust metrics accordingly. However, I would also say > that > this is not actually the responsibility of the routing protocol, but of the > management system in the network. > > Thus, I would say that physical attacks on notes are out of scope. > > Adrian > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Ulrich Herberg >> Sent: 09 April 2013 20:23 >> To: Abdussalam Baryun >> Cc: draft-ietf-manet-nhdp-sec-threats; manet >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- >> threats-02 >> >> AB, >> >> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >> wrote: >> >[...] >> > >> > As a respond to my first to AB#1, AB#2 messages, and to [1] message. >> > The NHDP threat related to physical attacks were ignored by the I-D. >> > The I-D describes non-physical attacks in section 4 but does not for >> > physical attacks, which has threats. The neighbors may get both >> > together non-physical and physical, as if two or more neighbors are in >> > radio range coverage. I don't think this was introduced in the I-D, >> > which I hope editors follow. >> > >> > Military Scenario Example: >> > >> > Identity or link spoof can occur in other scenarios mentioned in I-D >> > (i.e. spoofed the address while attacker is out of that neighbor radio >> > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >> > identity-spoof attack only after the neighbor is physically attacked, >> > then M takes over that neighbor identity and responsibilities, even if >> > they were in same radio coverage. This is a threat because these >> > neighbors are in range of each other, and the node disapers from the >> > network. The I-D does not consider the situation where the neighbor >> > disapears from the network but replaced by an attacker M. This example >> > scenario assumes that neighbors are in range but not aware of the >> > physical attack, and the malicious node is aware. >> > >> > AB> Please editors of the I-D, consider in section 4.4.1 to add the >> > threat described, if not clear for you, please reply, >> >> What do you mean by physical attacks? Tampering with the hardware of >> the router running NHDP? I think that this is not the scope of the >> draft (and also irrelevant); the draft purely looks at security >> threats of misconfigured or malicious NHDP routers that misbehave when >> using NHDP. It could be that such a router has been hacked via an >> implementation flaw or physically exchanged some parts of the >> hardware; that does not matter. For the case you describe, how does it >> matter if the router disappears and comes back later? (whether or not >> it is physically exchanged, or just stopped sending HELLOs for a >> while). >> >> Regards >> Ulrich >> >> >> >> >> > [...] >> > >> > References: >> > [1] The message below, by Dearlove, C., (2013), IETF MANET WG >> > Discussion list, Re: [manet] AB#1 Comments for WGLC >> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >> > >> > >> > On 4/9/13, Dearlove, Christopher (UK) >> wrote: >> >> I'm neither recommending that a reference is included or excluded, I'm >> >> just >> >> providing here where one good source of definitions. Whether to >> >> reference > it >> >> is a judgement call as to what is considered widely known, and what >> >> isn't. >> >> >> >> But that definition is not limited to physical attack. >> >> >> >> -- >> >> Christopher Dearlove >> >> Senior Principal Engineer, Communications Group >> >> Communications, Networks and Image Analysis Capability >> >> BAE Systems Advanced Technology Centre >> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> >> >> BAE Systems (Operations) Limited >> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, >> >> Farnborough, Hants, GU14 6YU, UK >> >> Registered in England & Wales No: 1996687 >> >> >> >> >> >> -----Original Message----- >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> >> Sent: 09 April 2013 12:44 >> >> To: Dearlove, Christopher (UK) >> >> Cc: manet >> >> Subject: Re: [manet] AB#1 Comments for WGLC >> >> draft-ietf-manet-nhdp-sec-threats-02 >> >> >> >> ----------------------! WARNING ! ---------------------- >> >> This message originates from outside our organisation, >> >> either from an external partner or from the internet. >> >> Keep this in mind if you answer this message. >> >> Follow the 'Report Suspicious Emails' link on IT matters >> >> for instructions on reporting suspicious email messages. >> >> -------------------------------------------------------- >> >> >> >> Hi Chris, >> >> >> >> The I-D seems not to define physical attacks (my understanding), which >> >> I was not sure of but [1] (mentioned in first AB#1 message) did >> >> include, but I think your input is prefered to include in the I-D or >> >> used, >> >> >> >> AB >> >> >> >> On 4/9/13, Dearlove, Christopher (UK) >> >> wrote: >> >>> AB> you don't define *Threat*, and *Attack* >> >>> >> >>> Personally, I would start with ISO 27000 which has: >> >>> >> >>> ===== >> >>> 2.45 >> >>> threat >> >>> potential cause of an unwanted incident, which may result in harm to >> >>> a >> >>> system or organization >> >>> >> >>> 2.4 >> >>> attack >> >>> attempt to destroy, expose, alter, disable, steal or gain >> >>> unauthorized >> >>> access to or make unauthorized use of >> >>> an asset (2.3) >> >>> >> >>> 2.3 >> >>> asset >> >>> anything that has value to the organization >> >>> NOTE There are many types of assets, including: >> >>> a) information (2.18); >> >>> b) software, such as a computer program; >> >>> c) physical, such as computer; >> >>> d) services; >> >>> e) people, and their qualifications, skills, and experience; and >> >>> f) intangibles, such as reputation and image. >> >>> >> >>> 2.18 >> >>> information asset >> >>> knowledge or data that has value to the organization >> >>> ===== >> >>> >> >>> (The rules are that you may substitute in the definition, so attack >> >>> may >> >>> be >> >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> >>> unauthorized access to or make unauthorized use of anything that has >> >>> value >> >>> to the organization".) >> >>> >> >>> [There is also an overlapping set of definitions in ISO 27032, but >> >>> 27000 >> >>> is >> >>> more relevant here.] >> >>> >> >>> I don't know if there are any RFCs that reference ISO 27000. >> >>> >> >>> -- >> >>> Christopher Dearlove >> >>> Senior Principal Engineer, Communications Group >> >>> Communications, Networks and Image Analysis Capability >> >>> BAE Systems Advanced Technology Centre >> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >> >>> >> >>> BAE Systems (Operations) Limited >> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> >>> Centre, >> >>> Farnborough, Hants, GU14 6YU, UK >> >>> Registered in England & Wales No: 1996687 >> >>> >> >>> >> >>> >> ************************************************************** >> ****** >> >>> This email and any attachments are confidential to the intended >> >>> recipient and may also be privileged. If you are not the intended >> >>> recipient please delete it from your system and notify the sender. >> >>> You should not copy it or use it for any purpose nor disclose or >> >>> distribute its contents to any other person. >> >>> >> ************************************************************** >> ****** >> >>> >> >>> >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Tue Apr 9 13:54:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83721F98EC for ; Tue, 9 Apr 2013 13:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCQbHqBjcKWm for ; Tue, 9 Apr 2013 13:54:36 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2483C21F98ED for ; Tue, 9 Apr 2013 13:54:35 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn17so4161814wib.16 for ; Tue, 09 Apr 2013 13:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Scet7/jiirLudhEZVm3PDFu4pUamL5jlAXAVMRqwVqc=; b=h/Qr+uk1uomTY62om1xYRYI1vXYhy3/KYdM4FHJ507QiuDa3Um1M1VsFYg5VcUh2xN q6WyJLzNu9xxMQPGUCWh8PspKogk/0ziPFr+k4h6+MIdEDr7dvN8XD5azfPF3emC1i7c mtq89xY5a24QhsbNvoINQYPKlu+Ulv5VXQUO00/uzox8LRI5elvKi4Lzdu5wskgs8664 g6uxExMK+x4AizR9v3ImpauOnlPnvuc2u+oOmOUF0au0gTbgAGyqGEmCJFXJfxL9+kVw 4zPqDokYqqyPeutVhgNgmBwef2jE9EzeIp83whDNu2uzoVtSP5/fS6MS29H1emBu74QE tgOw== MIME-Version: 1.0 X-Received: by 10.180.149.227 with SMTP id ud3mr27337293wib.0.1365540875308; Tue, 09 Apr 2013 13:54:35 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 13:54:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 22:54:35 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:54:37 -0000 The main point was not the *physical attack*, the main point is that the I-D discusses only when the malicious node is not in range of the identity node that it is spoofing. I think that an attacker may be spoofing even if it was in radio coverage when the neighbor is disapeared. AB On 4/9/13, Ulrich Herberg wrote: > AB, > > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > wrote: >>[...] >> >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. >> The NHDP threat related to physical attacks were ignored by the I-D. >> The I-D describes non-physical attacks in section 4 but does not for >> physical attacks, which has threats. The neighbors may get both >> together non-physical and physical, as if two or more neighbors are in >> radio range coverage. I don't think this was introduced in the I-D, >> which I hope editors follow. >> >> Military Scenario Example: >> >> Identity or link spoof can occur in other scenarios mentioned in I-D >> (i.e. spoofed the address while attacker is out of that neighbor radio >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >> identity-spoof attack only after the neighbor is physically attacked, >> then M takes over that neighbor identity and responsibilities, even if >> they were in same radio coverage. This is a threat because these >> neighbors are in range of each other, and the node disapers from the >> network. The I-D does not consider the situation where the neighbor >> disapears from the network but replaced by an attacker M. This example >> scenario assumes that neighbors are in range but not aware of the >> physical attack, and the malicious node is aware. >> >> AB> Please editors of the I-D, consider in section 4.4.1 to add the >> threat described, if not clear for you, please reply, > > What do you mean by physical attacks? Tampering with the hardware of > the router running NHDP? I think that this is not the scope of the > draft (and also irrelevant); the draft purely looks at security > threats of misconfigured or malicious NHDP routers that misbehave when > using NHDP. It could be that such a router has been hacked via an > implementation flaw or physically exchanged some parts of the > hardware; that does not matter. For the case you describe, how does it > matter if the router disappears and comes back later? (whether or not > it is physically exchanged, or just stopped sending HELLOs for a > while). > > Regards > Ulrich > > > > >> [...] >> >> References: >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG >> Discussion list, Re: [manet] AB#1 Comments for WGLC >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >> >> >> On 4/9/13, Dearlove, Christopher (UK) >> wrote: >>> I'm neither recommending that a reference is included or excluded, I'm >>> just >>> providing here where one good source of definitions. Whether to reference >>> it >>> is a judgement call as to what is considered widely known, and what >>> isn't. >>> >>> But that definition is not limited to physical attack. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> Sent: 09 April 2013 12:44 >>> To: Dearlove, Christopher (UK) >>> Cc: manet >>> Subject: Re: [manet] AB#1 Comments for WGLC >>> draft-ietf-manet-nhdp-sec-threats-02 >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Hi Chris, >>> >>> The I-D seems not to define physical attacks (my understanding), which >>> I was not sure of but [1] (mentioned in first AB#1 message) did >>> include, but I think your input is prefered to include in the I-D or >>> used, >>> >>> AB >>> >>> On 4/9/13, Dearlove, Christopher (UK) >>> wrote: >>>> AB> you don't define *Threat*, and *Attack* >>>> >>>> Personally, I would start with ISO 27000 which has: >>>> >>>> ===== >>>> 2.45 >>>> threat >>>> potential cause of an unwanted incident, which may result in harm to a >>>> system or organization >>>> >>>> 2.4 >>>> attack >>>> attempt to destroy, expose, alter, disable, steal or gain unauthorized >>>> access to or make unauthorized use of >>>> an asset (2.3) >>>> >>>> 2.3 >>>> asset >>>> anything that has value to the organization >>>> NOTE There are many types of assets, including: >>>> a) information (2.18); >>>> b) software, such as a computer program; >>>> c) physical, such as computer; >>>> d) services; >>>> e) people, and their qualifications, skills, and experience; and >>>> f) intangibles, such as reputation and image. >>>> >>>> 2.18 >>>> information asset >>>> knowledge or data that has value to the organization >>>> ===== >>>> >>>> (The rules are that you may substitute in the definition, so attack may >>>> be >>>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >>>> unauthorized access to or make unauthorized use of anything that has >>>> value >>>> to the organization".) >>>> >>>> [There is also an overlapping set of definitions in ISO 27032, but >>>> 27000 >>>> is >>>> more relevant here.] >>>> >>>> I don't know if there are any RFCs that reference ISO 27000. >>>> >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, >>>> Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>> >>>> >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>> >>>> >>> >>> > From drdanhe@gmail.com Tue Apr 9 14:11:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5A21F97B8 for ; Tue, 9 Apr 2013 14:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPnGZIFrPV3p for ; Tue, 9 Apr 2013 14:11:58 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBC21F97AC for ; Tue, 9 Apr 2013 14:11:58 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so9192000ieb.36 for ; Tue, 09 Apr 2013 14:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L9T7RWSZlB5qDfLyhsGjGowQ/PjzTrKh9pJwU0KisIg=; b=wTcTIDr2WN84xeehXZD8uroTF2q1+nnWOgLOps+lu0BSh80EoUoiYDcOOdhRiSs26n sE7w7PH+kAlQouRIZdvN8opRL9PQGsHArkMdVKrpMkB8eZ4Uw+ZIf/YVSWTQV6b89FHZ eQzcAX/iApZCdqBEsAFjpRDYCzaT1zALpYt0wy2Hd0RhVUPcfIQVmiIj1G/QXgcUEQpq WjlVWLPfFluQgOw4r7iOkaf0wjRjIAaqE+L2pzOwtx7J9gcreFRX4WgRfqzjiVALZO/o vJd8KpyNNrsX1M9Skzv783TW68ih0a+TDQ6QVkjhQOzjjgCYva5Vm7sot/3swdF2gX3f Su2g== MIME-Version: 1.0 X-Received: by 10.42.42.69 with SMTP id s5mr15985706ice.2.1365541917761; Tue, 09 Apr 2013 14:11:57 -0700 (PDT) Received: by 10.50.56.5 with HTTP; Tue, 9 Apr 2013 14:11:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 22:11:57 +0100 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec50fe5f5ef2b9104d9f400bd Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:11:59 -0000 --bcaec50fe5f5ef2b9104d9f400bd Content-Type: text/plain; charset=ISO-8859-1 No. They don't need to define what is the attack means. Refer to ISO 27001:2005 which has clearly defined every terminologies. and again physical attack is out of scope to what we are doing information security at protocol levels! Cheers, Daniel On 9 April 2013 21:54, Abdussalam Baryun wrote: > The main point was not the *physical attack*, the main point is that > the I-D discusses only when the malicious node is not in range of the > identity node that it is spoofing. I think that an attacker may be > spoofing even if it was in radio coverage when the neighbor is > disapeared. > > AB > > On 4/9/13, Ulrich Herberg wrote: > > AB, > > > > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > > wrote: > >>[...] > >> > >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. > >> The NHDP threat related to physical attacks were ignored by the I-D. > >> The I-D describes non-physical attacks in section 4 but does not for > >> physical attacks, which has threats. The neighbors may get both > >> together non-physical and physical, as if two or more neighbors are in > >> radio range coverage. I don't think this was introduced in the I-D, > >> which I hope editors follow. > >> > >> Military Scenario Example: > >> > >> Identity or link spoof can occur in other scenarios mentioned in I-D > >> (i.e. spoofed the address while attacker is out of that neighbor radio > >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > >> identity-spoof attack only after the neighbor is physically attacked, > >> then M takes over that neighbor identity and responsibilities, even if > >> they were in same radio coverage. This is a threat because these > >> neighbors are in range of each other, and the node disapers from the > >> network. The I-D does not consider the situation where the neighbor > >> disapears from the network but replaced by an attacker M. This example > >> scenario assumes that neighbors are in range but not aware of the > >> physical attack, and the malicious node is aware. > >> > >> AB> Please editors of the I-D, consider in section 4.4.1 to add the > >> threat described, if not clear for you, please reply, > > > > What do you mean by physical attacks? Tampering with the hardware of > > the router running NHDP? I think that this is not the scope of the > > draft (and also irrelevant); the draft purely looks at security > > threats of misconfigured or malicious NHDP routers that misbehave when > > using NHDP. It could be that such a router has been hacked via an > > implementation flaw or physically exchanged some parts of the > > hardware; that does not matter. For the case you describe, how does it > > matter if the router disappears and comes back later? (whether or not > > it is physically exchanged, or just stopped sending HELLOs for a > > while). > > > > Regards > > Ulrich > > > > > > > > > >> [...] > >> > >> References: > >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG > >> Discussion list, Re: [manet] AB#1 Comments for WGLC > >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > >> > >> > >> On 4/9/13, Dearlove, Christopher (UK) > >> wrote: > >>> I'm neither recommending that a reference is included or excluded, I'm > >>> just > >>> providing here where one good source of definitions. Whether to > reference > >>> it > >>> is a judgement call as to what is considered widely known, and what > >>> isn't. > >>> > >>> But that definition is not limited to physical attack. > >>> > >>> -- > >>> Christopher Dearlove > >>> Senior Principal Engineer, Communications Group > >>> Communications, Networks and Image Analysis Capability > >>> BAE Systems Advanced Technology Centre > >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>> > >>> BAE Systems (Operations) Limited > >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >>> Centre, > >>> Farnborough, Hants, GU14 6YU, UK > >>> Registered in England & Wales No: 1996687 > >>> > >>> > >>> -----Original Message----- > >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > >>> Sent: 09 April 2013 12:44 > >>> To: Dearlove, Christopher (UK) > >>> Cc: manet > >>> Subject: Re: [manet] AB#1 Comments for WGLC > >>> draft-ietf-manet-nhdp-sec-threats-02 > >>> > >>> ----------------------! WARNING ! ---------------------- > >>> This message originates from outside our organisation, > >>> either from an external partner or from the internet. > >>> Keep this in mind if you answer this message. > >>> Follow the 'Report Suspicious Emails' link on IT matters > >>> for instructions on reporting suspicious email messages. > >>> -------------------------------------------------------- > >>> > >>> Hi Chris, > >>> > >>> The I-D seems not to define physical attacks (my understanding), which > >>> I was not sure of but [1] (mentioned in first AB#1 message) did > >>> include, but I think your input is prefered to include in the I-D or > >>> used, > >>> > >>> AB > >>> > >>> On 4/9/13, Dearlove, Christopher (UK) > >>> wrote: > >>>> AB> you don't define *Threat*, and *Attack* > >>>> > >>>> Personally, I would start with ISO 27000 which has: > >>>> > >>>> ===== > >>>> 2.45 > >>>> threat > >>>> potential cause of an unwanted incident, which may result in harm to a > >>>> system or organization > >>>> > >>>> 2.4 > >>>> attack > >>>> attempt to destroy, expose, alter, disable, steal or gain unauthorized > >>>> access to or make unauthorized use of > >>>> an asset (2.3) > >>>> > >>>> 2.3 > >>>> asset > >>>> anything that has value to the organization > >>>> NOTE There are many types of assets, including: > >>>> a) information (2.18); > >>>> b) software, such as a computer program; > >>>> c) physical, such as computer; > >>>> d) services; > >>>> e) people, and their qualifications, skills, and experience; and > >>>> f) intangibles, such as reputation and image. > >>>> > >>>> 2.18 > >>>> information asset > >>>> knowledge or data that has value to the organization > >>>> ===== > >>>> > >>>> (The rules are that you may substitute in the definition, so attack > may > >>>> be > >>>> parsed as "attempt to destroy, expose, alter, disable, steal or gain > >>>> unauthorized access to or make unauthorized use of anything that has > >>>> value > >>>> to the organization".) > >>>> > >>>> [There is also an overlapping set of definitions in ISO 27032, but > >>>> 27000 > >>>> is > >>>> more relevant here.] > >>>> > >>>> I don't know if there are any RFCs that reference ISO 27000. > >>>> > >>>> -- > >>>> Christopher Dearlove > >>>> Senior Principal Engineer, Communications Group > >>>> Communications, Networks and Image Analysis Capability > >>>> BAE Systems Advanced Technology Centre > >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>>> > >>>> BAE Systems (Operations) Limited > >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >>>> Centre, > >>>> Farnborough, Hants, GU14 6YU, UK > >>>> Registered in England & Wales No: 1996687 > >>>> > >>>> > >>>> ******************************************************************** > >>>> This email and any attachments are confidential to the intended > >>>> recipient and may also be privileged. If you are not the intended > >>>> recipient please delete it from your system and notify the sender. > >>>> You should not copy it or use it for any purpose nor disclose or > >>>> distribute its contents to any other person. > >>>> ******************************************************************** > >>>> > >>>> > >>> > >>> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec50fe5f5ef2b9104d9f400bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No. They don't need to define what is the attack means.
Refer to ISO 27001:2005 which has clearly defined every terminologies.=
=A0
and again physical attack is out of scope to what we are doing
information security=A0at protocol levels!
=A0
Cheers,
Daniel

On 9 April 2013 21:54, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
The main point was not the *physical = attack*, the main point is that
the I-D discusses only when the maliciou= s node is not in range of the
identity node that it is spoofing. I think that an attacker may be
spoof= ing even if it was in radio coverage when the neighbor is
disapeared.
AB

On 4/9/13, Ulrich Herberg <ulrich@herberg.name> wrote:
> AB,
>
&= gt; On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun
> <abdussalambaryun@gmail.com> w= rote:
>>[...]
>>
>> As a respond to my first to AB#1, AB#= 2 messages, and to [1] message.
>> The NHDP threat related to phys= ical attacks were ignored by the I-D.
>> The I-D describes non-phy= sical attacks in section 4 but does not for
>> physical attacks, which has threats. The neighbors may get both>> together non-physical and physical, as if two or more neighbors a= re in
>> radio range coverage. I don't think this was introduc= ed in the I-D,
>> which I hope editors follow.
>>
>> Military Scen= ario Example:
>>
>> Identity or link spoof can occur in o= ther scenarios mentioned in I-D
>> (i.e. spoofed the address while= attacker is out of that neighbor radio
>> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may no= t
>> identity-spoof attack only after the neighbor is physically a= ttacked,
>> then M takes over that neighbor identity and responsib= ilities, even if
>> they were in same radio coverage. This is a threat because these>> neighbors are in range of each other, and the node disapers from= the
>> network. The I-D does not consider the situation where the= neighbor
>> disapears from the network but replaced by an attacker M. This exa= mple
>> scenario assumes that neighbors are in range but not aware= of the
>> physical attack, and the malicious node is aware.
>>
>> AB> Please editors of the I-D, consider in section = 4.4.1 to add the
>> threat described, if not clear for you, please= reply,
>
> What do you mean by physical attacks? Tampering wit= h the hardware of
> the router running NHDP? I think that this is not the scope of the
= > draft (and also irrelevant); the draft purely looks at security
>= ; threats of misconfigured or malicious NHDP routers that misbehave when > using NHDP. It could be that such a router has been hacked via an
&= gt; implementation flaw or physically exchanged some parts of the
> h= ardware; that does not matter. For the case you describe, how does it
> matter if the router disappears and comes back later? (whether or not<= br>> it is physically exchanged, or just stopped sending HELLOs for a> while).
>
> Regards
> Ulrich
>
>
>
>
>> [...]
>>
>> References:
>&= gt; [1] The message below, by Dearlove, C., (2013), IETF MANET WG
>&g= t; Discussion list, Re: [manet] AB#1 Comments for WGLC
>> draft-ie= tf-manet-nhdp-sec-threats-02, 09.04.2013.
>>
>>
>> On 4/9/13, Dearlove, Christopher (UK) <= Chris.Dearlove@baesystems.= com>
>> wrote:
>>> I'm neither recommending= that a reference is included or excluded, I'm
>>> just
>>> providing here where one good source of d= efinitions. Whether to reference
>>> it
>>> is a ju= dgement call as to what is considered widely known, and what
>>>= ; isn't.
>>>
>>> But that definition is not limited to physical= attack.
>>>
>>> --
>>> Christopher Dea= rlove
>>> Senior Principal Engineer, Communications Group
>>> Communications, Networks and Image Analysis Capability
>= >> BAE Systems Advanced Technology Centre
>>> West Hannin= gfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>> Tel: +44 1245 242194<= /a> | =A0Fax: +44 1245 242124
>>> chris.dearlov= e@baesystems.com | http://www.baesystems.com
>>>
>>> BAE Syst= ems (Operations) Limited
>>> Registered Office: Warwick House, PO Box 87, Farnborough Aeros= pace
>>> Centre,
>>> Farnborough, Hants, GU14 6YU, = UK
>>> Registered in England & Wales No: 1996687
>>= ;>
>>>
>>> -----Original Message-----
>>> Fro= m: Abdussalam Baryun [mailto:= abdussalambaryun@gmail.com]
>>> Sent: 09 April 2013 12:44 >>> To: Dearlove, Christopher (UK)
>>> Cc: manet
&g= t;>> Subject: Re: [manet] AB#1 Comments for WGLC
>>> draf= t-ietf-manet-nhdp-sec-threats-02
>>>
>>> ----------= ------------! WARNING ! ----------------------
>>> This message originates from outside our organisation,
>= >> either from an external partner or from the internet.
>>&= gt; Keep this in mind if you answer this message.
>>> Follow th= e 'Report Suspicious Emails' link on IT matters
>>> for instructions on reporting suspicious email messages.
&g= t;>> --------------------------------------------------------
>= >>
>>> Hi Chris,
>>>
>>> The I-D = seems not to define physical attacks (my understanding), which
>>> I was not sure of but [1] (mentioned in first AB#1 message) di= d
>>> include, but I think your input is prefered to include in= the I-D or
>>> used,
>>>
>>> AB
>>>
>>> On 4/9/13, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com<= /a>>
>>> wrote:
>>>> AB> you don't def= ine *Threat*, and *Attack*
>>>>
>>>> Personally, I would start with ISO 270= 00 which has:
>>>>
>>>> =3D=3D=3D=3D=3D
&g= t;>>> 2.45
>>>> threat
>>>> potentia= l cause of an unwanted incident, which may result in harm to a
>>>> system or organization
>>>>
>>>= > 2.4
>>>> attack
>>>> attempt to destroy,= expose, alter, disable, steal or gain unauthorized
>>>> acc= ess to or make unauthorized use of
>>>> an asset (2.3)
>>>>
>>>> 2.3=
>>>> asset
>>>> anything that has value to t= he organization
>>>> NOTE There are many types of assets, in= cluding:
>>>> a) information (2.18);
>>>> b) software, su= ch as a computer program;
>>>> c) physical, such as computer= ;
>>>> d) services;
>>>> e) people, and their= qualifications, skills, and experience; and
>>>> f) intangibles, such as reputation and image.
>>&= gt;>
>>>> 2.18
>>>> information asset
&= gt;>>> knowledge or data that has value to the organization
>>>> =3D=3D=3D=3D=3D
>>>>
>>>> (T= he rules are that you may substitute in the definition, so attack may
&g= t;>>> be
>>>> parsed as "attempt to destroy, e= xpose, alter, disable, steal or gain
>>>> unauthorized access to or make unauthorized use of anythin= g that has
>>>> value
>>>> to the organizatio= n".)
>>>>
>>>> [There is also an overlap= ping set of definitions in ISO 27032, but
>>>> 27000
>>>> is
>>>> more rele= vant here.]
>>>>
>>>> I don't know if the= re are any RFCs that reference ISO 27000.
>>>>
>>&g= t;> --
>>>> Christopher Dearlove
>>>> Senior Principal = Engineer, Communications Group
>>>> Communications, Networks= and Image Analysis Capability
>>>> BAE Systems Advanced Tec= hnology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
>>>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
&= gt;>>> chris.dear= love@baesystems.com | http://www.baesystems.com
>>>>
>>>> BAE Systems (Operations) Limited
&g= t;>>> Registered Office: Warwick House, PO Box 87, Farnborough Aer= ospace
>>>> Centre,
>>>> Farnborough, Hants, = GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>&= gt;>
>>>>
>>>> ***************************= *****************************************
>>>> This email an= d any attachments are confidential to the intended
>>>> recipient and may also be privileged. If you are not the i= ntended
>>>> recipient please delete it from your system and= notify the sender.
>>>> You should not copy it or use it fo= r any purpose nor disclose or
>>>> distribute its contents to any other person.
>>&g= t;> ********************************************************************=
>>>>
>>>>
>>>
>>> >
_______________________________________________
manet mailing li= st
manet@ietf.org
https://www.ie= tf.org/mailman/listinfo/manet

--bcaec50fe5f5ef2b9104d9f400bd-- From adrian@olddog.co.uk Tue Apr 9 14:19:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1621F9919 for ; Tue, 9 Apr 2013 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxJTWVOaAMUW for ; Tue, 9 Apr 2013 14:19:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6121F9871 for ; Tue, 9 Apr 2013 14:19:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39LJdtJ010571; Tue, 9 Apr 2013 22:19:39 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39LJc6a010565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 22:19:39 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> In-Reply-To: Date: Tue, 9 Apr 2013 22:19:37 +0100 Message-ID: <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL8dT1L0fSxv8YysEdWEQSmBLQ01AIO9KVUlmFtR9A= Content-Language: en-gb Cc: 'draft-ietf-manet-nhdp-sec-threats' , 'manet' Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:19:44 -0000 This discussion is getting a bit circuitous! However, if you want IETF definitions of security terms, please read RFC 4949. And please direct any questions on the contents to the Security Area and not to this list! Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative reference to 4949. Adrian > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 09 April 2013 21:38 > To: adrian@olddog.co.uk > Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet > Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet- > nhdp-sec-threats-02] > > Hi Adrian, > > I asked the editors to define *attack* but they don't want to, so if > it was out of the scope, So I need editors to make it clearly defined > in the document, IMHO, excluding that attack or including SHOULD be > informed in this informational I-D > > AB > > On 4/9/13, Adrian Farrel wrote: > > Hi, > > > > I think that some of these comments relate to subversion of nodes. This > > topic > > often comes up in discussion of routing protocol security (although > > strangely > > not in the discussion of application level security - maybe they have more > > security clue than we do!) > > > > There are two types of subversion: > > 1. Installing new software on existing hardware > > 2. Replacing in-the-field hardware > > > > The second of these is usually protectable by security associations since > > physically replacing one node will not replicate the security credentials > > and so > > the node will not be able to participate in the security relationships > > necessary > > for the protocol. > > > > The first is usually regarded as faintly amusing! The idea that your main > > problem with a subverted node is harm to the routing infrastructure is > > wrong. If > > a node that routes packets has been subverted then *anything* may happen in > > your > > network. Protection against software subversion varies from nodes that > > physically self-destruct if tampered with, to nodes that require security > > checks > > before software can be modified. > > > > But, in both cases, there is nothing that the routing protocol can do. If a > > routing peer has the security credentials but decides to act badly, so be > > it! > > (There were a number of attempts to characterise the on-wire behavior of > > bad-actors, but - perhaps, of course - such attempts are self-defeating). > > > > > > Another view of a physical attack is one that degrades the performance of a > > node > > or link, perhaps through radio interference. I would argue that the only > > thing > > that a routing protocol can do in this case is to observe the degraded > > performance and to adjust metrics accordingly. However, I would also say > > that > > this is not actually the responsibility of the routing protocol, but of the > > management system in the network. > > > > Thus, I would say that physical attacks on notes are out of scope. > > > > Adrian > > > >> -----Original Message----- > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of > >> Ulrich Herberg > >> Sent: 09 April 2013 20:23 > >> To: Abdussalam Baryun > >> Cc: draft-ietf-manet-nhdp-sec-threats; manet > >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- > >> threats-02 > >> > >> AB, > >> > >> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > >> wrote: > >> >[...] > >> > > >> > As a respond to my first to AB#1, AB#2 messages, and to [1] message. > >> > The NHDP threat related to physical attacks were ignored by the I-D. > >> > The I-D describes non-physical attacks in section 4 but does not for > >> > physical attacks, which has threats. The neighbors may get both > >> > together non-physical and physical, as if two or more neighbors are in > >> > radio range coverage. I don't think this was introduced in the I-D, > >> > which I hope editors follow. > >> > > >> > Military Scenario Example: > >> > > >> > Identity or link spoof can occur in other scenarios mentioned in I-D > >> > (i.e. spoofed the address while attacker is out of that neighbor radio > >> > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > >> > identity-spoof attack only after the neighbor is physically attacked, > >> > then M takes over that neighbor identity and responsibilities, even if > >> > they were in same radio coverage. This is a threat because these > >> > neighbors are in range of each other, and the node disapers from the > >> > network. The I-D does not consider the situation where the neighbor > >> > disapears from the network but replaced by an attacker M. This example > >> > scenario assumes that neighbors are in range but not aware of the > >> > physical attack, and the malicious node is aware. > >> > > >> > AB> Please editors of the I-D, consider in section 4.4.1 to add the > >> > threat described, if not clear for you, please reply, > >> > >> What do you mean by physical attacks? Tampering with the hardware of > >> the router running NHDP? I think that this is not the scope of the > >> draft (and also irrelevant); the draft purely looks at security > >> threats of misconfigured or malicious NHDP routers that misbehave when > >> using NHDP. It could be that such a router has been hacked via an > >> implementation flaw or physically exchanged some parts of the > >> hardware; that does not matter. For the case you describe, how does it > >> matter if the router disappears and comes back later? (whether or not > >> it is physically exchanged, or just stopped sending HELLOs for a > >> while). > >> > >> Regards > >> Ulrich > >> > >> > >> > >> > >> > [...] > >> > > >> > References: > >> > [1] The message below, by Dearlove, C., (2013), IETF MANET WG > >> > Discussion list, Re: [manet] AB#1 Comments for WGLC > >> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > >> > > >> > > >> > On 4/9/13, Dearlove, Christopher (UK) > >> wrote: > >> >> I'm neither recommending that a reference is included or excluded, I'm > >> >> just > >> >> providing here where one good source of definitions. Whether to > >> >> reference > > it > >> >> is a judgement call as to what is considered widely known, and what > >> >> isn't. > >> >> > >> >> But that definition is not limited to physical attack. > >> >> > >> >> -- > >> >> Christopher Dearlove > >> >> Senior Principal Engineer, Communications Group > >> >> Communications, Networks and Image Analysis Capability > >> >> BAE Systems Advanced Technology Centre > >> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> >> > >> >> BAE Systems (Operations) Limited > >> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >> Centre, > >> >> Farnborough, Hants, GU14 6YU, UK > >> >> Registered in England & Wales No: 1996687 > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > >> >> Sent: 09 April 2013 12:44 > >> >> To: Dearlove, Christopher (UK) > >> >> Cc: manet > >> >> Subject: Re: [manet] AB#1 Comments for WGLC > >> >> draft-ietf-manet-nhdp-sec-threats-02 > >> >> > >> >> ----------------------! WARNING ! ---------------------- > >> >> This message originates from outside our organisation, > >> >> either from an external partner or from the internet. > >> >> Keep this in mind if you answer this message. > >> >> Follow the 'Report Suspicious Emails' link on IT matters > >> >> for instructions on reporting suspicious email messages. > >> >> -------------------------------------------------------- > >> >> > >> >> Hi Chris, > >> >> > >> >> The I-D seems not to define physical attacks (my understanding), which > >> >> I was not sure of but [1] (mentioned in first AB#1 message) did > >> >> include, but I think your input is prefered to include in the I-D or > >> >> used, > >> >> > >> >> AB > >> >> > >> >> On 4/9/13, Dearlove, Christopher (UK) > >> >> wrote: > >> >>> AB> you don't define *Threat*, and *Attack* > >> >>> > >> >>> Personally, I would start with ISO 27000 which has: > >> >>> > >> >>> ===== > >> >>> 2.45 > >> >>> threat > >> >>> potential cause of an unwanted incident, which may result in harm to > >> >>> a > >> >>> system or organization > >> >>> > >> >>> 2.4 > >> >>> attack > >> >>> attempt to destroy, expose, alter, disable, steal or gain > >> >>> unauthorized > >> >>> access to or make unauthorized use of > >> >>> an asset (2.3) > >> >>> > >> >>> 2.3 > >> >>> asset > >> >>> anything that has value to the organization > >> >>> NOTE There are many types of assets, including: > >> >>> a) information (2.18); > >> >>> b) software, such as a computer program; > >> >>> c) physical, such as computer; > >> >>> d) services; > >> >>> e) people, and their qualifications, skills, and experience; and > >> >>> f) intangibles, such as reputation and image. > >> >>> > >> >>> 2.18 > >> >>> information asset > >> >>> knowledge or data that has value to the organization > >> >>> ===== > >> >>> > >> >>> (The rules are that you may substitute in the definition, so attack > >> >>> may > >> >>> be > >> >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain > >> >>> unauthorized access to or make unauthorized use of anything that has > >> >>> value > >> >>> to the organization".) > >> >>> > >> >>> [There is also an overlapping set of definitions in ISO 27032, but > >> >>> 27000 > >> >>> is > >> >>> more relevant here.] > >> >>> > >> >>> I don't know if there are any RFCs that reference ISO 27000. > >> >>> > >> >>> -- > >> >>> Christopher Dearlove > >> >>> Senior Principal Engineer, Communications Group > >> >>> Communications, Networks and Image Analysis Capability > >> >>> BAE Systems Advanced Technology Centre > >> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com > >> >>> > >> >>> BAE Systems (Operations) Limited > >> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >> >>> Centre, > >> >>> Farnborough, Hants, GU14 6YU, UK > >> >>> Registered in England & Wales No: 1996687 > >> >>> > >> >>> > >> >>> > >> > ************************************************************** > >> ****** > >> >>> This email and any attachments are confidential to the intended > >> >>> recipient and may also be privileged. If you are not the intended > >> >>> recipient please delete it from your system and notify the sender. > >> >>> You should not copy it or use it for any purpose nor disclose or > >> >>> distribute its contents to any other person. > >> >>> > >> > ************************************************************** > >> ****** > >> >>> > >> >>> > >> >> > >> >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > From adrian@olddog.co.uk Tue Apr 9 14:22:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BDD21F9728 for ; Tue, 9 Apr 2013 14:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui8phAtHdFoH for ; Tue, 9 Apr 2013 14:22:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D361221F94CC for ; Tue, 9 Apr 2013 14:22:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39LM4wr005369; Tue, 9 Apr 2013 22:22:04 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39LM2xM005350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 22:22:02 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'Ulrich Herberg'" References: In-Reply-To: Date: Tue, 9 Apr 2013 22:22:01 +0100 Message-ID: <027001ce3568$474afa10$d5e0ee30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMB7yA85cZh5yRqUVHMMjrjH2ed5wHLbWcpAaCktDCWS5GTgA== Content-Language: en-gb Cc: 'draft-ietf-manet-nhdp-sec-threats' , 'manet' Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:22:10 -0000 Personally, I think this misinterprets "spoofing". You don't spoof a node, you spoof packets so that they appear to have come from a node. A > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 09 April 2013 21:55 > To: Ulrich Herberg > Cc: draft-ietf-manet-nhdp-sec-threats; manet > Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- > threats-02 > > The main point was not the *physical attack*, the main point is that > the I-D discusses only when the malicious node is not in range of the > identity node that it is spoofing. I think that an attacker may be > spoofing even if it was in radio coverage when the neighbor is > disapeared. > > AB > > On 4/9/13, Ulrich Herberg wrote: > > AB, > > > > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > > wrote: > >>[...] > >> > >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. > >> The NHDP threat related to physical attacks were ignored by the I-D. > >> The I-D describes non-physical attacks in section 4 but does not for > >> physical attacks, which has threats. The neighbors may get both > >> together non-physical and physical, as if two or more neighbors are in > >> radio range coverage. I don't think this was introduced in the I-D, > >> which I hope editors follow. > >> > >> Military Scenario Example: > >> > >> Identity or link spoof can occur in other scenarios mentioned in I-D > >> (i.e. spoofed the address while attacker is out of that neighbor radio > >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > >> identity-spoof attack only after the neighbor is physically attacked, > >> then M takes over that neighbor identity and responsibilities, even if > >> they were in same radio coverage. This is a threat because these > >> neighbors are in range of each other, and the node disapers from the > >> network. The I-D does not consider the situation where the neighbor > >> disapears from the network but replaced by an attacker M. This example > >> scenario assumes that neighbors are in range but not aware of the > >> physical attack, and the malicious node is aware. > >> > >> AB> Please editors of the I-D, consider in section 4.4.1 to add the > >> threat described, if not clear for you, please reply, > > > > What do you mean by physical attacks? Tampering with the hardware of > > the router running NHDP? I think that this is not the scope of the > > draft (and also irrelevant); the draft purely looks at security > > threats of misconfigured or malicious NHDP routers that misbehave when > > using NHDP. It could be that such a router has been hacked via an > > implementation flaw or physically exchanged some parts of the > > hardware; that does not matter. For the case you describe, how does it > > matter if the router disappears and comes back later? (whether or not > > it is physically exchanged, or just stopped sending HELLOs for a > > while). > > > > Regards > > Ulrich > > > > > > > > > >> [...] > >> > >> References: > >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG > >> Discussion list, Re: [manet] AB#1 Comments for WGLC > >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > >> > >> > >> On 4/9/13, Dearlove, Christopher (UK) > >> wrote: > >>> I'm neither recommending that a reference is included or excluded, I'm > >>> just > >>> providing here where one good source of definitions. Whether to reference > >>> it > >>> is a judgement call as to what is considered widely known, and what > >>> isn't. > >>> > >>> But that definition is not limited to physical attack. > >>> > >>> -- > >>> Christopher Dearlove > >>> Senior Principal Engineer, Communications Group > >>> Communications, Networks and Image Analysis Capability > >>> BAE Systems Advanced Technology Centre > >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>> > >>> BAE Systems (Operations) Limited > >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >>> Centre, > >>> Farnborough, Hants, GU14 6YU, UK > >>> Registered in England & Wales No: 1996687 > >>> > >>> > >>> -----Original Message----- > >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > >>> Sent: 09 April 2013 12:44 > >>> To: Dearlove, Christopher (UK) > >>> Cc: manet > >>> Subject: Re: [manet] AB#1 Comments for WGLC > >>> draft-ietf-manet-nhdp-sec-threats-02 > >>> > >>> ----------------------! WARNING ! ---------------------- > >>> This message originates from outside our organisation, > >>> either from an external partner or from the internet. > >>> Keep this in mind if you answer this message. > >>> Follow the 'Report Suspicious Emails' link on IT matters > >>> for instructions on reporting suspicious email messages. > >>> -------------------------------------------------------- > >>> > >>> Hi Chris, > >>> > >>> The I-D seems not to define physical attacks (my understanding), which > >>> I was not sure of but [1] (mentioned in first AB#1 message) did > >>> include, but I think your input is prefered to include in the I-D or > >>> used, > >>> > >>> AB > >>> > >>> On 4/9/13, Dearlove, Christopher (UK) > >>> wrote: > >>>> AB> you don't define *Threat*, and *Attack* > >>>> > >>>> Personally, I would start with ISO 27000 which has: > >>>> > >>>> ===== > >>>> 2.45 > >>>> threat > >>>> potential cause of an unwanted incident, which may result in harm to a > >>>> system or organization > >>>> > >>>> 2.4 > >>>> attack > >>>> attempt to destroy, expose, alter, disable, steal or gain unauthorized > >>>> access to or make unauthorized use of > >>>> an asset (2.3) > >>>> > >>>> 2.3 > >>>> asset > >>>> anything that has value to the organization > >>>> NOTE There are many types of assets, including: > >>>> a) information (2.18); > >>>> b) software, such as a computer program; > >>>> c) physical, such as computer; > >>>> d) services; > >>>> e) people, and their qualifications, skills, and experience; and > >>>> f) intangibles, such as reputation and image. > >>>> > >>>> 2.18 > >>>> information asset > >>>> knowledge or data that has value to the organization > >>>> ===== > >>>> > >>>> (The rules are that you may substitute in the definition, so attack may > >>>> be > >>>> parsed as "attempt to destroy, expose, alter, disable, steal or gain > >>>> unauthorized access to or make unauthorized use of anything that has > >>>> value > >>>> to the organization".) > >>>> > >>>> [There is also an overlapping set of definitions in ISO 27032, but > >>>> 27000 > >>>> is > >>>> more relevant here.] > >>>> > >>>> I don't know if there are any RFCs that reference ISO 27000. > >>>> > >>>> -- > >>>> Christopher Dearlove > >>>> Senior Principal Engineer, Communications Group > >>>> Communications, Networks and Image Analysis Capability > >>>> BAE Systems Advanced Technology Centre > >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >>>> chris.dearlove@baesystems.com | http://www.baesystems.com > >>>> > >>>> BAE Systems (Operations) Limited > >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > >>>> Centre, > >>>> Farnborough, Hants, GU14 6YU, UK > >>>> Registered in England & Wales No: 1996687 > >>>> > >>>> > >>>> > ************************************************************** > ****** > >>>> This email and any attachments are confidential to the intended > >>>> recipient and may also be privileged. If you are not the intended > >>>> recipient please delete it from your system and notify the sender. > >>>> You should not copy it or use it for any purpose nor disclose or > >>>> distribute its contents to any other person. > >>>> > ************************************************************** > ****** > >>>> > >>>> > >>> > >>> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue Apr 9 14:38:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E36821F98E0 for ; Tue, 9 Apr 2013 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh1S4nXYYCst for ; Tue, 9 Apr 2013 14:38:14 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 175EB21F97FF for ; Tue, 9 Apr 2013 14:38:13 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id f13so5244331vbg.0 for ; Tue, 09 Apr 2013 14:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sE2gMeTmzMvVTpiSbhFMQ4JBtGxmTS8zcpr7rD4U5aY=; b=O2WTvolCzxycuNlQ0njH5hMIE3lPY8XY1xm72fC+KU+jyj5z0QQVvECWx+xYgFskBr rQrPcHpnBwBQzO7nLd8OPaUlPlM0WtxLKetM7KGznISMvKx+4myLrBzWlyx9UGbbs+b5 9652DoNIFqDtZMpJ4FZSlzyVxEJU5hM15hExs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sE2gMeTmzMvVTpiSbhFMQ4JBtGxmTS8zcpr7rD4U5aY=; b=pHvyiRKbIsUp2K1bS6SJPkjqIIP29sr7mbpvQstaT60xtI+z7zp6DCPnW86JJ4bif9 O/JJcA/larwHQMM01+wI4BuQ94iJV3Akq6aEC/beO1ja3HneOammet4tRW3I291KqUgD YcV9PDTsHpySMgqLMnjrhF46RHLxDYOn360l7qnTau/B1450EZJYApNR9KMyMokbQ9Rj FScoqeWBN5uN1Cad5VXxymkXCBqzxDQaA6X+nHAcUhTvJi04Kw9LtISFKG/1o0E5Neac 8ai22bNqZ7Cb29dHr5e3q5TxMO0doP81On6rzoOExL8DKvOqpO5d+Yn9B7JcGntZ6X3F UhrA== MIME-Version: 1.0 X-Received: by 10.52.243.196 with SMTP id xa4mr17577496vdc.22.1365543493491; Tue, 09 Apr 2013 14:38:13 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 14:38:13 -0700 (PDT) In-Reply-To: <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> Date: Tue, 9 Apr 2013 14:38:13 -0700 Message-ID: From: Ulrich Herberg To: "adrian@olddog.co.uk" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn55nG17ccXcV9Yfz2z2/d6e1PmRksY0DZU6B8WKeNb3rRSE+eb9lbATh7hZzT0/tmqYCyY Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:38:15 -0000 On Tue, Apr 9, 2013 at 2:19 PM, Adrian Farrel wrote: [...] > > Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative > reference to 4949. That is POSSIBLE. We MIGHT add the reference ;-) Seriously, it would not hurt adding this informative reference, so it's fine for me to add it. Ulrich > > Adrian > >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 09 April 2013 21:38 >> To: adrian@olddog.co.uk >> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet >> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet- >> nhdp-sec-threats-02] >> >> Hi Adrian, >> >> I asked the editors to define *attack* but they don't want to, so if >> it was out of the scope, So I need editors to make it clearly defined >> in the document, IMHO, excluding that attack or including SHOULD be >> informed in this informational I-D >> >> AB >> >> On 4/9/13, Adrian Farrel wrote: >> > Hi, >> > >> > I think that some of these comments relate to subversion of nodes. This >> > topic >> > often comes up in discussion of routing protocol security (although >> > strangely >> > not in the discussion of application level security - maybe they have more >> > security clue than we do!) >> > >> > There are two types of subversion: >> > 1. Installing new software on existing hardware >> > 2. Replacing in-the-field hardware >> > >> > The second of these is usually protectable by security associations since >> > physically replacing one node will not replicate the security credentials >> > and so >> > the node will not be able to participate in the security relationships >> > necessary >> > for the protocol. >> > >> > The first is usually regarded as faintly amusing! The idea that your main >> > problem with a subverted node is harm to the routing infrastructure is >> > wrong. If >> > a node that routes packets has been subverted then *anything* may happen in >> > your >> > network. Protection against software subversion varies from nodes that >> > physically self-destruct if tampered with, to nodes that require security >> > checks >> > before software can be modified. >> > >> > But, in both cases, there is nothing that the routing protocol can do. If a >> > routing peer has the security credentials but decides to act badly, so be >> > it! >> > (There were a number of attempts to characterise the on-wire behavior of >> > bad-actors, but - perhaps, of course - such attempts are self-defeating). >> > >> > >> > Another view of a physical attack is one that degrades the performance of a >> > node >> > or link, perhaps through radio interference. I would argue that the only >> > thing >> > that a routing protocol can do in this case is to observe the degraded >> > performance and to adjust metrics accordingly. However, I would also say >> > that >> > this is not actually the responsibility of the routing protocol, but of the >> > management system in the network. >> > >> > Thus, I would say that physical attacks on notes are out of scope. >> > >> > Adrian >> > >> >> -----Original Message----- >> >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of >> >> Ulrich Herberg >> >> Sent: 09 April 2013 20:23 >> >> To: Abdussalam Baryun >> >> Cc: draft-ietf-manet-nhdp-sec-threats; manet >> >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- >> >> threats-02 >> >> >> >> AB, >> >> >> >> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >> >> wrote: >> >> >[...] >> >> > >> >> > As a respond to my first to AB#1, AB#2 messages, and to [1] message. >> >> > The NHDP threat related to physical attacks were ignored by the I-D. >> >> > The I-D describes non-physical attacks in section 4 but does not for >> >> > physical attacks, which has threats. The neighbors may get both >> >> > together non-physical and physical, as if two or more neighbors are in >> >> > radio range coverage. I don't think this was introduced in the I-D, >> >> > which I hope editors follow. >> >> > >> >> > Military Scenario Example: >> >> > >> >> > Identity or link spoof can occur in other scenarios mentioned in I-D >> >> > (i.e. spoofed the address while attacker is out of that neighbor radio >> >> > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >> >> > identity-spoof attack only after the neighbor is physically attacked, >> >> > then M takes over that neighbor identity and responsibilities, even if >> >> > they were in same radio coverage. This is a threat because these >> >> > neighbors are in range of each other, and the node disapers from the >> >> > network. The I-D does not consider the situation where the neighbor >> >> > disapears from the network but replaced by an attacker M. This example >> >> > scenario assumes that neighbors are in range but not aware of the >> >> > physical attack, and the malicious node is aware. >> >> > >> >> > AB> Please editors of the I-D, consider in section 4.4.1 to add the >> >> > threat described, if not clear for you, please reply, >> >> >> >> What do you mean by physical attacks? Tampering with the hardware of >> >> the router running NHDP? I think that this is not the scope of the >> >> draft (and also irrelevant); the draft purely looks at security >> >> threats of misconfigured or malicious NHDP routers that misbehave when >> >> using NHDP. It could be that such a router has been hacked via an >> >> implementation flaw or physically exchanged some parts of the >> >> hardware; that does not matter. For the case you describe, how does it >> >> matter if the router disappears and comes back later? (whether or not >> >> it is physically exchanged, or just stopped sending HELLOs for a >> >> while). >> >> >> >> Regards >> >> Ulrich >> >> >> >> >> >> >> >> >> >> > [...] >> >> > >> >> > References: >> >> > [1] The message below, by Dearlove, C., (2013), IETF MANET WG >> >> > Discussion list, Re: [manet] AB#1 Comments for WGLC >> >> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >> >> > >> >> > >> >> > On 4/9/13, Dearlove, Christopher (UK) >> >> wrote: >> >> >> I'm neither recommending that a reference is included or excluded, I'm >> >> >> just >> >> >> providing here where one good source of definitions. Whether to >> >> >> reference >> > it >> >> >> is a judgement call as to what is considered widely known, and what >> >> >> isn't. >> >> >> >> >> >> But that definition is not limited to physical attack. >> >> >> >> >> >> -- >> >> >> Christopher Dearlove >> >> >> Senior Principal Engineer, Communications Group >> >> >> Communications, Networks and Image Analysis Capability >> >> >> BAE Systems Advanced Technology Centre >> >> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >> >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> >> >> >> >> BAE Systems (Operations) Limited >> >> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> >> Centre, >> >> >> Farnborough, Hants, GU14 6YU, UK >> >> >> Registered in England & Wales No: 1996687 >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> >> >> Sent: 09 April 2013 12:44 >> >> >> To: Dearlove, Christopher (UK) >> >> >> Cc: manet >> >> >> Subject: Re: [manet] AB#1 Comments for WGLC >> >> >> draft-ietf-manet-nhdp-sec-threats-02 >> >> >> >> >> >> ----------------------! WARNING ! ---------------------- >> >> >> This message originates from outside our organisation, >> >> >> either from an external partner or from the internet. >> >> >> Keep this in mind if you answer this message. >> >> >> Follow the 'Report Suspicious Emails' link on IT matters >> >> >> for instructions on reporting suspicious email messages. >> >> >> -------------------------------------------------------- >> >> >> >> >> >> Hi Chris, >> >> >> >> >> >> The I-D seems not to define physical attacks (my understanding), which >> >> >> I was not sure of but [1] (mentioned in first AB#1 message) did >> >> >> include, but I think your input is prefered to include in the I-D or >> >> >> used, >> >> >> >> >> >> AB >> >> >> >> >> >> On 4/9/13, Dearlove, Christopher (UK) >> >> >> wrote: >> >> >>> AB> you don't define *Threat*, and *Attack* >> >> >>> >> >> >>> Personally, I would start with ISO 27000 which has: >> >> >>> >> >> >>> ===== >> >> >>> 2.45 >> >> >>> threat >> >> >>> potential cause of an unwanted incident, which may result in harm to >> >> >>> a >> >> >>> system or organization >> >> >>> >> >> >>> 2.4 >> >> >>> attack >> >> >>> attempt to destroy, expose, alter, disable, steal or gain >> >> >>> unauthorized >> >> >>> access to or make unauthorized use of >> >> >>> an asset (2.3) >> >> >>> >> >> >>> 2.3 >> >> >>> asset >> >> >>> anything that has value to the organization >> >> >>> NOTE There are many types of assets, including: >> >> >>> a) information (2.18); >> >> >>> b) software, such as a computer program; >> >> >>> c) physical, such as computer; >> >> >>> d) services; >> >> >>> e) people, and their qualifications, skills, and experience; and >> >> >>> f) intangibles, such as reputation and image. >> >> >>> >> >> >>> 2.18 >> >> >>> information asset >> >> >>> knowledge or data that has value to the organization >> >> >>> ===== >> >> >>> >> >> >>> (The rules are that you may substitute in the definition, so attack >> >> >>> may >> >> >>> be >> >> >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> >> >>> unauthorized access to or make unauthorized use of anything that has >> >> >>> value >> >> >>> to the organization".) >> >> >>> >> >> >>> [There is also an overlapping set of definitions in ISO 27032, but >> >> >>> 27000 >> >> >>> is >> >> >>> more relevant here.] >> >> >>> >> >> >>> I don't know if there are any RFCs that reference ISO 27000. >> >> >>> >> >> >>> -- >> >> >>> Christopher Dearlove >> >> >>> Senior Principal Engineer, Communications Group >> >> >>> Communications, Networks and Image Analysis Capability >> >> >>> BAE Systems Advanced Technology Centre >> >> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> >>> >> >> >>> BAE Systems (Operations) Limited >> >> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> >> >>> Centre, >> >> >>> Farnborough, Hants, GU14 6YU, UK >> >> >>> Registered in England & Wales No: 1996687 >> >> >>> >> >> >>> >> >> >>> >> >> >> ************************************************************** >> >> ****** >> >> >>> This email and any attachments are confidential to the intended >> >> >>> recipient and may also be privileged. If you are not the intended >> >> >>> recipient please delete it from your system and notify the sender. >> >> >>> You should not copy it or use it for any purpose nor disclose or >> >> >>> distribute its contents to any other person. >> >> >>> >> >> >> ************************************************************** >> >> ****** >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > > From yi.jiazi@gmail.com Tue Apr 9 14:44:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B721F9997 for ; Tue, 9 Apr 2013 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.485 X-Spam-Level: *** X-Spam-Status: No, score=3.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, J_CHICKENPOX_83=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPoQzOQZQwdh for ; Tue, 9 Apr 2013 14:44:35 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61821F998B for ; Tue, 9 Apr 2013 14:44:35 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so5520975wiw.4 for ; Tue, 09 Apr 2013 14:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rJJbrxOPc6XYZYevqs6EZFiskLV/TeVkai6x4Vx4Gic=; b=XE41eJN/AcioECjWuQmJIpSQN77YwmrdfOZqx4yomz9hWx0ty9tCJSONYIE3PWTNwW yMt/l6Ko8hsBtacRVTIZcUlhc+qf58kCHRwufCs0R8yHmjr/bn1dCUfvQbpBlL4LobSW 6KKRfGO2zkgAMjA1YWkA4pvj/KhcHfakvljtw2jW5XDAEmuG+HpjEWw8beLfjj14w0gL AwOf8KkzIeNDLk+6ZRqxL00hJ5k7TBht9jYXSuNBPNPIgCPsGIcY1kmr0a+HX+3B5iNh 9UfhslFObKDEyyITg3evqHYbKJYiYA7MgzyCXAMEVNWpyZQJRZ3KF3bxkujDWHTMfOFk +sZg== X-Received: by 10.180.90.18 with SMTP id bs18mr756441wib.31.1365543869113; Tue, 09 Apr 2013 14:44:29 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fg6sm31571218wib.10.2013.04.09.14.44.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 14:44:28 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> Date: Tue, 9 Apr 2013 23:44:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>, <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1503) Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:44:36 -0000 Hi,=20 I think it's simply because: o LOADng is in active development cycle. There are a lot of = engineers working on it. We have new results/implementation experience = everyday.=20 o There are a lot of people interested in LOADng.=20 o it's about running code/implementation=20 -- hopefully it's still what IETF (or MANET WG) = believes in.=20 All the previous discussions are purely technical. I really don't want = to start the political part. But if that happens, I would have tons of = words to say.=20 sincerely Jiazi On Apr 9, 2013, at 6:43 PM, JP Vasseur (jvasseur) = wrote: > Why are we still discussing loadng on this mailing list as opposed to = the WG Manet reactive routing protocol ? >=20 > JP Vasseur > Cisco Fellow >=20 > Sent from my iPhone >=20 > On 9 avr. 2013, at 09:11, "Jiazi Yi" wrote: >=20 >> Hi,=20 >>=20 >> On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY = wrote: >>=20 >>> Hi,=20 >>>=20 >>> On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY = wrote: >>>=20 >>>> Hi Jiazi, >>>>=20 >>>> Thank you for illustrating the difference between the IETF draft = and the scientific publications. Also, regarding the publications sent. = I have some questions about the results listed at the sent publications. >>>>=20 >>>> 1. What is the propagation delay set on evaluating the End-To-End = delay? as i know that the propagation delay affects largely the = end-to-end delay result. This is because , when you changed the = propagation delay of the channel (wireless or wired) you will gain = different results. >>>=20 >>> The propagation delay depends on the lower-layer protocol used. In = our simulations for LOADng evaluation, it's 802.11b.=20 >>>=20 >>> So, you use nodes of 250m range, Mesh topology connected.We could = consider LOADng as Layer 3 protocol, is this right? >>=20 >> LOADng can be used in both layer 2 and layer 3. In IETF, we care more = about its application in layer 3. =20 >> In our tests/simulations, it's in layer 3.=20 >>=20 >>>>=20 >>>> 2. Regarding the overhead, I think that there are two points of = view related to the overhead: >>>> A. Network Overhead (like the one mentioned at the = papers) >>>> B. Processing Overhead (like memory usage and = required processing) >>>> Did you estimate the factor *2.B*? if yes, what is its value? >>>=20 >>> The "processing overhead" for an on-demand protocol like LOADng is = trivial, with O(n) complexity.=20 >>>=20 >>> I mean by processing overhead,the overhead introduced by the = protocol to be implemented, (How many events executed to perform the = protocol?) Also, the memory usage used to implement or simulate the = protocol (I think the LOADng interoperability-report mentioned = 6000-lines Java code, is it for implementation or test?). This will be = very efficient to select the suitable IC (MCU or DSP) to implement the = protocol. >>=20 >> In fact, the 6000-line java code is with functions like network = simulation, test, different extensions. For a "pure" LOADng = implementation, it can be greatly reduced.=20 >> For example, the implementations of Hitachi is with 1589 C code, or = 1987 C++ code.=20 >>=20 >> For the moment, all the implementations that I'm aware of, are in = software. Because the protocol is fairly simple, I think it would be = enough to have software implementation, which also has the advantage of = flexibility.=20 >>=20 >> best >>=20 >> Jiazi >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue Apr 9 15:36:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7516B21F9334 for ; Tue, 9 Apr 2013 15:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JowHCU2b3Z2Q for ; Tue, 9 Apr 2013 15:36:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id BB8D921F9123 for ; Tue, 9 Apr 2013 15:36:35 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so4192856wid.11 for ; Tue, 09 Apr 2013 15:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F9KgW9S5cRk17GOz2DJ1K4Ng26AxFa6UIivJNnHqTU4=; b=PLOTnC4oNlhG36KOCRZXWIrPeaQwCMqq1qxaxbLDF35cOdRio49r2KJLbtsyRBBi7T momh3z4lqQLQoydoL5kWKoAY+Q+r0u+pW3p2CK1ObkX74Ej1BGcvy3rrXc6tos80Vju7 BZMwTdBTiFRoO7+GpsGT1FKWZU+cEwd1R7e4rtKi647ol4c3j78cVTencso28geBmJq3 FzXyYqQFP9UyjEm0FS4zrCCAMl/FsVniK+nKCKT5ZdX8caYPB/avxG41bDMGoCKE9HdB in90sW0b6jMGkrOzR0vNris6RdwDegFDkpSEiElYeNA5hTaMJFbpg8wP4aWgTs0altqQ Z0iA== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr41236181wjb.24.1365546994904; Tue, 09 Apr 2013 15:36:34 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 15:36:34 -0700 (PDT) In-Reply-To: <027001ce3568$474afa10$d5e0ee30$@olddog.co.uk> References: <027001ce3568$474afa10$d5e0ee30$@olddog.co.uk> Date: Wed, 10 Apr 2013 00:36:34 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-sec-threats Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:36:37 -0000 Ok, the main point of the comment is that the examples of section 4.4.1 only considers when the malicious node using identity of another that is not in range, I hope the editors include scenarios that there is a threat even if in the radio range when also the malicious node aware when that node is in sleep mode or malfunction. The condition of same radio range does not stop the NHDP threat in my opinion, if you think it does please advise. This AB#3 comment suggested considering the scenario of same coverage for neighbors but possible spoof, AB On 4/9/13, Adrian Farrel wrote: > Personally, I think this misinterprets "spoofing". You don't spoof a node, > you > spoof packets so that they appear to have come from a node. > A > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Abdussalam Baryun >> Sent: 09 April 2013 21:55 >> To: Ulrich Herberg >> Cc: draft-ietf-manet-nhdp-sec-threats; manet >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- >> threats-02 >> >> The main point was not the *physical attack*, the main point is that >> the I-D discusses only when the malicious node is not in range of the >> identity node that it is spoofing. I think that an attacker may be >> spoofing even if it was in radio coverage when the neighbor is >> disapeared. >> >> AB >> >> On 4/9/13, Ulrich Herberg wrote: >> > AB, >> > >> > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >> > wrote: >> >>[...] >> >> >> >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. >> >> The NHDP threat related to physical attacks were ignored by the I-D. >> >> The I-D describes non-physical attacks in section 4 but does not for >> >> physical attacks, which has threats. The neighbors may get both >> >> together non-physical and physical, as if two or more neighbors are in >> >> radio range coverage. I don't think this was introduced in the I-D, >> >> which I hope editors follow. >> >> >> >> Military Scenario Example: >> >> >> >> Identity or link spoof can occur in other scenarios mentioned in I-D >> >> (i.e. spoofed the address while attacker is out of that neighbor radio >> >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >> >> identity-spoof attack only after the neighbor is physically attacked, >> >> then M takes over that neighbor identity and responsibilities, even if >> >> they were in same radio coverage. This is a threat because these >> >> neighbors are in range of each other, and the node disapers from the >> >> network. The I-D does not consider the situation where the neighbor >> >> disapears from the network but replaced by an attacker M. This example >> >> scenario assumes that neighbors are in range but not aware of the >> >> physical attack, and the malicious node is aware. >> >> >> >> AB> Please editors of the I-D, consider in section 4.4.1 to add the >> >> threat described, if not clear for you, please reply, >> > >> > What do you mean by physical attacks? Tampering with the hardware of >> > the router running NHDP? I think that this is not the scope of the >> > draft (and also irrelevant); the draft purely looks at security >> > threats of misconfigured or malicious NHDP routers that misbehave when >> > using NHDP. It could be that such a router has been hacked via an >> > implementation flaw or physically exchanged some parts of the >> > hardware; that does not matter. For the case you describe, how does it >> > matter if the router disappears and comes back later? (whether or not >> > it is physically exchanged, or just stopped sending HELLOs for a >> > while). >> > >> > Regards >> > Ulrich >> > >> > >> > >> > >> >> [...] >> >> >> >> References: >> >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG >> >> Discussion list, Re: [manet] AB#1 Comments for WGLC >> >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >> >> >> >> >> >> On 4/9/13, Dearlove, Christopher (UK) >> >> wrote: >> >>> I'm neither recommending that a reference is included or excluded, >> >>> I'm >> >>> just >> >>> providing here where one good source of definitions. Whether to >> >>> reference >> >>> it >> >>> is a judgement call as to what is considered widely known, and what >> >>> isn't. >> >>> >> >>> But that definition is not limited to physical attack. >> >>> >> >>> -- >> >>> Christopher Dearlove >> >>> Senior Principal Engineer, Communications Group >> >>> Communications, Networks and Image Analysis Capability >> >>> BAE Systems Advanced Technology Centre >> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >> >>> >> >>> BAE Systems (Operations) Limited >> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> >>> Centre, >> >>> Farnborough, Hants, GU14 6YU, UK >> >>> Registered in England & Wales No: 1996687 >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> >>> Sent: 09 April 2013 12:44 >> >>> To: Dearlove, Christopher (UK) >> >>> Cc: manet >> >>> Subject: Re: [manet] AB#1 Comments for WGLC >> >>> draft-ietf-manet-nhdp-sec-threats-02 >> >>> >> >>> ----------------------! WARNING ! ---------------------- >> >>> This message originates from outside our organisation, >> >>> either from an external partner or from the internet. >> >>> Keep this in mind if you answer this message. >> >>> Follow the 'Report Suspicious Emails' link on IT matters >> >>> for instructions on reporting suspicious email messages. >> >>> -------------------------------------------------------- >> >>> >> >>> Hi Chris, >> >>> >> >>> The I-D seems not to define physical attacks (my understanding), >> >>> which >> >>> I was not sure of but [1] (mentioned in first AB#1 message) did >> >>> include, but I think your input is prefered to include in the I-D or >> >>> used, >> >>> >> >>> AB >> >>> >> >>> On 4/9/13, Dearlove, Christopher (UK) >> >>> wrote: >> >>>> AB> you don't define *Threat*, and *Attack* >> >>>> >> >>>> Personally, I would start with ISO 27000 which has: >> >>>> >> >>>> ===== >> >>>> 2.45 >> >>>> threat >> >>>> potential cause of an unwanted incident, which may result in harm to >> >>>> a >> >>>> system or organization >> >>>> >> >>>> 2.4 >> >>>> attack >> >>>> attempt to destroy, expose, alter, disable, steal or gain >> >>>> unauthorized >> >>>> access to or make unauthorized use of >> >>>> an asset (2.3) >> >>>> >> >>>> 2.3 >> >>>> asset >> >>>> anything that has value to the organization >> >>>> NOTE There are many types of assets, including: >> >>>> a) information (2.18); >> >>>> b) software, such as a computer program; >> >>>> c) physical, such as computer; >> >>>> d) services; >> >>>> e) people, and their qualifications, skills, and experience; and >> >>>> f) intangibles, such as reputation and image. >> >>>> >> >>>> 2.18 >> >>>> information asset >> >>>> knowledge or data that has value to the organization >> >>>> ===== >> >>>> >> >>>> (The rules are that you may substitute in the definition, so attack >> >>>> may >> >>>> be >> >>>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >> >>>> unauthorized access to or make unauthorized use of anything that has >> >>>> value >> >>>> to the organization".) >> >>>> >> >>>> [There is also an overlapping set of definitions in ISO 27032, but >> >>>> 27000 >> >>>> is >> >>>> more relevant here.] >> >>>> >> >>>> I don't know if there are any RFCs that reference ISO 27000. >> >>>> >> >>>> -- >> >>>> Christopher Dearlove >> >>>> Senior Principal Engineer, Communications Group >> >>>> Communications, Networks and Image Analysis Capability >> >>>> BAE Systems Advanced Technology Centre >> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >> >>>> >> >>>> BAE Systems (Operations) Limited >> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> >>>> Centre, >> >>>> Farnborough, Hants, GU14 6YU, UK >> >>>> Registered in England & Wales No: 1996687 >> >>>> >> >>>> >> >>>> >> ************************************************************** >> ****** >> >>>> This email and any attachments are confidential to the intended >> >>>> recipient and may also be privileged. If you are not the intended >> >>>> recipient please delete it from your system and notify the sender. >> >>>> You should not copy it or use it for any purpose nor disclose or >> >>>> distribute its contents to any other person. >> >>>> >> ************************************************************** >> ****** >> >>>> >> >>>> >> >>> >> >>> >> > >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From ulrich@herberg.name Tue Apr 9 16:41:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28ED21F8F9E for ; Tue, 9 Apr 2013 16:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRbG11kQRkoG for ; Tue, 9 Apr 2013 16:41:48 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A66FD21F8F2C for ; Tue, 9 Apr 2013 16:41:48 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e12so5173789vbg.31 for ; Tue, 09 Apr 2013 16:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jHuANylFHU/6dr6w+4vy4TI/DLPA/r2VVfbca5xfikY=; b=gTJ8sjHRuY4cwOnm/6/8r7xTnIWbH+NHNzljKPfR4tCyn9GVvYxKs864FY4J+x104K ptWtRLn5qtB2GxgwzMb7Xd/iJuTDrFn8UPnjMSErQus6+Z4if6nllrt5zXKgk8LQ8xI8 kVEadttJ5L6eDT7HbJgCt6SDe+oeU1AG9411E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=jHuANylFHU/6dr6w+4vy4TI/DLPA/r2VVfbca5xfikY=; b=N59Cv5RQ8+tk9QByG1ZWgili+Q0nYdF3YcPpQ7P5Eo1T0fcI4fyIwGLqDoUGdWKMRE Rr4/sLraDZVkoiGCsfv1FO/lDig1kV2XxzTY29Xy96sInr+jeZddwB/pyQGe5Xts5SvE +XO1KtHPG1nXa11SB/FrGzJbxMD9yNOXDNhHmzEThpfu1loPQ9v/+q0eW/Hnt7tHllcH 2lrWMdOW02oSuoUQ03NRVQeKQ3IGL4kI0tBvbI5h8eIg88ll831fD9mOKyZH9/01uD0F tP1MFfqGSASzE6J6CmEHUWp7Xfki90WAwrFYyPyw+dmHvPpWrki1Yr1gxyMBx1AcPsw2 vZMQ== MIME-Version: 1.0 X-Received: by 10.220.224.77 with SMTP id in13mr20787509vcb.12.1365550908083; Tue, 09 Apr 2013 16:41:48 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 16:41:47 -0700 (PDT) In-Reply-To: References: <027001ce3568$474afa10$d5e0ee30$@olddog.co.uk> Date: Tue, 9 Apr 2013 16:41:47 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlYataYsnEmyIZNxxnXuOQE+7mitTYvSWbx3rwVBH3izgwmGU63LyRE0vHNbl784cfNxRql Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 23:41:50 -0000 The draft does not say that identity spoofing is only applicable when the malicious node is not in direct communication range with the router it spoofs the address of outgoing messages. Read: Figure 1 depicts a ***simple example***. In that ***example***, NHDP router A is in radio range of C, but not of the Compromised NHDP router X. This is just for illustration purposes and in particular because it is extended in the following example in figure 2. Router A and X could also be in radio range, it would still be identity spoofing (and nothing of the description of the attack in the paragraphs before the two examples indicate any requirement about being in radio range or not). On Tue, Apr 9, 2013 at 3:36 PM, Abdussalam Baryun wrote: > Ok, the main point of the comment is that the examples of section > 4.4.1 only considers when the malicious node using identity of another > that is not in range, I hope the editors include scenarios that there > is a threat even if in the radio range when also the malicious node > aware when that node is in sleep mode or malfunction. > > The condition of same radio range does not stop the NHDP threat in my > opinion, if you think it does please advise. This AB#3 comment > suggested considering the scenario of same coverage for neighbors but > possible spoof, > > AB > > On 4/9/13, Adrian Farrel wrote: >> Personally, I think this misinterprets "spoofing". You don't spoof a node, >> you >> spoof packets so that they appear to have come from a node. >> A >> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >>> Abdussalam Baryun >>> Sent: 09 April 2013 21:55 >>> To: Ulrich Herberg >>> Cc: draft-ietf-manet-nhdp-sec-threats; manet >>> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- >>> threats-02 >>> >>> The main point was not the *physical attack*, the main point is that >>> the I-D discusses only when the malicious node is not in range of the >>> identity node that it is spoofing. I think that an attacker may be >>> spoofing even if it was in radio coverage when the neighbor is >>> disapeared. >>> >>> AB >>> >>> On 4/9/13, Ulrich Herberg wrote: >>> > AB, >>> > >>> > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >>> > wrote: >>> >>[...] >>> >> >>> >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. >>> >> The NHDP threat related to physical attacks were ignored by the I-D. >>> >> The I-D describes non-physical attacks in section 4 but does not for >>> >> physical attacks, which has threats. The neighbors may get both >>> >> together non-physical and physical, as if two or more neighbors are in >>> >> radio range coverage. I don't think this was introduced in the I-D, >>> >> which I hope editors follow. >>> >> >>> >> Military Scenario Example: >>> >> >>> >> Identity or link spoof can occur in other scenarios mentioned in I-D >>> >> (i.e. spoofed the address while attacker is out of that neighbor radio >>> >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >>> >> identity-spoof attack only after the neighbor is physically attacked, >>> >> then M takes over that neighbor identity and responsibilities, even if >>> >> they were in same radio coverage. This is a threat because these >>> >> neighbors are in range of each other, and the node disapers from the >>> >> network. The I-D does not consider the situation where the neighbor >>> >> disapears from the network but replaced by an attacker M. This example >>> >> scenario assumes that neighbors are in range but not aware of the >>> >> physical attack, and the malicious node is aware. >>> >> >>> >> AB> Please editors of the I-D, consider in section 4.4.1 to add the >>> >> threat described, if not clear for you, please reply, >>> > >>> > What do you mean by physical attacks? Tampering with the hardware of >>> > the router running NHDP? I think that this is not the scope of the >>> > draft (and also irrelevant); the draft purely looks at security >>> > threats of misconfigured or malicious NHDP routers that misbehave when >>> > using NHDP. It could be that such a router has been hacked via an >>> > implementation flaw or physically exchanged some parts of the >>> > hardware; that does not matter. For the case you describe, how does it >>> > matter if the router disappears and comes back later? (whether or not >>> > it is physically exchanged, or just stopped sending HELLOs for a >>> > while). >>> > >>> > Regards >>> > Ulrich >>> > >>> > >>> > >>> > >>> >> [...] >>> >> >>> >> References: >>> >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG >>> >> Discussion list, Re: [manet] AB#1 Comments for WGLC >>> >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >>> >> >>> >> >>> >> On 4/9/13, Dearlove, Christopher (UK) >>> >> wrote: >>> >>> I'm neither recommending that a reference is included or excluded, >>> >>> I'm >>> >>> just >>> >>> providing here where one good source of definitions. Whether to >>> >>> reference >>> >>> it >>> >>> is a judgement call as to what is considered widely known, and what >>> >>> isn't. >>> >>> >>> >>> But that definition is not limited to physical attack. >>> >>> >>> >>> -- >>> >>> Christopher Dearlove >>> >>> Senior Principal Engineer, Communications Group >>> >>> Communications, Networks and Image Analysis Capability >>> >>> BAE Systems Advanced Technology Centre >>> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> >>> >>> BAE Systems (Operations) Limited >>> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> >>> Centre, >>> >>> Farnborough, Hants, GU14 6YU, UK >>> >>> Registered in England & Wales No: 1996687 >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> >>> Sent: 09 April 2013 12:44 >>> >>> To: Dearlove, Christopher (UK) >>> >>> Cc: manet >>> >>> Subject: Re: [manet] AB#1 Comments for WGLC >>> >>> draft-ietf-manet-nhdp-sec-threats-02 >>> >>> >>> >>> ----------------------! WARNING ! ---------------------- >>> >>> This message originates from outside our organisation, >>> >>> either from an external partner or from the internet. >>> >>> Keep this in mind if you answer this message. >>> >>> Follow the 'Report Suspicious Emails' link on IT matters >>> >>> for instructions on reporting suspicious email messages. >>> >>> -------------------------------------------------------- >>> >>> >>> >>> Hi Chris, >>> >>> >>> >>> The I-D seems not to define physical attacks (my understanding), >>> >>> which >>> >>> I was not sure of but [1] (mentioned in first AB#1 message) did >>> >>> include, but I think your input is prefered to include in the I-D or >>> >>> used, >>> >>> >>> >>> AB >>> >>> >>> >>> On 4/9/13, Dearlove, Christopher (UK) >>> >>> wrote: >>> >>>> AB> you don't define *Threat*, and *Attack* >>> >>>> >>> >>>> Personally, I would start with ISO 27000 which has: >>> >>>> >>> >>>> ===== >>> >>>> 2.45 >>> >>>> threat >>> >>>> potential cause of an unwanted incident, which may result in harm to >>> >>>> a >>> >>>> system or organization >>> >>>> >>> >>>> 2.4 >>> >>>> attack >>> >>>> attempt to destroy, expose, alter, disable, steal or gain >>> >>>> unauthorized >>> >>>> access to or make unauthorized use of >>> >>>> an asset (2.3) >>> >>>> >>> >>>> 2.3 >>> >>>> asset >>> >>>> anything that has value to the organization >>> >>>> NOTE There are many types of assets, including: >>> >>>> a) information (2.18); >>> >>>> b) software, such as a computer program; >>> >>>> c) physical, such as computer; >>> >>>> d) services; >>> >>>> e) people, and their qualifications, skills, and experience; and >>> >>>> f) intangibles, such as reputation and image. >>> >>>> >>> >>>> 2.18 >>> >>>> information asset >>> >>>> knowledge or data that has value to the organization >>> >>>> ===== >>> >>>> >>> >>>> (The rules are that you may substitute in the definition, so attack >>> >>>> may >>> >>>> be >>> >>>> parsed as "attempt to destroy, expose, alter, disable, steal or gain >>> >>>> unauthorized access to or make unauthorized use of anything that has >>> >>>> value >>> >>>> to the organization".) >>> >>>> >>> >>>> [There is also an overlapping set of definitions in ISO 27032, but >>> >>>> 27000 >>> >>>> is >>> >>>> more relevant here.] >>> >>>> >>> >>>> I don't know if there are any RFCs that reference ISO 27000. >>> >>>> >>> >>>> -- >>> >>>> Christopher Dearlove >>> >>>> Senior Principal Engineer, Communications Group >>> >>>> Communications, Networks and Image Analysis Capability >>> >>>> BAE Systems Advanced Technology Centre >>> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>>> >>> >>>> BAE Systems (Operations) Limited >>> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> >>>> Centre, >>> >>>> Farnborough, Hants, GU14 6YU, UK >>> >>>> Registered in England & Wales No: 1996687 >>> >>>> >>> >>>> >>> >>>> >>> ************************************************************** >>> ****** >>> >>>> This email and any attachments are confidential to the intended >>> >>>> recipient and may also be privileged. If you are not the intended >>> >>>> recipient please delete it from your system and notify the sender. >>> >>>> You should not copy it or use it for any purpose nor disclose or >>> >>>> distribute its contents to any other person. >>> >>>> >>> ************************************************************** >>> ****** >>> >>>> >>> >>>> >>> >>> >>> >>> >>> > >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> From abdussalambaryun@gmail.com Tue Apr 9 17:23:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55121F9854 for ; Tue, 9 Apr 2013 17:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6zym-NiZbyv for ; Tue, 9 Apr 2013 17:23:08 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 04B0821F9437 for ; Tue, 9 Apr 2013 17:23:07 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so5452012wgh.5 for ; Tue, 09 Apr 2013 17:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UdcD7zN7OJJIP9KTsUA7LpZPJRTgVbC74O+9wnC+3q0=; b=RDDi/ucs02cuBbT5yunt5lCU1YpgQQW/i6rflo+hHZySkw2/PQBlABA60CXfQbwhIH Zq9EWe2BYOmbNsM8RmTPmBGXFqdNTR9zUoX7wombKvq1a5EBbDpa83wjnmHYtVDx1yp2 +m8isJNP9TvyWkKWGA/qPOqb2fPcv3GphPW3km59P4MaKyZvw4/JO1ITbNwCpykTsPBo /XFxuM6QRBq5zusP/2PtpW5TJb5GXYpirnGFUEi2ZIN+bK4WPxEtVF95rgHIBDIkeE1U HUvd3GC5M1U0jslEnbLkyHFfi1VeHZ4NH/TLma5MggpwxPOm1hoQegphtn5AMU0lBUKl FV6A== MIME-Version: 1.0 X-Received: by 10.180.11.136 with SMTP id q8mr22937049wib.18.1365553387154; Tue, 09 Apr 2013 17:23:07 -0700 (PDT) Received: by 10.180.76.209 with HTTP; Tue, 9 Apr 2013 17:23:06 -0700 (PDT) In-Reply-To: References: <027001ce3568$474afa10$d5e0ee30$@olddog.co.uk> Date: Wed, 10 Apr 2013 02:23:06 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:23:09 -0000 It is clear from the I-D section 4.4.1 that the section only considers A is not in radio range of X, I don't know how you can say A and X could be in range in Fig.2, there is no line and they are far away, it mentions that A uses hops to reach. I ment in my scenario that D, X and A may be in same radio coverage (only one hop) and that still may have threats to NHDP, this not represented. If you see the link line between each node-to-node you notice that radio range means there is a line between them. If you recall seeing Fig.3 to know how the authors describe range and lost, AB On 4/10/13, Ulrich Herberg wrote: > The draft does not say that identity spoofing is only applicable when > the malicious node is not in direct communication range with the > router it spoofs the address of outgoing messages. > Read: > Figure 1 depicts a ***simple example***. In that ***example***, NHDP > router A is in radio range of C, but not of the Compromised NHDP > router X. > > This is just for illustration purposes and in particular because it is > extended in the following example in figure 2. Router A and X could > also be in radio range, it would still be identity spoofing (and > nothing of the description of the attack in the paragraphs before the > two examples indicate any requirement about being in radio range or > not). > > On Tue, Apr 9, 2013 at 3:36 PM, Abdussalam Baryun > wrote: >> Ok, the main point of the comment is that the examples of section >> 4.4.1 only considers when the malicious node using identity of another >> that is not in range, I hope the editors include scenarios that there >> is a threat even if in the radio range when also the malicious node >> aware when that node is in sleep mode or malfunction. >> >> The condition of same radio range does not stop the NHDP threat in my >> opinion, if you think it does please advise. This AB#3 comment >> suggested considering the scenario of same coverage for neighbors but >> possible spoof, >> >> AB >> >> On 4/9/13, Adrian Farrel wrote: >>> Personally, I think this misinterprets "spoofing". You don't spoof a >>> node, >>> you >>> spoof packets so that they appear to have come from a node. >>> A >>> >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>>> Of >>>> Abdussalam Baryun >>>> Sent: 09 April 2013 21:55 >>>> To: Ulrich Herberg >>>> Cc: draft-ietf-manet-nhdp-sec-threats; manet >>>> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- >>>> threats-02 >>>> >>>> The main point was not the *physical attack*, the main point is that >>>> the I-D discusses only when the malicious node is not in range of the >>>> identity node that it is spoofing. I think that an attacker may be >>>> spoofing even if it was in radio coverage when the neighbor is >>>> disapeared. >>>> >>>> AB >>>> >>>> On 4/9/13, Ulrich Herberg wrote: >>>> > AB, >>>> > >>>> > On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >>>> > wrote: >>>> >>[...] >>>> >> >>>> >> As a respond to my first to AB#1, AB#2 messages, and to [1] message. >>>> >> The NHDP threat related to physical attacks were ignored by the I-D. >>>> >> The I-D describes non-physical attacks in section 4 but does not for >>>> >> physical attacks, which has threats. The neighbors may get both >>>> >> together non-physical and physical, as if two or more neighbors are >>>> >> in >>>> >> radio range coverage. I don't think this was introduced in the I-D, >>>> >> which I hope editors follow. >>>> >> >>>> >> Military Scenario Example: >>>> >> >>>> >> Identity or link spoof can occur in other scenarios mentioned in I-D >>>> >> (i.e. spoofed the address while attacker is out of that neighbor >>>> >> radio >>>> >> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >>>> >> identity-spoof attack only after the neighbor is physically >>>> >> attacked, >>>> >> then M takes over that neighbor identity and responsibilities, even >>>> >> if >>>> >> they were in same radio coverage. This is a threat because these >>>> >> neighbors are in range of each other, and the node disapers from the >>>> >> network. The I-D does not consider the situation where the neighbor >>>> >> disapears from the network but replaced by an attacker M. This >>>> >> example >>>> >> scenario assumes that neighbors are in range but not aware of the >>>> >> physical attack, and the malicious node is aware. >>>> >> >>>> >> AB> Please editors of the I-D, consider in section 4.4.1 to add the >>>> >> threat described, if not clear for you, please reply, >>>> > >>>> > What do you mean by physical attacks? Tampering with the hardware of >>>> > the router running NHDP? I think that this is not the scope of the >>>> > draft (and also irrelevant); the draft purely looks at security >>>> > threats of misconfigured or malicious NHDP routers that misbehave >>>> > when >>>> > using NHDP. It could be that such a router has been hacked via an >>>> > implementation flaw or physically exchanged some parts of the >>>> > hardware; that does not matter. For the case you describe, how does >>>> > it >>>> > matter if the router disappears and comes back later? (whether or not >>>> > it is physically exchanged, or just stopped sending HELLOs for a >>>> > while). >>>> > >>>> > Regards >>>> > Ulrich >>>> > >>>> > >>>> > >>>> > >>>> >> [...] >>>> >> >>>> >> References: >>>> >> [1] The message below, by Dearlove, C., (2013), IETF MANET WG >>>> >> Discussion list, Re: [manet] AB#1 Comments for WGLC >>>> >> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >>>> >> >>>> >> >>>> >> On 4/9/13, Dearlove, Christopher (UK) >>>> >> >>>> >> wrote: >>>> >>> I'm neither recommending that a reference is included or excluded, >>>> >>> I'm >>>> >>> just >>>> >>> providing here where one good source of definitions. Whether to >>>> >>> reference >>>> >>> it >>>> >>> is a judgement call as to what is considered widely known, and what >>>> >>> isn't. >>>> >>> >>>> >>> But that definition is not limited to physical attack. >>>> >>> >>>> >>> -- >>>> >>> Christopher Dearlove >>>> >>> Senior Principal Engineer, Communications Group >>>> >>> Communications, Networks and Image Analysis Capability >>>> >>> BAE Systems Advanced Technology Centre >>>> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>> >>>> >>> BAE Systems (Operations) Limited >>>> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> >>> Centre, >>>> >>> Farnborough, Hants, GU14 6YU, UK >>>> >>> Registered in England & Wales No: 1996687 >>>> >>> >>>> >>> >>>> >>> -----Original Message----- >>>> >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>> >>> Sent: 09 April 2013 12:44 >>>> >>> To: Dearlove, Christopher (UK) >>>> >>> Cc: manet >>>> >>> Subject: Re: [manet] AB#1 Comments for WGLC >>>> >>> draft-ietf-manet-nhdp-sec-threats-02 >>>> >>> >>>> >>> ----------------------! WARNING ! ---------------------- >>>> >>> This message originates from outside our organisation, >>>> >>> either from an external partner or from the internet. >>>> >>> Keep this in mind if you answer this message. >>>> >>> Follow the 'Report Suspicious Emails' link on IT matters >>>> >>> for instructions on reporting suspicious email messages. >>>> >>> -------------------------------------------------------- >>>> >>> >>>> >>> Hi Chris, >>>> >>> >>>> >>> The I-D seems not to define physical attacks (my understanding), >>>> >>> which >>>> >>> I was not sure of but [1] (mentioned in first AB#1 message) did >>>> >>> include, but I think your input is prefered to include in the I-D >>>> >>> or >>>> >>> used, >>>> >>> >>>> >>> AB >>>> >>> >>>> >>> On 4/9/13, Dearlove, Christopher (UK) >>>> >>> >>>> >>> wrote: >>>> >>>> AB> you don't define *Threat*, and *Attack* >>>> >>>> >>>> >>>> Personally, I would start with ISO 27000 which has: >>>> >>>> >>>> >>>> ===== >>>> >>>> 2.45 >>>> >>>> threat >>>> >>>> potential cause of an unwanted incident, which may result in harm >>>> >>>> to >>>> >>>> a >>>> >>>> system or organization >>>> >>>> >>>> >>>> 2.4 >>>> >>>> attack >>>> >>>> attempt to destroy, expose, alter, disable, steal or gain >>>> >>>> unauthorized >>>> >>>> access to or make unauthorized use of >>>> >>>> an asset (2.3) >>>> >>>> >>>> >>>> 2.3 >>>> >>>> asset >>>> >>>> anything that has value to the organization >>>> >>>> NOTE There are many types of assets, including: >>>> >>>> a) information (2.18); >>>> >>>> b) software, such as a computer program; >>>> >>>> c) physical, such as computer; >>>> >>>> d) services; >>>> >>>> e) people, and their qualifications, skills, and experience; and >>>> >>>> f) intangibles, such as reputation and image. >>>> >>>> >>>> >>>> 2.18 >>>> >>>> information asset >>>> >>>> knowledge or data that has value to the organization >>>> >>>> ===== >>>> >>>> >>>> >>>> (The rules are that you may substitute in the definition, so >>>> >>>> attack >>>> >>>> may >>>> >>>> be >>>> >>>> parsed as "attempt to destroy, expose, alter, disable, steal or >>>> >>>> gain >>>> >>>> unauthorized access to or make unauthorized use of anything that >>>> >>>> has >>>> >>>> value >>>> >>>> to the organization".) >>>> >>>> >>>> >>>> [There is also an overlapping set of definitions in ISO 27032, but >>>> >>>> 27000 >>>> >>>> is >>>> >>>> more relevant here.] >>>> >>>> >>>> >>>> I don't know if there are any RFCs that reference ISO 27000. >>>> >>>> >>>> >>>> -- >>>> >>>> Christopher Dearlove >>>> >>>> Senior Principal Engineer, Communications Group >>>> >>>> Communications, Networks and Image Analysis Capability >>>> >>>> BAE Systems Advanced Technology Centre >>>> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> >>>> >>>> BAE Systems (Operations) Limited >>>> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> >>>> Centre, >>>> >>>> Farnborough, Hants, GU14 6YU, UK >>>> >>>> Registered in England & Wales No: 1996687 >>>> >>>> >>>> >>>> >>>> >>>> >>>> ************************************************************** >>>> ****** >>>> >>>> This email and any attachments are confidential to the intended >>>> >>>> recipient and may also be privileged. If you are not the intended >>>> >>>> recipient please delete it from your system and notify the sender. >>>> >>>> You should not copy it or use it for any purpose nor disclose or >>>> >>>> distribute its contents to any other person. >>>> >>>> >>>> ************************************************************** >>>> ****** >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> > >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> > From abdussalambaryun@gmail.com Tue Apr 9 18:28:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E580B21F9885 for ; Tue, 9 Apr 2013 18:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVGklKYDgegD for ; Tue, 9 Apr 2013 18:28:12 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D203F21F9773 for ; Tue, 9 Apr 2013 18:28:12 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id y19so3281006dan.19 for ; Tue, 09 Apr 2013 18:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=+OPo/MjiESQQhuv++SkqYmusf5jJOSKh9C8OV1SDr/s=; b=oGypnV2Jl3xQwgym4Pa19enYxylAUjasaoexg4RN8fSJoxE9TCDeSaHoIcHzpOuTD4 aR5V+Taic3oi2ft4bc8mwLBWGVHQO86E2qZnrpqeJpexr0ezkfarvJWpodRFyY85qzxV RDvm5pyaWN2Xlo9qIPC0qXiRztl7Wak/QMGIpQebERpca6G5NBPhcDkvPQ2VG9jCF4hj x3qZ7m2Mmw5iZo0z0MAsDo8SOKUMzUcGR7Pt45CFU16BCkRUkgHi/16a5XTJvaEgVhq2 vhm+l3HffPpBQeUf/Y/l8i9gZXclLzWznnWNoB7PIxEAo2HBRjsWLhOP/gjUlKTtGGC1 WTtg== MIME-Version: 1.0 X-Received: by 10.68.43.35 with SMTP id t3mr5401492pbl.202.1365557292496; Tue, 09 Apr 2013 18:28:12 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Tue, 9 Apr 2013 18:28:12 -0700 (PDT) In-Reply-To: <4E25BD56-9309-4D7B-A12B-778F60ACB173@jiaziyi.com> References: <4E25BD56-9309-4D7B-A12B-778F60ACB173@jiaziyi.com> Date: Wed, 10 Apr 2013 03:28:12 +0200 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:28:14 -0000 Please note that you need to consider all issues in RFC6130, Interface information bases and Neighbor Information bases should be discuss further in your I-D. Regarding L2, I repeat that you need to discuss what is in RFC6130, if mentioned any interaction then consider, However, I will respond to this below message after two weeks from now, AB On 4/9/13, Jiazi Yi wrote: > Hi, > > (AB, sorry if you received multiple copies of this reply. My previous > message was rejected by the mailing list because of some technical reason= s). > > > On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun > wrote: > >> This message Author: Abdussalam Baryun >> Classified: I-D Review >> >> Second Message Reply to your WGLC request dated 25/03/2013 >> The I-D Reviewed By: Abdussalam Baryun (AB) Dated: 08/04/2013 >> Reviewer Comment AB#2: Questions and Comments >> ++++++++++++++++++++++++++++++++++++ >> >> Copyright Notice: >> Copyright (c) 2012 IETF Trust and the person identified as the >> message author. All rights reserved. >> This message is to comment on the MANET WG work in progress I-D: >> draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message >> may contain parts/texts of the I-D under review >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> [Overall] >> >> AB> The I-D structure approach is a little not clear, because it >> states threats, but mostly describes the attacker possibility not the >> way attacker uses the NHDP to make threat. I suggest focus on: 1) NHDP >> messages, 2)IIB and NIB, then 3)Impact routing using NHDP (as you >> mentioned in section-5). Both point 1 and 2 are not clear in I-D (they >> were mentioned in RFC6130 security consideration section). I don=92t >> find in I-D about; threats against NHDP confidentiality, integrity, >> Info-Freshness, and availability (may be in other words or meanings, >> but these words are mostly used). > > I don't know what's IIB and NIB. But this draft mainly focus on the > threats/attacks to NHDP, not impacts to the routing protocol using NHDP - > because we can't assume how NDHP used, but just illustrate some examples > like MPR selection, etc. This issue has been fully discussed in previous > sessions, and I believe the WG consensus is clear. > >> >> AB> Using the words *Exploits Allowed by protocol* by Sanzgiri et al. >> (2002)[2] is better to clarify threats. In your approach you describe >> attacks as the threats. They are not the same thing. Please read to >> compare this I-D approach with [2]. I recommend editing *Exploits >> Allowed by NHDP* into the work to clarify threats, making it easier to >> read. > > I think Chris' post > http://www.ietf.org/mail-archive/web/manet/current/msg15259.html > gives a very good definition of threat/attack. They are not the same, but > highly related. I don't see there is misuse of those two words in the dra= ft. > > >> >> [I-D][section 4.3] Eavesdropping does not pose a direct threat to the >> network nor to NHDP, >> >> AB> From above text, what is an *indirect threat* mentioned? How can >> we know if direct or indirect while information was accessed (lost >> privacy), means a threat, don=92t you think? Elsewhere you mention >> passive threat/attack where is that definition? > > "Passive attack" is well-known term in network security, and is used in > numerous articles. > Personally, I don't see there is need to define every word like "direct", > "passive", "common", "range" in the ID. They have no different means than= in > the dictionary. > > >> >> AB> section 4.8 mentions my comments on the list before regarding >> attacks on sequence number, just you named it attack on link quality. >> It is ok. >> ------------------------ > > No, it's different from your comments. > >> >> [Layer Protocol affects] >> >> AB> Does attacks on IP layer increase threats to NHDP? Not understood fr= om >> I-D. >> AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP? >> Does/Can NHDP possible depend on the lower layers, if yes, what are >> the threats? Please note that these issues mentioned in RFC6130 but >> not in this I-D. >> ---------------------- > > We don't even know what L2 L2.5 will be used with NHDP, so it's impossibl= e > to have further discussions on it. > >> >> [The use of NHDP] >> >> AB> If there is an attack on NHDP does that mostly mean that its users >> are attacked as well? > > The consequence of the attacks has been introduced in the ID. > >> AB> In AODVv2 mentions that NHDP used to monitor and assure >> bi-directional links, does that use have threats, why not mentioned, >> please do. > > No. AODVv2 has no normative reference to NHDP. > >> AB> Does the NHDP detect the attack neighbor? IMO, it can, please mentio= n >> this. > > It's not relevant to this draft. > >> AB> Is the NHDP using an unreliable communication? If yes then should >> explain the threats of that. In high density of neighbors/malicious >> what is the threat? > > NHDP is for ad hoc networks, i.e., it would be through unreliable medium. > The whole ID is based on this assumption. I didn't see there is need to > mention it -- because it has been included. > >> AB> Does the threat increase if packets have more neighbor messages >> packed in one packet? > > I can't see it. > >> >> [I-D] [section 3] An Attacker has several ways of harming this >> neighbor discovery process: It can announce "wrong" information about >> its identity, >> postulate non-existent links, and replay HELLO messages. >> >> AB> wrong identity!, what about interface address, network address? > > They are identities. > >> ----------------------------- >> >> [NHDP-Messaging] >> AB> This I-D does not distinguish between IP packets and RFC5444 >> Packets, as to describe the influence of the attacks on both packets. > > This I-D is about RFC 5444 message. > >> >> AB> Regarding Invalid Hello Messages of: interface addresses or its >> IP addresses, and network addresses relate to threats, what are their >> influences to NHDP threats? > > I'm not sure you understand interface/IP/network addresses. > >> AB> Please consider the Scenarios of RFC6130 Appendix F [Topology >> Picture] (from 1 to 11, if related). You need to explain how the >> threats in different topologies, as mentioned topology positions in >> introduction of this I-D. If no NHDP threats due to those different >> topologies then please mention no threats. IMHO, is important to >> mention, they are same number of neighbors, but different topologies >> with different NHDP threat levels. > > The appendix F of rfc6130 is just a set of examples, not a normative part= of > NHDP. > It's impossible/unnecessary to illustrate all different topologies. > >> [RFC6130] This is acquired through HELLO message exchange between >> neighboring routers. This information is made available through the >> Interface Information Bases and Neighbor Information Base, describing >> the router=92s 1-hop neighborhood and symmetric 2-hop neighborhood. >> >> AB> As per above text of 6130, please explain threats of invalid IIB >> and NIB in the I-D. >> >> AB> In the I-D security consideration, you mention that you in this >> I-D make security consideration for NHDP, but in RFC6130 one of its >> security consideration mentions invalid messages. I expected to see >> Invalid Hello Messages as mentioned in RFC6130 security section 17.1, >> why not consider as an NHDP threat? > > In fact, it has been documented in the ID, like link spoofing/identity > spoofing. > >> >> AB> If a node receives the NHDP messages that are not as specified in >> procedure of RFC6130 section 10 and 10.1, then is that a threat? IMO, >> yes it is, please mention it. >> ------------------------------- > > NHDP will verify the message in section 12.1 Invalid Message > >> >> [NHDP Security Considerations] >> >> [RFC6622][section 4] security in MANETs, "one size rarely fits all" >> and that MANET routing protocol deployment domains have varying >> security requirements ranging from "unbreakable" to "virtually none". >> >> AB> Different deployment domains, which make the security requirement >> different. So could we say threats are different also in different >> deployment domains. Please mention in this I-D. > > The assumption of the document is in section 1 Introduction. That's one o= f > reasons why we call it "common" threats. > >> AB> wrong behavior can come from a malicious node, but it can also >> come from a neighbor that is malfunctioning. Do you consider both as >> same threats? This should be clear in I-D. > > It is already in the I-D: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The document analyses possible attacks and mis-configurations on NHDP > and... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > since -01 revision > http://www.ietf.org/mail-archive/web/manet/current/msg13831.html > > > best > > Jiazi > >> This Message Reference: >> ------------------------------------ >> [2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc >> Network, IEEE ICNP, 2002. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> This is last message comment, I really hope this is useful, thanking you= . >> >> Best Regards, >> >> Abdussalam Baryun >> >> ------------------------------------------------------------------------= --------------- >> This message is not sent to private email boxes, but sent to IETF >> MANET mail box. >> This message and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> This message is in compliance with the IETF regulations. >> ------------------------------------------------------------------------= --------------- >> >>> On 3/25/13, Stan Ratliff (sratliff) wrote: >>>> WG, >>>> >>>> I've re-started the WGLC on this document. There's a 2-week WGLC >>>> period, >>>> ending on April 8, 2013. >>>> >>>> Regards, >>>> Stan >>>> _______________________________________________ >>>> 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 > > > > Jiazi > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From sratliff@cisco.com Tue Apr 9 20:00:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86BA21F935D for ; Tue, 9 Apr 2013 20:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+6jw--WDAJj for ; Tue, 9 Apr 2013 20:00:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 809C121F9357 for ; Tue, 9 Apr 2013 20:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12192; q=dns/txt; s=iport; t=1365562824; x=1366772424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Po1QOBIoumQNKmMkcRUWGgnS/chhDZa49t/OB5crwhQ=; b=FcQf1D5Qcg74DkJZvN9lwlwLewldUEvTyrvKJgEUo2ixbXepOXgojXPT qCO95APQ3DkLRujut/JAQ1+Ub/8biy0jajiuAx08km26WiKoNJNJqtZ1r Tqxb1eTJltB8k1uvFJWa4eH50fm9FN5mtqdpBRldFxTFA5oXbr7G8daJC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGPUZFGtJV2Y/2dsb2JhbABICYMGNsEngRkWdIIfAQEBAwEBAQFSFwIDAQQDBQcEAgEIEQQBAQEKHQchBgsUCQgBAQQOAwIIh3oDCQYMsG6EGw2JXYxBgREHAw53AgYgBgUHAgSCWmEDlReNVYUcgVWBKQ1AgSoJFx4 X-IronPort-AV: E=Sophos;i="4.87,443,1363132800"; d="scan'208";a="196929537" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 10 Apr 2013 03:00:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3A30NS1030119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 03:00:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 22:00:23 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] Thread-Index: Ac41YHmsQtOwcXf3R/m2xjp82EuUYAAK4iWAAAF1uYAAAKZMgAALQBmA Date: Wed, 10 Apr 2013 03:00:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1009ACEA@xmb-aln-x03.cisco.com> References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.212] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5CFE2590440D1046B855B86FE7308F28@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 03:00:26 -0000 =85then PLEASE do=85 ;-)=20 Regards, Stan On Apr 9, 2013, at 5:38 PM, Ulrich Herberg wrote: > On Tue, Apr 9, 2013 at 2:19 PM, Adrian Farrel wrote= : > [...] >>=20 >> Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informativ= e >> reference to 4949. >=20 > That is POSSIBLE. We MIGHT add the reference ;-) >=20 > Seriously, it would not hurt adding this informative reference, so > it's fine for me to add it. >=20 > Ulrich >=20 >=20 >=20 >>=20 >> Adrian >>=20 >>> -----Original Message----- >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> Sent: 09 April 2013 21:38 >>> To: adrian@olddog.co.uk >>> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet >>> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draft-ietf-ma= net- >>> nhdp-sec-threats-02] >>>=20 >>> Hi Adrian, >>>=20 >>> I asked the editors to define *attack* but they don't want to, so if >>> it was out of the scope, So I need editors to make it clearly defined >>> in the document, IMHO, excluding that attack or including SHOULD be >>> informed in this informational I-D >>>=20 >>> AB >>>=20 >>> On 4/9/13, Adrian Farrel wrote: >>>> Hi, >>>>=20 >>>> I think that some of these comments relate to subversion of nodes. Thi= s >>>> topic >>>> often comes up in discussion of routing protocol security (although >>>> strangely >>>> not in the discussion of application level security - maybe they have = more >>>> security clue than we do!) >>>>=20 >>>> There are two types of subversion: >>>> 1. Installing new software on existing hardware >>>> 2. Replacing in-the-field hardware >>>>=20 >>>> The second of these is usually protectable by security associations si= nce >>>> physically replacing one node will not replicate the security credenti= als >>>> and so >>>> the node will not be able to participate in the security relationships >>>> necessary >>>> for the protocol. >>>>=20 >>>> The first is usually regarded as faintly amusing! The idea that your m= ain >>>> problem with a subverted node is harm to the routing infrastructure is >>>> wrong. If >>>> a node that routes packets has been subverted then *anything* may happ= en in >>>> your >>>> network. Protection against software subversion varies from nodes that >>>> physically self-destruct if tampered with, to nodes that require secur= ity >>>> checks >>>> before software can be modified. >>>>=20 >>>> But, in both cases, there is nothing that the routing protocol can do.= If a >>>> routing peer has the security credentials but decides to act badly, so= be >>>> it! >>>> (There were a number of attempts to characterise the on-wire behavior = of >>>> bad-actors, but - perhaps, of course - such attempts are self-defeatin= g). >>>>=20 >>>>=20 >>>> Another view of a physical attack is one that degrades the performance= of a >>>> node >>>> or link, perhaps through radio interference. I would argue that the on= ly >>>> thing >>>> that a routing protocol can do in this case is to observe the degraded >>>> performance and to adjust metrics accordingly. However, I would also s= ay >>>> that >>>> this is not actually the responsibility of the routing protocol, but o= f the >>>> management system in the network. >>>>=20 >>>> Thus, I would say that physical attacks on notes are out of scope. >>>>=20 >>>> Adrian >>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f >>> Of >>>>> Ulrich Herberg >>>>> Sent: 09 April 2013 20:23 >>>>> To: Abdussalam Baryun >>>>> Cc: draft-ietf-manet-nhdp-sec-threats; manet >>>>> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec= - >>>>> threats-02 >>>>>=20 >>>>> AB, >>>>>=20 >>>>> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun >>>>> wrote: >>>>>> [...] >>>>>>=20 >>>>>> As a respond to my first to AB#1, AB#2 messages, and to [1] message. >>>>>> The NHDP threat related to physical attacks were ignored by the I-D. >>>>>> The I-D describes non-physical attacks in section 4 but does not for >>>>>> physical attacks, which has threats. The neighbors may get both >>>>>> together non-physical and physical, as if two or more neighbors are = in >>>>>> radio range coverage. I don't think this was introduced in the I-D, >>>>>> which I hope editors follow. >>>>>>=20 >>>>>> Military Scenario Example: >>>>>>=20 >>>>>> Identity or link spoof can occur in other scenarios mentioned in I-D >>>>>> (i.e. spoofed the address while attacker is out of that neighbor rad= io >>>>>> coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not >>>>>> identity-spoof attack only after the neighbor is physically attacked= , >>>>>> then M takes over that neighbor identity and responsibilities, even = if >>>>>> they were in same radio coverage. This is a threat because these >>>>>> neighbors are in range of each other, and the node disapers from the >>>>>> network. The I-D does not consider the situation where the neighbor >>>>>> disapears from the network but replaced by an attacker M. This examp= le >>>>>> scenario assumes that neighbors are in range but not aware of the >>>>>> physical attack, and the malicious node is aware. >>>>>>=20 >>>>>> AB> Please editors of the I-D, consider in section 4.4.1 to add the >>>>>> threat described, if not clear for you, please reply, >>>>>=20 >>>>> What do you mean by physical attacks? Tampering with the hardware of >>>>> the router running NHDP? I think that this is not the scope of the >>>>> draft (and also irrelevant); the draft purely looks at security >>>>> threats of misconfigured or malicious NHDP routers that misbehave whe= n >>>>> using NHDP. It could be that such a router has been hacked via an >>>>> implementation flaw or physically exchanged some parts of the >>>>> hardware; that does not matter. For the case you describe, how does i= t >>>>> matter if the router disappears and comes back later? (whether or not >>>>> it is physically exchanged, or just stopped sending HELLOs for a >>>>> while). >>>>>=20 >>>>> Regards >>>>> Ulrich >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> [...] >>>>>>=20 >>>>>> References: >>>>>> [1] The message below, by Dearlove, C., (2013), IETF MANET WG >>>>>> Discussion list, Re: [manet] AB#1 Comments for WGLC >>>>>> draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. >>>>>>=20 >>>>>>=20 >>>>>> On 4/9/13, Dearlove, Christopher (UK) >>>>> wrote: >>>>>>> I'm neither recommending that a reference is included or excluded, = I'm >>>>>>> just >>>>>>> providing here where one good source of definitions. Whether to >>>>>>> reference >>>> it >>>>>>> is a judgement call as to what is considered widely known, and what >>>>>>> isn't. >>>>>>>=20 >>>>>>> But that definition is not limited to physical attack. >>>>>>>=20 >>>>>>> -- >>>>>>> Christopher Dearlove >>>>>>> Senior Principal Engineer, Communications Group >>>>>>> Communications, Networks and Image Analysis Capability >>>>>>> BAE Systems Advanced Technology Centre >>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>=20 >>>>>>> BAE Systems (Operations) Limited >>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, >>>>>>> Farnborough, Hants, GU14 6YU, UK >>>>>>> Registered in England & Wales No: 1996687 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>>>>> Sent: 09 April 2013 12:44 >>>>>>> To: Dearlove, Christopher (UK) >>>>>>> Cc: manet >>>>>>> Subject: Re: [manet] AB#1 Comments for WGLC >>>>>>> draft-ietf-manet-nhdp-sec-threats-02 >>>>>>>=20 >>>>>>> ----------------------! WARNING ! ---------------------- >>>>>>> This message originates from outside our organisation, >>>>>>> either from an external partner or from the internet. >>>>>>> Keep this in mind if you answer this message. >>>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>>> for instructions on reporting suspicious email messages. >>>>>>> -------------------------------------------------------- >>>>>>>=20 >>>>>>> Hi Chris, >>>>>>>=20 >>>>>>> The I-D seems not to define physical attacks (my understanding), wh= ich >>>>>>> I was not sure of but [1] (mentioned in first AB#1 message) did >>>>>>> include, but I think your input is prefered to include in the I-D o= r >>>>>>> used, >>>>>>>=20 >>>>>>> AB >>>>>>>=20 >>>>>>> On 4/9/13, Dearlove, Christopher (UK) >>>>>>> wrote: >>>>>>>> AB> you don't define *Threat*, and *Attack* >>>>>>>>=20 >>>>>>>> Personally, I would start with ISO 27000 which has: >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D >>>>>>>> 2.45 >>>>>>>> threat >>>>>>>> potential cause of an unwanted incident, which may result in harm = to >>>>>>>> a >>>>>>>> system or organization >>>>>>>>=20 >>>>>>>> 2.4 >>>>>>>> attack >>>>>>>> attempt to destroy, expose, alter, disable, steal or gain >>>>>>>> unauthorized >>>>>>>> access to or make unauthorized use of >>>>>>>> an asset (2.3) >>>>>>>>=20 >>>>>>>> 2.3 >>>>>>>> asset >>>>>>>> anything that has value to the organization >>>>>>>> NOTE There are many types of assets, including: >>>>>>>> a) information (2.18); >>>>>>>> b) software, such as a computer program; >>>>>>>> c) physical, such as computer; >>>>>>>> d) services; >>>>>>>> e) people, and their qualifications, skills, and experience; and >>>>>>>> f) intangibles, such as reputation and image. >>>>>>>>=20 >>>>>>>> 2.18 >>>>>>>> information asset >>>>>>>> knowledge or data that has value to the organization >>>>>>>> =3D=3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> (The rules are that you may substitute in the definition, so attac= k >>>>>>>> may >>>>>>>> be >>>>>>>> parsed as "attempt to destroy, expose, alter, disable, steal or ga= in >>>>>>>> unauthorized access to or make unauthorized use of anything that h= as >>>>>>>> value >>>>>>>> to the organization".) >>>>>>>>=20 >>>>>>>> [There is also an overlapping set of definitions in ISO 27032, but >>>>>>>> 27000 >>>>>>>> is >>>>>>>> more relevant here.] >>>>>>>>=20 >>>>>>>> I don't know if there are any RFCs that reference ISO 27000. >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Christopher Dearlove >>>>>>>> Senior Principal Engineer, Communications Group >>>>>>>> Communications, Networks and Image Analysis Capability >>>>>>>> BAE Systems Advanced Technology Centre >>>>>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>>>>=20 >>>>>>>> BAE Systems (Operations) Limited >>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>>>>> Centre, >>>>>>>> Farnborough, Hants, GU14 6YU, UK >>>>>>>> Registered in England & Wales No: 1996687 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>=20 >>> ************************************************************** >>>>> ****** >>>>>>>> This email and any attachments are confidential to the intended >>>>>>>> recipient and may also be privileged. If you are not the intended >>>>>>>> recipient please delete it from your system and notify the sender. >>>>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>>>> distribute its contents to any other person. >>>>>>>>=20 >>>>>=20 >>> ************************************************************** >>>>> ****** >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Apr 9 20:02:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE721F8BAE for ; Tue, 9 Apr 2013 20:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRa7qsl54Qko for ; Tue, 9 Apr 2013 20:02:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91221F8B9C for ; Tue, 9 Apr 2013 20:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4349; q=dns/txt; s=iport; t=1365562973; x=1366772573; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fl26+HbUU0Le4lUZzS3EOlCdlSctHsTVtOwZDfVLEpk=; b=gmQFnZLTKSQMSlCNYQxQFkivgGamWwkrLzdBEhgXakaTwGvSOxriteOr pW5UOFlrqW7KK4GkeR+JxxMi5y5qs2YkP4pNrgdJ80Ra0yNgONds/oceG R372CcXvGRrpjv8EW8w5eXAfOyluZRSuMMErTW+IU8nePAWu6rtHR6Or5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFACbVZFGtJV2b/2dsb2JhbABRgwY2rw6SGYEZFnSCHwEBAQMBAQEBaQIFAwMFCwIBCA4KCiQnCxMSAgQOBQiHegMJBgywbo1+BIxBgiACMQeCYGEDlRuNUYUcgn4Ngig X-IronPort-AV: E=Sophos;i="4.87,443,1363132800"; d="scan'208";a="196941354" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Apr 2013 03:02:52 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3A32qgj004945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 03:02:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 22:02:52 -0500 From: "Stan Ratliff (sratliff)" To: Jiazi Yi Thread-Topic: [manet] LOADng Data Collection Cycle Thread-Index: AQHONTzna9U3ZRODC02K20Z5KC7BBJjObDCAgABT8ACAAFj9AA== Date: Wed, 10 Apr 2013 03:02:51 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1009AD3B@xmb-aln-x03.cisco.com> References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <19F37C9A-89F7-402C-8C8E-91BE2ECFBB34@jiaziyi.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>, <3427472E-8BE2-4845-96C9-7C3E240AA60E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.212] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 03:02:54 -0000 (Putting my co-chair hat firmly on)=85=20 I think that this discussion has been productive, and should continue. As s= omeone mentioned on the list, the discussion may well lead to improvements = in the AODVv2 specification.=20 So, my recommendation would be to "Keep Calm, and Carry On". Regards, Stan On Apr 9, 2013, at 5:44 PM, Jiazi Yi wrote: > Hi,=20 >=20 > I think it's simply because: >=20 > o LOADng is in active development cycle. There are a lot of engineers wo= rking on it. We have new results/implementation experience everyday.=20 >=20 > o There are a lot of people interested in LOADng.=20 >=20 > o it's about running code/implementation=20 > -- hopefully it's still what IETF (or MANET WG) believes in.=20 >=20 > All the previous discussions are purely technical. I really don't want to= start the political part. But if that happens, I would have tons of words = to say.=20 >=20 > sincerely >=20 > Jiazi >=20 > On Apr 9, 2013, at 6:43 PM, JP Vasseur (jvasseur) wr= ote: >=20 >> Why are we still discussing loadng on this mailing list as opposed to th= e WG Manet reactive routing protocol ? >>=20 >> JP Vasseur >> Cisco Fellow >>=20 >> Sent from my iPhone >>=20 >> On 9 avr. 2013, at 09:11, "Jiazi Yi" wrote: >>=20 >>> Hi,=20 >>>=20 >>> On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY w= rote: >>>=20 >>>> Hi,=20 >>>>=20 >>>> On Apr 4, 2013, at 2:01 PM, AHMED AWAMRY w= rote: >>>>=20 >>>>> Hi Jiazi, >>>>>=20 >>>>> Thank you for illustrating the difference between the IETF draft and = the scientific publications. Also, regarding the publications sent. I have = some questions about the results listed at the sent publications. >>>>>=20 >>>>> 1. What is the propagation delay set on evaluating the End-To-End del= ay? as i know that the propagation delay affects largely the end-to-end del= ay result. This is because , when you changed the propagation delay of the = channel (wireless or wired) you will gain different results. >>>>=20 >>>> The propagation delay depends on the lower-layer protocol used. In our= simulations for LOADng evaluation, it's 802.11b.=20 >>>>=20 >>>> So, you use nodes of 250m range, Mesh topology connected.We could cons= ider LOADng as Layer 3 protocol, is this right? >>>=20 >>> LOADng can be used in both layer 2 and layer 3. In IETF, we care more a= bout its application in layer 3. =20 >>> In our tests/simulations, it's in layer 3.=20 >>>=20 >>>>>=20 >>>>> 2. Regarding the overhead, I think that there are two points of view= related to the overhead: >>>>> A. Network Overhead (like the one mentioned at the pap= ers) >>>>> B. Processing Overhead (like memory usage and required= processing) >>>>> Did you estimate the factor *2.B*? if yes, what is its value? >>>>=20 >>>> The "processing overhead" for an on-demand protocol like LOADng is tri= vial, with O(n) complexity.=20 >>>>=20 >>>> I mean by processing overhead,the overhead introduced by the protocol = to be implemented, (How many events executed to perform the protocol?) Also= , the memory usage used to implement or simulate the protocol (I think the = LOADng interoperability-report mentioned 6000-lines Java code, is it for im= plementation or test?). This will be very efficient to select the suitable = IC (MCU or DSP) to implement the protocol. >>>=20 >>> In fact, the 6000-line java code is with functions like network simulat= ion, test, different extensions. For a "pure" LOADng implementation, it can= be greatly reduced.=20 >>> For example, the implementations of Hitachi is with 1589 C code, or 198= 7 C++ code.=20 >>>=20 >>> For the moment, all the implementations that I'm aware of, are in softw= are. Because the protocol is fairly simple, I think it would be enough to h= ave software implementation, which also has the advantage of flexibility.=20 >>>=20 >>> best >>>=20 >>> Jiazi >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue Apr 9 21:17:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859121F8FEB for ; Tue, 9 Apr 2013 21:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEU-cS82DmLF for ; Tue, 9 Apr 2013 21:17:58 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2C69521F8FC7 for ; Tue, 9 Apr 2013 21:17:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ht10so40322vcb.13 for ; Tue, 09 Apr 2013 21:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VV2V3lgT1jFtwOsUsIMQtmiweTmbI9iIukJtblH6bR8=; b=TnZI2VvJfIcuvw0sCvVEFBND3noLmD4X3d0YxvewmmaoMi8h0ICud3q8jhr+lL4eEt kUBxRiFun8K2XXMi80sIbuNRWy/c/pFu+W8dPqqIZYv66VwU4xlDFMTXnAyRCBWCcbbj 31Om3SHi37VNGxLgPtHluC3gMykBrSYyfuZ04= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=VV2V3lgT1jFtwOsUsIMQtmiweTmbI9iIukJtblH6bR8=; b=Kf60r9V0FUbNjp36cXbMTdvL7SQAGiSA1iMiwB2++StJPeWRjSPk5CQ9BMimPfKAdy BB45yK0oHkeExU9oLICymlqd+WmMkVpBca7EJEVRL7yY4y8yQiZN1kg31pG1ze4JcD0A D40jO8gYKA3wTyaJiH9wNaxVpxzaKnPylfanLJfm5HbSh+SUzZqR4x+HByoBvGIrW3EQ mQkSeuyyc4lmdZgu6vDF0w6MP/wx72di3Vh95y2vozzWiHOwrvxaVGRVxcJVpEXfZI3u MKAhdNY4B60hGKozWpKx+CgFn79MP+O2x/HNy7pKYDZqzNMQUZdla6hA7enDIBpNYjhM 9s8w== MIME-Version: 1.0 X-Received: by 10.220.209.15 with SMTP id ge15mr304352vcb.15.1365567476662; Tue, 09 Apr 2013 21:17:56 -0700 (PDT) Received: by 10.220.88.13 with HTTP; Tue, 9 Apr 2013 21:17:56 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1009ACEA@xmb-aln-x03.cisco.com> References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> <2ED1D3801ACAAB459FDB4EAC9EAD090C1009ACEA@xmb-aln-x03.cisco.com> Date: Tue, 9 Apr 2013 21:17:56 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=bcaec54fb6445ddaaa04d9f9f43b X-Gm-Message-State: ALoCoQmCeSUCkkYmRoH/1a54CplA3abihnDWS7xa9/gpGmc7+L3as99134DIH8OVZsXO3ggH5RpC Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 04:17:59 -0000 --bcaec54fb6445ddaaa04d9f9f43b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can you define the word "PLEASE"? It's not known 6919 terminology. Or is there an errata that I have not seen? And I'd like to correct myself... I said "it would not hurt adding..."; of course I meant "it WOULD PROBABLY not hurt adding..." Ulrich On Tuesday, April 9, 2013, Stan Ratliff (sratliff) wrote: > =85then PLEASE do=85 ;-) > > Regards, > Stan > > On Apr 9, 2013, at 5:38 PM, Ulrich Herberg wrote: > > > On Tue, Apr 9, 2013 at 2:19 PM, Adrian Farrel > wrote: > > [...] > >> > >> Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an > informative > >> reference to 4949. > > > > That is POSSIBLE. We MIGHT add the reference ;-) > > > > Seriously, it would not hurt adding this informative reference, so > > it's fine for me to add it. > > > > Ulrich > > > > > > > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > >>> Sent: 09 April 2013 21:38 > >>> To: adrian@olddog.co.uk > >>> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet > >>> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC > draft-ietf-manet- > >>> nhdp-sec-threats-02] > >>> > >>> Hi Adrian, > >>> > >>> I asked the editors to define *attack* but they don't want to, so if > >>> it was out of the scope, So I need editors to make it clearly defined > >>> in the document, IMHO, excluding that attack or including SHOULD be > >>> informed in this informational I-D > >>> > >>> AB > >>> > >>> On 4/9/13, Adrian Farrel wrote: > >>>> Hi, > >>>> > >>>> I think that some of these comments relate to subversion of nodes. > This > >>>> topic > >>>> often comes up in discussion of routing protocol security (although > >>>> strangely > >>>> not in the discussion of application level security - maybe they hav= e > more > >>>> security clue than we do!) > >>>> > >>>> There are two types of subversion: > >>>> 1. Installing new software on existing hardware > >>>> 2. Replacing in-the-field hardware > >>>> > >>>> The second of these is usually protectable by security associations > since > >>>> physically replacing one node will not replicate the security > credentials > >>>> and so > >>>> the node will not be able to participate in the security relationshi= ps > >>>> necessary > >>>> for the protocol. > >>>> > >>>> The first is usually regarded as faintly amusing! The idea that your > main > >>>> problem with a subverted node is harm to the routing infrastructure = is > >>>> wrong. If > >>>> a node that routes packets has been subverted then *anything* may > happen in > >>>> your > >>>> network. Protection against software subversion varies from nodes th= at > >>>> physically self-destruct if tampered with, to nodes that require > security > >>>> checks > >>>> before software can be modified. > >>>> > >>>> But, in both cases, there is nothing that the routing protocol can > do. If a > >>>> routing peer has the security credentials but decides to act badly, > so be > >>>> it! > >>>> (There were a number of attempts to characterise the on-wire behavio= r > of > >>>> bad-actors, but - perhaps, of course - such attempts are > self-defeating). > >>>> > >>>> > >>>> Another view of a physical attack is one that degrades the > performance of a > >>>> node > >>>> or link, perhaps through radio interference. I would argue that the > only > >>>> thing > >>>> that a routing protocol can do in this case is to observe the degrad= ed > >>>> performance and to adjust metrics accordingly. However, I would also > say > >>>> that > >>>> this is not actually the responsibility of the routing protocol, but > of the > >>>> management system in the network. > >>>> > >>>> Thus, I would say that physical attacks on notes are out of scope. > >>>> > >>>> Adrian > >>>> > >>>>> -----Original Message----- > >>>>> From: manet-bounces@ietf.org --bcaec54fb6445ddaaa04d9f9f43b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can you define the word "PLEASE"? It's not known 6919 termino= logy. Or is there an errata that I have not seen?

And I&= #39;d like to correct myself... I said "it would not hurt adding...&qu= ot;; of course I meant "it WOULD PROBABLY not hurt adding..."

Ulrich=A0

On Tuesday, April 9, 2013= , Stan Ratliff (sratliff) wrote:
=85then= PLEASE do=85 ;-)

Regards,
Stan

On Apr 9, 2013, at 5:38 PM, Ulrich Herberg wrote:

> On Tue, Apr 9, 2013 at 2:19 PM, Adrian Farrel <adrian@olddog.co.= uk> wrote:
> [...]
>>
>> Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an info= rmative
>> reference to 4949.
>
> That is POSSIBLE. We MIGHT add the reference ;-)
>
> Seriously, it would not hurt adding this informative reference, so
> it's fine for me to add it.
>
> Ulrich
>
>
>
>>
>> Adrian
>>
>>> -----Original Message-----
>>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com<= /a>]
>>> Sent: 09 April 2013 21:38
>>> To: adrian@olddog.co.uk
>>> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet >>> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draf= t-ietf-manet-
>>> nhdp-sec-threats-02]
>>>
>>> Hi Adrian,
>>>
>>> I asked the editors to define *attack* but they don't want= to, so if
>>> it was out of the scope, So I need editors to make it clearly = defined
>>> in the document, IMHO, excluding that attack or including SHOU= LD be
>>> informed in this informational I-D
>>>
>>> AB
>>>
>>> On 4/9/13, Adrian Farrel <adrian@olddog.co.uk> wr= ote:
>>>> Hi,
>>>>
>>>> I think that some of these comments relate to subversion o= f nodes. This
>>>> topic
>>>> often comes up in discussion of routing protocol security = (although
>>>> strangely
>>>> not in the discussion of application level security - mayb= e they have more
>>>> security clue than we do!)
>>>>
>>>> There are two types of subversion:
>>>> 1. Installing new software on existing hardware
>>>> 2. Replacing in-the-field hardware
>>>>
>>>> The second of these is usually protectable by security ass= ociations since
>>>> physically replacing one node will not replicate the secur= ity credentials
>>>> and so
>>>> the node will not be able to participate in the security r= elationships
>>>> necessary
>>>> for the protocol.
>>>>
>>>> The first is usually regarded as faintly amusing! The idea= that your main
>>>> problem with a subverted node is harm to the routing infra= structure is
>>>> wrong. If
>>>> a node that routes packets has been subverted then *anythi= ng* may happen in
>>>> your
>>>> network. Protection against software subversion varies fro= m nodes that
>>>> physically self-destruct if tampered with, to nodes that r= equire security
>>>> checks
>>>> before software can be modified.
>>>>
>>>> But, in both cases, there is nothing that the routing prot= ocol can do. If a
>>>> routing peer has the security credentials but decides to a= ct badly, so be
>>>> it!
>>>> (There were a number of attempts to characterise the on-wi= re behavior of
>>>> bad-actors, but - perhaps, of course - such attempts are s= elf-defeating).
>>>>
>>>>
>>>> Another view of a physical attack is one that degrades the= performance of a
>>>> node
>>>> or link, perhaps through radio interference. I would argue= that the only
>>>> thing
>>>> that a routing protocol can do in this case is to observe = the degraded
>>>> performance and to adjust metrics accordingly. However, I = would also say
>>>> that
>>>> this is not actually the responsibility of the routing pro= tocol, but of the
>>>> management system in the network.
>>>>
>>>> Thus, I would say that physical attacks on notes are out o= f scope.
>>>>
>>>> Adrian
>>>>
>>>>> -----Original Message-----
>>>>> From: manet-bounces@ietf.org
--bcaec54fb6445ddaaa04d9f9f43b-- From l.wood@surrey.ac.uk Tue Apr 9 23:35:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D221F8E73 for ; Tue, 9 Apr 2013 23:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhzQTT+C4QAM for ; Tue, 9 Apr 2013 23:35:16 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66821F8E59 for ; Tue, 9 Apr 2013 23:35:15 -0700 (PDT) Received: from [193.109.255.147:16494] by server-6.bemta-14.messagelabs.com id A8/A6-31180-22805615; Wed, 10 Apr 2013 06:35:14 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-4.tower-72.messagelabs.com!1365575713!8046078!2 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29611 invoked from network); 10 Apr 2013 06:35:14 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-4.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 10 Apr 2013 06:35:14 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 10 Apr 2013 07:35:12 +0100 From: To: , , Date: Wed, 10 Apr 2013 07:35:12 +0100 Thread-Topic: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] Thread-Index: Ac41TK8ANyoFLbILT+uoqHkr+c1ZwwAaBUY5 Message-ID: <290E20B455C66743BE178C5C84F12408223F494E59@EXMB01CMS.surrey.ac.uk> References: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> In-Reply-To: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org Subject: Re: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 06:35:17 -0000 Hey, this is the same guy who called for a ban on April 1 RFCs on the main = IETF discussion list. Since additional copyrights are against the spirit of the Note Well and of = list discussion, I'd just ban posts originating them. While quoting them is of course fair use, added copyright or no. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Adrian F= arrel [adrian@olddog.co.uk] Sent: 09 April 2013 19:04 To: 'Stan Ratliff (sratliff)'; 'Abdussalam Baryun' Cc: 'manet' Subject: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nh= dp-olsrv2-sec-01]i Hi Stan, I wouldn't worry about this text. In my opinion it is at best purposeless a= nd confusing. The IETF Trust deems all emails to IETF mailing lists to be contributions t= o the IETF. This should be clear from the Note Well that all participants see whe= never they sign up to an IETF mailing list and whenever they bother to look more closely (for example, at RFC 5378). In my opinion, no amount of added verbiage to an email can change the copyr= ight that applies to it under the IETF Trust rules. Of course, everyone is entit= led to their own opinion and the opinions of their paid or bar-room lawyers. I tend to think that admonitions in email footers to not read an email that= was not intended for me are kind of amusing. I usually read emails from top dow= n, so I don't get to that bit until it is too late. But, in any case, if an email comes to me via a mailing list, how do I know whether I was supposed to rec= eive it or not? I know some people automatically throw away any email with that = kind of footnote just to be on the safe side, so including the note seems counter-productive to IETF work. Maybe, however, this is just another distraction on the MANET list? What is= the next technical topic? Cheers, Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Stan Ratliff (sratliff) > Sent: 09 April 2013 18:44 > To: Abdussalam Baryun > Cc: manet; > Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 > > AB, > > On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: > > [snip] > > > > ++++++++++++++++++++++++++++++++++++ > > > > Copyright Notice: > > Copyright (c) 2012 IETF Trust and the person identified as the > > message author. All rights reserved. > > This message is to comment on the MANET WG work in progress I-D: > > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > > may contain parts/texts of the I-D under review > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > [snip] > > > > This message is owned by the author, and was not sent to any private > > email box, just IETF emails. > > > ************************************************************** > ****** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > > ************************************************************** > ****** > > [snip] > > > I'm somewhat concerned by these 3 blocks of text in your emails. The IETF= have > quite a few rules & regs about intellectual property rights; some of the = above > text, if taken in the most stringent manner, could be seen to preclude us= e of any > of your ideas into the associated documents. Please explain the motivatio= n > behind the text I've highlighted above. > > Regards, > Stan > > > _______________________________________________ > 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 Chris.Dearlove@baesystems.com Wed Apr 10 02:24:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9A21F9123 for ; Wed, 10 Apr 2013 02:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgi+qTQQyQlH for ; Wed, 10 Apr 2013 02:24:09 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCED21F9132 for ; Wed, 10 Apr 2013 02:24:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,444,1363132800"; d="scan'208";a="327814421" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 10 Apr 2013 10:24:06 +0100 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3A9O6t3024821 for ; Wed, 10 Apr 2013 10:24:06 +0100 X-IronPort-AV: E=Sophos;i="4.87,444,1363132800"; d="scan'208";a="13105148" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 10 Apr 2013 10:24:06 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 10:24:06 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "'Stan Ratliff (sratliff)'" Thread-Topic: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] Thread-Index: Ac41TK8ANyoFLbILT+uoqHkr+c1ZwwAeRggw Date: Wed, 10 Apr 2013 09:24:06 +0000 Message-ID: References: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> In-Reply-To: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'manet' Subject: Re: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:24:10 -0000 One of those blocks of text gets added when I post from this work address. = Nothing I can do about it. But as Adrian says, posting here has rules, and = I therefore assume that when it says the intended recipient, that means eve= ryone on the list. Or reading its archives. Or using it any IETF related wa= y. Or any other way consistent with the rules. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 09 April 2013 19:05 To: 'Stan Ratliff (sratliff)'; 'Abdussalam Baryun' Cc: 'manet' Subject: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nh= dp-olsrv2-sec-01] ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Stan, I wouldn't worry about this text. In my opinion it is at best purposeless a= nd confusing. The IETF Trust deems all emails to IETF mailing lists to be contributions t= o the IETF. This should be clear from the Note Well that all participants see whe= never they sign up to an IETF mailing list and whenever they bother to look more closely (for example, at RFC 5378). In my opinion, no amount of added verbiage to an email can change the copyr= ight that applies to it under the IETF Trust rules. Of course, everyone is entit= led to their own opinion and the opinions of their paid or bar-room lawyers. I tend to think that admonitions in email footers to not read an email that= was not intended for me are kind of amusing. I usually read emails from top dow= n, so I don't get to that bit until it is too late. But, in any case, if an email comes to me via a mailing list, how do I know whether I was supposed to rec= eive it or not? I know some people automatically throw away any email with that = kind of footnote just to be on the safe side, so including the note seems counter-productive to IETF work. Maybe, however, this is just another distraction on the MANET list? What is= the next technical topic? Cheers, Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Stan Ratliff (sratliff) > Sent: 09 April 2013 18:44 > To: Abdussalam Baryun > Cc: manet; > Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 >=20 > AB, >=20 > On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: >=20 > [snip] > > > > ++++++++++++++++++++++++++++++++++++ > > > > Copyright Notice: > > Copyright (c) 2012 IETF Trust and the person identified as the > > message author. All rights reserved. > > This message is to comment on the MANET WG work in progress I-D: > > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > > may contain parts/texts of the I-D under review > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > [snip] > > > > This message is owned by the author, and was not sent to any private > > email box, just IETF emails. > > > ************************************************************** > ****** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > > ************************************************************** > ****** >=20 > [snip] >=20 >=20 > I'm somewhat concerned by these 3 blocks of text in your emails. The IETF= have > quite a few rules & regs about intellectual property rights; some of the = above > text, if taken in the most stringent manner, could be seen to preclude us= e of any > of your ideas into the associated documents. Please explain the motivatio= n > behind the text I've highlighted above. >=20 > Regards, > Stan >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From drdanhe@gmail.com Wed Apr 10 02:42:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37B021F8D79 for ; Wed, 10 Apr 2013 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLVoWMe0rD3N for ; Wed, 10 Apr 2013 02:42:33 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9654921F8D40 for ; Wed, 10 Apr 2013 02:42:33 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id r13so232691iar.5 for ; Wed, 10 Apr 2013 02:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I/y1S5/vxvm2fFCoYwJ4qx1JSxOngQzXdmpQWzaSSig=; b=ER32ysh3bylLmtV99PCuNM/NKseGxDMAX/rui/Snsn1u9AwTb0q8qp9sA/EU7/y+rI G0+GPUqww0HyjxFfdxqsCuDAdvO5vSeqIRB3RR7sZmZKu1VGGL8gI03fAK4/kwEm7915 ffBpaUJTXr6gaDPDPrC0JLOKeFFvtAg4bAcm45x/tuCGyUeeZP1z53iY0fv3HfIcWlSC 2Ed8V2ZFcqTUjkO99M2c+7Bsjng4LLA+fmAtsGnaJpHdkxzGqzBXKY/5F8+caDw2+MIl XAan88ddPm738TKSwUIaNpm1MxHWyIdiuMLw1vfawS7sFAuY254EOUrKtgrl4T+nekkv A/9Q== MIME-Version: 1.0 X-Received: by 10.50.6.35 with SMTP id x3mr12560404igx.85.1365586953122; Wed, 10 Apr 2013 02:42:33 -0700 (PDT) Received: by 10.50.56.5 with HTTP; Wed, 10 Apr 2013 02:42:32 -0700 (PDT) In-Reply-To: References: <01eb01ce354c$b77d9390$2678bab0$@olddog.co.uk> Date: Wed, 10 Apr 2013 10:42:32 +0100 Message-ID: From: Daniel He To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7bd770f4409f7a04d9fe7dfa Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nhdp-olsrv2-sec-01] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:42:35 -0000 --047d7bd770f4409f7a04d9fe7dfa Content-Type: text/plain; charset=ISO-8859-1 As I understood your additive text is fine, nothing to do against the IETF rules( as Adrian said,i.e. RFC 5378). In RFC 5378 has said, IETF means every participants in IETF activities including mailing list, we are granted the rights to use and reproduce the derivative work from the "contributions" such as emails. What I concern is that "confidential warning" which is totally against IETF rule. as RFC5378 said, " No information in the Contribution is confidential, and the IETF, IETF Trust, ISOC, and its affiliated organizations may freely disclose any information in the Contribution. Best Regards, Daniel On 10 April 2013 10:24, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > One of those blocks of text gets added when I post from this work address. > Nothing I can do about it. But as Adrian says, posting here has rules, and > I therefore assume that when it says the intended recipient, that means > everyone on the list. Or reading its archives. Or using it any IETF related > way. Or any other way consistent with the rules. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 09 April 2013 19:05 > To: 'Stan Ratliff (sratliff)'; 'Abdussalam Baryun' > Cc: 'manet' > Subject: [manet] Copyright in emails [Was: Comments for > draft-ietf-manet-nhdp-olsrv2-sec-01] > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Stan, > > I wouldn't worry about this text. In my opinion it is at best purposeless > and > confusing. > > The IETF Trust deems all emails to IETF mailing lists to be contributions > to the > IETF. This should be clear from the Note Well that all participants see > whenever > they sign up to an IETF mailing list and whenever they bother to look more > closely (for example, at RFC 5378). > > In my opinion, no amount of added verbiage to an email can change the > copyright > that applies to it under the IETF Trust rules. Of course, everyone is > entitled > to their own opinion and the opinions of their paid or bar-room lawyers. > > I tend to think that admonitions in email footers to not read an email > that was > not intended for me are kind of amusing. I usually read emails from top > down, so > I don't get to that bit until it is too late. But, in any case, if an email > comes to me via a mailing list, how do I know whether I was supposed to > receive > it or not? I know some people automatically throw away any email with that > kind > of footnote just to be on the safe side, so including the note seems > counter-productive to IETF work. > > Maybe, however, this is just another distraction on the MANET list? What > is the > next technical topic? > > Cheers, > Adrian > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of > > Stan Ratliff (sratliff) > > Sent: 09 April 2013 18:44 > > To: Abdussalam Baryun > > Cc: manet; > > Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01 > > > > AB, > > > > On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote: > > > > [snip] > > > > > > ++++++++++++++++++++++++++++++++++++ > > > > > > Copyright Notice: > > > Copyright (c) 2012 IETF Trust and the person identified as the > > > message author. All rights reserved. > > > This message is to comment on the MANET WG work in progress I-D: > > > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message > > > may contain parts/texts of the I-D under review > > > ======================================= > > > > > [snip] > > > > > > This message is owned by the author, and was not sent to any private > > > email box, just IETF emails. > > > > > ************************************************************** > > ****** > > > This email and any attachments are confidential to the intended > > > recipient and may also be privileged. If you are not the intended > > > recipient please delete it from your system and notify the sender. > > > You should not copy it or use it for any purpose nor disclose or > > > distribute its contents to any other person. > > > > > ************************************************************** > > ****** > > > > [snip] > > > > > > I'm somewhat concerned by these 3 blocks of text in your emails. The > IETF have > > quite a few rules & regs about intellectual property rights; some of the > above > > text, if taken in the most stringent manner, could be seen to preclude > use of > any > > of your ideas into the associated documents. Please explain the > motivation > > behind the text I've highlighted above. > > > > Regards, > > Stan > > > > > > _______________________________________________ > > 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 > --047d7bd770f4409f7a04d9fe7dfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I understood your additive text is fine, nothing to do against the IETF = rules( as Adrian said,i.e. RFC 5378).=A0 In RFC 5378 has said, IETF means e= very participants in IETF activities including mailing list, we are granted= the rights to use and reproduce the derivative work from the "contrib= utions" such as emails.

What I concern is that "confidential warning" which is totall= y against IETF rule. as RFC5378 said, "
 No information in the=
 Contribution is confidential, and the IETF,
      IETF Trust, ISOC, and its affiliated organizations may freely
      disclose any information in the Contribution.

Best Regards,
Daniel

On 10 April 2013 10:24,= Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com= > wrote:
One of those blocks of text gets added when = I post from this work address. Nothing I can do about it. But as Adrian say= s, posting here has rules, and I therefore assume that when it says the int= ended recipient, that means everyone on the list. Or reading its archives. = Or using it any IETF related way. Or any other way consistent with the rule= s.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bou= nces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: 09 April 2013 19:05
To: 'Stan Ratliff (sratliff)'; 'Abdussalam Baryun'
Cc: 'manet'
Subject: [manet] Copyright in emails [Was: Comments for draft-ietf-manet-nh= dp-olsrv2-sec-01]

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Stan,

I wouldn't worry about this text. In my opinion it is at best purposele= ss and
confusing.

The IETF Trust deems all emails to IETF mailing lists to be contributions t= o the
IETF. This should be clear from the Note Well that all participants see whe= never
they sign up to an IETF mailing list and whenever they bother to look more<= br> closely (for example, at RFC 5378).

In my opinion, no amount of added verbiage to an email can change the copyr= ight
that applies to it under the IETF Trust rules. Of course, everyone is entit= led
to their own opinion and the opinions of their paid or bar-room lawyers.
I tend to think that admonitions in email footers to not read an email that= was
not intended for me are kind of amusing. I usually read emails from top dow= n, so
I don't get to that bit until it is too late. But, in any case, if an e= mail
comes to me via a mailing list, how do I know whether I was supposed to rec= eive
it or not? I know some people automatically throw away any email with that = kind
of footnote just to be on the safe side, so including the note seems
counter-productive to IETF work.

Maybe, however, this is just another distraction on the MANET list? What is= the
next technical topic?

Cheers,
Adrian

> -----Original Message-----
> From: mane= t-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Stan Ratliff (sratliff)
> Sent: 09 April 2013 18:44
> To: Abdussalam Baryun
> Cc: manet; <draft-ietf-manet-nhdp-olsrv2-sec@tools.ietf.o= rg>
> Subject: Re: [manet] Comments for draft-ietf-manet-nhdp-olsrv2-sec-01<= br> >
> AB,
>
> On Apr 9, 2013, at 11:23 AM, Abdussalam Baryun wrote:
>
> [snip]
> >
> > ++++++++++++++++++++++++++++++++++++
> >
> > Copyright Notice:
> > Copyright (c) 2012 IETF Trust and the person identified as the > > message author. All rights reserved.
> > This message is to comment on the MANET WG work in progress I-D:<= br> > > draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this mess= age
> > may contain parts/texts of the I-D under review
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> [snip]
> >
> > This message is owned by the author, and was not sent to any priv= ate
> > email box, just IETF emails.
> >
> **************************************************************
> ******
> > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended=
> > recipient please delete it from your system and notify the sender= .
> > You should not copy it or use it for any purpose nor disclose or<= br> > > distribute its contents to any other person.
> >
> **************************************************************
> ******
>
> [snip]
>
>
> I'm somewhat concerned by these 3 blocks of text in your emails. T= he IETF have
> quite a few rules & regs about intellectual property rights; some = of the above
> text, if taken in the most stringent manner, could be seen to preclude= use of
any
> of your ideas into the associated documents. Please explain the motiva= tion
> behind the text I've highlighted above.
>
> Regards,
> Stan
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet

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

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

--047d7bd770f4409f7a04d9fe7dfa-- From abdussalambaryun@gmail.com Wed Apr 10 02:58:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FB221F9184 for ; Wed, 10 Apr 2013 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR7jeF0FZy0l for ; Wed, 10 Apr 2013 02:57:58 -0700 (PDT) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 034E421F918C for ; Wed, 10 Apr 2013 02:57:57 -0700 (PDT) Received: by mail-da0-f49.google.com with SMTP id t11so143414daj.22 for ; Wed, 10 Apr 2013 02:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5tdX53cT/83XM8zvDSuco26Fk2Cr1M5gOEFJbGrhCLc=; b=FRkrA5ClBQtn6Q4NXuQX/2mXRuMgE/6yANxAxjCar0lXaSfNxiYyDM6ZsB+a/OpWxq +7sLaF8f/YQjIzXi4RCSJlov70OvazS7mZbMHq9tgr1Y468SISEuuUThdemeOQlv5KKb RL+l6caqMIptDoNcz5dv5dzICcvQXR6x4jcQvPI/V5TAx5Q9qTXwf42KQqP+FbikJyVy Pc8fpfEhT2XWC1Wwf2Hhn6tKL4cEBMYI1IfpV0CUQyPNFQSW09AzuSAMR/tt6l+Y18n0 O6qGlj2aKIs+bpzedxKBz76C9W3j7UM/QFbk/K0i1q99WZRyVDpT+4hGERfhvnZKkGgn BG9A== MIME-Version: 1.0 X-Received: by 10.68.43.35 with SMTP id t3mr1768104pbl.202.1365587877664; Wed, 10 Apr 2013 02:57:57 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Wed, 10 Apr 2013 02:57:57 -0700 (PDT) In-Reply-To: <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> Date: Wed, 10 Apr 2013 10:57:57 +0100 Message-ID: From: Abdussalam Baryun To: adrian Content-Type: multipart/alternative; boundary=bcaec53aeed85b9d4504d9feb4ff Cc: draft-ietf-manet-nhdp-sec-threats , manet Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:58:00 -0000 --bcaec53aeed85b9d4504d9feb4ff Content-Type: text/plain; charset=ISO-8859-1 Message Author: Abdussalam Baryun Dated: 10.04.2013 Classified: Informational Hi Adrian, AD of Routing Area I did not have any intention to make myself get-knowledge, I know the definition and don't need to ask other WGs, the reviewer job is to ask the authors not others. The reviewer's job is not to comment on things for his knowledge it is the knowledge of other readers in future. The reviewer is an owner of the document under review because he is a participant in MANET WG, hope that IETF editors remember that. Please note that the *attack* was not defined, and the reviewer knows what it means but there was confusion in the review process (each reviewer has his own procedure that I hope IETF respects). The RFC6130 is the standard under study by the I-D of NHDP threats, therefore the reviewer needs to have consistency between both documents. Reviewer got into the below process: ============================ 1) Read both documents RFC6130 and the I-D. 2) The RFC6130 mentions wireless sensors as possible deployment, the reviewer needed to read LLN threats for consistency, because many sensors lossy. 3) The document of LLN threat analysis was read by the reviewer. 4) the LLN document defines *attack* and mentions physical attacks as threats (please note that the reviewer did not bring up new idea of attacks it was all in IETF documents), so reviewer wants consistency. 5) the reviewer wants to know why the I-D thinks that the threats are common, but it does not refer to the LLN threats even though the RFC6130 mentions sensors. 6) Reveiwer did not ignore the input of MANET WG discussion related to lossy nodes. One participant mentions that MANET can be lossy if it gets physical attacks. The MANET WG does not define this as out of scope. The reviewer has right to ask the authors as the document is MANET document and the MANET WG does not define excluding such attack. 7) The comments were published, and requesting editors to define *attack* and *threats*, and if possible to refer to the LLN threat document ( reviewer does never ignore other WG documents because in same Working Area). 8) Editors refused to define important words, refused to refer to any. Only after you send your comments the editors followed. The reveiwer wanted the better for the Internet Community and responded. I hope IETF don't misunderstand reviewer's process. 9) Reviewer feels discouraged, and not understand reasons of such reaction to volunteering efforts and no editing process working in parallel with other efforts. I may send another comment for the WGs, regarding this issue, for progress. Please note that the reviewer is doing a good job if you compare how many people reviewed the I-D. The reviewer is never reason to recycle, it is ignoring issues of other I-Ds that make things recycles in any WG in any Area. Best Regards Abdussalam Baryun This message is a reply to clarify the reviewer's intention. This On Tue, Apr 9, 2013 at 10:19 PM, Adrian Farrel wrote: > This discussion is getting a bit circuitous! > > However, if you want IETF definitions of security terms, please read RFC > 4949. > And please direct any questions on the contents to the Security Area and > not to > this list! > > Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative > reference to 4949. > > Adrian > > > -----Original Message----- > > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > > Sent: 09 April 2013 21:38 > > To: adrian@olddog.co.uk > > Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet > > Subject: Re: Node subversion [Was: AB#3 Comments for WGLC > draft-ietf-manet- > > nhdp-sec-threats-02] > > > > Hi Adrian, > > > > I asked the editors to define *attack* but they don't want to, so if > > it was out of the scope, So I need editors to make it clearly defined > > in the document, IMHO, excluding that attack or including SHOULD be > > informed in this informational I-D > > > > AB > > > > On 4/9/13, Adrian Farrel wrote: > > > Hi, > > > > > > I think that some of these comments relate to subversion of nodes. This > > > topic > > > often comes up in discussion of routing protocol security (although > > > strangely > > > not in the discussion of application level security - maybe they have > more > > > security clue than we do!) > > > > > > There are two types of subversion: > > > 1. Installing new software on existing hardware > > > 2. Replacing in-the-field hardware > > > > > > The second of these is usually protectable by security associations > since > > > physically replacing one node will not replicate the security > credentials > > > and so > > > the node will not be able to participate in the security relationships > > > necessary > > > for the protocol. > > > > > > The first is usually regarded as faintly amusing! The idea that your > main > > > problem with a subverted node is harm to the routing infrastructure is > > > wrong. If > > > a node that routes packets has been subverted then *anything* may > happen in > > > your > > > network. Protection against software subversion varies from nodes that > > > physically self-destruct if tampered with, to nodes that require > security > > > checks > > > before software can be modified. > > > > > > But, in both cases, there is nothing that the routing protocol can do. > If a > > > routing peer has the security credentials but decides to act badly, so > be > > > it! > > > (There were a number of attempts to characterise the on-wire behavior > of > > > bad-actors, but - perhaps, of course - such attempts are > self-defeating). > > > > > > > > > Another view of a physical attack is one that degrades the performance > of a > > > node > > > or link, perhaps through radio interference. I would argue that the > only > > > thing > > > that a routing protocol can do in this case is to observe the degraded > > > performance and to adjust metrics accordingly. However, I would also > say > > > that > > > this is not actually the responsibility of the routing protocol, but > of the > > > management system in the network. > > > > > > Thus, I would say that physical attacks on notes are out of scope. > > > > > > Adrian > > > > > >> -----Original Message----- > > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf > > Of > > >> Ulrich Herberg > > >> Sent: 09 April 2013 20:23 > > >> To: Abdussalam Baryun > > >> Cc: draft-ietf-manet-nhdp-sec-threats; manet > > >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec- > > >> threats-02 > > >> > > >> AB, > > >> > > >> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun > > >> wrote: > > >> >[...] > > >> > > > >> > As a respond to my first to AB#1, AB#2 messages, and to [1] message. > > >> > The NHDP threat related to physical attacks were ignored by the I-D. > > >> > The I-D describes non-physical attacks in section 4 but does not for > > >> > physical attacks, which has threats. The neighbors may get both > > >> > together non-physical and physical, as if two or more neighbors are > in > > >> > radio range coverage. I don't think this was introduced in the I-D, > > >> > which I hope editors follow. > > >> > > > >> > Military Scenario Example: > > >> > > > >> > Identity or link spoof can occur in other scenarios mentioned in I-D > > >> > (i.e. spoofed the address while attacker is out of that neighbor > radio > > >> > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not > > >> > identity-spoof attack only after the neighbor is physically > attacked, > > >> > then M takes over that neighbor identity and responsibilities, even > if > > >> > they were in same radio coverage. This is a threat because these > > >> > neighbors are in range of each other, and the node disapers from the > > >> > network. The I-D does not consider the situation where the neighbor > > >> > disapears from the network but replaced by an attacker M. This > example > > >> > scenario assumes that neighbors are in range but not aware of the > > >> > physical attack, and the malicious node is aware. > > >> > > > >> > AB> Please editors of the I-D, consider in section 4.4.1 to add the > > >> > threat described, if not clear for you, please reply, > > >> > > >> What do you mean by physical attacks? Tampering with the hardware of > > >> the router running NHDP? I think that this is not the scope of the > > >> draft (and also irrelevant); the draft purely looks at security > > >> threats of misconfigured or malicious NHDP routers that misbehave when > > >> using NHDP. It could be that such a router has been hacked via an > > >> implementation flaw or physically exchanged some parts of the > > >> hardware; that does not matter. For the case you describe, how does it > > >> matter if the router disappears and comes back later? (whether or not > > >> it is physically exchanged, or just stopped sending HELLOs for a > > >> while). > > >> > > >> Regards > > >> Ulrich > > >> > > >> > > >> > > >> > > >> > [...] > > >> > > > >> > References: > > >> > [1] The message below, by Dearlove, C., (2013), IETF MANET WG > > >> > Discussion list, Re: [manet] AB#1 Comments for WGLC > > >> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013. > > >> > > > >> > > > >> > On 4/9/13, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> > > >> wrote: > > >> >> I'm neither recommending that a reference is included or excluded, > I'm > > >> >> just > > >> >> providing here where one good source of definitions. Whether to > > >> >> reference > > > it > > >> >> is a judgement call as to what is considered widely known, and what > > >> >> isn't. > > >> >> > > >> >> But that definition is not limited to physical attack. > > >> >> > > >> >> -- > > >> >> Christopher Dearlove > > >> >> Senior Principal Engineer, Communications Group > > >> >> Communications, Networks and Image Analysis Capability > > >> >> BAE Systems Advanced Technology Centre > > >> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > >> >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > > >> >> chris.dearlove@baesystems.com | http://www.baesystems.com > > >> >> > > >> >> BAE Systems (Operations) Limited > > >> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > > >> Centre, > > >> >> Farnborough, Hants, GU14 6YU, UK > > >> >> Registered in England & Wales No: 1996687 > > >> >> > > >> >> > > >> >> -----Original Message----- > > >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > > >> >> Sent: 09 April 2013 12:44 > > >> >> To: Dearlove, Christopher (UK) > > >> >> Cc: manet > > >> >> Subject: Re: [manet] AB#1 Comments for WGLC > > >> >> draft-ietf-manet-nhdp-sec-threats-02 > > >> >> > > >> >> ----------------------! WARNING ! ---------------------- > > >> >> This message originates from outside our organisation, > > >> >> either from an external partner or from the internet. > > >> >> Keep this in mind if you answer this message. > > >> >> Follow the 'Report Suspicious Emails' link on IT matters > > >> >> for instructions on reporting suspicious email messages. > > >> >> -------------------------------------------------------- > > >> >> > > >> >> Hi Chris, > > >> >> > > >> >> The I-D seems not to define physical attacks (my understanding), > which > > >> >> I was not sure of but [1] (mentioned in first AB#1 message) did > > >> >> include, but I think your input is prefered to include in the I-D > or > > >> >> used, > > >> >> > > >> >> AB > > >> >> > > >> >> On 4/9/13, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> > > >> >> wrote: > > >> >>> AB> you don't define *Threat*, and *Attack* > > >> >>> > > >> >>> Personally, I would start with ISO 27000 which has: > > >> >>> > > >> >>> ===== > > >> >>> 2.45 > > >> >>> threat > > >> >>> potential cause of an unwanted incident, which may result in harm > to > > >> >>> a > > >> >>> system or organization > > >> >>> > > >> >>> 2.4 > > >> >>> attack > > >> >>> attempt to destroy, expose, alter, disable, steal or gain > > >> >>> unauthorized > > >> >>> access to or make unauthorized use of > > >> >>> an asset (2.3) > > >> >>> > > >> >>> 2.3 > > >> >>> asset > > >> >>> anything that has value to the organization > > >> >>> NOTE There are many types of assets, including: > > >> >>> a) information (2.18); > > >> >>> b) software, such as a computer program; > > >> >>> c) physical, such as computer; > > >> >>> d) services; > > >> >>> e) people, and their qualifications, skills, and experience; and > > >> >>> f) intangibles, such as reputation and image. > > >> >>> > > >> >>> 2.18 > > >> >>> information asset > > >> >>> knowledge or data that has value to the organization > > >> >>> ===== > > >> >>> > > >> >>> (The rules are that you may substitute in the definition, so > attack > > >> >>> may > > >> >>> be > > >> >>> parsed as "attempt to destroy, expose, alter, disable, steal or > gain > > >> >>> unauthorized access to or make unauthorized use of anything that > has > > >> >>> value > > >> >>> to the organization".) > > >> >>> > > >> >>> [There is also an overlapping set of definitions in ISO 27032, but > > >> >>> 27000 > > >> >>> is > > >> >>> more relevant here.] > > >> >>> > > >> >>> I don't know if there are any RFCs that reference ISO 27000. > > >> >>> > > >> >>> -- > > >> >>> Christopher Dearlove > > >> >>> Senior Principal Engineer, Communications Group > > >> >>> Communications, Networks and Image Analysis Capability > > >> >>> BAE Systems Advanced Technology Centre > > >> >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > >> >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 > > >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com > > >> >>> > > >> >>> BAE Systems (Operations) Limited > > >> >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > > >> >>> Centre, > > >> >>> Farnborough, Hants, GU14 6YU, UK > > >> >>> Registered in England & Wales No: 1996687 > > >> >>> > > >> >>> > > >> >>> > > >> > > ************************************************************** > > >> ****** > > >> >>> This email and any attachments are confidential to the intended > > >> >>> recipient and may also be privileged. If you are not the intended > > >> >>> recipient please delete it from your system and notify the sender. > > >> >>> You should not copy it or use it for any purpose nor disclose or > > >> >>> distribute its contents to any other person. > > >> >>> > > >> > > ************************************************************** > > >> ****** > > >> >>> > > >> >>> > > >> >> > > >> >> > > >> _______________________________________________ > > >> manet mailing list > > >> manet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > > --bcaec53aeed85b9d4504d9feb4ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Message Author: Abdussalam Baryun
Dated: 10= .04.2013
Classified: Informational
=A0
=A0
Hi Adrian,
AD of Routing Area
=A0
I d= id not have any intention to make myself get-knowledge, I know the definiti= on and don't need to ask other WGs, the reviewer job is to ask the auth= ors not others. The reviewer's job is not to comment on things for his = knowledge it is the knowledge of other readers in future. The reviewer is a= n owner of the document under review because he is a participant in MANET W= G, hope that IETF=A0editors remember that.
=A0
Please note that the *attack* was not defined, and the r= eviewer knows what it means but there was confusion in the review process (= each reviewer has his own procedure that I hope IETF respects). The RFC6130= is the standard under study by the I-D of NHDP threats, therefore the revi= ewer needs to have consistency between both documents.
=A0
Reviewer got into the below process:
=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
1) Read both docum= ents RFC6130 and the I-D.
=A0
2) The RFC6130 mentions wireless sensors as poss= ible deployment, the reviewer needed to read LLN threats for consistency, b= ecause many=A0sensors lossy.
=A0
3) The document of LLN threat analysis was read by the reviewer.
=A0
4) the LLN docume= nt defines *attack* and mentions physical attacks as threats (please note t= hat the reviewer did not bring up new idea of attacks it was all in IETF do= cuments), so reviewer wants consistency.
=A0
5) the revie= wer wants to know why the I-D thinks that the threats are common, but it do= es not refer to the LLN threats even though the RFC6130 mentions sensors.
=A0
6) Reveiwer = did not ignore the input of MANET WG discussion related to lossy nodes. One= participant mentions that MANET can be lossy if it gets physical attacks. = The MANET WG does not define this as out of scope. The reviewer has right t= o ask the authors as the document is MANET document and the MANET WG does n= ot define excluding such attack.
=A0
7) The comme= nts were published, and requesting editors to define *attack* and *threats*= , and if possible to refer to the LLN threat document ( reviewer does never= ignore other WG documents because in same Working Area).
=A0
8) Editors r= efused to define important words, refused to refer to any. Only after you s= end your comments the editors followed. The reveiwer wanted the better for = the Internet Community and responded. I hope IETF don't misunderstand r= eviewer's process.
=A0
9) Reviewer = feels discouraged, and not understand reasons of such reaction to volunteer= ing efforts and no editing process working in parallel with other efforts.<= /div>
=A0
I may send a= nother comment for the WGs, regarding this issue, for progress.
=A0
Please note that t= he reviewer is doing a good job if you compare how many people reviewed the= I-D. The reviewer is never reason to recycle, it is ignoring issues of oth= er I-Ds that make things recycles in any WG in any Area.
=A0
Best Regards=
Abdussalam Baryun
=A0
This message is a reply to = clarify the reviewer's intention. This
On Tue, Apr 9, 2013 at 10:19 PM, Adrian Fa= rrel <adrian@olddog.co.uk> wrote:
This discussion is getting a bit circuitous!

However, if you want IETF definitions of security terms, please read RFC 49= 49.
And please direct any questions on the contents to the Security Area and no= t to
this list!

Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative reference to 4949.

Adrian

> -----Original Message-----
> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> Sent: 09 April 2013 21:3= 8
> To: adrian@olddog.co.uk
> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet
> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draft-ietf-m= anet-
> nhdp-sec-threats-02]
>
> Hi Adrian,
>
> I asked the editors to define *attack* but they don't want to, so = if
> it was out of the scope, So I need editors to make it clearly defined<= br> > in the document, IMHO, excluding that attack or including SHOULD be > informed in this informational I-D
>
> AB
>
> On 4/9/13, Adrian Farrel <ad= rian@olddog.co.uk> wrote:
> > Hi,
> >
> > I think that some of these comments relate to subversion of nodes= . This
> > topic
> > often comes up in discussion of routing protocol security (althou= gh
> > strangely
> > not in the discussion of application level security - maybe they = have more
> > security clue than we do!)
> >
> > There are two types of subversion:
> > 1. Installing new software on existing hardware
> > 2. Replacing in-the-field hardware
> >
> > The second of these is usually protectable by security associatio= ns since
> > physically replacing one node will not replicate the security cre= dentials
> > and so
> > the node will not be able to participate in the security relation= ships
> > necessary
> > for the protocol.
> >
> > The first is usually regarded as faintly amusing! The idea that y= our main
> > problem with a subverted node is harm to the routing infrastructu= re is
> > wrong. If
> > a node that routes packets has been subverted then *anything* may= happen in
> > your
> > network. Protection against software subversion varies from nodes= that
> > physically self-destruct if tampered with, to nodes that require = security
> > checks
> > before software can be modified.
> >
> > But, in both cases, there is nothing that the routing protocol ca= n do. If a
> > routing peer has the security credentials but decides to act badl= y, so be
> > it!
> > (There were a number of attempts to characterise the on-wire beha= vior of
> > bad-actors, but - perhaps, of course - such attempts are self-def= eating).
> >
> >
> > Another view of a physical attack is one that degrades the perfor= mance of a
> > node
> > or link, perhaps through radio interference. I would argue that t= he only
> > thing
> > that a routing protocol can do in this case is to observe the deg= raded
> > performance and to adjust metrics accordingly. However, I would a= lso say
> > that
> > this is not actually the responsibility of the routing protocol, = but of the
> > management system in the network.
> >
> > Thus, I would say that physical attacks on notes are out of scope= .
> >
> > Adrian
> >
> >> -----Original Message-----
> >> From: manet-bounces= @ietf.org [mailto:manet-bounc= es@ietf.org] On Behalf
> Of
> >> Ulrich Herberg
> >> Sent: 09 April 2013 20:23
> >> To: Abdussalam Baryun
> >> Cc: draft-ietf-manet-nhdp-sec-threats; manet
> >> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-= nhdp-sec-
> >> threats-02
> >>
> >> AB,
> >>
> >> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun
> >> <abdussalamb= aryun@gmail.com> wrote:
> >> >[...]
> >> >
> >> > As a respond to my first to AB#1, AB#2 messages, and to = [1] message.
> >> > The NHDP threat related to physical attacks were ignored= by the I-D.
> >> > The I-D describes non-physical attacks in section 4 but = does not for
> >> > physical attacks, which has threats. The neighbors may g= et both
> >> > together non-physical and physical, as if two or more ne= ighbors are in
> >> > radio range coverage. I don't think this was introdu= ced in the I-D,
> >> > which I hope editors follow.
> >> >
> >> > Military Scenario Example:
> >> >
> >> > Identity or link spoof can occur in other scenarios ment= ioned in I-D
> >> > (i.e. spoofed the address while attacker is out of that = neighbor radio
> >> > coverage, as in section 4.4.1 Fig.1 ). Malicious router = (M) may not
> >> > identity-spoof attack only after the neighbor is physica= lly attacked,
> >> > then M takes over that neighbor identity and responsibil= ities, even if
> >> > they were in same radio coverage. This is a threat becau= se these
> >> > neighbors are in range of each other, and the node disap= ers from the
> >> > network. The I-D does not consider the situation where t= he neighbor
> >> > disapears from the network but replaced by an attacker M= . This example
> >> > scenario assumes that neighbors are in range but not awa= re of the
> >> > physical attack, and the malicious node is aware.
> >> >
> >> > AB> Please editors of the I-D, consider in section 4.= 4.1 to add the
> >> > threat described, if not clear for you, please reply, > >>
> >> What do you mean by physical attacks? Tampering with the hard= ware of
> >> the router running NHDP? I think that this is not the scope o= f the
> >> draft (and also irrelevant); the draft purely looks at securi= ty
> >> threats of misconfigured or malicious NHDP routers that misbe= have when
> >> using NHDP. It could be that such a router has been hacked vi= a an
> >> implementation flaw or physically exchanged some parts of the=
> >> hardware; that does not matter. For the case you describe, ho= w does it
> >> matter if the router disappears and comes back later? (whethe= r or not
> >> it is physically exchanged, or just stopped sending HELLOs fo= r a
> >> while).
> >>
> >> Regards
> >> Ulrich
> >>
> >>
> >>
> >>
> >> > [...]
> >> >
> >> > References:
> >> > [1] The message below, by Dearlove, C., (2013), IETF MAN= ET WG
> >> > Discussion list, Re: [manet] AB#1 Comments for WGLC
> >> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013.
> >> >
> >> >
> >> > On 4/9/13, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> > >> wrote:
> >> >> I'm neither recommending that a reference is inc= luded or excluded, I'm
> >> >> just
> >> >> providing here where one good source of definitions.= Whether to
> >> >> reference
> > it
> >> >> is a judgement call as to what is considered widely = known, and what
> >> >> isn't.
> >> >>
> >> >> But that definition is not limited to physical attac= k.
> >> >>
> >> >> --
> >> >> Christopher Dearlove
> >> >> Senior Principal Engineer, Communications Group
> >> >> Communications, Networks and Image Analysis Capabili= ty
> >> >> BAE Systems Advanced Technology Centre
> >> >> West Hanningfield Road, Great Baddow, Chelmsford, CM= 2 8HN, UK
> >> >> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
> >> >> chr= is.dearlove@baesystems.com | http://www.baesystems.com
> >> >>
> >> >> BAE Systems (Operations) Limited
> >> >> Registered Office: Warwick House, PO Box 87, Farnbor= ough Aerospace
> >> Centre,
> >> >> Farnborough, Hants, GU14 6YU, UK
> >> >> Registered in England & Wales No: 1996687
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> >> >> Sent: 09 April 2013 12:44
> >> >> To: Dearlove, Christopher (UK)
> >> >> Cc: manet
> >> >> Subject: Re: [manet] AB#1 Comments for WGLC
> >> >> draft-ietf-manet-nhdp-sec-threats-02
> >> >>
> >> >> ----------------------! WARNING ! ------------------= ----
> >> >> This message originates from outside our organisatio= n,
> >> >> either from an external partner or from the internet= .
> >> >> Keep this in mind if you answer this message.
> >> >> Follow the 'Report Suspicious Emails' link o= n IT matters
> >> >> for instructions on reporting suspicious email messa= ges.
> >> >> ----------------------------------------------------= ----
> >> >>
> >> >> Hi Chris,
> >> >>
> >> >> The I-D seems not to define physical attacks (my und= erstanding), which
> >> >> I was not sure of but [1] (mentioned in first AB#1 m= essage) did
> >> >> include, but I think your input is prefered to inclu= de in the I-D or
> >> >> used,
> >> >>
> >> >> AB
> >> >>
> >> >> On 4/9/13, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com>= ;
> >> >> wrote:
> >> >>> AB> you don't define *Threat*, and *Attac= k*
> >> >>>
> >> >>> Personally, I would start with ISO 27000 which h= as:
> >> >>>
> >> >>> =3D=3D=3D=3D=3D
> >> >>> 2.45
> >> >>> threat
> >> >>> potential cause of an unwanted incident, which m= ay result in harm to
> >> >>> a
> >> >>> system or organization
> >> >>>
> >> >>> 2.4
> >> >>> attack
> >> >>> attempt to destroy, expose, alter, disable, stea= l or gain
> >> >>> unauthorized
> >> >>> access to or make unauthorized use of
> >> >>> an asset (2.3)
> >> >>>
> >> >>> 2.3
> >> >>> asset
> >> >>> anything that has value to the organization
> >> >>> NOTE There are many types of assets, including:<= br> > >> >>> a) information (2.18);
> >> >>> b) software, such as a computer program;
> >> >>> c) physical, such as computer;
> >> >>> d) services;
> >> >>> e) people, and their qualifications, skills, and= experience; and
> >> >>> f) intangibles, such as reputation and image. > >> >>>
> >> >>> 2.18
> >> >>> information asset
> >> >>> knowledge or data that has value to the organiza= tion
> >> >>> =3D=3D=3D=3D=3D
> >> >>>
> >> >>> (The rules are that you may substitute in the de= finition, so attack
> >> >>> may
> >> >>> be
> >> >>> parsed as "attempt to destroy, expose, alte= r, disable, steal or gain
> >> >>> unauthorized access to or make unauthorized use = of anything that has
> >> >>> value
> >> >>> to the organization".)
> >> >>>
> >> >>> [There is also an overlapping set of definitions= in ISO 27032, but
> >> >>> 27000
> >> >>> is
> >> >>> more relevant here.]
> >> >>>
> >> >>> I don't know if there are any RFCs that refe= rence ISO 27000.
> >> >>>
> >> >>> --
> >> >>> Christopher Dearlove
> >> >>> Senior Principal Engineer, Communications Group<= br> > >> >>> Communications, Networks and Image Analysis Capa= bility
> >> >>> BAE Systems Advanced Technology Centre
> >> >>> West Hanningfield Road, Great Baddow, Chelmsford= , CM2 8HN, UK
> >> >>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124 > >> >>> chris.dearlove@baesystems.com | http://www.baesystems.com
> >> >>>
> >> >>> BAE Systems (Operations) Limited
> >> >>> Registered Office: Warwick House, PO Box 87, Far= nborough Aerospace
> >> >>> Centre,
> >> >>> Farnborough, Hants, GU14 6YU, UK
> >> >>> Registered in England & Wales No: 1996687 > >> >>>
> >> >>>
> >> >>>
> >>
> **************************************************************
> >> ******
> >> >>> This email and any attachments are confidential = to the intended
> >> >>> recipient and may also be privileged. If you are= not the intended
> >> >>> recipient please delete it from your system and = notify the sender.
> >> >>> You should not copy it or use it for any purpose= nor disclose or
> >> >>> distribute its contents to any other person.
> >> >>>
> >>
> **************************************************************
> >> ******
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> _______________________________________________
> >> manet mailing list
> >> manet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/manet
> >
> >


--bcaec53aeed85b9d4504d9feb4ff-- From adrian@olddog.co.uk Wed Apr 10 03:59:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2073221F8EAA for ; Wed, 10 Apr 2013 03:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.03 X-Spam-Level: * X-Spam-Status: No, score=1.03 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_INCREASE_VOL=3.629] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uoqn0MGA6Kz for ; Wed, 10 Apr 2013 03:59:29 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED0421F8DA0 for ; Wed, 10 Apr 2013 03:59:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3AAxQ2e009779; Wed, 10 Apr 2013 11:59:26 +0100 Received: from 950129200 (87-127-157-145.static.enta.net [87.127.157.145] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3AAxO4H009771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 11:59:25 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <024601ce3560$7f144350$7d3cc9f0$@olddog.co.uk> <026f01ce3567$f13a8190$d3af84b0$@olddog.co.uk> In-Reply-To: Date: Wed, 10 Apr 2013 11:59:23 +0100 Message-ID: <002f01ce35da$76d3d5a0$647b80e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL8dT1L0fSxv8YysEdWEQSmBLQ01AIO9KVUAX3lBPIBe/qpoJZKfOBw Cc: 'draft-ietf-manet-nhdp-sec-threats' , 'manet' Subject: Re: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 10:59:30 -0000 Hi, > I did not have any intention to make myself get-knowledge, I know > the definition and don't need to ask other WGs, the reviewer job is > to ask the authors not others. The reviewer's job is not to comment > on things for his knowledge it is the knowledge of other readers in > future. The reviewer is an owner of the document under review > because he is a participant in MANET WG, hope that IETF=A0editors > remember that. And in view of all this it is your job to supply suggested text, not to = ask questions. This is not a quiz or an academic review. We are trying to write a document together. =A0 > Please note that the *attack* was not defined And we have agreed that a reference to 4949 will be added. So perhaps we = can close this topic and get on with our lives? > and the reviewer knows what it means but there was confusion > in the review process (each reviewer has his own procedure that > I hope IETF respects).=20 i very much doubt that the IETF (singular or corporate) cares one hoot = for what process anyone uses when reviewing a document. > The RFC6130 is the standard under study by the I-D of NHDP threats, > therefore the reviewer needs to have consistency between both > documents. >=A0 > Reviewer got into the below process: [snip] =A0 > 4) the LLN document defines *attack* No it doesn't! It references and quotes from RFC 4949. > mentions physical attacks as threats (please note that the > reviewer did not bring up new idea of attacks it was all in > IETF documents), so reviewer wants consistency. The LLN document looks at a broader scope of attacks on LLNs. This document looks at the threats for specific routing protocols. That = is a difference that cannot be reconciled except by expanding the scope of = this document. I assume you would like that scope expanded. I do not see any support for this position within the working group. You might consider writing your own draft on the wider security issues = for MANETs if you believe that this needs to be addressed. I cannot = guarantee that the WG will be interested or supportive, but you can publish your work = as a white paper or through the ISE. > 5) the reviewer wants to know why the I-D thinks that the threats > are common, but it does not refer to the LLN threats even though > the RFC6130 mentions sensors. I understand that there are issues of English usage. English is not your = native language. It is also not the native language of the document editor. "Common" is perhaps not the perfect word. You didn't make an alternative suggestion, but I suspect and alternative would have be "the main". = However, I don't have an issue with the use of the word, and I am a pedant. > 6) Reveiwer did not ignore the input of MANET WG discussion > related to lossy nodes. One participant mentions that MANET=20 > can be lossy if it gets physical attacks. The MANET WG does not > define this as out of scope.=20 But surely you have misunderstood! The fact a physical attack causes a = link to become (more) lossy does not make the attack within scope for the = specific protocols considered by this document because those protocols already = handle lossy links. So, as my email said, there is nothing that needs to be = done or said for this type of attack. > The reviewer has right to ask the > authors as the document is MANET document and the MANET > WG does not define excluding such attack. Asking questions is not the same as asking them to do things. If you = want material included in the document, you have to write it yourself. =A0 > 7) The comments were published, and requesting editors to define > *attack* and *threats* Haven't we already covered that several times, now. A reference to 4949 = is being included. Nothing more needs to be said on this point. > and if possible to refer to the LLN threat document That has been discussed. No-one else has said on the list that they = consider this a good idea, and several have said they think it a poor idea. I = believe that closes the issue. > 8) Editors refused to define important words, refused to refer to=20 > any. Only after you send your comments the editors followed.=20 I didn't see a refusal. I did see discussion about maybe referencing an = ISO document.=20 I didn't see any recommendation for a reference or text from you. The editors may have followed my comment because I made a concrete = proposal for a specific change. > 9) Reviewer feels discouraged, and not understand reasons of such > reaction to volunteering efforts and no editing process working in=20 > parallel with other efforts. I am sure everyone feels very sad that you feel discouraged. the answer = is not to increase your volume, but to increase your quality. > I may send another comment for the WGs, regarding this issue,=20 > for progress. I, for one, would appreciate it if you throttled back on your comments = and focused on making positive contributions. Reviews that just point out deficiencies are not very constructive to the IETF process - you need to = supply solutions, not problems. And discussions of process, how things = happened, or who said what, are getting seriously disruptive. I really think they need to = stop being posted to the MANET list. I cannot believe that the majority of = the working group is interested, and they are very clearly not in scope. =A0 Thanks, Adrian From internet-drafts@ietf.org Wed Apr 10 09:17:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0A821F9933; Wed, 10 Apr 2013 09:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llO2Q9NSZxfQ; Wed, 10 Apr 2013 09:17:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3521F9939; Wed, 10 Apr 2013 09:17:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410161729.29543.17971.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 09:17:29 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:17:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Security Threats for NHDP Author(s) : Ulrich Herberg Jiazi Yi Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-threats-03.txt Pages : 17 Date : 2013-04-10 Abstract: This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yi.jiazi@gmail.com Wed Apr 10 09:27:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BC21F875A for ; Wed, 10 Apr 2013 09:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.185 X-Spam-Level: *** X-Spam-Status: No, score=3.185 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNhp9NZKUc0I for ; Wed, 10 Apr 2013 09:27:24 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D228C21F8746 for ; Wed, 10 Apr 2013 09:27:22 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ez12so5016287wid.6 for ; Wed, 10 Apr 2013 09:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=VxHv6kUPaH1l17xBbPhiWbHmtjAMKQagsGmRO9HrSUs=; b=qfpcTykjidmPYo497NHJ/LYVFZ2Ch8qZg9gTsIgBaMr6A7BTBt76wqRSJi7q3cFm6r i1RvNwQempiC9vdZPNvUWfvTy7ATRAYKy0XF9MMAARsFhhUcUrmFUB+Yhen+enZ/nCbR ZPo3/rsYejdtykLQbto3gPy0MjlwiUE5IXv2hxzAsNsFJ+9A8281c1m+NDoBh2DFjRNi ttxBQ/LOKexWVUC4fI/ZjpIAT/AMfarpQwDtj5SnkyifSLu4VLSkrUgcUbpnz3DwzIkY zj7f8k5kqR+smZrFMpD5ZaRYlkOMyRuPh7B225yyszRXInHk4wd1xZ3o1JZYiqUzE+fs /R6w== X-Received: by 10.180.72.165 with SMTP id e5mr27531409wiv.7.1365611240028; Wed, 10 Apr 2013 09:27:20 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id o5sm949050wix.3.2013.04.10.09.27.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 09:27:19 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jiazi Yi In-Reply-To: <20130410161729.29543.17971.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 18:27:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130410161729.29543.17971.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" X-Mailer: Apple Mail (2.1503) Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:27:26 -0000 Dear all,=20 A new revision of nhdp-sec-threats has been submitted.=20 There are only two editorial changes: o "As radio signals can be received as well as transmitted by = any *compatible* wireless device within radio range..." o Added an informative reference to RFC4949, where terminologies = are defined in more detail.=20 As far as we can tell, there are no remaining actions from the last = call. AB has suggested that the authors do additional work, but has not = proposed any specific text or pointed out any flaws in the existing = text. The authors do not believe any further work is required, and we = have not heard any support for further changes or offers of work from = the working group. best Jiazi On Apr 10, 2013, at 6:17 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. >=20 > Title : Security Threats for NHDP > Author(s) : Ulrich Herberg > Jiazi Yi > Thomas Heide Clausen > Filename : draft-ietf-manet-nhdp-sec-threats-03.txt > Pages : 17 > Date : 2013-04-10 >=20 > Abstract: > This document analyses common security threats of the Neighborhood > Discovery Protocol (NHDP), and describes their potential impacts on > MANET routing protocols using NHDP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Apr 10 10:16:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3321F8EEA for ; Wed, 10 Apr 2013 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gByg24H9RoK7 for ; Wed, 10 Apr 2013 10:16:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4E21F8EF1 for ; Wed, 10 Apr 2013 10:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1365614195; x=1366823795; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=U8dNaysjuYz2DrQYLExzAXxhJIbnTMfjWwKeMtMWfHc=; b=NtwSpotUFnmWqE8v57+n70BrmGBEQerV/SW+suGMcI408+GSS7/b3/1n vsetBnAsXan1xsxkr8MhP9l2Yro9RXiEXUWq/dyMWyMFGCzRt1SBTqCPs KxsC22CrEg2NJxotvsITV/IaWbyTiIdjbRTLM9++rntVL54aId1JJlfsd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAIKdZVGtJV2c/2dsb2JhbABQgwY2RMB0gQ8WdIIfAQEBAwEBAQE3NAsFCwIBCA4KChQQJwslAgQOBQgBiAUGBwW/L45jAjEHgmBhA5ghj22DC4Io X-IronPort-AV: E=Sophos;i="4.87,449,1363132800"; d="scan'208";a="197344115" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 10 Apr 2013 17:16:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3AHGOrr029419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 17:16:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 10 Apr 2013 12:16:23 -0500 From: "Stan Ratliff (sratliff)" To: Jiazi Yi Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-03.txt Thread-Index: AQHONgbqvh7LMp6H1ku6yDr2ffICgZjP+EuAgAANuIA= Date: Wed, 10 Apr 2013 17:16:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1009BC2F@xmb-aln-x03.cisco.com> References: <20130410161729.29543.17971.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.113] Content-Type: text/plain; charset="us-ascii" Content-ID: <24CAFCFFDAC4CF44BA22DB3A14B79192@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:16:36 -0000 OK, folks -=20 WGLC on this document has now closed. Thanks to everyone that reviewed the = document. Jiazi, I'm going to request that you provide the initial write-up= of the Shepherd's document to me.=20 Regards, Stan On Apr 10, 2013, at 12:27 PM, Jiazi Yi wrote: > Dear all,=20 >=20 > A new revision of nhdp-sec-threats has been submitted.=20 >=20 > There are only two editorial changes: >=20 > o "As radio signals can be received as well as transmitted by any *compa= tible* wireless device within radio range..." >=20 > o Added an informative reference to RFC4949, where terminologies are def= ined in more detail.=20 >=20 > As far as we can tell, there are no remaining actions from the last call.= AB has suggested that the authors do additional work, but has not proposed= any specific text or pointed out any flaws in the existing text. The autho= rs do not believe any further work is required, and we have not heard any s= upport for further changes or offers of work from the working group. >=20 > best >=20 > Jiazi >=20 > On Apr 10, 2013, at 6:17 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of= the IETF. >>=20 >> Title : Security Threats for NHDP >> Author(s) : Ulrich Herberg >> Jiazi Yi >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-threats-03.txt >> Pages : 17 >> Date : 2013-04-10 >>=20 >> Abstract: >> This document analyses common security threats of the Neighborhood >> Discovery Protocol (NHDP), and describes their potential impacts on >> MANET routing protocols using NHDP. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ahmed_awamry_86@yahoo.com Sun Apr 14 03:32:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48BD21F84D1 for ; Sun, 14 Apr 2013 03:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.112 X-Spam-Level: ** X-Spam-Status: No, score=2.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FORGED_YAHOO_RCVD=2.297] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHSpO3wVFmzm for ; Sun, 14 Apr 2013 03:32:48 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5D21F84CE for ; Sun, 14 Apr 2013 03:32:48 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1URKEp-0004Dg-JP for manet@ietf.org; Sun, 14 Apr 2013 03:32:47 -0700 Date: Sun, 14 Apr 2013 03:32:47 -0700 (PDT) From: "Ahmed A. Elawamry" To: manet@ietf.org Message-ID: <1365935567594-365223.post@n7.nabble.com> In-Reply-To: References: <1364740656964-363492.post@n7.nabble.com> <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com> <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [manet] LOADng Data Collection Cycle X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 10:32:48 -0000 Hi Jiazi, Are these memory requirements (1987 C++ lines) for LOADng or LOADng-CTP? as i see from the publications, it provides better performance. Also, Is the routing table for LOADng and LOADng-CTP are identical (have the same fields)? Regards, Ahmed A. Elawamry ----- Best Regards, Ahmed A. Elawamry -- View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365223.html Sent from the IETF - manet mailing list archive at Nabble.com. From bclaise@cisco.com Mon Apr 15 06:19:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95B921F877B; Mon, 15 Apr 2013 06:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STwdwYCX3M0B; Mon, 15 Apr 2013 06:19:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 94FA421F84E0; Mon, 15 Apr 2013 06:19:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FDJtkY012245; Mon, 15 Apr 2013 15:19:55 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FDJ96V026137; Mon, 15 Apr 2013 15:19:20 +0200 (CEST) Message-ID: <516BFE4D.70803@cisco.com> Date: Mon, 15 Apr 2013 15:19:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: draft-ietf-manet-olsrv2-mib@tools.ietf.org, Adrian Farrel Content-Type: multipart/alternative; boundary="------------060009030700000604090409" Cc: "pm-dir@ietf.org" , manet@ietf.org Subject: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:19:57 -0000 This is a multi-part message in MIME format. --------------060009030700000604090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a performance metric directorate point of view. This draft doesn't contain any reference to RFC6390, but contains "performance metric". Hence this review was triggered. For details about the directorate, see http://www.ietf.org/iesg/directorate/performance-metrics.html Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 Abstract This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information,performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. Basically, all performance metrics come from this table: o olsrv2InterfacePerfTable - records performance counters for each active OLSRv2 interface on this device. selected path to each destination for which any such path is known. This table has AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via nhdpIfIndex from the NHDP-MIB. NHDP-MIB is RFC 6779: NhdpInterfacePerfEntry ::= SEQUENCE { nhdpIfHelloMessageXmits Counter32, nhdpIfHelloMessageRecvd Counter32, nhdpIfHelloMessageXmitAccumulatedSize Counter64, nhdpIfHelloMessageRecvdAccumulatedSize Counter64, nhdpIfHelloMessageTriggeredXmits Counter32, nhdpIfHelloMessagePeriodicXmits Counter32, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount Counter32 } This draft contains similar objects in olsrv2InterfacePerfTable : Olsrv2InterfacePerfEntry ::= SEQUENCE { olsrv2IfTcMessageXmits Counter32, olsrv2IfTcMessageRecvd Counter32, olsrv2IfTcMessageXmitAccumulatedSize Counter64, olsrv2IfTcMessageRecvdAccumulatedSize Counter64, olsrv2IfTcMessageTriggeredXmits Counter32, olsrv2IfTcMessagePeriodicXmits Counter32, olsrv2IfTcMessageForwardedXmits Counter32, olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount Counter32 } Personally, I don't believe that those objects should be subject to the RFC 6390 template definition. (Performance Metric Definition Template, section 5.4.4, RFC 6390). First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not subject to it Second reason: these objects are not really performance metrics, but mainly basic monitoring objects. Since RFC 6779 uses the term performance information (in the abstract), I would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not the "performance metric". That would avoid some confusion. However, keeping the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency reason with RFC 6779. Regards, Benoit --------------060009030700000604090409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a performance metric directorate point of view.

This draft doesn't contain any reference to RFC6390, but contains "performance metric". Hence this review was triggered. For details about the directorate, see http://www.ietf.org/iesg/directorate/performance-metrics.html
 
Definition of Managed Objects for the  Optimized Link State Routing 
Protocol version 2 

Abstract

   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into state information, performance metrics, and notifications.  This
   additional state and performance information is useful to
   troubleshoot problems and performance issues of the routing protocol.
   Different levels of compliance allow implementers to use smaller
   subsets of all defined objects, allowing for this MIB module to be
   deployed on more constrained routers.

Basically, all performance metrics come from this table:
   o  olsrv2InterfacePerfTable - records performance counters for each
      active OLSRv2 interface on this device. selected path to each
      destination for which any such path is known.  This table has
      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
      nhdpIfIndex from the NHDP-MIB.

NHDP-MIB is RFC 6779:
   NhdpInterfacePerfEntry ::=
      SEQUENCE {
         nhdpIfHelloMessageXmits
            Counter32,
         nhdpIfHelloMessageRecvd
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSize
            Counter64,
         nhdpIfHelloMessageRecvdAccumulatedSize
            Counter64,
         nhdpIfHelloMessageTriggeredXmits
            Counter32,
         nhdpIfHelloMessagePeriodicXmits
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
            Counter32
      }

This draft contains similar objects in olsrv2InterfacePerfTable :
    Olsrv2InterfacePerfEntry ::=
       SEQUENCE {
          olsrv2IfTcMessageXmits
             Counter32,
          olsrv2IfTcMessageRecvd
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedSize
             Counter64,
          olsrv2IfTcMessageRecvdAccumulatedSize
             Counter64,
          olsrv2IfTcMessageTriggeredXmits
             Counter32,
          olsrv2IfTcMessagePeriodicXmits
             Counter32,
          olsrv2IfTcMessageForwardedXmits
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
             Counter32
       }

Personally, I don't believe that those objects should be subject to the RFC 6390 template definition. (Performance Metric Definition Template, section 5.4.4, RFC 6390).
First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not subject to it
Second reason: these objects are not really performance metrics, but mainly basic monitoring objects.

Since RFC 6779 uses the term performance information (in the abstract), I would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not the "performance metric". That would avoid some confusion. However, keeping the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency reason with RFC 6779.

Regards, Benoit


    

  


--------------060009030700000604090409--

From yi.jiazi@gmail.com  Mon Apr 15 08:20:52 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F821F93A9 for ; Mon, 15 Apr 2013 08:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.97
X-Spam-Level: *
X-Spam-Status: No, score=1.97 tagged_above=-999 required=5 tests=[AWL=5.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXqysZZ5erut for ; Mon, 15 Apr 2013 08:20:51 -0700 (PDT)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6951721F8F4A for ; Mon, 15 Apr 2013 08:20:51 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f11so280534wgh.27 for ; Mon, 15 Apr 2013 08:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=o5AoKbVVaSwTMxFNZYlxd/DacU8QxBmXifE8PAc2FMA=; b=R4ssqmCi/a+vYRkxqOe3dJtBlr2h4vO36stOpMIir0lJWYA4/zRB0j99NYu4PwHMJK y+gWKK9A3Z9aobXM4xi5vO9/qyfA9QbYjCrZbqVZWTz7yEvECWpIZMcXIh6IOLrQ7kPC mmNuLFKkvv5zkQPXZlxJ6UHY8m1YxgGSZPP2a9b0vSuQViUAG/HEPHSH0t74JnCEzCnk 7VFpVR+ynPjKDReZwTScwHOdRLbbrSyjr7ccQybNuMIZx8byMZ/P9JePhYm8EJ+Mavpe a1dThfULakNE+Il3XLKZNWE7FA2fTRJIR9m777TMZhgIR4bED2cg4uQiKA8WKE1L5NfA 6Pag==
X-Received: by 10.180.104.197 with SMTP id gg5mr1129712wib.13.1366039250599; Mon, 15 Apr 2013 08:20:50 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id fz3sm377123wib.0.2013.04.15.08.20.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:20:49 -0700 (PDT)
Sender: Jiazi YI 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: <1365935567594-365223.post@n7.nabble.com>
Date: Mon, 15 Apr 2013 17:20:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1364740656964-363492.post@n7.nabble.com>  <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com>  <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>  <1365935567594-365223.post@n7.nabble.com>
To: "manet@ietf.org List" 
X-Mailer: Apple Mail (2.1503)
Subject: Re: [manet] LOADng Data Collection Cycle
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 15:20:52 -0000

Dear Ahmed,=20


On Apr 14, 2013, at 12:32 PM, Ahmed A. Elawamry =
 wrote:

> Hi Jiazi,
>=20
> Are these memory requirements (1987 C++ lines) for LOADng or =
LOADng-CTP? as
> i see from the publications, it provides better performance.

The Hitachi's C++ implementation is for LOADng. For the moment, only =
LIX's implementation is with LOADng-CTP.=20
There is no doubt that LOADng with CTP extension provides better =
performance than basic LOADng in sensor-to-root (or MP2P) scenarios.=20
In fact, the CTP extension for LOADng is fairly simple and =
straightforward. With my estimation, it needs probably 100~ lines of =
code.=20


>=20
> Also, Is the routing table for LOADng and LOADng-CTP are identical =
(have the
> same fields)?


Yes, the routing table is identical. The message used (RREQ/RREP) are =
the same.=20
The collection tree extension is designed to be compatible with LOADng - =
even the router without collection tree extension could join the =
collection tree (but performance won't be the same, of course).=20

best

Jiazi


On Apr 14, 2013, at 12:32 PM, Ahmed A. Elawamry =
 wrote:

> Hi Jiazi,
>=20
> Are these memory requirements (1987 C++ lines) for LOADng or =
LOADng-CTP? as
> i see from the publications, it provides better performance.
>=20
> Also, Is the routing table for LOADng and LOADng-CTP are identical =
(have the
> same fields)?
>=20
> Regards,
> Ahmed A. Elawamry=20
>=20
>=20
>=20
> -----
> Best Regards,
> Ahmed A. Elawamry
>=20
> --
> View this message in context: =
http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365223.=
html
> Sent from the IETF - manet mailing list archive at Nabble.com.
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From internet-drafts@ietf.org  Mon Apr 15 09:00:44 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592D921F8F50; Mon, 15 Apr 2013 09:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.95
X-Spam-Level: 
X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhlQMv4UYwLS; Mon, 15 Apr 2013 09:00:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB421F84CE; Mon, 15 Apr 2013 08:59:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
Message-ID: <20130415155915.4011.3274.idtracker@ietfa.amsl.com>
Date: Mon, 15 Apr 2013 08:59:15 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 16:00:49 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of t=
he IETF.

	Title           : Integrity Check Value and Timestamp TLV Definitions for =
Mobile Ad Hoc Networks (MANETs)
	Author(s)       : Ulrich Herberg
                          Thomas Heide Clausen
                          Christopher Dearlove
	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
	Pages           : 24
	Date            : 2013-04-15

Abstract:
   This document revises, extends and replaces RFC 6622.  It describes
   general and flexible TLVs for representing cryptographic Integrity
   Check Values (ICVs) and timestamps, using the generalized Mobile Ad
   Hoc Network (MANET) packet/message format defined in RFC 5444.  It
   defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
   for affixing ICVs and timestamps to a packet, a message, and one or
   more addresses, respectively.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Mon Apr 15 09:01:19 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC1021F958B; Mon, 15 Apr 2013 09:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.043
X-Spam-Level: 
X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwn1Mhyk6GW2; Mon, 15 Apr 2013 09:01:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 288E321F94D0; Mon, 15 Apr 2013 08:59:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
Message-ID: <20130415155952.4018.17726.idtracker@ietfa.amsl.com>
Date: Mon, 15 Apr 2013 08:59:52 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-sec-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 16:01:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of t=
he IETF.

	Title           : Integrity Protection for Control Messages in NHDP and OL=
SRv2
	Author(s)       : Ulrich Herberg
                          Christopher Dearlove
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-nhdp-olsrv2-sec-02.txt
	Pages           : 14
	Date            : 2013-04-15

Abstract:
   This document specifies integrity and replay protection for required
   implementation in the MANET Neighborhood Discovery Protocol (NHDP)
   and the Optimized Link State Routing Protocol version 2 (OLSRv2).
   This document specifies how an included integrity check value (ICV)
   and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
   OLSRv2 for countering a number of security threats.  The ICV TLV uses
   a SHA-256 based HMAC and one or more shared secret keys.  The
   timestamp TLV is based on POSIX time, and assumes that the clocks in
   all routers in the network can be synchronized with sufficient
   precision.  The mechanism in this specification can also be used for
   other MANET protocols using RFC5444.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-sec-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-olsrv2-sec-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ulrich@herberg.name  Mon Apr 15 09:25:48 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D151921F9404 for ; Mon, 15 Apr 2013 09:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5WJrqHoWeQo for ; Mon, 15 Apr 2013 09:25:45 -0700 (PDT)
Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id CA49D21F9418 for ; Mon, 15 Apr 2013 09:25:41 -0700 (PDT)
Received: by mail-vb0-f52.google.com with SMTP id w8so3890031vbf.39 for ; Mon, 15 Apr 2013 09:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=ERQrU5Q8veEONkbvsLv15C6asyT0BfrUPyTKuowg3s4=; b=IFNio8vV02jB67mvAkjvco7SCgDZg9iOSfzGdm4p99PToH8n3FZV2L40FpslagOCp8 u/nIXEBTmRq+YiozE8OlnrZb8DqnVazfytnd/xflfzzyH3nOXCOvunHyZ+dGH0dWShoC Ht182rsZA5CapxTIhXUTkkluxzFsVDvkWxVJQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=ERQrU5Q8veEONkbvsLv15C6asyT0BfrUPyTKuowg3s4=; b=MukVcIgca0cBjaQMBzcF7D0JP67lJw8oqZk/WRQevUelVxTI1VEyGEMb6Lz5b+1Q/B bCKTKmrFpfxZNHaj4K9tpzC+MQNlyQV6zVwK66BiHu/P/pxD5KysQP6Vra0F7UWZPGjV Lv7ya4zs9WFsasOwdq0y0xw6hG1zGwpnLCcMr5rzHS49qXGEzElCsRW9ZmcgomYLyDnj KIfinYSTYA7naPV1oP8T5uQIddhEr9tifd/vo4rDQtZu4cMWK+EKuGlJFwGQbE/guAC3 sOd7gkZGuYp05wWtbM0c0/ZptF8XUQY06j80H7jpOnP09iuY+AKZe3Bpsj4ZhkEUVlc4 0hJQ==
MIME-Version: 1.0
X-Received: by 10.52.24.229 with SMTP id x5mr14168354vdf.84.1366043140965; Mon, 15 Apr 2013 09:25:40 -0700 (PDT)
Received: by 10.220.190.137 with HTTP; Mon, 15 Apr 2013 09:25:40 -0700 (PDT)
Date: Mon, 15 Apr 2013 09:25:40 -0700
Message-ID: 
From: Ulrich Herberg 
To: bebemaster@gmail.com, manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkT9Sjmx4qc6CW0ZZuVNF2thAz/5be96Mw70nnofpzKalOtLo/mVe7PirHwFUVLfZIDBqSM
Subject: Re: [manet] rfc6622-bis-01 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 16:25:49 -0000

Justin,

thank you very much for your review. We just submitted new revisions
(of both RFC6622bis and nhdp-olsrv2-sec)
addressing your comments, as well as a suggestion from Henning to
allow for truncated ICVs (thanks, Henning!).

Several people in the WG have supported these documents on the list,
and I hope that we can initiate a WG LC very soon. Note that OLSRv2 is
blocked in the RFC editor as long as these documents are not finished.

See below for my answers to Justin's comments.

On Mon, Mar 25, 2013 at 2:01 PM, Justin Dean  wrote:
> Below I have included my comments in-line tagged with JD.  The new TLV
> subtype assignment confuses the issue of replacement of 6622.  Are there
> situations where ICV TLVs with subtype 1 as defined in 6622 are
>
> more appropriate?  My guess is No. In any case I shouldn't be guessing,
> so that should be made more clear.

We added some sentence to make this clearer. In particular, type
extension 1 *is not* obsoleted. Type extension 2 is used for also
protecting the IP source address, which is used by RFC6130. This works
only for 1-hop communication (e.g., HELLOs), not for TC messages.


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

We preferred replacing the document, as it makes it much easier to
read, instead of referencing the different sections that have changed.
Also, several references (e.g., to NIST documents) have been updated.
It would be tedious to update these references.


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

See above, this type is not "superior", and does not replace or
obsolete the type extension 1.


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

Please have a look at the latest revision. I first was of the same
opinion when we discussed that between the authors, but now I think
that this obsoletion of 6622 was the right step rather than saying
this updates section X, this paragraph is inserted between Y and Z of
6622 etc.

Note that we made many editorial improvements over 6622 as well.
These include clarifying that an HMAC is not just crypto(hash(data)),
proper handling of multivalue Address Block TLVs, and truncated ICVs,
and ensuring proper handling of an empty packet TLV block. None of
this would have been clear had we not been creating one document.

Further comments from me are prefixed with "UH>"

>
> simpler than two and this one really is more useful.
>
> Despite that and despite the number of comments below
> I do believe that with a few editorial changes the document should be
> moved forward.
>
>
>
> Mobile Ad hoc Networking (MANET)                              U. Herberg
> Internet-Draft                           Fujitsu Laboratories of America
> Obsoletes: 6622 (if approved)                                 T. Clausen
> Intended status: Standards Track                LIX, Ecole Polytechnique
> Expires: September 24, 2013                                  C. Dearlove
>                                                          BAE Systems ATC
>                                                           March 23, 2013
>
>
>           Integrity Check Value and Timestamp TLV Definitions
>                   for Mobile Ad Hoc Networks (MANETs)
>                     draft-ietf-manet-rfc6622-bis-01
>
> Abstract
>
>    This document extends and replaces RFC 6622.  It describes general
>    and flexible TLVs for representing cryptographic Integrity Check
>    Values (ICVs) (i.e., digital signatures or Message Authentication
>    Codes (MACs)) as well as timestamps, using the generalized Mobile Ad
>    Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>    defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>    for affixing ICVs and timestamps to a packet, a message, and an
>    address, respectively.
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on September 24, 2013.
>
> Copyright Notice
>
>    Copyright (c) 2013 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 1]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  Differences from RFC6622 . . . . . . . . . . . . . . . . .  3
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
>    4.  Security Architecture  . . . . . . . . . . . . . . . . . . . .  4
>    5.  Overview and Functioning . . . . . . . . . . . . . . . . . . .  5
>    6.  General ICV TLV Structure  . . . . . . . . . . . . . . . . . .  6
>    7.  General Timestamp TLV Structure  . . . . . . . . . . . . . . .  7
>    8.  Packet TLVs  . . . . . . . . . . . . . . . . . . . . . . . . .  7
>      8.1.  Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . .  7
>      8.2.  Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . .  8
>    9.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . .  8
>      9.1.  Message ICV TLV  . . . . . . . . . . . . . . . . . . . . .  8
>      9.2.  Message TIMESTAMP TLV  . . . . . . . . . . . . . . . . . .  9
>    10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . .  9
>      10.1. Address Block ICV TLV  . . . . . . . . . . . . . . . . . .  9
>      10.2. Address Block TIMESTAMP TLV  . . . . . . . . . . . . . . .  9
>    11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>    12. ICV: Hash Function and Cryptographic Function  . . . . . . . . 10
>      12.1. General ICV TLV Structure  . . . . . . . . . . . . . . . . 10
>        12.1.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . 11
>      12.2. Considerations for Calculating the ICV . . . . . . . . . . 11
>        12.2.1.  Packet ICV TLV  . . . . . . . . . . . . . . . . . . . 12
>        12.2.2.  Message ICV TLV . . . . . . . . . . . . . . . . . . . 12
>        12.2.3.  Address Block ICV TLV . . . . . . . . . . . . . . . . 12
>      12.3. Example of a Message Including an ICV  . . . . . . . . . . 12
>    13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
>      13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14
>      13.2. Packet TLV Type Registrations  . . . . . . . . . . . . . . 14
>      13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15
>      13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16
>      13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 17
>      13.6. Cryptographic Functions  . . . . . . . . . . . . . . . . . 18
>    14. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
>    15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
>    16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
>      16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
>      16.2. Informative References . . . . . . . . . . . . . . . . . . 21
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 2]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
> 1.  Introduction
>
>    This document, which extends and replaces [RFC6622], specifies:
>
> JD: This document extends and replaces [RFC6622].  It specifies:

UH> We changed that.


>
>    o  Two TLVs for carrying Integrity Check Values (ICVs) and timestamps
>       in packets, messages, and address blocks as defined by [RFC5444].
>
> JD: Two TLV structures; One for carrying Integrity Check Values (ICVs),
> and one for timestamps. TLV type assignments for packet, message and address
> block TLVs for these structures.

UH> We changed that (not quite like you suggested, but in a similar way)

>
>    o  A generic framework for ICVs, accounting (for Message TLVs) for
>       mutable message header fields ( and
>       ), where these fields are present in messages.
>
>    This document retains the IANA registries, defined in [RFC6622], for
>    recording code points for hash-functions, cryptographic functions,
>    and ICV calculations.  This document requests additional allocations
>    from these registries.
>
>    Moreover, in Section 12, this document defines the following:
>
>    o  A method for generating ICVs using a combination of a
>       cryptographic function and a hash function.
> JD: There is text in section 5 which should be moved to here.

UH> Please tell us if the new revision makes that clearer.

>
> 1.1.  Differences from RFC6622
>
>    This document obsoletes [RFC6622].  The changes introduced by this
>    document are, however, small.  In addition to editorial updates, this
>    document adds a new type extension for the ICV TLV that is specified
>    in Section 12 of this document.  The TLV value of a TLV with this
>    type extension has the same internal structure as a TLV with type
>    extension 1, but is calculated also over the source address of the IP
>    datagram carrying the packet, message, or address block.
>
>    The rationale for adding this type extension is that some MANET
>    protocols, such as [RFC6130] and [OLSRv2], use the IP source address
>    of the IP datagram carrying the packet, message or address block,
>    e.g., to identify links with neighbor routers.  If this address is
>    not otherwise contained in the packet, message, or address block
>    payload (which is permitted, e.g., in [RFC6130]), the address is not
>    protected against tampering.
>
> 2.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    [RFC2119].
>
>    This document uses the terminology and notation defined in [RFC5444].
>    In particular, the following TLV fields and notation from [RFC5444]
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 3]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    are used in this specification:
>
>      is the hop limit of a message, as specified in
>       Section 5.2 of [RFC5444].
>
>      is the hop count of a message, as specified in
>       Section 5.2 of [RFC5444].
>
>      is the length of the value field in a TLV in octets, as
>       specified in Section 5.4.1 of [RFC5444].
>
>    single-length  is the length of a single value in the value field in
>       a TLV in octets, as specified in Section 5.4.1 of [RFC5444].  (It
>       is equal to  except in a multivalue Address Block TLV.)
>
> 3.  Applicability Statement
>
>    MANET routing protocols using the format defined in [RFC5444] are
>    accorded the ability to carry additional information in control
>    messages and packets, through the inclusion of TLVs.  Information so
>    included MAY be used by a MANET routing protocol, or by an extension
>    of a MANET routing protocol, according to its specification.
>
>    This document specifies how to include an ICV for a packet, a
>    message, and addresses in address blocks within a message, using such
>    TLVs.  This document also specifies how to treat "mutable" fields,
>    specifically the  and  fields, if
>    present in the message header when calculating ICVs, such that the
>    resulting ICV can be correctly verified by any recipient.
>
>    This document describes a generic framework for creating ICVs, and
>    how to include these ICVs in TLVs.  In Section 12, an example method
>    for calculating such ICVs is given, using a cryptographic function
>    and a hash function.
>
> 4.  Security Architecture
>
>    Basic MANET routing protocol specifications are often "oblivious to
>    security"; however, they may have a clause allowing a control message
>    to be rejected as "badly formed" or "insecure" prior to the message
>    being processed or forwarded.  In particular, MANET routing protocols
>    such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
>    Optimized Link State Routing Protocol version 2 [OLSRv2] recognize
>    external reasons (such as failure to verify an ICV) for rejecting a
>    message that would be considered "invalid for processing".
>
>    This architecture is a result of the observation that with respect to
>    security in MANETs, "one size rarely fits all" and that MANET routing
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 4]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    protocol deployment domains have varying security requirements
>    ranging from "unbreakable" to "virtually none".  The virtue of this
>    approach is that MANET routing protocol specifications (and
>    implementations) can remain "generic", with extensions providing
>    proper security mechanisms specific to a deployment domain.
>
>    The MANET routing protocol "security architecture", in which this
>    specification situates itself, can therefore be summarized as
>    follows:
>
>    o  MANET routing protocol specifications, with a clause allowing an
>       extension to reject a message (prior to processing/forwarding) as
>       "badly formed" or "insecure".
>
>    o  MANET routing protocol security extensions, rejecting messages as
>       "badly formed" or "insecure", as appropriate for a given security
>       requirement specific to a deployment domain.
>
>    o  Code points and an exchange format for information, necessary for
>       specification of such MANET routing protocol security extensions.
>
>    This document addresses the last of the issues listed above by
>    specifying a common exchange format for cryptographic ICVs, making
>    reservations from within the Packet TLV, Message TLV, and Address
>    Block TLV registries of [RFC5444], to be used (and shared) among
>    MANET routing protocol security extensions.
>
>    For the specific decomposition of an ICV using a cryptographic
>    function and a hash function (specified in Section 12), this document
>    reports the two IANA registries from [RFC6622] for code points for
>    hash functions and cryptographic functions adhering to [RFC5444].
>
>    With respect to [RFC5444], this document is:
>
>    o  Intended to be used in the non-normative, but intended, mode of
>       use described in Appendix B of [RFC5444].
>
>    o  A specific example of the Security Considerations section of
>       [RFC5444] (the authentication part).
>
> 5.  Overview and Functioning
>
>    This document specifies a syntactical representation of security-
>    related information for use with [RFC5444] addresses, messages, and
>    packets, and also reports and updates IANA registrations (from
>    [RFC6622]) of TLV types and type extension registries for these TLV
>    types.
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 5]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    Moreover, this document provides guidelines for how MANET routing
>    protocols, and MANET routing protocol extensions using this
>    specification, should treat ICV and Timestamp TLVs, and mutable
>    fields in messages.  This specification does not represent a stand-
>    alone protocol; MANET routing protocols, and MANET routing protocol
>    extensions using this specification, MUST provide instructions as to
>    how to handle packets, messages, and addresses with security
>    information, associated as specified in this document.
> JD: The above paragraphs are to me clearer than the introduction on
> what the goal of this document is.  Specifically the statement
> "This specification does not represent a stand alone protocol" should
> be much more prominent than it currently is.

UH> Good point. I hope this is clearer now.

>
>    This document reports previously assigned TLV types (from [RFC6622])
>    from the registries defined for Packet, Message, and Address Block
>    TLVs in [RFC5444].  When a TLV type is assigned from one of these
>    registries, a registry for type extensions for that TLV type is
>    created by IANA.  This document reports and updates these type
>    extension registries, in order to specify internal structure (and
>    accompanying processing) of the  field of a TLV.
>
>    For example, and as defined in this document, an ICV TLV with type
>    extension = 0 specifies that the  field has no pre-defined
>    internal structure but is simply a sequence of octets.  An ICV TLV
>    with type extension = 1 specifies that the  field has a pre-
>    defined internal structure and defines its interpretation.  An ICV
>    TLV with type extension = 2 specifies a modified version of this
>    definition.  (Specifically, with type extension = 1 or type extension
>    = 2, the  field contains the result of combining a
>    cryptographic function and a hash function, calculated over the
>    contents of the packet, message or address block, with sub-fields
>    indicating which hash function and cryptographic function have been
>    used; this is specified in Section 12.  The difference between the
>    two type extensions is that the ICV TLV with type extension = 2 is
>    calculated also over the source address of the IP datagram carrying
>    the packet, message, or address block.)
> JD: Seems long winded without saying very much here.  Should type
> extension 1 still be used?  (No) Will it break anything? (No)

UH> See above, it is still used. And we hope the new revision is clearer
in that regards.

>
>    Other documents can request assignments for other type extensions; if
>    they do so, they MUST specify their internal structure (if any) and
>    interpretation.
>
> 6.  General ICV TLV Structure
>
>    The value of the ICV TLV is:
>
>        := 
>
>    where
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 6]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>      is a field, of  octets, which contains the
>       information to be interpreted by the ICV verification process, as
>       specified by the type extension.
>
>    Note that this does not stipulate how to calculate the 
>    nor the internal structure thereof, if any; such information MUST be
>    specified by the type extension for the ICV TLV type; see Section 13.
>    This document specifies three such type extensions -- one for ICVs
>    without pre-defined structures, and two for ICVs constructed
>    combining a cryptographic function and a hash function.
>
> 7.  General Timestamp TLV Structure
>
>    The value of the Timestamp TLV is:
>
>        := 
>
>    where:
>
>      is an unsigned integer field, of length , which
>       contains the timestamp.
>
>       Note that this does not stipulate how to calculate the
>        nor the internal structure thereof, if any; such
>       information MUST be specified by the type extension for the
>       TIMESTAMP TLV type; see Section 13.
>
>    A timestamp is essentially "freshness information".  As such, its
>    setting and interpretation are to be determined by the MANET routing
>    protocol, or MANET routing protocol extension, that uses the
>    timestamp and can, for example, correspond to a POSIX timestamp, GPS
>    timestamp, or a simple sequence number.
> JD: Some mention of difficulty of insuring time synchronization across a
> MANET and how it's out of scope of this document should be included.

UH> Done


>  8.  Packet TLVs
>
>    Two Packet TLVs are defined: one for including the cryptographic ICV
>    of a packet and one for including the timestamp indicating the time
>    at which the cryptographic ICV was calculated.
>
> 8.1.  Packet ICV TLV
>
>    A Packet ICV TLV is an example of an ICV TLV as described in
>    Section 6.
>
>    The following considerations apply:
>
>    o  Because packets as defined in [RFC5444] are never forwarded by
>       routers, no special considerations are required regarding mutable
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 7]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>       fields (e.g.,  and ), if present
>       within any messages in the packet, when calculating the ICV.
>
>    o  Any Packet ICV TLVs already present in the Packet TLV block MUST
>       be removed before calculating the ICV, and the Packet TLV block
>       size MUST be recalculated accordingly.  Removed ICV TLVs MUST be
>       restored after having calculated the ICV value.
>
> JD: More clearly specify what "remove" means.  I am assuming that the
> TLV block size or phastlv bit needs to be updated but that needs to be said.

UH> Good point, done.

>
>    The rationale for removing any Packet ICV TLV already present prior
>    to calculating the ICV is that several ICVs may be added to the same
>    packet, e.g., using different ICV functions.
>
> 8.2.  Packet TIMESTAMP TLV
>
>    A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described
>    in Section 7.  If a packet contains a TIMESTAMP TLV and an ICV TLV,
>    the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV,
>    in order to include it in the calculation of the ICV.
> JD: Shouldn't ALL packet TLVs (which are relevant for the ICV in question)
> other than ones listed as TCV TLVs be added before TCV TLVs are added?

UH> Text updated.


>
> 9.  Message TLVs
>
>    Two Message TLVs are defined: one for including the cryptographic ICV
>    of a message and one for including the timestamp indicating the time
>    at which the cryptographic ICV was calculated.
>
> 9.1.  Message ICV TLV
>
>    A Message ICV TLV is an example of an ICV TLV as described in
>    Section 6.  When determining the  for a message, the
>    following considerations MUST be applied:
>
>    o  The fields  and , if present, MUST
>       both be assumed to have the value 0 (zero) when calculating the
>       ICV.
>
>    o  Any Message ICV TLVs already present in the Message TLV block MUST
>       be removed before calculating the ICV, and the message size as
>       well as the Message TLV block size MUST be recalculated
>       accordingly.  Removed ICV TLVs MUST be restored after having
>       calculated the ICV value.
> JD: MUST be restored and size fields updated as well.  Also all relevant
> TLVs other than TCV TLVs must be added prior to TCV value calcuations.
>    The rationale for removing any Message ICV TLV already present prior
>    to calculating the ICV is that several ICVs may be added to the same
>    message, e.g., using different ICV functions.


UH> Done.


>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 8]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
> 9.2.  Message TIMESTAMP TLV
>
>    A Message TIMESTAMP TLV is an example of a Timestamp TLV as described
>    in Section 7.  If a message contains a TIMESTAMP TLV and an ICV TLV,
>    the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV,
>    in order to include it in the calculation of the ICV.
>
> 10.  Address Block TLVs
>
>    Two Address Block TLVs are defined: one for associating a
>    cryptographic ICV to an address and one for including the timestamp
>    indicating the time at which the cryptographic ICV was calculated.
>
> 10.1.  Address Block ICV TLV
>
>    An Address Block ICV TLV is an example of an ICV TLV as described in
>    Section 6.  The ICV is calculated over the address, concatenated with
>    any other values -- for example, any other Address Block TLV 
>    fields -- associated with that address.  A MANET routing protocol or
>    MANET routing protocol extension using Address Block ICV TLVs MUST
>    specify how to include any such concatenated attribute of the address
>    in the calculation and verification processes for the ICV.  When
>    determining the  for an address, the following
>    consideration MUST be applied:
>
>    o  If other TLV values are concatenated with the address for
>       calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs
>       already associated with the address.
>
>    The rationale for not concatenating the address with any ICV TLV
>    values already associated with the address when calculating the ICV
>    is that several ICVs may be added to the same address, e.g., using
>    different ICV functions.
> JD: It may be helpful to point out that a list of TLV values associated
> with and address will not likely exist as such within a packet.  This TCV
> is distinct from packet/message TCVs in this regard.


UH> Could you propose any concrete text? That would be helpful.


>
> 10.2.  Address Block TIMESTAMP TLV
>
>    An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as
>    described in Section 7.  If both a TIMESTAMP TLV and an ICV TLV are
>    associated with an address, the TIMESTAMP TLV  MUST be covered
>    when calculating the value of the ICV to be contained in the ICV TLV
>    value (i.e., concatenated with the associated address and any other
>    values as described in Section 10.1).
>
> 11.  ICV: Basic
>
>    The basic ICV, represented by way of an ICV TLV with type extension =
>    0, is a simple bit-field containing the cryptographic ICV.  This
>    assumes that the mechanism stipulating how ICVs are calculated and
>
>
>
> Herberg, et al.        Expires September 24, 2013               [Page 9]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    verified is established outside of this specification, e.g., by way
>    of administrative configuration or external out-of-band signaling.
>    Thus, the , when using type extension = 0, is
>
>        := 
>
>    where:
>
>      is an unsigned integer field, of length , which
>       contains the cryptographic ICV.
>
> 12.  ICV: Hash Function and Cryptographic Function
>
>    One common way of calculating an ICV is combining a cryptographic
>    function and a hash function applied to the content.  This
>    decomposition is specified in this section, using either type
>    extension = 1 or type extension = 2, in the ICV TLVs.
> JD: nix "using either type extension = 1 or type extension = 2, in the ICV
> TLVs"

UH> See above, we still use type extension = 1


> 12.1.  General ICV TLV Structure
>
>    The following data structure allows representation of a cryptographic
>    ICV, including specification of the appropriate hash function and
>    cryptographic function used for calculating the ICV:
>
>                     := 
>                                   
>                                   
>                                   
>                                   
>
>    where:
>
>      is an 8-bit unsigned integer field specifying the
>       hash function.
>
>      is an 8-bit unsigned integer field
>       specifying the cryptographic function.
>
>      is an 8-bit unsigned integer field specifying the
>       length of the  field in number of octets.  The value 0x00
>       is reserved for using a single pre-installed, shared key.
> JD: Functional change suggestion.  Might we reserve a small number of
> values similar to 0 but which may have different as yet to be determined
> meanings.

UH> We disagree with the proposed change. The key-id-length may have any
value, so reserving values for key-id-length would preclude using a
key-id field of that length. Also, the purpose is unclear ("yet to be
determined meaning")


> For example, use of a key provided out of bound such as a packet level
>
> "global" for this packet key for message TCV TLVs. Repeatedly providing a
> key seems like it may become cumbersome.
>      is a field specifying the key identifier of the key that
>       was used to calculate the ICV of the message, which allows unique
>       identification of different keys with the same originator.  It is
>       the responsibility of each key originator to make sure that
>       actively used keys that it issues have distinct key identifiers.
>       If  equals 0x00, the  field is not
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 10]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>       contained in the TLV, and a single pre-installed, shared key is
>       used.
>
>      is an unsigned integer field, whose length is  -
>        3 - , except in a multivslue Address Block TLV, in
>       which it is single-length - 3 - , and which
>       contains the cryptographic ICV.
>
>    The version of this TLV, specified in this section, assumes that,
>    unless otherwise specified, calculating the ICV can be decomposed
>    into:
>
>       ICV-value = cryptographic-function(hash-function(content))
>
>    In some cases a different combination of cryptographic function and
>    hash function may be specified.  This is the case for the HMAC
>    function, which is specified as defined in Section 13.6, using the
>    hash function twice.
>
>    The hash function and the cryptographic function correspond to the
>    entries in two IANA registries, which are reported by this
>    specification and are described in Section 13.
>
> 12.1.1.  Rationale
>
>    The rationale for separating the hash function and the cryptographic
>    function into two octets instead of having all combinations in a
>    single octet -- possibly as a TLV type extension -- is that adding
>    further hash functions or cryptographic functions in the future may
>    lead to a non-contiguous number space.
>
>    The rationale for not including a field that lists parameters of the
>    cryptographic ICV in the TLV is that, before being able to validate a
>    cryptographic ICV, routers have to exchange or acquire keys (e.g.,
>    public keys).  Any additional parameters can be provided together
>    with the keys in that bootstrap process.  It is therefore not
>    necessary, and would even entail an extra overhead, to transmit the
>    parameters within every message.  One implicitly available parameter
>    is the length of an ICV, which is  - 3 -  (or
>    single-length - 3 -  in a multivalue Address Block
>    TLV) and which depends on the choice of the cryptographic function.
>
> 12.2.  Considerations for Calculating the ICV
>
>    The considerations listed in the following subsections MUST be
>    applied when calculating the ICV for Packet, Message, and Address
>    Block ICV TLVs, respectively.
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 11]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
> 12.2.1.  Packet ICV TLV
>
>    When determining the  for a packet, with type extension =
>    1, the ICV is calculated over the fields ,
>    , , and -- if present --
>     (in that order), concatenated with the entire packet,
>    including the packet header, all Packet TLVs (other than Packet ICV
>    TLVs), and all included Messages and their message headers, in
>    accordance with Section 8.1.  When determining the  for a
>    packet, with type extension = 2, the same procedure is used, except
>    that the source address of the IP datagram carrying the packet is
>    also concatenated, in the first position, with the data used.
> JD: don't use concatenated use proceded by or followed by. Might also
> mention network byte ordering issues as at this point we are dealing with
> packets.

UH> Good point. Fixed.


>
> 12.2.2.  Message ICV TLV
>
>    When determining the  for a message, with type extension =
>    1, the ICV is calculated over the fields ,
>    , , and -- if present --
>     (in that order), concatenated with the entire message.  The
>    considerations in Section 9.1 MUST be applied.  When determining the
>     for a message, with type extension = 2, the same
>    procedure is used, except that the source address of the IP datagram
>    carrying the message is also concatenated, in the first position,
>    with the data used.
>
> 12.2.3.  Address Block ICV TLV
>
>    When determining the  for an address, block, with type
>    extension = 2, the ICV is calculated over the fields ,
>    , , and -- if present --
>     (in that order), concatenated with the address, and
>    concatenated with any other values -- for example, any other address
>    block TLV  that is associated with that address.  A MANET
>    routing protocol or MANET routing protocol extension using Address
>    Block ICV TLVs MUST specify how to include any such concatenated
>    attribute of the address in the verification process of the ICV.  The
>    considerations in Section 10.1 MUST be applied.  When determining the
>     for an address block, with type extension = 2, the same
>    procedure is used, except that the source address of the IP datagram
>    carrying the address block is also concatenated, in the first
>    position, with the data used.
> JD: Typo first mention of type extension = 2 should be =1. Seems like
> we should be able to specify a generalized method for including the values.
> Why not just specify that all address tlv type/value pairs associated with
> an
>
> address be included in order type.subtype order? Punting is fine but I don't
> see why it needs to be done.

UH> I hope the new text is clearer (and the typo is fixed)



> 12.3.  Example of a Message Including an ICV
>
>    The sample message depicted in Figure 1 is derived from Appendix D of
>    [RFC5444].  The message contains an ICV Message TLV, with the value
>    representing an ICV that is 16 octets long of the whole message, and
>    a key identifier that is 4 octets long.  The type extension of the
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 12]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    Message TLV is 1, for the specific decomposition of an ICV using a
>    cryptographic function and a hash function, as specified in
>    Section 12.
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | PV=0 |  PF=8  |    Packet Sequence Number     | Message Type  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | MF=15 | MAL=3 |      Message Length = 44      | Msg Orig Addr |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Message Originator Address (cont)       |   Hop Limit   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Hop Count   |    Message Sequence Number    | Msg TLV Block |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Length = 27   |     ICV       |  MTLVF = 144  |  MTLVExt = 1  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Value Len = 23 |   Hash Func   |  Crypto Func  |Key ID length=4|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          Key Identifier                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          ICV Value                            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          ICV Value (cont)                     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          ICV Value (cont)                     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          ICV Value (cont)                     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                     Figure 1: Example Message with ICV
>
> JD: Shouldn't we change this to type = 2 as that is the only "new" thing
> this document is specifying and encouraging?  Structure should stay the
> same.

UH> It does not really matter, as both type extensions are still used in
the document, and both have the same structure.


>
> 13.  IANA Considerations
>
>    This specification reports the following, originally specified in
>    [RFC6622]:
>
>    o  Two Packet TLV types, which have been allocated from the 0-223
>       range of the "Packet TLV Types" repository of [RFC5444], as
>       specified in Table 1.
>
>    o  Two Message TLV types, which have been allocated from the 0-127
>       range of the "Message TLV Types" repository of [RFC5444], as
>       specified in Table 2.
>
>    o  Two Address Block TLV types, which have been allocated from the
>       0-127 range of the "Address Block TLV Types" repository of
>       [RFC5444], as specified in Table 3.
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 13]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    This specification updates the following, created in [RFC6622]:
>
>    o  A type extension registry for each of these TLV types with values
>       as listed in Tables 1, 2, and 3.
>
>    The following terms are used as defined in [BCP26]: "Namespace",
>    "Registration", and "Designated Expert".
>
>    The following policy is used as defined in [BCP26]: "Expert Review".
>
> 13.1.  Expert Review: Evaluation Guidelines
>
>    For TLV type extensions registries where an Expert Review is
>    required, the Designated Expert SHOULD take the same general
>    recommendations into consideration as those specified by [RFC5444].
>
>    For the Timestamp TLV, the same type extensions for all Packet,
>    Message, and Address Block TLVs SHOULD be numbered identically.
>
> 13.2.  Packet TLV Type Registrations
>
>    IANA has, in accordance with [RFC6622], made allocations from the
>    "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs
>    specified in Table 1.  IANA are requested to modify this allocation
>    (defining type extension = 2) as indicated.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 14]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    +-----------+------+-----------+------------------------------------+
>    |    Name   | Type |    Type   |             Description            |
>    |           |      | Extension |                                    |
>    +-----------+------+-----------+------------------------------------+
>    |    ICV    |   5  |     0     |           ICV of a packet          |
>    |           |      |    1-2    |     ICV, using a cryptographic     |
>    |           |      |           |  function and a hash function, as  |
>    |           |      |           |   specified in Section 12 of this  |
>    |           |      |           |              document              |
>    |           |      |   3-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
>    |           |      |           |   length, given by the TLV Length  |
>    |           |      |           | field.  The MANET routing protocol |
>    |           |      |           |   has to define how to interpret   |
>    |           |      |           |           this timestamp           |
>    |           |      |     1     |    Unsigned 32-bit timestamp, as   |
>    |           |      |           |   specified in [IEEE 1003.1-2008   |
>    |           |      |           |              (POSIX)]              |
>    |           |      |     2     |  NTP timestamp format, as defined  |
>    |           |      |           |            in [RFC5905]            |
>    |           |      |     3     |    Signed timestamp of arbitrary   |
>    |           |      |           | length with no constraints such as |
>    |           |      |           |  monotonicity.  In particular, it  |
>    |           |      |           |   may represent any random value   |
>    |           |      |   4-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    +-----------+------+-----------+------------------------------------+
>
> JD: Mostly a style thing but dislike how 1-2 are included together.
> Suggest separating them out and indicating the difference
> (source IP address used).  Same suggestion for other IANA tables.

UH> We agree and changed that.


>                    Table 1: Packet TLV Types
>
>    More than one ICV Packet TLV with the same type extension MAY be
>    included in a packet if these represent different ICV calculations
>    (e.g., with type extension 1 or 2 and different cryptographic
>    function and/or hash function, or with a different key identifier).
>    ICV Packet TLVs that carry what is declared to be the same
>    information MUST NOT be included in the same packet.
>
> 13.3.  Message TLV Type Registrations
>
>    IANA has, in accordance with [RFC6622], made allocations from the
>    "Message TLV Types" namespace of [RFC5444] for the Message TLVs
>    specified in Table 2.  IANA are requested to modify this allocation
>    (defining type extension = 2) as indicated.
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 15]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    +-----------+------+-----------+------------------------------------+
>    |    Name   | Type |    Type   |             Description            |
>    |           |      | Extension |                                    |
>    +-----------+------+-----------+------------------------------------+
>    |    ICV    |   5  |     0     |          ICV of a message          |
>    |           |      |    1-2    |     ICV, using a cryptographic     |
>    |           |      |           |  function and a hash function, as  |
>    |           |      |           |   specified in Section 12 of this  |
>    |           |      |           |              document              |
>    |           |      |   3-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
>    |           |      |           |   length, given by the TLV Length  |
>    |           |      |           |               field.               |
>    |           |      |     1     |    Unsigned 32-bit timestamp, as   |
>    |           |      |           |   specified in [IEEE 1003.1-2008   |
>    |           |      |           |              (POSIX)]              |
>    |           |      |     2     |  NTP timestamp format, as defined  |
>    |           |      |           |            in [RFC5905]            |
>    |           |      |     3     |    Signed timestamp of arbitrary   |
>    |           |      |           | length with no constraints such as |
>    |           |      |           |  monotonicity.  In particular, it  |
>    |           |      |           |   may represent any random value   |
>    |           |      |   4-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    +-----------+------+-----------+------------------------------------+
>
>                         Table 2: Message TLV Types
>
>    More than one ICV Message TLV with the same type extension MAY be
>    included in a message if these represent different ICV calculations
>    (e.g., with type extension 1 or 2 and different cryptographic
>    function and/or hash function, or with a different key identifier).
>    ICV Message TLVs that carry what is declared to be the same
>    information MUST NOT be included in the same message.
>
> 13.4.  Address Block TLV Type Registrations
>
>    IANA has, in accordance with [RFC6622], made allocations from the
>    "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs
>    specified in Table 3.  IANA are requested to modify this allocation
>    (defining type extension = 2) as indicated.
>
>
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 16]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    +-----------+------+-----------+------------------------------------+
>    |    Name   | Type |    Type   |             Description            |
>    |           |      | Extension |                                    |
>    +-----------+------+-----------+------------------------------------+
>    |    ICV    |   5  |     0     |     ICV of an object (e.g., an     |
>    |           |      |           |              address)              |
>    |           |      |    1-2    |     ICV, using a cryptographic     |
>    |           |      |           |  function and a hash function, as  |
>    |           |      |           |   specified in Section 12 of this  |
>    |           |      |           |              document              |
>    |           |      |   3-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    | TIMESTAMP |   6  |     0     |   Unsigned timestamp of arbitrary  |
>    |           |      |           |   length, given by the TLV Length  |
>    |           |      |           |                field               |
>    |           |      |     1     |    Unsigned 32-bit timestamp, as   |
>    |           |      |           |   specified in [IEEE 1003.1-2008   |
>    |           |      |           |              (POSIX)]              |
>    |           |      |     2     |  NTP timestamp format, as defined  |
>    |           |      |           |            in [RFC5905]            |
>    |           |      |     3     |    Signed timestamp of arbitrary   |
>    |           |      |           | length with no constraints such as |
>    |           |      |           |  monotonicity.  In particular, it  |
>    |           |      |           |   may represent any random value   |
>    |           |      |   4-251   |      Unassigned; Expert Review     |
>    |           |      |  252-255  |          Experimental Use          |
>    +-----------+------+-----------+------------------------------------+
>
>                      Table 3: Address Block TLV Types
>
>    More than one ICV Address Block TLV with the same type extension MAY
>    be associated with an address if these represent different ICV
>    calculations (e.g., with type extension 1 or 2 and different
>    cryptographic function and/or hash function, or with a different key
>    identifier).  ICV Address Block TLVs that carry what is declared to
>    be the same information MUST NOT be associated with the same address.
>
> 13.5.  Hash Functions
>
>    IANA has, in accordance with [RFC6622], created a new registry for
>    hash functions that can be used when creating an ICV, as specified in
>    Section 12 of this document.  The initial assignments and allocation
>    policies are specified in Table 4.  This registry is unchanged by
>    this specification.
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 17]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    +-------------+-----------+-----------------------------------------+
>    |     Hash    | Algorithm |               Description               |
>    |   Function  |           |                                         |
>    |    Value    |           |                                         |
>    +-------------+-----------+-----------------------------------------+
>    |      0      |    none   | The "identity function": The hash value |
>    |             |           |    of an object is the object itself    |
>    |      1      |    SHA1   |            [NIST-FIPS-180-2]            |
>    |      2      |   SHA224  |         [NIST-FIPS-180-2-change]        |
>    |      3      |   SHA256  |            [NIST-FIPS-180-2]            |
>    |      4      |   SHA384  |            [NIST-FIPS-180-2]            |
>    |      5      |   SHA512  |            [NIST-FIPS-180-2]            |
>    |    6-251    |           |        Unassigned; Expert Review        |
>    |   252-255   |           |             Experimental Use            |
>    +-------------+-----------+-----------------------------------------+
>
>                       Table 4: Hash Function Registry
>
> 13.6.  Cryptographic Functions
>
>    IANA has, in accordance with [RFC6622], created a new registry for
>    the cryptographic functions, as specified in Section 12 of this
>    document.  Initial assignments and allocation policies are specified
>    in Table 5.  This registry is unchanged by this specification.
>
>    +----------------+-----------+--------------------------------------+
>    |  Cryptographic | Algorithm |              Description             |
>    | Function Value |           |                                      |
>    +----------------+-----------+--------------------------------------+
>    |        0       |    none   |  The "identity function": The value  |
>    |                |           |   of an encrypted hash is the hash   |
>    |                |           |                itself                |
>    |        1       |    RSA    |               [RFC3447]              |
>    |        2       |    DSA    |           [NIST-FIPS-186-3]          |
>    |        3       |    HMAC   |               [RFC2104]              |
>    |        4       |    3DES   |           [NIST-SP-800-67]           |
>    |        5       |    AES    |            [NIST-FIPS-197]           |
>    |        6       |   ECDSA   |           [ANSI-X9-62-2005]          |
>    |      7-251     |           |       Unassigned; Expert Review      |
>    |     252-255    |           |           Experimental Use           |
>    +----------------+-----------+--------------------------------------+
>
>                  Table 5: Cryptographic Function Registry
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 18]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
> 14.  Security Considerations
>
>    This document does not specify a protocol.  It provides a syntactical
>    component for cryptographic ICVs of messages and packets, as defined
>    in [RFC5444].  It can be used to address security issues of a MANET
>    routing protocol or MANET routing protocol extension.  As such, it
>    has the same security considerations as [RFC5444].
>
>    In addition, a MANET routing protocol or MANET routing protocol
>    extension that uses this specification MUST specify how to use the
>    framework, and the TLVs presented in this document.  In addition, the
>    protection that the MANET routing protocol or MANET routing protocol
>    extensions attain by using this framework MUST be described.
>
>    As an example, a MANET routing protocol that uses this component to
>    reject "badly formed" or "insecure" messages if a control message
>    does not contain a valid ICV SHOULD indicate the security assumption
>    that if the ICV is valid, the message is considered valid.  It also
>    SHOULD indicate the security issues that are counteracted by this
>    measure (e.g., link or identity spoofing) as well as the issues that
>    are not counteracted (e.g., compromised keys).
>
> 15.  Acknowledgements
>
>    The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE
>    Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan
>    (Ecole Polytechnique), and Henning Rogge (FGAN) for their
>    constructive comments on [RFC6622].
>
>    The authors also appreciate the detailed reviews of [RFC6622] from
>    the Area Directors, in particular Stewart Bryant (Cisco), Stephen
>    Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as
>    well as Donald Eastlake (Huawei) from the Security Directorate.
>
> 16.  References
>
> 16.1.  Normative References
>
>    [BCP26]                     Narten, T. and H. Alvestrand, "Guidelines
>                                for Writing an IANA Considerations
>                                Section in RFCs", BCP 26, RFC 5226,
>                                May 2008.
>
>    [RFC2119]                   Bradner, S., "Key words for use in RFCs
>                                to Indicate Requirement Levels", BCP 14,
>                                RFC 2119, March 1997.
>
>    [RFC5444]                   Clausen, T., Dearlove, C., Dean, J., and
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 19]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>                                C. Adjih, "Generalized Mobile Ad Hoc
>                                Network (MANET) Packet/Message Format",
>                                RFC 5444, February 2009.
>
>    [RFC5905]                   Mills, D., Martin, J., Ed., Burbank, J.,
>                                and W. Kasch, "Network Time Protocol
>                                Version 4: Protocol and Algorithms
>                                Specification", RFC 5905, June 2010.
>
>    [RFC3447]                   Jonsson, J. and B. Kaliski, "Public-Key
>                                Cryptography Standards (PKCS) #1: RSA
>                                Cryptography Specifications Version 2.1",
>                                RFC 3447, February 2003.
>
>    [RFC2104]                   Krawczyk, H., Bellare, M., and R.
>                                Canetti, "HMAC: Keyed-Hashing for Message
>                                Authentication", RFC 2104, February 1997.
>
>    [NIST-FIPS-197]             National Institute of Standards and
>                                Technology, "Specification for the
>                                Advanced Encryption Standard (AES)",
>                                FIPS 197, November 2001.
>
>    [NIST-FIPS-186-3]           National Institute of Standards and
>                                Technology, "Digital Signature Standard
>                                (DSS)", FIPS 186-3, June 2009.
>
>    [ANSI-X9-62-2005]           American National Standards Institute,
>                                "Public Key Cryptography for the
>                                Financial Services Industry: The Elliptic
>                                Curve Digital Signature Algorithm
>                                (ECDSA)", ANSI X9.62-2005, November 2005.
>
>    [NIST-SP-800-67]            National Institute of Standards and
>                                Technology, "Recommendation for the
>                                Triple Data Encryption Algorithm
>                                (TDEA) Block Cipher", Special
>                                Publication 800-67, May 2004.
>
>    [NIST-FIPS-180-2]           National Institute of Standards and
>                                Technology, "Specifications for the
>                                Secure Hash Standard", FIPS 180-2,
>                                August 2002.
>
>    [NIST-FIPS-180-2-change]    National Institute of Standards and
>                                Technology, "Federal Information
>                                Processing Standards Publication 180-2 (+
>                                Change Notice to include SHA-224)",
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 20]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>                                FIPS 180-2, August 2002.
>
>    [IEEE 1003.1-2008 (POSIX)]  IEEE Computer Society, "1003.1-2008
>                                Standard for Information Technology -
>                                Portable Operating System Interface
>                                (POSIX) Base Specifications, Issue 7",
>                                December 2008.
>
> 16.2.  Informative References
>
>    [RFC6130]                   Clausen, T., Dearlove, C., and J. Dean,
>                                "Mobile Ad Hoc Network (MANET)
>                                Neighborhood Discovery Protocol (NHDP)",
>                                RFC 6130, April 2011.
>
>    [RFC6622]                   Herberg, U. and T. Clausen, "Integrity
>                                Check Value and Timestamp TLV Definitions
>                                for Mobile Ad Hoc Networks (MANETs)",
>                                RFC 6622, May 2012.
>
>    [OLSRv2]                    Clausen, T., Dearlove, C., Jacquet, P.,
>                                and U. Herberg, "The Optimized Link State
>                                Routing Protocol version 2", Work
>                                in Progress, March 2012.
>
> Authors' Addresses
>
>    Ulrich Herberg
>    Fujitsu Laboratories of America
>    1240 E. Arques Ave.
>    Sunnyvale, CA  94085
>    USA
>
>    EMail: ulrich@herberg.name
>    URI:   http://www.herberg.name/
>
>
>    Thomas Heide Clausen
>    LIX, Ecole Polytechnique
>    91128 Palaiseau Cedex
>    France
>
>    Phone: +33 6 6058 9349
>    EMail: T.Clausen@computer.org
>    URI:   http://www.thomasclausen.org/
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 21]
>
> Internet-Draft      ICV and Timestamp TLVs for MANETs         March 2013
>
>
>    Christopher Dearlove
>    BAE Systems Advanced Technology Centre
>    West Hanningfield Road
>    Great Baddow, Chelmsford
>    United Kingdom
>
>    Phone: +44 1245 242194
>    EMail: chris.dearlove@baesystems.com
>    URI:   http://www.baesystems.com/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herberg, et al.        Expires September 24, 2013              [Page 22]
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From ulrich@herberg.name  Mon Apr 15 13:10:54 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C183521F9437 for ; Mon, 15 Apr 2013 13:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.828
X-Spam-Level: 
X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6yZM80R3G9G for ; Mon, 15 Apr 2013 13:10:54 -0700 (PDT)
Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id BF61921F9440 for ; Mon, 15 Apr 2013 13:10:53 -0700 (PDT)
Received: by mail-vb0-f53.google.com with SMTP id i3so4087571vbh.40 for ; Mon, 15 Apr 2013 13:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8hw7JsVb95sMHl7O4NtfnLeHtpN9nfL8L8nwww10aT8=; b=kHfuGWXaQtc/gfnKdAl+IG3edScFZuRNkQcC6rOI7NyRXd2LOWgC8Ohe4FZEWfaUu5 fRlOh+AOIqjDgOwj+mi0BXFZUrAfwgZwOtgiZHGS5hJMlrlY2R4yjIKKHGqG6aomx+3W By2BhWAs4j7IC2Z+sg7S37ZEaocaBDKullsEE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8hw7JsVb95sMHl7O4NtfnLeHtpN9nfL8L8nwww10aT8=; b=YFOOmIj/05th5YVt8r+xAJ5MhQzgM5O2LSJNZXPKSC9fz0tXXJng4oKxWzLXBuVXbb KbSvLQW3Bjvg/8l+Yxz+xTFLa+u0+7SWDZc2FQospKTbKnMR+1H6veYVNepDTsc8FKRo UAcQep86V9VvX94/08bn/KfXTJ/6uV4XaVP3HjAfVrSt5Q6rCk774J0dSeTUetHLnYBy NvEkpGVVon0RhkTE3A4s7S/JF4YrwMyhhIA43sWU/teDbewQwMDnab8KVsVoKVMfyvlZ I0H35iAL5w5b1/pcKOnqvslm0xjD+44ekhjaTVXrZ8HH83yzVHBxujJvg3THL0dcCdrk 7icg==
MIME-Version: 1.0
X-Received: by 10.52.176.38 with SMTP id cf6mr14659014vdc.132.1366056653063; Mon, 15 Apr 2013 13:10:53 -0700 (PDT)
Received: by 10.220.190.137 with HTTP; Mon, 15 Apr 2013 13:10:52 -0700 (PDT)
In-Reply-To: <516BFE4D.70803@cisco.com>
References: <516BFE4D.70803@cisco.com>
Date: Mon, 15 Apr 2013 13:10:52 -0700
Message-ID: 
From: Ulrich Herberg 
To: Benoit Claise 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQngOj27EmzWksrle4DEWzd/kuA2GXLux/YRghpWrifPXI1KS9gZvbJVLU4qDb+cGGZHKJno
Cc: "pm-dir@ietf.org" , manet@ietf.org, draft-ietf-manet-olsrv2-mib@tools.ietf.org
Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 20:10:54 -0000

Benoit,

thank you very much for this review. I agree that using the term
"performance information" instead of "performance metrics" is a good
idea. We will make the change.

Best regards
Ulrich

On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise  wrote:
> Dear all,
>
> I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
> performance metric directorate point of view.
>
> This draft doesn't contain any reference to RFC6390, but contains
> "performance metric". Hence this review was triggered. For details about the
> directorate, see
> http://www.ietf.org/iesg/directorate/performance-metrics.html
>
>
> Definition of Managed Objects for the  Optimized Link State Routing
> Protocol version 2
>
> Abstract
>
>    This document defines the Management Information Base (MIB) module
>    for configuring and managing the Optimized Link State Routing
>    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
>    into state information, performance metrics, and notifications.  This
>    additional state and performance information is useful to
>    troubleshoot problems and performance issues of the routing protocol.
>    Different levels of compliance allow implementers to use smaller
>    subsets of all defined objects, allowing for this MIB module to be
>    deployed on more constrained routers.
>
>
> Basically, all performance metrics come from this table:
>
>    o  olsrv2InterfacePerfTable - records performance counters for each
>       active OLSRv2 interface on this device. selected path to each
>       destination for which any such path is known.  This table has
>       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
>       nhdpIfIndex from the NHDP-MIB.
>
> NHDP-MIB is RFC 6779:
>    NhdpInterfacePerfEntry ::=
>       SEQUENCE {
>          nhdpIfHelloMessageXmits
>             Counter32,
>          nhdpIfHelloMessageRecvd
>             Counter32,
>          nhdpIfHelloMessageXmitAccumulatedSize
>             Counter64,
>          nhdpIfHelloMessageRecvdAccumulatedSize
>             Counter64,
>          nhdpIfHelloMessageTriggeredXmits
>             Counter32,
>          nhdpIfHelloMessagePeriodicXmits
>             Counter32,
>          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>             Counter32,
>          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>             Counter32,
>          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>             Counter32
>       }
>
>
> This draft contains similar objects in olsrv2InterfacePerfTable :
>
>     Olsrv2InterfacePerfEntry ::=
>        SEQUENCE {
>           olsrv2IfTcMessageXmits
>              Counter32,
>           olsrv2IfTcMessageRecvd
>              Counter32,
>           olsrv2IfTcMessageXmitAccumulatedSize
>              Counter64,
>           olsrv2IfTcMessageRecvdAccumulatedSize
>              Counter64,
>           olsrv2IfTcMessageTriggeredXmits
>              Counter32,
>           olsrv2IfTcMessagePeriodicXmits
>              Counter32,
>           olsrv2IfTcMessageForwardedXmits
>              Counter32,
>           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>              Counter32
>        }
>
>
> Personally, I don't believe that those objects should be subject to the RFC
> 6390 template definition. (Performance Metric Definition Template, section
> 5.4.4, RFC 6390).
> First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> subject to it
> Second reason: these objects are not really performance metrics, but mainly
> basic monitoring objects.
>
> Since RFC 6779 uses the term performance information (in the abstract), I
> would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
> the "performance metric". That would avoid some confusion. However, keeping
> the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
> reason with RFC 6779.
>
> Regards, Benoit
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From valerio.arnaboldi@iit.cnr.it  Tue Apr 16 07:02:04 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2105821F96C3 for ; Tue, 16 Apr 2013 07:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.481
X-Spam-Level: **
X-Spam-Status: No, score=2.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI71cM2ZVdLr for ; Tue, 16 Apr 2013 07:02:01 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85421F968C for ; Tue, 16 Apr 2013 07:02:01 -0700 (PDT)
Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by mxbk.iit.cnr.it (Postfix) with ESMTPA id 168C2C141B for ; Tue, 16 Apr 2013 16:02:00 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi
To: manet@ietf.org
Message-Id: <20130416140201.4C85421F968C@ietfa.amsl.com>
Date: Tue, 16 Apr 2013 07:02:01 -0700 (PDT)
Subject: [manet] IFIP SUSTAINIT 2013  - Deadline extended to May 3, 2013
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Apr 2013 14:02:04 -0000

Due to numerous requests, the manuscript submission deadline is extended to May 3, 2013.

-------------------------------------------------------------------
*** Our apologies if you receive multiple copies of this e-mail ***
-------------------------------------------------------------------

                          CALL FOR PAPERS

                          SustainIT 2013

                      The Third IFIP Conference on
            Sustainable Internet and ICT for Sustainability

           http://www.dicgim.unipa.it/networks/sustainit2013

                          October 30-31, 2012
                        Palermo, Sicily, Italy

 Sponsored by the IFIP TC6 WG 6.3, Performance of Communication Systems

           Technically co-sponsored by IEEE Computer Society
        Technical Committee on Computer Communications (TCCC)

           In cooperation with IEEE Communications Society
  Technical Subcommittee on Green Communications and Computing (TSGCC)

                            Supported by
          EINS: The Network of Excellence in Internet Science

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

           **** Paper Submission Deadline (EXTENDED!)--- MAY 3, 2013 ****    

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

The best paper presented at the conference will receive thSustainIT-2013-CfP-3-exte Best Paper Award. Papers of particular merit will be considered for a special section/issue in the Elsevier Journal of Computer Communications (COMCOM) and the Elsevier Journal of Pervasive and Mobile Computing (PMC).

SCOPE AND OVERVIEW 
------------------------------------------------------------------------

Today, energy efficiency is widely regarded as one of the biggest technological and societal challenges for developing a more sustainable world. The Internet - and more generally information and communication technologies (ICT) - can play an essential role to achieve a more sustainable energy use and to reduce our carbon footprint. On the one hand, Internet is a significant energy consumer, and it is necessary to redesign current Internet technologies, as well as network architectures, devices and components, services and protocols to improve energy efficiency. On the other hand, ICT is a key enabling technology to foster a more intelligent use of energy in areas such as buildings, transport and electric grids. 

Both aspects of the problem raise interesting scientific challenges, and require a comprehensive effort and inter-disciplinary research at all levels of abstraction. The goal of this conference is to bring together people from different research areas, and provide a forum to exchange ideas, discuss solutions, and share experiences among researchers, professionals, and application developers both from industry and academia.

Original papers addressing both theoretical and practical aspects of energy-awareness for Internet-based systems, and the design of ICT solutions for eco-sustainability are solicited.

Topics of interest include but are not limited to:

- Green Internet
- Power-aware Internet applications
- Energy-efficient network architecture and protocols 
- Green wireless networking
- Energy-efficient network technologies
- Cross-layer optimization for green networking
- Standards and metrics for green communications
- Energy-efficient management of network resources 
- Energy efficiency in data centres 
- Energy efficiency, Quality of Service, and reliability
- Algorithms for reduced power, energy and heat
- Data processing in smart energy systems
- ICT for energy efficiency in smart homes and buildings
- ICT for sustainable smart cities 
- ICT for sustainable transports and logistics
- ICT for green mobility
- ICT for energy efficiency in industrial environments
- ICT for smart grids
- Security and privacy in ICT for energy systems
- Sustainability achievements due to ICT-based optimization 
- Energy consumption measurements, models, and monitoring tools
- Measurement and evaluation of the Internet sustainability
- Test-bed and prototype implementations



PAPER SUBMISSION
------------------------------------------------------------------------
All submissions must describe original research, not published or currently under review for another workshop, conference, or journal.

Papers must be submitted electronically in PDF format through EDAS. Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Manuscripts must be limited to 9 pages, single spacing, double column, and must STRICTLY adhere to the template format. Detailed instructions for manuscript preparation and submission are available on the conference website (http://www.dicgim.unipa.it/networks/sustainit2013/submission.html).

*************************************************************************
Submission implies the willingness of, at least, one author to register and attend the conference to present the paper. The organizers reserve the right to exclude a paper from distribution after the conference if the paper is not presented at the conference.

*************************************************************************


IMPORTANT DATES
------------------------------------------------------------------------
- Paper registration deadline (EXTENDED):     May 3, 2013
- Paper submission deadline (EXTENDED):       May 3, 2013
- Acceptance/Reject notification:             June 30, 2013
- Camera-ready version due:                   July 30, 2013


ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
  Giuseppe Lo Re, University of Palermo, Italy
  Sajal K. Das, University of Texas at Arlington, USA  

PROGRAM CO-CHAIRS
  Raffaele Bruno, IIT-CNR, Italy
  Thierry Klein, Bell Labs, USA

STEERING COMMITTEE
  Marco Conti (Chair), IIT-CNR, Italy
  Giuseppe Anastasi, University of Pisa, Italy
  Jon Crowcroft, University of Cambridge, UK
  Thierry Klein, Bell Labs, USA

INDUSTRIAL TRACK CO-CHAIRS
  Cristina Bueti, ITU-T: Environment & Climate Change, Switzerland
  Luca Valcarenghi, SSUP, Italy

PUBLICITY CHAIR
  Valerio Arnaboldi, IIT-CNR, Italy


TECHNICAL PROGRAM COMMITTEE
  Marco Ajmone Marsan, Politecnico di Torino, Italy
  Lachlan Andrew, Swinburne University of Technology, Australia
  Sujata Banerjee, Hewlett-Packard Laboratories, USA
  Jiannong Cao, Hong Kong Polytechnic University, Hong Kong
  Antonio Capone, Politecnico di Milano, Italy
  Franco Davoli, University of Genoa, Italy
  Jose de Souza, Federal University of Ceara, Brazil
  Jaafar Elmirghani, University of Leeds, UK
  Sebastia Galmes, Universitat de les Illes Balears, Spain
  Andres Garcia-Saavedra, Universidad Carlos III de Madrid, Spain
  Isabelle Guerin Lassous, Universite de Lyon - LIP, France
  Rune Gustavsson, Royal Institute of Technology (KTH), Sweden
  Helmut Hlavacs, University of Vienna, Austria
  Karin Hummel, ETH Zurich, Switzerland
  David Hutchison, Lancaster University, UK
  Krishna Kant, George Mason University, USA
  Bart Lannoo, Ghent University - iMind, Belgium
  Laurent Lefevre, INRIA, France
  Francesco Marcelloni, University of Pisa, Italy
  Alan Marchiori, United Technologies Research Center, USA
  Enzo Mingozzi, University of Pisa, Italy
  Daniele Miorandi, Create-Net, Italy
  Archan Misra, Singapore Management University, Singapore
  Sandor Molnar, Budapest University of Technology and Economics, Hungary
  Inder Monga, Energy Sciences Network, USA
  Bruce Nordman, Lawrence Berkeley National Laboratory, USA
  Andrea Passarella, IIT-CNR, Italy
  Jean-Marc Pierson, University Paul Sabatier, France
  Andreas Pitsillides, University of Cyprus, Cyprus
  Daniele Puccinelli, SUPSI, Switzerland
  Pedro Reviriego, Universidad Antonio de Nebrija, Spain
  Behrooz Shirazi, Washington State University
  Domenico Talia, Universita' della Calabria, Italy
  Luca Valcarenghi, Scuola Superiore Sant'Anna, Italy
  Adam Wolisz, Technical University of Berlin, Germany
  Weigang Wu, Sun Yat-sen University, China
  Moshe Zukerman, City University of Hong Kong, Hong Kong
  Gil Zussman, Columbia University, USA

CONTACTS
------------------------------------------------------------------------
For further information, please visit the conference website (http://www.dicgim.unipa.it/networks/sustainit2013), or send an e-mail message to sustainit2013@unipa.it.




From emmanuel.baccelli@inria.fr  Tue Apr 16 08:27:14 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7921F9776 for ; Tue, 16 Apr 2013 08:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.248
X-Spam-Level: 
X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU3HC29Rm2mZ for ; Tue, 16 Apr 2013 08:27:13 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id B56A821F9775 for ; Tue, 16 Apr 2013 08:27:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,486,1363129200"; d="scan'208,217";a="13535355"
Received: from zmbs1.inria.fr ([128.93.142.14]) by mail2-relais-roc.national.inria.fr with ESMTP; 16 Apr 2013 17:27:11 +0200
Date: Tue, 16 Apr 2013 17:27:11 +0200 (CEST)
From: Emmanuel Baccelli 
To: manet@ietf.org
Message-ID: <2003007123.14474108.1366126031458.JavaMail.root@inria.fr>
In-Reply-To: <1513188775.8093110.1364460942718.JavaMail.root@inria.fr>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_14474107_1420701267.1366126031457"
X-Originating-IP: [194.116.79.226]
X-Mailer: Zimbra 7.2.2_GA_2857 (ZimbraWebClient - SAF3 (Mac)/7.2.2_GA_2852)
Subject: [manet] Reminder - MANIAC Challenge 2013 - Call for Papers/Hacking
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Apr 2013 15:27:14 -0000

------=_Part_14474107_1420701267.1366126031457
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

(apologies in advance for potential cross-postings)=20

-----------------=20

Folks,=20

You like to work on mobile ad hoc networking?=20
You like to code?=20
You like to compete?=20
Join us and consider the following Call for Papers and Hacking!=20

** Call for Short Papers for the 3rd MANIAC Challenge **=20

Co-located with the 87th IETF meeting in Berlin, Germany=20
July 27 - August 2, 2013=20

http://2013.maniacchallenge. org=20

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

The MANIAC Challenge is a competition to better understand cooperation and=
=20
interoperability in ad hoc networks. Competing teams students/researchers=
=20
come together to form a wireless ad hoc network, while simultaneously=20
connected to a backbone of access points. The organizers will generate=20
traffic coming from the backbone, destined to somewhere in the network. A=
=20
hop-by-hop bidding contest decides the path of each data packet towards its=
=20
destination.=20

Each team usually consists of two to three people. Teams will be judged=20
based on how much of the traffic they relay gets to its destination. To get=
=20
their traffic across the network, each team must rely on other teams=20
willingness to forward traffic for them. We have developed software and an=
=20
API over Android to allow teams to program their nodes, in particular=20
override forwarding decisions made by the routing protocol and participate=
=20
in the hop-by-hop bidding contest.=20

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

The specific focus of the MANIAC Challenge 2013 is on developing and=20
comparatively evaluating strategies to offload infrastructure access points=
=20
via customer ad hoc forwarding using handhelds (e.g., smartphones,=20
tablets). The incentive for customers is discounted monthly fees, and the=
=20
incentive for operators is decreased infrastructure costs. The idea is to=
=20
demonstrate scenarios/strategies that do not degrade user experience while=
=20
offering significant mobile offloading on the infrastructure.=20
Details about the scenario and competition rules are available at=20
http://2013.maniacchallenge. org/rules-setup .=20

----------=20
Submission=20
----------=20

We solicit the submission of short papers (max. 2 pages IEEE double-column=
=20
format) describing strategies for mobile offloading. After being=20
peer-reviewed, authors of selected submissions will be invited to=20
participate in the MANIAC Challenge and to attend the IETF meeting. We=20
highly encourage authors to continue the development of the offloading=20
strategy during the review time.=20

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

-------------=20
Participation=20
-------------=20

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

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

Each participant will then concurrently run its strategy during the=20
contest, taking place on July 27th at the Freie Universit=E4t Berlin. The=
=20
following day, a workshop will take place at the IETF venue, where we will=
=20
summarize and discuss the results of the contest.=20

The winners of the MANIAC Challenge 2013 will be announced during the IRTF=
=20
Open Meeting, which is part of the IETF/IRTF week with high visibility. The=
=20
IRTF Open Meeting usually will be attended by more than 100 experts from=20
industry and academia working on Internet Engineering.=20

Winners will take home some prizes to be determined with sponsors. Competin=
g=20
teams will be provided complimentary IETF registration enabling them to att=
end=20
the 87th IETF meeting in Berlin, July 28 - August 2nd.=20

Details about the submission and participation are available at=20
http://2013.maniacchallenge. org/participation/=20

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

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

---------------=20
Important Dates=20
---------------=20
- Deadline for short paper submission: May 5, 2013=20
- Notification of acceptance: May 12, 2013=20
- Release of API and software: May 12, 2013=20
- MANIAC challenge dates: July 27 - 28, 2013=20
- IETF/IRTF meeting: July 28 - August 2, 2013=20

----------------=20
MANIAC Co-Chairs=20
----------------=20

- Emmanuel Baccelli (INRIA)=20
- Oliver Hahm (INRIA)=20
- Felix Juraschek (Freie Universit=E4t Berlin)=20
- Thomas Schmidt (HAW Hamburg)=20
- Heiko Will (Freie Universit=E4t Berlin)=20
- Matthias W=E4hlisch (Freie Universit=E4t Berlin)=20

-------=20
Contact=20
-------=20
For questions, please contact maniac2013@lists.fu- berlin.de=20

------=_Part_14474107_1420701267.1366126031457
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<=
div style=3D'font-family: times new roman,new york,times,serif; font-size: =
12pt; color: #000000'>
(=
apologies in advance for potential cross-postings)

-----------------<=
br>
Folks,

You like to work on mobile ad hoc networking?
You l=
ike to code?
You like to compete?
Join us and consider the following =
Call for Papers and Hacking!


        ** &nbs=
p;Call for Short Papers for the 3rd MANIAC Challenge  **

 =
        Co-located with the 87th IETF meeting in Berlin=
, Germany
                 =
     July 27 - August 2, 2013

        =
         http://2013.mania=
cchallenge.org

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

The MANIAC Challenge is =
a competition to better understand cooperation and
interoperability in a=
d hoc networks. Competing teams students/researchers
come together to fo=
rm a wireless ad hoc network, while simultaneously
connected to a backbo=
ne of access points. The organizers will generate
traffic coming from th=
e backbone, destined to somewhere in the network. A
hop-by-hop bidding c=
ontest decides the path of each data packet towards its
destination.
=

Each team usually consists of two to three people. Teams will be judged=

based on how much of the traffic they relay gets to its destination. To=
 get
their traffic across the network, each team must rely on other team=
s
willingness to forward traffic for them. We have developed software an=
d an
API over Android to allow teams to program their nodes, in particul=
ar
override forwarding decisions made by the routing protocol and partic=
ipate
in the hop-by-hop bidding contest.

------------------------=
------------------------
Topic of 3rd MANIAC Challenge: Mobile Offl=
oading
------------------------------------------------

The =
specific focus of the MANIAC Challenge 2013 is on developing and
compara=
tively evaluating strategies to offload infrastructure access points
via=
 customer ad hoc forwarding using handhelds (e.g., smartphones,
tablets)=
. The incentive for customers is discounted monthly fees, and the
incent=
ive for operators is decreased infrastructure costs. The idea is to
demo=
nstrate scenarios/strategies that do not degrade user experience while
o=
ffering significant mobile offloading on the infrastructure.
Details abo=
ut the scenario and competition rules are available at
http://2013.maniacchallenge.org/rules-setup.
=

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

We solicit the submission=
 of short papers (max. 2 pages IEEE double-column
format) describing str=
ategies for mobile offloading. After being
peer-reviewed, authors of sel=
ected submissions will be invited to
participate in the MANIAC Challenge=
 and to attend the IETF meeting. We
highly encourage authors to continue=
 the development of the offloading
strategy during the review time.
<=
br>Please, submit your short paper via email to maniac2013@lists.fu-berlin.de.

-------------
Parti=
cipation
-------------

Author participation will consist in atten=
ding the MANIAC Challenge in
Berlin, Germany, July 27 - 28, 2013. Author=
s are also invited to attend the
IETF/IRTF meeting July 28 - August 2, 2=
013. Participation in the MANIAC
Challenge is free of charge. Registrati=
on costs (at full-time student rate)
for the IETF/IRTF meeting are spons=
ored by ISOC.

Authors bring an implementation of the strategy descri=
bed in the paper
submitted by the author, running on the common API and =
the common hardware
used for the event: the Nexus 7 tablet. The MANIAC A=
PI and software will be
released with the notification of acceptance. Ha=
rdware will be provided by
the organizers if necessary.

Each part=
icipant will then concurrently run its strategy during the
contest, taki=
ng place on July 27th at the Freie Universit=E4t Berlin. The
following d=
ay, a workshop will take place at the IETF venue, where we will
summariz=
e and discuss the results of the contest.

The winners of the MANIAC =
Challenge 2013 will be announced during the IRTF
Open Meeting, which is =
part of the IETF/IRTF week with high visibility. The
IRTF Open Meeting u=
sually will be attended by more than 100 experts from
industry and acade=
mia working on Internet Engineering.

Winners will take home some pri=
zes to be determined with sponsors. Competing
teams will be provided com=
plimentary IETF registration enabling them to attend
the 87th IETF meeti=
ng in Berlin, July 28 - August 2nd.

Details about the submission and=
 participation are available at
ht=
tp://2013.maniacchallenge.org/participation/


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

If you are interested in the MANI=
AC Challenge 2013, please subscribe to
the mailing list maniac2013-info@lists.fu-berlin.de. We will =
inform you
about updates.
https://lists.fu-berlin.de/listinfo/maniac2013-info#sub=
scribe

---------------
Important Dates 
-------------=
--
 -  Deadline for short paper submission: May 5, 2013 <=
br> -  Notification of acceptance: May 12, 2013 
 - =
 Release of API and software: May 12, 2013
 -  MANIAC cha=
llenge dates: July 27 - 28, 2013 
 -  IETF/IRTF meeting: =
July 28 - August 2, 2013

----------------
MANIAC Co-Chairs <=
br>----------------

 - Emmanuel Baccelli (INRIA)
 - Oli=
ver Hahm (INRIA)
 - Felix Juraschek (Freie Universit=E4t Berlin) - Thomas Schmidt (HAW Hamburg)
 - Heiko Will (Freie Universi=
t=E4t Berlin)
 - Matthias W=E4hlisch (Freie Universit=E4t Berlin)
-------
Contact
-------
For questions, please contact <=
a href=3D"mailto:maniac2013@lists.fu-berlin.de" target=3D"_blank" style=3D"=
color: rgb(17, 85, 204); ">maniac2013@lists.fu-berlin.de



------=_Part_14474107_1420701267.1366126031457--

From ahmed_awamry_86@yahoo.com  Sat Apr 20 23:52:35 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F061821F874E for ; Sat, 20 Apr 2013 23:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.187
X-Spam-Level: *
X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FORGED_YAHOO_RCVD=2.297]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-Vj829mlSog for ; Sat, 20 Apr 2013 23:52:35 -0700 (PDT)
Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5987D21F86F0 for ; Sat, 20 Apr 2013 23:52:35 -0700 (PDT)
Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UTo8Y-0005RH-VZ for manet@ietf.org; Sat, 20 Apr 2013 23:52:34 -0700
Date: Sat, 20 Apr 2013 23:52:34 -0700 (PDT)
From: "Ahmed A. Elawamry" 
To: manet@ietf.org
Message-ID: <1366527154968-365958.post@n7.nabble.com>
In-Reply-To: 
References: <1364740656964-363492.post@n7.nabble.com>  <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com>  <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>  <1365935567594-365223.post@n7.nabble.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [manet] LOADng Data Collection Cycle
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Apr 2013 06:52:36 -0000

Hi,

Please i have a question about end-to-end delay. Why the end-to-end delay of
AODV is lower than LOADng (at higher number of nodes) although LOADng has
lower overhead?.

Regards,
Ahmed A. Elawamry



-----
Best Regards,
Ahmed A. Elawamry

--
View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365958.html
Sent from the IETF - manet mailing list archive at Nabble.com.

From yi.jiazi@gmail.com  Mon Apr 22 03:14:32 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E784421F8EC1 for ; Mon, 22 Apr 2013 03:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw-Qfpe5DCQI for ; Mon, 22 Apr 2013 03:14:32 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E921F8EB2 for ; Mon, 22 Apr 2013 03:14:31 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id l13so4019415wie.0 for ; Mon, 22 Apr 2013 03:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=WXAbBTakEZD6JQzI33471Z5CfxXDFBNhq36EZiQJQ3o=; b=GHt/zbeSL+3qdW1kM/cbyoSHvpxNAfmRyPruavfUhspRCkFlvhs7CnShlQwAt901dP AnVI/Csp8HKnGaqqMtShjWcB8RdZwQPGRv7jpbODM0dzM0G+YqJc+nr8YtdCHGYQBDh4 5h+i/7A04yMIFRVF/2wfOaE9v/VqIHkzmLMMpdnpjjlbQJQ7kJAlBNGCg4OSzzQqyW9k cnRUusQFeYkTPc6F/zSfr80yqQaTaqG1a8hob+bLF7Ec2VzMItNTdRutH2Wro16+lX11 V/nVaW/PjhUL64jeCmRqLZKlg8aoIARleZZNXEQm6iFOI3PGdtT6BD6rWOEnFTGcr+xF 5YQQ==
X-Received: by 10.194.92.176 with SMTP id cn16mr32655101wjb.51.1366625660930;  Mon, 22 Apr 2013 03:14:20 -0700 (PDT)
Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPSA id ek4sm19033192wib.11.2013.04.22.03.14.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 03:14:20 -0700 (PDT)
Sender: Jiazi YI 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: <1366527154968-365958.post@n7.nabble.com>
Date: Mon, 22 Apr 2013 12:14:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E898A4C-4484-4005-95AD-CB81B6CD4773@jiaziyi.com>
References: <1364740656964-363492.post@n7.nabble.com>  <1365021754.6552.YahooMailNeo@web122302.mail.ne1.yahoo.com>  <588429BA-0EB4-446B-A4DD-AF3D65AAD5F1@jiaziyi.com> <1365076875.48060.YahooMailNeo@web122302.mail.ne1.yahoo.com> <1365325781.85623.YahooMailNeo@web122305.mail.ne1.yahoo.com>  <1365935567594-365223.post@n7.nabble.com>  <1366527154968-365958.post@n7.nabble.com>
To: Ahmed A. Elawamry 
X-Mailer: Apple Mail (2.1503)
Cc: manet@ietf.org
Subject: Re: [manet] LOADng Data Collection Cycle
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 10:14:33 -0000

Hi,=20

LOADng has slightly longer delay than AODV is because LOADng core =
specification eliminates intermediate route reply (iRREP).=20

When intermediate route reply is used (by AODV),  an intermediate router =
could reply to a Route Request. For LOADng, only the destination router =
can reply the route request. By doing so, LOADng might need longer time =
for route discovery.=20

LOADng core specification prohibits iRREP because:

	o iRREP needs more fields in the RREQ message, which increases =
message overhead.=20
	o iRREP requires more processing in the router to avoid loops
	o There is possibility of loops when iRREP is used.=20
	o iRREP provides attack vectors to the protocol, which makes the =
network hard to secure.=20
	o In networks where reactive protocol is used (for example, =
sensor networks), delay is not critical issue, in most of the cases.=20

A more detailed discussion about this issue is available at=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	J. Yi, T. Clausen, A. Bas: Smart Route Request for on-demand =
route discovery in constrained environments, IEEE International =
Conference on Wireless Information Technology and Systems (ICWITS), 2012=20=


a pdf version: =
http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb=
00ae8ff62c37d68175.pdf

Please check section 3A - Intermediate Route Replies: to be, or not to =
be...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In the meantime, while iRREP is eliminated in the core specification of =
LOADng, it can exist as an extension of LOADng.=20

best


Jiazi

On Apr 21, 2013, at 8:52 AM, Ahmed A. Elawamry =
 wrote:

> Hi,
>=20
> Please i have a question about end-to-end delay. Why the end-to-end =
delay of
> AODV is lower than LOADng (at higher number of nodes) although LOADng =
has
> lower overhead?.
>=20
> Regards,
> Ahmed A. Elawamry
>=20
>=20
>=20
> -----
> Best Regards,
> Ahmed A. Elawamry
>=20
> --
> View this message in context: =
http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365958.=
html
> Sent from the IETF - manet mailing list archive at Nabble.com.
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From henning.rogge@fkie.fraunhofer.de  Mon Apr 22 06:00:55 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A3421F8DFC for ; Mon, 22 Apr 2013 06:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4tIvqB2009L for ; Mon, 22 Apr 2013 06:00:54 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CA80B21F8FDB for ; Mon, 22 Apr 2013 06:00:46 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUGMO-0000qj-Aq; Mon, 22 Apr 2013 15:00:44 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UUGMO-0006qB-88; Mon, 22 Apr 2013 15:00:44 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 22 Apr 2013 15:00:43 +0200
Message-ID: <51753476.2070802@fkie.fraunhofer.de>
Date: Mon, 22 Apr 2013 15:00:38 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: 
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com>
In-Reply-To: <20130415155915.4011.3274.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040203090007010705080605"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17061/Mon Apr 22 14:24:27 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 43b2ec1105388d0c049f599e9f35ae6b
Cc: Joe Macker , Stan Ratliff 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 13:00:55 -0000

--------------ms040203090007010705080605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

thank you to the Authors for updating the document quickly.

We thought we finally got the OLSRv2 RFC running, but hit a roadblock=20
again... so lets try to get rid of it.

I think draft 02 is much more explicit about a lot of things and clears=20
up the difference between the two ICV TLV extensions well.

How do we push forward now?

Henning Rogge


On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
>   This draft is a work item of the Mobile Ad-hoc Networks Working Group=
 of the IETF.
>
> 	Title           : Integrity Check Value and Timestamp TLV Definitions =
for Mobile Ad Hoc Networks (MANETs)
> 	Author(s)       : Ulrich Herberg
>                            Thomas Heide Clausen
>                            Christopher Dearlove
> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> 	Pages           : 24
> 	Date            : 2013-04-15
>
> Abstract:
>     This document revises, extends and replaces RFC 6622.  It describes=

>     general and flexible TLVs for representing cryptographic Integrity
>     Check Values (ICVs) and timestamps, using the generalized Mobile Ad=

>     Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>     defines two Packet TLVs, two Message TLVs, and two Address Block TL=
Vs
>     for affixing ICVs and timestamps to a packet, a message, and one or=

>     more addresses, respectively.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


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


--------------ms040203090007010705080605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjIxMzAwNDJaMCMGCSqGSIb3DQEJBDEWBBTdWo5t3V8L/HinyQGYJj0FQ6fg+jBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEArHLRNzlzj98G4qNMXAkdRKS4kMRp2BTl9xnW7bSYc6/0
UvjE2Gy3RI36/Ic9Zu0CpTZf4yLcpHAjbftbx7DcL+hZ/WkeDWAwrQ2ht1kZq/Uj8PxsT/li
zyukwkDkx6giBgJLofRJmWkQqebrNa5+vGzyoWQBNapsMXQe3zMg3Tg3RlaibZHQorVj/8Kh
Quj5OMrIgkxJJDv//MlhkhF/xCwma+T85Y86UqFt1oG3tb2DuKtiLA9x5VnB6/CuNdP4Vh53
h1jUfoqnMW8GlT3EGQxwmn3ohqSbeGy60sxYDhi6yXZES8CIk9VtjFIGDK1pYzjlOmKj3lY7
0h3I2e0cqQAAAAAAAA==
--------------ms040203090007010705080605--

From Chris.Dearlove@baesystems.com  Mon Apr 22 08:17:44 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38C21F91B7 for ; Mon, 22 Apr 2013 08:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo5+FTbuBPom for ; Mon, 22 Apr 2013 08:17:43 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9821F9132 for ; Mon, 22 Apr 2013 08:17:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,527,1363132800"; d="scan'208";a="331161812"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Apr 2013 16:17:42 +0100
Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3MFHfvp021822 for ; Mon, 22 Apr 2013 16:17:41 +0100
X-IronPort-AV: E=Sophos;i="4.87,527,1363132800"; d="scan'208";a="14129508"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Apr 2013 16:17:41 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 16:17:41 +0100
From: "Dearlove, Christopher (UK)" 
To: Henning Rogge , "manet@ietf.org" 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOOfJ3dwosW8Q57kaBNPnQXb4xXJjiLhwAgAA1JbA=
Date: Mon, 22 Apr 2013 15:17:40 +0000
Message-ID: 
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de>
In-Reply-To: <51753476.2070802@fkie.fraunhofer.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Joe Macker , Stan Ratliff 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 15:17:44 -0000

We, the authors, think both this document, and the also necessary NHDP/OLSR=
v2 security document are ready for WGLC, as I think Ulrich has already desc=
ribed. We would like to urge the WG chairs to start the process.

We'd also like to thank Henning for saying he'd like truncated signatures, =
which enabled the authors to realise that truncated signatures actually alr=
eady worked, it's just no one had pointed that out and made it explicitly a=
llowed. So we did. Also thanks to Justin for pointing out that that packet =
signatures were underspecified in one detail, also now fixed. Plus general =
comments from both reviewers also appreciated.

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H=
enning Rogge
Sent: 22 April 2013 14:01
To: manet@ietf.org
Cc: Joe Macker; Stan Ratliff
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

Hi,

thank you to the Authors for updating the document quickly.

We thought we finally got the OLSRv2 RFC running, but hit a roadblock=20
again... so lets try to get rid of it.

I think draft 02 is much more explicit about a lot of things and clears=20
up the difference between the two ICV TLV extensions well.

How do we push forward now?

Henning Rogge


On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>   This draft is a work item of the Mobile Ad-hoc Networks Working Group o=
f the IETF.
>
> =09Title           : Integrity Check Value and Timestamp TLV Definitions =
for Mobile Ad Hoc Networks (MANETs)
> =09Author(s)       : Ulrich Herberg
>                            Thomas Heide Clausen
>                            Christopher Dearlove
> =09Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> =09Pages           : 24
> =09Date            : 2013-04-15
>
> Abstract:
>     This document revises, extends and replaces RFC 6622.  It describes
>     general and flexible TLVs for representing cryptographic Integrity
>     Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>     Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>     defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>     for affixing ICVs and timestamps to a packet, a message, and one or
>     more addresses, respectively.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


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


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


From bebemaster@gmail.com  Mon Apr 22 10:59:14 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974DA21F8425 for ; Mon, 22 Apr 2013 10:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GBG7prw9Kk6 for ; Mon, 22 Apr 2013 10:59:09 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEB21F83DF for ; Mon, 22 Apr 2013 10:59:04 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ea20so2226371lab.16 for ; Mon, 22 Apr 2013 10:59:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2xuOwZk5KDOWU9qgj8Yh3hlKZoXKlkLflBXsoAd+djs=; b=K+TDSA7hOI7o2wxpKJsB0DZO6CA3bap7wOqfMLJWgu1fFb/WnuX7u8gGM1/ZP2BG6N yr66elK3Z7yt07k4zaRiagEPqsDHp7eFBP+OBV7wyFQER5G6umfgba01297K0CACp8Gq IDWgqCEET3G1KDY9gpWiQCSC09OyGHk7K9Zp0CWsqZxKDIZrhA0EEgZdKRfyS9uTxDCu EqEmrgSQgX5cWIaWloNf5OX9jlwA9rhB9541BrWx8Ur9iy4V6kdMYdzZ17H6U70+q3EJ IWm2kid3rqMQsewhZ6ZuhnWCmxxOPiE0/sYF0iD0Z/AYSRyeHXBbu2czCyS/YQ6zkIGe gqxQ==
MIME-Version: 1.0
X-Received: by 10.112.139.130 with SMTP id qy2mr13923348lbb.34.1366653542895;  Mon, 22 Apr 2013 10:59:02 -0700 (PDT)
Received: by 10.152.125.134 with HTTP; Mon, 22 Apr 2013 10:59:02 -0700 (PDT)
In-Reply-To: 
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de> 
Date: Mon, 22 Apr 2013 13:59:02 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c34b4ef496f204daf6d29f
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 17:59:14 -0000

--001a11c34b4ef496f204daf6d29f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the update.  The clarity with the packet level signatures is
appreciated.  From a quick look I only have two minor nits.

The added paragraph to section 12.1.1 "Rationale" is really quite helpful
and find its placement buried in the middle of the specification
unfortunate.  Section 1.1 provides a summary of the rational but IMO it is
less helpful than the new paragraph provided (although I can see how the
detail at 1.1 would be overmuch).

2) The registration type extension breakouts including descriptions for
each is helpful but the wording for the new (type=3D2) can be simplified.
ICV, using a cryptographic function and hash function (including the IP
datagraph source address), as specified in Section 12 of this document.

I'll try and do one more through look through once it's last called which I
am in favor of happening at this time.

Justin Dean






























On Mon, Apr 22, 2013 at 11:17 AM, Dearlove, Christopher (UK) <
Chris.Dearlove@baesystems.com> wrote:

> We, the authors, think both this document, and the also necessary
> NHDP/OLSRv2 security document are ready for WGLC, as I think Ulrich has
> already described. We would like to urge the WG chairs to start the proce=
ss.
>
> We'd also like to thank Henning for saying he'd like truncated signatures=
,
> which enabled the authors to realise that truncated signatures actually
> already worked, it's just no one had pointed that out and made it
> explicitly allowed. So we did. Also thanks to Justin for pointing out tha=
t
> that packet signatures were underspecified in one detail, also now fixed.
> Plus general comments from both reviewers also appreciated.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre=
,
> Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Henning Rogge
> Sent: 22 April 2013 14:01
> To: manet@ietf.org
> Cc: Joe Macker; Stan Ratliff
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>
> Hi,
>
> thank you to the Authors for updating the document quickly.
>
> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
> again... so lets try to get rid of it.
>
> I think draft 02 is much more explicit about a lot of things and clears
> up the difference between the two ICV TLV extensions well.
>
> How do we push forward now?
>
> Henning Rogge
>
>
> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >   This draft is a work item of the Mobile Ad-hoc Networks Working Group
> of the IETF.
> >
> >       Title           : Integrity Check Value and Timestamp TLV
> Definitions for Mobile Ad Hoc Networks (MANETs)
> >       Author(s)       : Ulrich Herberg
> >                            Thomas Heide Clausen
> >                            Christopher Dearlove
> >       Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> >       Pages           : 24
> >       Date            : 2013-04-15
> >
> > Abstract:
> >     This document revises, extends and replaces RFC 6622.  It describes
> >     general and flexible TLVs for representing cryptographic Integrity
> >     Check Values (ICVs) and timestamps, using the generalized Mobile Ad
> >     Hoc Network (MANET) packet/message format defined in RFC 5444.  It
> >     defines two Packet TLVs, two Message TLVs, and two Address Block TL=
Vs
> >     for affixing ICVs and timestamps to a packet, a message, and one or
> >     more addresses, respectively.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
> >
>
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--001a11c34b4ef496f204daf6d29f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thanks for the update.=A0 The cla=
rity with the packet level signatures is appreciated.=A0 From a quick look =
I only have two minor nits. 

The added paragraph to section 12=
.1.1 "Rationale" is really quite helpful and find its placement b=
uried in the middle of the specification unfortunate.=A0 Section 1.1 provid=
es a summary of the rational but IMO it is less helpful than the new paragr=
aph provided (although I can see how the detail at 1.1 would be overmuch).<=
br>

2) The registration type extension breakouts including descriptio=
ns for each is helpful but the wording for the new (type=3D2) can be simpli=
fied.
ICV, using a cryptographic function and hash function (inclu=
ding the IP datagraph source address), as specified in Section 12 of this d=
ocument.


I'll try and do one more through look through once it's l=
ast called which I am in favor of happening at this time.

Just=
in Dean

<=
/tr>
<=
/tr>
      
<=
/tr>
      
<=
/tr>
      
<=
/tr>






=




      



















On Mon, Apr 22, 2013 at 11:17 AM, Dearlo=
ve, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:


We, the authors, think both this document, a=
nd the also necessary NHDP/OLSRv2 security document are ready for WGLC, as =
I think Ulrich has already described. We would like to urge the WG chairs t=
o start the process.




We'd also like to thank Henning for saying he'd like truncated sign=
atures, which enabled the authors to realise that truncated signatures actu=
ally already worked, it's just no one had pointed that out and made it =
explicitly allowed. So we did. Also thanks to Justin for pointing out that =
that packet signatures were underspecified in one detail, also now fixed. P=
lus general comments from both reviewers also appreciated.




--

Christopher Dearlove

Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245=
 242194=A0| =A0Fax: +44 1245 242124

chris.dearlove@baesystems.=
com | http://ww=
w.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687






-----Original Message-----

From: manet-bounces@ietf.org =
[mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge

Sent: 22 April 2013 14:01

To: manet@ietf.org

Cc: Joe Macker; Stan Ratliff

Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt



Hi,



thank you to the Authors for updating the document quickly.



We thought we finally got the OLSRv2 RFC running, but hit a roadblock

again... so lets try to get rid of it.



I think draft 02 is much more explicit about a lot of things and clears

up the difference between the two ICV TLV extensions well.



How do we push forward now?



Henning Rogge





On 04/15/2013 05:59 PM, interne=
t-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> =A0 This draft is a work item of the Mobile Ad-hoc Networks Working Gr=
oup of the IETF.

>

> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Integrity Check Value and Time=
stamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)

> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ulrich Herberg

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Cl=
ausen

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christopher Dea=
rlove

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-rfc6622-bis-02.=
txt

> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 24

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-15

>

> Abstract:

> =A0 =A0 This document revises, extends and replaces RFC 6622. =A0It de=
scribes

> =A0 =A0 general and flexible TLVs for representing cryptographic Integ=
rity

> =A0 =A0 Check Values (ICVs) and timestamps, using the generalized Mobi=
le Ad

> =A0 =A0 Hoc Network (MANET) packet/message format defined in RFC 5444.=
 =A0It

> =A0 =A0 defines two Packet TLVs, two Message TLVs, and two Address Blo=
ck TLVs

> =A0 =A0 for affixing ICVs and timestamps to a packet, a message, and o=
ne or

> =A0 =A0 more addresses, respectively.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc=
6622-bis

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-=
02

>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ma=
net-rfc6622-bis-02

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> manet mailing list

> manet@ietf.org

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

>





--

Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr

Kommunikation, Informationsverarbeitung und Ergonomie FKIE

Kommunikationssysteme (KOM)

Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany

Telefon +49 =
228 9435-961, =A0 Fax +49 228 9435 685

mailto:henning.rogge@fk=
ie.fraunhofer.de http://www.fkie.fraunhofer.de






***************************************************************=
*****

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************




_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--001a11c34b4ef496f204daf6d29f--

From ulrich@herberg.name  Mon Apr 22 11:11:37 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6687821E8051 for ; Mon, 22 Apr 2013 11:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qg9Mb8hLBTU for ; Mon, 22 Apr 2013 11:11:35 -0700 (PDT)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A321F905C for ; Mon, 22 Apr 2013 11:11:35 -0700 (PDT)
Received: by mail-vb0-f48.google.com with SMTP id p13so6089891vbe.21 for ; Mon, 22 Apr 2013 11:11:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vtIH4M2PMqq4PstLbxATetFBGIj6wfBLa4T/nozLheg=; b=FLRdTuZKGgxEu+QVxiiBeM59bkOherEB2EeO3nfkrJ0DBFGcMdKV7/SIuQPFH+a2/Q yDk41und6xQJjIB7czycy+mg/dmS508YxaWsp0ggDGTteRlH04etW/nbD3AHFmIaL5q0 XsN7uoWKkVN3sMIamU8ba35x4ZKDYHtXta3Xc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=vtIH4M2PMqq4PstLbxATetFBGIj6wfBLa4T/nozLheg=; b=JTg2b0m/cSutImx2xotFQ/61FCHA+PuaGnzaaXevtUbtAAFivCA0SMjE3teoyuhY5p cWXsNfLPXMxXzWKbu3DTGXHKHCb15tzh9LeN3Bm/O3kkc7y71P77adB2590cNoXo75MW w7dn3bZYd4yF4pG7rq2wx2oIgvDsM3B7bSk/jY45+yEb/4Bh7yhJzhbCxRbtvHUvJbFe 7rGWnNU5IA8/hvwU577m266+a1uxr3yiqXgGNPX8AvNgBfqYCAB6m/wS2LWb7WeJI9IH ybUfCdZxkYgMgLkVov4OcyWIuGjsOcHxsRumMGObzU+XqutTLXbog/qv2AspMdsnEmUs 9HBg==
MIME-Version: 1.0
X-Received: by 10.52.176.38 with SMTP id cf6mr16861433vdc.132.1366654294986; Mon, 22 Apr 2013 11:11:34 -0700 (PDT)
Received: by 10.220.190.199 with HTTP; Mon, 22 Apr 2013 11:11:34 -0700 (PDT)
In-Reply-To: 
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de>  
Date: Mon, 22 Apr 2013 11:11:34 -0700
Message-ID: 
From: Ulrich Herberg 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=bcaec5015cfbc8a59c04daf6ff50
X-Gm-Message-State: ALoCoQnGX2BqNDMNtNpRM6Kp++3cZA390CLDy8luoDaPOO0uiM2GnsplONKmHvfGM0fsYVfJlxuf
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 18:11:37 -0000

--bcaec5015cfbc8a59c04daf6ff50
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Justin for providing the additional comments. We have added them
to the TODO list of things to happen during a WGLC, which we hope can be
initiated now.

Best regards
Ulrich

On Mon, Apr 22, 2013 at 10:59 AM, Justin Dean  wrote:

> Thanks for the update.  The clarity with the packet level signatures is
> appreciated.  From a quick look I only have two minor nits.
>
> The added paragraph to section 12.1.1 "Rationale" is really quite helpful
> and find its placement buried in the middle of the specification
> unfortunate.  Section 1.1 provides a summary of the rational but IMO it i=
s
> less helpful than the new paragraph provided (although I can see how the
> detail at 1.1 would be overmuch).
>
> 2) The registration type extension breakouts including descriptions for
> each is helpful but the wording for the new (type=3D2) can be simplified.
> ICV, using a cryptographic function and hash function (including the IP
> datagraph source address), as specified in Section 12 of this document.
>
> I'll try and do one more through look through once it's last called which
> I am in favor of happening at this time.
>
> Justin Dean
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Apr 22, 2013 at 11:17 AM, Dearlove, Christopher (UK) <
> Chris.Dearlove@baesystems.com> wrote:
>
>> We, the authors, think both this document, and the also necessary
>> NHDP/OLSRv2 security document are ready for WGLC, as I think Ulrich has
>> already described. We would like to urge the WG chairs to start the proc=
ess.
>>
>> We'd also like to thank Henning for saying he'd like truncated
>> signatures, which enabled the authors to realise that truncated signatur=
es
>> actually already worked, it's just no one had pointed that out and made =
it
>> explicitly allowed. So we did. Also thanks to Justin for pointing out th=
at
>> that packet signatures were underspecified in one detail, also now fixed=
.
>> Plus general comments from both reviewers also appreciated.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
>> Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
>> Of Henning Rogge
>> Sent: 22 April 2013 14:01
>> To: manet@ietf.org
>> Cc: Joe Macker; Stan Ratliff
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>
>> Hi,
>>
>> thank you to the Authors for updating the document quickly.
>>
>> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
>> again... so lets try to get rid of it.
>>
>> I think draft 02 is much more explicit about a lot of things and clears
>> up the difference between the two ICV TLV extensions well.
>>
>> How do we push forward now?
>>
>> Henning Rogge
>>
>>
>> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >   This draft is a work item of the Mobile Ad-hoc Networks Working Grou=
p
>> of the IETF.
>> >
>> >       Title           : Integrity Check Value and Timestamp TLV
>> Definitions for Mobile Ad Hoc Networks (MANETs)
>> >       Author(s)       : Ulrich Herberg
>> >                            Thomas Heide Clausen
>> >                            Christopher Dearlove
>> >       Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>> >       Pages           : 24
>> >       Date            : 2013-04-15
>> >
>> > Abstract:
>> >     This document revises, extends and replaces RFC 6622.  It describe=
s
>> >     general and flexible TLVs for representing cryptographic Integrity
>> >     Check Values (ICVs) and timestamps, using the generalized Mobile A=
d
>> >     Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>> >     defines two Packet TLVs, two Message TLVs, and two Address Block
>> TLVs
>> >     for affixing ICVs and timestamps to a packet, a message, and one o=
r
>> >     more addresses, respectively.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > manet mailing list
>> > manet@ietf.org
>> > https://www.ietf.org/mailman/listinfo/manet
>> >
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>
>>
>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended
>> recipient please delete it from your system and notify the sender.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--bcaec5015cfbc8a59c04daf6ff50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Justin for providing the additional comments. We have added them =
to the TODO list of things to happen during a WGLC, which we hope can be in=
itiated now.

Best regards
Ulrich


On Mon, Apr 22, 2013 at 10:59 AM, Justin Dean <bebemaster@gmail.com=
> wrote:


Thanks for the update.=A0 The cla=
rity with the packet level signatures is appreciated.=A0 From a quick look =
I only have two minor nits. 

The added paragraph to section 12=
.1.1 "Rationale" is really quite helpful and find its placement b=
uried in the middle of the specification unfortunate.=A0 Section 1.1 provid=
es a summary of the rational but IMO it is less helpful than the new paragr=
aph provided (although I can see how the detail at 1.1 would be overmuch).<=
br>


2) The registration type extension breakouts including descriptio=
ns for each is helpful but the wording for the new (type=3D2) can be simpli=
fied.
ICV, using a cryptographic function and hash function (inclu=
ding the IP datagraph source address), as specified in Section 12 of this d=
ocument.



I'll try and do one more through look through once it's l=
ast called which I am in favor of happening at this time.

Justin Dean












      






      






      






      





=






On Mon, Apr 22, 2013 at 11:17 AM, Dearlo=
ve, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:



We, the authors, think both this document, a=
nd the also necessary NHDP/OLSRv2 security document are ready for WGLC, as =
I think Ulrich has already described. We would like to urge the WG chairs t=
o start the process.





We'd also like to thank Henning for saying he'd like truncated sign=
atures, which enabled the authors to realise that truncated signatures actu=
ally already worked, it's just no one had pointed that out and made it =
explicitly allowed. So we did. Also thanks to Justin for pointing out that =
that packet signatures were underspecified in one detail, also now fixed. P=
lus general comments from both reviewers also appreciated.





--

Christopher Dearlove

Senior Principal Engineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124

chris.de=
arlove@baesystems.com | http://www.baesystems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687






-----Original Message-----

From: manet-bou=
nces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge

Sent: 22 April 2013 14:01

To: manet@ietf.org<=
br>
Cc: Joe Macker; Stan Ratliff

Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt



Hi,



thank you to the Authors for updating the document quickly.



We thought we finally got the OLSRv2 RFC running, but hit a roadblock

again... so lets try to get rid of it.



I think draft 02 is much more explicit about a lot of things and clears

up the difference between the two ICV TLV extensions well.



How do we push forward now?



Henning Rogge





On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> =A0 This draft is a work item of the Mobile Ad-hoc Networks Working Gr=
oup of the IETF.

>

> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Integrity Check Value and Time=
stamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)

> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ulrich Herberg

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Cl=
ausen

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christopher Dea=
rlove

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-rfc6622-bis-02.=
txt

> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 24

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-15

>

> Abstract:

> =A0 =A0 This document revises, extends and replaces RFC 6622. =A0It de=
scribes

> =A0 =A0 general and flexible TLVs for representing cryptographic Integ=
rity

> =A0 =A0 Check Values (ICVs) and timestamps, using the generalized Mobi=
le Ad

> =A0 =A0 Hoc Network (MANET) packet/message format defined in RFC 5444.=
 =A0It

> =A0 =A0 defines two Packet TLVs, two Message TLVs, and two Address Blo=
ck TLVs

> =A0 =A0 for affixing ICVs and timestamps to a packet, a message, and o=
ne or

> =A0 =A0 more addresses, respectively.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc=
6622-bis

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-=
02

>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ma=
net-rfc6622-bis-02

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> manet mailing list

> manet@ietf.org=


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

>





--

Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr

Kommunikation, Informationsverarbeitung und Ergonomie FKIE

Kommunikationssysteme (KOM)

Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany

Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de






***************************************************************=
*****

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************




_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet






_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--bcaec5015cfbc8a59c04daf6ff50--

From henning.rogge@fkie.fraunhofer.de  Tue Apr 23 02:13:02 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2121F9643 for ; Tue, 23 Apr 2013 02:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awaueaCwC03t for ; Tue, 23 Apr 2013 02:12:48 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 08F5421F949A for ; Tue, 23 Apr 2013 02:12:46 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUZHJ-0003zZ-OI for manet@ietf.org; Tue, 23 Apr 2013 11:12:45 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UUZHJ-00075h-Lh for manet@ietf.org; Tue, 23 Apr 2013 11:12:45 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Apr 2013 11:12:45 +0200
Message-ID: <51765087.6000302@fkie.fraunhofer.de>
Date: Tue, 23 Apr 2013 11:12:39 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: "manet@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090707080103050404060101"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17068/Tue Apr 23 06:38:29 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: f805957957133c0514251c3ba99aca04
Subject: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 09:13:02 -0000

--------------ms090707080103050404060101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

as promised in the earlier review of DLEP-04, here are some more points=20
to discuss for DLEP link metrics.


Layer-2 traffic data
--------------------

Many IP radios can easily keep track of the incoming and outgoing data=20
to its neighbors, both in terms of bytes and frames. This data is useful =

for calculating routing metrics, so I would like to see statistic=20
metrics (as described in my private draft) as optional metrics for DLEP.

This way manufacturers do not need to invent proprietary metric TLVs for =

this data.



Layer-2 mesh
------------

It seems that many IP radios try to establish a transparent layer-2 mesh =

between the radios on the same channel. The fact that the linklayer=20
forms a mesh is useful knowledge for a layer-3 MANET routing protocol,=20
it allows an implementation to optimize its flooding and forwarding=20
routings (by not using two-hop routes within the layer-2 mesh domain).

I would suggest adding a new TLV to DLEP with a single byte value to=20
signal this feature to the router. Establishing a codepoint for "no=20
mesh" and one for "mesh" should be enough for the basic DLEP draft,=20
other optional codepoints that signal more features of the radio=20
available to the router could be defined in later RFCs.





9.X Mesh

The Mesh TLV is used in Peer Discovery and Peer Update messages to=20
indicate if the radio use a transparent layer-2 mesh to forward the traff=
ic.

The Mesh TLV contains the following fields:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |TLV Type =3DTBD  |Length =3D 1     |Mesh Capability|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    TLV Type    -  TBD

    Length      -  1

    Mesh Capability -  Value 0 means the radio does not use mesh=20
forwarding on this DLEP interface. Value 1 means the radio does use mesh =

forwarding, but do not provide further data about the feature.



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


--------------ms090707080103050404060101
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjMwOTEyNDRaMCMGCSqGSIb3DQEJBDEWBBTYt31/t4TMuEnA4UDkZZuddJ+rXDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEADQ5MKU5SO5viYZ0ZkZ8qHbJSbCO0mZ5QuCbAfidojoXE
yD8LyIKrH6LJ603+rnJTiK/dLkpkQ6htLs2X3KJKykguArr+bOPcnKfERIZlYfCzdPG0+tOL
T2wc1h2ONcWb+CGy0NPnSJQvqaHKiVy++yCbTVlM15rvfZDn/9pp/Q3vYx9Eu+/iwck/FM+1
x/HZi6v6KRPyBUMXh5JFWDa990HJFyGsHbv21VcSfbhqmQfUZzOhSyLa1C/lnTa7ooIHyFL+
lakHpAyNKgVZKbk1qkPoq10FH8Yb59i2uYv8AySbmVLVPokkFn12OXym7yzxK6wu5Awn5Nfg
f+HGdkcDcQAAAAAAAA==
--------------ms090707080103050404060101--

From Martin.Duke@boeing.com  Tue Apr 23 06:25:19 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954BF21F9612 for ; Tue, 23 Apr 2013 06:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1NzoFvxX6Ru for ; Tue, 23 Apr 2013 06:25:18 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5B21F966D for ; Tue, 23 Apr 2013 06:25:17 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r3NDPG1a026907 for ; Tue, 23 Apr 2013 08:25:16 -0500
Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r3NDPEFj026423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Apr 2013 08:25:15 -0500
Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.221]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.38]) with mapi id 14.02.0328.011; Tue, 23 Apr 2013 06:25:14 -0700
From: "Duke, Martin" 
To: "henning.rogge@fkie.fraunhofer.de" , "manet@ietf.org" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQALIEHp/iu20C0eCAfN8pC7SSJjjy5eg
Date: Tue, 23 Apr 2013 13:25:13 +0000
Message-ID: <5A8A5085482DA84995F4E70F5093AB50221D1F@XCH-BLV-503.nw.nos.boeing.com>
References: <51765087.6000302@fkie.fraunhofer.de>
In-Reply-To: <51765087.6000302@fkie.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 13:25:19 -0000

I support the addition of this metric, as we're dealing with radios that ha=
ve this capability. But while we're spending a byte anyway, why not simply =
report the layer-2 hop count to the neighbor?

Martin Duke
Boeing

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H=
enning Rogge
Sent: Tuesday, April 23, 2013 2:13 AM
To: manet@ietf.org
Subject: [manet] DLEP link metric discussion

Hi,

as promised in the earlier review of DLEP-04, here are some more points to =
discuss for DLEP link metrics.


Layer-2 traffic data
--------------------

Many IP radios can easily keep track of the incoming and outgoing data
to its neighbors, both in terms of bytes and frames. This data is useful
for calculating routing metrics, so I would like to see statistic
metrics (as described in my private draft) as optional metrics for DLEP.

This way manufacturers do not need to invent proprietary metric TLVs for
this data.



Layer-2 mesh
------------

It seems that many IP radios try to establish a transparent layer-2 mesh
between the radios on the same channel. The fact that the linklayer
forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
it allows an implementation to optimize its flooding and forwarding
routings (by not using two-hop routes within the layer-2 mesh domain).

I would suggest adding a new TLV to DLEP with a single byte value to
signal this feature to the router. Establishing a codepoint for "no
mesh" and one for "mesh" should be enough for the basic DLEP draft,
other optional codepoints that signal more features of the radio
available to the router could be defined in later RFCs.





9.X Mesh

The Mesh TLV is used in Peer Discovery and Peer Update messages to
indicate if the radio use a transparent layer-2 mesh to forward the traffic=
.

The Mesh TLV contains the following fields:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |TLV Type =3DTBD  |Length =3D 1     |Mesh Capability|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    TLV Type    -  TBD

    Length      -  1

    Mesh Capability -  Value 0 means the radio does not use mesh
forwarding on this DLEP interface. Value 1 means the radio does use mesh
forwarding, but do not provide further data about the feature.



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


From abdussalambaryun@gmail.com  Tue Apr 23 06:50:26 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E721F9688 for ; Tue, 23 Apr 2013 06:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Level: 
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjI7ues4xijZ for ; Tue, 23 Apr 2013 06:50:25 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9597B21F9410 for ; Tue, 23 Apr 2013 06:50:25 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id 10so452625pdc.28 for ; Tue, 23 Apr 2013 06:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=O6ESqcTfzcWkVwJqeKsEEVORs42sOJ94Hihhx3L7TuM=; b=fDVL3GA2oGfwQeCgSDz9ALZjgl3muaiGGeECx00sKaqtaVWycZJYbcGXrW4+oZCMwl TTSpGBYuoxBzC1kUaWqisVI1LbRydX1/vOnSQyxkuhOQ2ScQTfpvY4ZkfJFBjM73nVUA rOrtTkmbJeAvRb6yuML6gGeYKXEgDVMrBT2Oa87Ke9L+HYr+IHT9KG+jahViNUUdYel5 x0YEPImfXM/U0LHNt35Xh44/60Je8rG399IMVkPXBJ0eTi0V3YCsACzJvyWzBmJronht 03UlYeoaGyofzuBu9T+j1DMkL0wNkq2tOSDurOL/xPHNh3wHCTj7jcV0tIiSZdLBK08l Sw6Q==
MIME-Version: 1.0
X-Received: by 10.68.209.162 with SMTP id mn2mr40846592pbc.190.1366725025355;  Tue, 23 Apr 2013 06:50:25 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Tue, 23 Apr 2013 06:50:25 -0700 (PDT)
In-Reply-To: <51753476.2070802@fkie.fraunhofer.de>
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de>
Date: Tue, 23 Apr 2013 15:50:25 +0200
Message-ID: 
From: Abdussalam Baryun 
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 13:50:27 -0000

IMO, this document is not related only to OLSRv2 and it was not
presented in any WG meeting (obsoletes RFC6622), it is better to get
more discussions and feedback for its progress,

AB

On 4/22/13, Henning Rogge  wrote:
> Hi,
>
> thank you to the Authors for updating the document quickly.
>
> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
> again... so lets try to get rid of it.
>
> I think draft 02 is much more explicit about a lot of things and clears
> up the difference between the two ICV TLV extensions well.
>
> How do we push forward now?
>
> Henning Rogge
>
>
> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Mobile Ad-hoc Networks Working Group =
of
>> the IETF.
>>
>> 	Title           : Integrity Check Value and Timestamp TLV Definitions f=
or
>> Mobile Ad Hoc Networks (MANETs)
>> 	Author(s)       : Ulrich Herberg
>>                            Thomas Heide Clausen
>>                            Christopher Dearlove
>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>> 	Pages           : 24
>> 	Date            : 2013-04-15
>>
>> Abstract:
>>     This document revises, extends and replaces RFC 6622.  It describes
>>     general and flexible TLVs for representing cryptographic Integrity
>>     Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>     Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>     defines two Packet TLVs, two Message TLVs, and two Address Block TLV=
s
>>     for affixing ICVs and timestamps to a packet, a message, and one or
>>     more addresses, respectively.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>

From sratliff@cisco.com  Tue Apr 23 07:06:37 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC70821F96BF for ; Tue, 23 Apr 2013 07:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkCxlJUJKzmE for ; Tue, 23 Apr 2013 07:06:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0925A21F96B6 for ; Tue, 23 Apr 2013 07:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3367; q=dns/txt; s=iport; t=1366725997; x=1367935597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=08CjfCUyYnJ3vooxMVhAfLTVPhetI9LLCrl6frr2bXs=; b=G8aDgYIeTaTxr4PX0maVtYTahEjuVgL0rlG8Sf3CqAyQgg1dOTT6RG30 3IlZXI0yCFuQRDnX45jv7+IVdXnF8aGoyKARi4t0zhFxWl8CdsEh5gszp TK3pPEBxmtnvkDVlAY8PxwYqkPS/miY6WzM16lrU6B+s/EG5nU9sm6+1Y g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjUFAP2UdlGtJV2Y/2dsb2JhbABQgwY2RMBXgQEWdIIfAQEBAwEBAQFrCwULAgEIGAodBycLFBECBA4FCAGIBQYHBa0sjyqOdQIxB4JoYQOIV49mj3qDDoIo
X-IronPort-AV: E=Sophos;i="4.87,533,1363132800"; d="scan'208";a="202004380"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 23 Apr 2013 14:06:24 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3NE6OcI026679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Apr 2013 14:06:24 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 09:06:23 -0500
From: "Stan Ratliff (sratliff)" 
To: Abdussalam Baryun 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOP1lqPggRoPSGOUukBlfHXFaqD5jkKCGAgAAEdQA=
Date: Tue, 23 Apr 2013 14:06:22 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C36A9@xmb-aln-x03.cisco.com>
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.54.113]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <94868BEB6A750646A717741BA13C9192@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 14:06:38 -0000

AB,=20

On Apr 23, 2013, at 9:50 AM, Abdussalam Baryun wrote:

> IMO, this document is not related only to OLSRv2 and it was not
> presented in any WG meeting (obsoletes RFC6622), it is better to get
> more discussions and feedback for its progress,

Do you have a list of concerns, or specific areas of the document you feel =
need additional discussion? To be completely honest, a general recommendati=
on to "talk about it more" doesn't help me a lot.=20

Regards,
Stan


>=20
> AB
>=20
> On 4/22/13, Henning Rogge  wrote:
>> Hi,
>>=20
>> thank you to the Authors for updating the document quickly.
>>=20
>> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
>> again... so lets try to get rid of it.
>>=20
>> I think draft 02 is much more explicit about a lot of things and clears
>> up the difference between the two ICV TLV extensions well.
>>=20
>> How do we push forward now?
>>=20
>> Henning Rogge
>>=20
>>=20
>> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>  This draft is a work item of the Mobile Ad-hoc Networks Working Group =
of
>>> the IETF.
>>>=20
>>> 	Title           : Integrity Check Value and Timestamp TLV Definitions =
for
>>> Mobile Ad Hoc Networks (MANETs)
>>> 	Author(s)       : Ulrich Herberg
>>>                           Thomas Heide Clausen
>>>                           Christopher Dearlove
>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>> 	Pages           : 24
>>> 	Date            : 2013-04-15
>>>=20
>>> Abstract:
>>>    This document revises, extends and replaces RFC 6622.  It describes
>>>    general and flexible TLVs for representing cryptographic Integrity
>>>    Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>    Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>    defines two Packet TLVs, two Message TLVs, and two Address Block TLV=
s
>>>    for affixing ICVs and timestamps to a packet, a message, and one or
>>>    more addresses, respectively.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>=20
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>=20
>>=20
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>=20
>>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From rick.taylor@cassidian.com  Tue Apr 23 07:08:18 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8BC21F96CE for ; Tue, 23 Apr 2013 07:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SneeG7ooerW9 for ; Tue, 23 Apr 2013 07:08:18 -0700 (PDT)
Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 43C2521F96E9 for ; Tue, 23 Apr 2013 07:08:15 -0700 (PDT)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 23 Apr 2013 16:08:13 +0200
Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Tue, 23 Apr 2013 16:08:11 +0200
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 23 Apr 2013 16:08:11 +0200
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 23 Apr 2013 16:08:11 +0200
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 15:08:11 +0100
From: "Taylor, Rick" 
To: "Duke, Martin" , "henning.rogge@fkie.fraunhofer.de" ,  "manet@ietf.org" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQALI2QiFp03LlkCfeEVaxZbdLZjjy5eggAALQCA=
Date: Tue, 23 Apr 2013 14:08:10 +0000
Message-ID: 
References: <51765087.6000302@fkie.fraunhofer.de> <11680519-94d5-44cd-96ef-1f106d1bf830@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <11680519-94d5-44cd-96ef-1f106d1bf830@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.23.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Apr 2013 14:08:11.0660 (UTC) FILETIME=[FD3B0CC0:01CE402B]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19818.007
X-TM-AS-Result: No--31.867400-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 14:08:18 -0000

The difference between a 1 byte Boolean value and a layer2-hopcount is how =
big should the TLV data packet be... 8-bits?  16-bits?  etc.

I vote for 1 byte Boolean.

Also, exposing layer-2 topology information could lead to people requesting=
 a TLV to notify a change of layer-2 hopcount.  I would keep the lid on the=
 can of worms.

Rick Taylor

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Duke, Martin
> Sent: 23 April 2013 14:25
> To: henning.rogge@fkie.fraunhofer.de; manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>
> I support the addition of this metric, as we're dealing with radios that
> have this capability. But while we're spending a byte anyway, why not
> simply report the layer-2 hop count to the neighbor?
>
> Martin Duke
> Boeing
>
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Henning Rogge
> Sent: Tuesday, April 23, 2013 2:13 AM
> To: manet@ietf.org
> Subject: [manet] DLEP link metric discussion
>
> Hi,
>
> as promised in the earlier review of DLEP-04, here are some more points t=
o
> discuss for DLEP link metrics.
>
>
> Layer-2 traffic data
> --------------------
>
> Many IP radios can easily keep track of the incoming and outgoing data
> to its neighbors, both in terms of bytes and frames. This data is useful
> for calculating routing metrics, so I would like to see statistic
> metrics (as described in my private draft) as optional metrics for DLEP.
>
> This way manufacturers do not need to invent proprietary metric TLVs for
> this data.
>
>
>
> Layer-2 mesh
> ------------
>
> It seems that many IP radios try to establish a transparent layer-2 mesh
> between the radios on the same channel. The fact that the linklayer
> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
> it allows an implementation to optimize its flooding and forwarding
> routings (by not using two-hop routes within the layer-2 mesh domain).
>
> I would suggest adding a new TLV to DLEP with a single byte value to
> signal this feature to the router. Establishing a codepoint for "no
> mesh" and one for "mesh" should be enough for the basic DLEP draft,
> other optional codepoints that signal more features of the radio
> available to the router could be defined in later RFCs.
>
>
>
>
>
> 9.X Mesh
>
> The Mesh TLV is used in Peer Discovery and Peer Update messages to
> indicate if the radio use a transparent layer-2 mesh to forward the
> traffic.
>
> The Mesh TLV contains the following fields:
>
>      0                   1                   2
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |TLV Type =3DTBD  |Length =3D 1     |Mesh Capability|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     TLV Type    -  TBD
>
>     Length      -  1
>
>     Mesh Capability -  Value 0 means the radio does not use mesh
> forwarding on this DLEP interface. Value 1 means the radio does use mesh
> forwarding, but do not provide further data about the feature.
>
>
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
The information contained within this e-mail and any files attached to this=
 e-mail is private and in addition may include commercially sensitive infor=
mation. The contents of this e-mail are for the intended recipient only and=
 therefore if you wish to disclose the information contained within this e-=
mail or attached files, please contact the sender prior to any such disclos=
ure. If you are not the intended recipient, any disclosure, copying or dist=
ribution is prohibited. Please also contact the sender and inform them of t=
he error and delete the e-mail, including any attached files from your syst=
em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, =
Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

From hrogge@googlemail.com  Tue Apr 23 07:31:20 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B5A21F9610 for ; Tue, 23 Apr 2013 07:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BitfWucgeZP for ; Tue, 23 Apr 2013 07:31:18 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C5B2C21F958A for ; Tue, 23 Apr 2013 07:31:17 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id at1so734363iec.15 for ; Tue, 23 Apr 2013 07:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=xPy0SDAaaQOY7XETHDi3/MCzoOXkPtPIAIJ0srkzgPg=; b=QrAo5IKPt4IY5uJtvE8vR/6TnydHc0CBQ9gPePHlqwHNGkKezErxKmm2j1c4x5ykho XDfK58cwKYx6rS5p5JC2apBV9VbFRrYfqf6u9n+5aBX43XRg53f2UdUY2JqZTSTv6Mi3 i+V+bodkSwf+QizNMRskwPc3ayCdKQpcfsSe5BU8o2QinRAtEvlgk/50UxXgncFNjraj uwjOUK59wIRHcqOw0iopgqsj50Vx48R2HVuRAMXeDy18FUEUNnA54BxNSDbNjF1aQll/ 35EIeJpN6CEE6MAH7Xl3DwZssRUq+XzK2hkIS34ARVtNqXbYjp6dTkAsbO4KDQ1N66vZ ampA==
X-Received: by 10.50.219.168 with SMTP id pp8mr24030903igc.57.1366727477379; Tue, 23 Apr 2013 07:31:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.142.169 with HTTP; Tue, 23 Apr 2013 07:30:56 -0700 (PDT)
In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50221D1F@XCH-BLV-503.nw.nos.boeing.com>
References: <51765087.6000302@fkie.fraunhofer.de> <5A8A5085482DA84995F4E70F5093AB50221D1F@XCH-BLV-503.nw.nos.boeing.com>
From: Henning Rogge 
Date: Tue, 23 Apr 2013 16:30:56 +0200
Message-ID: 
To: "Duke, Martin" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 14:31:20 -0000

The current solution is just a single "boolean" (with later chances of
expansion) value per Radio. Thats easy to implement and doesn't
produce lots of overhead.

Adding data that changes dynamically to each neighbor is a lot more of both=
.

I think we can work on this (feature to export layer-2 topology
through DLEP), but this should become an Extension-RFC. Lets keep it
out of the core specification.

Henning Rogge

On Tue, Apr 23, 2013 at 3:25 PM, Duke, Martin  wrot=
e:
> I support the addition of this metric, as we're dealing with radios that =
have this capability. But while we're spending a byte anyway, why not simpl=
y report the layer-2 hop count to the neighbor?
>
> Martin Duke
> Boeing
>
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of=
 Henning Rogge
> Sent: Tuesday, April 23, 2013 2:13 AM
> To: manet@ietf.org
> Subject: [manet] DLEP link metric discussion
>
> Hi,
>
> as promised in the earlier review of DLEP-04, here are some more points t=
o discuss for DLEP link metrics.
>
>
> Layer-2 traffic data
> --------------------
>
> Many IP radios can easily keep track of the incoming and outgoing data
> to its neighbors, both in terms of bytes and frames. This data is useful
> for calculating routing metrics, so I would like to see statistic
> metrics (as described in my private draft) as optional metrics for DLEP.
>
> This way manufacturers do not need to invent proprietary metric TLVs for
> this data.
>
>
>
> Layer-2 mesh
> ------------
>
> It seems that many IP radios try to establish a transparent layer-2 mesh
> between the radios on the same channel. The fact that the linklayer
> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
> it allows an implementation to optimize its flooding and forwarding
> routings (by not using two-hop routes within the layer-2 mesh domain).
>
> I would suggest adding a new TLV to DLEP with a single byte value to
> signal this feature to the router. Establishing a codepoint for "no
> mesh" and one for "mesh" should be enough for the basic DLEP draft,
> other optional codepoints that signal more features of the radio
> available to the router could be defined in later RFCs.
>
>
>
>
>
> 9.X Mesh
>
> The Mesh TLV is used in Peer Discovery and Peer Update messages to
> indicate if the radio use a transparent layer-2 mesh to forward the traff=
ic.
>
> The Mesh TLV contains the following fields:
>
>      0                   1                   2
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |TLV Type =3DTBD  |Length =3D 1     |Mesh Capability|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     TLV Type    -  TBD
>
>     Length      -  1
>
>     Mesh Capability -  Value 0 means the radio does not use mesh
> forwarding on this DLEP interface. Value 1 means the radio does use mesh
> forwarding, but do not provide further data about the feature.
>
>
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



--=20
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

From ietf@jiaziyi.com  Tue Apr 23 07:36:43 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AC321F95DC for ; Tue, 23 Apr 2013 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkwvAnLG7PK9 for ; Tue, 23 Apr 2013 07:36:42 -0700 (PDT)
Received: from mx1000.mochahost.com (mx1000.mochahost.com [50.31.147.194]) by ietfa.amsl.com (Postfix) with ESMTP id B090021F9530 for ; Tue, 23 Apr 2013 07:36:42 -0700 (PDT)
Received: from mocha3004.mochahost.com ([50.31.147.60]:34770) by mx1000.mochahost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1UUeL7-003iu7-Vx for manet@ietf.org; Tue, 23 Apr 2013 10:37:02 -0400
Received: from cpanel ([127.0.0.1]:53926 helo=webmail.jiaziyi.com, webmail.jiaziyi.com) by mocha3004.mochahost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UUeKo-002L2P-AG for manet@ietf.org; Tue, 23 Apr 2013 10:36:42 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Apr 2013 10:36:42 -0400
From: ietf@jiaziyi.com
To: 
Message-ID: 
X-Sender: ietf@jiaziyi.com
User-Agent: Roundcube Webmail/0.8.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mx1000.mochahost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jiaziyi.com
X-Get-Message-Sender-Via: mx1000.mochahost.com: mailgid no entry from get_relayhosts_entry
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 14:36:43 -0000

(sorry if you receive duplicate of this message. Some of my mails to 
the mailing list are rejected, and I'm trying to figure out with our 
secretary...)

Hi,

I had a review of the draft. I think it's in good shape, and ready for 
WGLC.

a few comments:

In section 6 & 7, I didn't find the definition of notation
	+
Not in this draft, either rfc 5444.

page 13,  source code address ==> source node address?

section 9.1 bullet 1 states that the  and 
 must be zeroed before calculating ICV. I'm thinking 
about that we might need to mention that some protocol-specific mutable 
fields must be zeroed here also. For example, in LOADng, as a reactive 
protocol, metric fields are defined as "mutable" (in the meantime, I 
still have some thoughts on those mutable fields that I need to discuss 
with other LOADng authors, but it's not that relevant here).

best

Jiazi


On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group 
of the IETF.

	Title           : Integrity Check Value and Timestamp TLV Definitions 
for Mobile Ad Hoc Networks (MANETs)
	Author(s)       : Ulrich Herberg
                         Thomas Heide Clausen
                         Christopher Dearlove
	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
	Pages           : 24
	Date            : 2013-04-15

Abstract:
  This document revises, extends and replaces RFC 6622.  It describes
  general and flexible TLVs for representing cryptographic Integrity
  Check Values (ICVs) and timestamps, using the generalized Mobile Ad
  Hoc Network (MANET) packet/message format defined in RFC 5444.  It
  defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
  for affixing ICVs and timestamps to a packet, a message, and one or
  more addresses, respectively.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6622-bis-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From buddenbergr@gmail.com  Tue Apr 23 08:57:16 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56E221F95F0 for ; Tue, 23 Apr 2013 08:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLxwhA7znm-W for ; Tue, 23 Apr 2013 08:57:16 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEA021F95DC for ; Tue, 23 Apr 2013 08:57:16 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id lb1so584156pab.19 for ; Tue, 23 Apr 2013 08:57:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=k+AUWmYTWTOXPX+fJuCX/pjftx5eg2vc9VXvOy84ZwU=; b=oRvnujYO1mJfD+2mg5FaerX1U/e+KfGmqwr3ugWnjvos8jMmILQa3knS2tgsDIn2lc DodjuyTlkQ/1BlYRsEbnzAbxT9GseOiiw3HCqixaYThecRd6cjxmF/8cjYwihJAx6wm8 p6z7KwlLOs3fSVLJmL2Cq7oun334VrbVxeSlkncVb1p/iYtSDmD4y8jJFKdanp3MwDBI QmMtp+wuo4HSuo7VlfUmdWmiLTXFdyUqRNPeHzRvrPkej880vI/AIwXDFw5mUrFZb+dX HU2PNFPAQdeUzE+2+kc2CGaRnywtQEpc833btan+Nvz2QEMAnIm4Nz1KI2eIq0bDTvrZ lR7g==
X-Received: by 10.68.209.162 with SMTP id mn2mr41972134pbc.190.1366732635869;  Tue, 23 Apr 2013 08:57:15 -0700 (PDT)
Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPS id do4sm30061280pbc.8.2013.04.23.08.57.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Apr 2013 08:57:14 -0700 (PDT)
Message-ID: <1366732633.1720.14.camel@localhost>
From: Rex Buddenberg 
To: manet@ietf.org
Date: Tue, 23 Apr 2013 08:57:13 -0700
In-Reply-To: <51765087.6000302@fkie.fraunhofer.de>
References: <51765087.6000302@fkie.fraunhofer.de>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 15:57:17 -0000

On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:
> Hi,
> 
> as promised in the earlier review of DLEP-04, here are some more points 
> to discuss for DLEP link metrics.
> 
> 
> Layer-2 traffic data
> --------------------
> 
> Many IP radios can easily keep track of the incoming and outgoing data 
> to its neighbors, both in terms of bytes and frames. This data is useful 
> for calculating routing metrics, so I would like to see statistic 
> metrics (as described in my private draft) as optional metrics for DLEP.

At layer 3, routers are peer-peer.  But most radio networks at layer 2
are not: a radio network segment (such as an LTE or 802.16 one) has a
base station (BS) and several subscriber stations (SS).  BS has all
kinds of this data readily at hand; a SS will only have metrics
pertinent to that particular SS.  In these kinds of network segments,
mining the SS that a router is attached to may not tell you important
data -- rather, you want to mine the BS which may be attached to a
different router.

> 
> This way manufacturers do not need to invent proprietary metric TLVs for 
> this data.

While the data in the BS is not itself described in the standards (e.g.
IEEE 802.16); the gozintas and gozoutas are very carefully described.
There are about four dozen -- the upload map (UL-MAP) is the single most
important one, but ranging messages will tell you a lot about link
quality if you wiretap them ... or the database they go into.  We need
not reinvent all these data notions.

> 
> 
> 
> Layer-2 mesh
> ------------
> 
Henning, we need to be careful about the term 'mesh'.  It's been badly
abused and poorly defined ... and if you've been raised with
fiber/copper underlying connectivity, the set of assumptions changes
(you got that part), but it changes in some ways that you didn't get.

> It seems that many IP radios try to establish a transparent layer-2 mesh 
> between the radios on the same channel. The fact that the linklayer 
> forms a mesh is useful knowledge for a layer-3 MANET routing protocol, 
> it allows an implementation to optimize its flooding and forwarding 
> routings (by not using two-hop routes within the layer-2 mesh domain).

There are two issues here that need to be disentangled.

The first is knowledge of connectivity at layer 2, and feeding it upward
to the routing table.  OK, I'll live with that.

But the second is the MAC.  With a shared media, you need one
(conversely, with point-point media you don't).  So capacity of the
layer 2 radio network is baseband capacity prorated across all the SS in
the segment .... minus the overhead used by the MAC.  In the case of
ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
gets worse as the segment gets more congested ... so one of the metrics
you would need to get hold of is how congested the network segment
is ... so you don't overload and stall it.

> 
> I would suggest adding a new TLV to DLEP with a single byte value to 
> signal this feature to the router. Establishing a codepoint for "no 
> mesh" and one for "mesh" should be enough for the basic DLEP draft, 
> other optional codepoints that signal more features of the radio 
> available to the router could be defined in later RFCs.

All the conventional radio networks commonly used in the internet
(802.11, 802.16, LTE) have the BS/SS asymmetry.  The one place I know
where this is not the case is in AIS, the distributed system whereby
ships report their lat/long positions.  I've not analyzed that MAC in
detail though.  
> 
> 
> 
> 
> 
> 9.X Mesh
> 
> The Mesh TLV is used in Peer Discovery and Peer Update messages to 
> indicate if the radio use a transparent layer-2 mesh to forward the traffic.
> 
> The Mesh TLV contains the following fields:
> 
>      0                   1                   2
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |TLV Type =TBD  |Length = 1     |Mesh Capability|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     TLV Type    -  TBD
> 
>     Length      -  1
> 
>     Mesh Capability -  Value 0 means the radio does not use mesh 
> forwarding on this DLEP interface. Value 1 means the radio does use mesh 
> forwarding, but do not provide further data about the feature.
> 
> 
> 
> Henning Rogge
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



From hrogge@googlemail.com  Tue Apr 23 09:35:45 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96221F96F4 for ; Tue, 23 Apr 2013 09:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UeZeDm5hdV7 for ; Tue, 23 Apr 2013 09:35:44 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D4FB021F96B1 for ; Tue, 23 Apr 2013 09:35:43 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id fp12so735992lab.18 for ; Tue, 23 Apr 2013 09:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qYZaNWCL2jICfpQHQiSpml4wVXuKaa9+YYGPzXPII1Q=; b=QaD6d3c6IJu7ocwTFNpmilZstMYKuK+ych//2J1yCkuM4sKg7A+T/j8hbtCL5gHl3G uCrkLgirhDuZtGdaMLD1CJw4WHzCaGTD9e7EFJhaUogUsKfQXa2hGHFSjt2SFON7oLhA G5c7OL9lDjiCq72QPU2rclJXQj4bXo0BVYufiTQyldyVIBJcxkmtpjVEoLKz9q7wqHiV G77bOMdjNkayzjRA9KxrU0HdLfUIKqeWS5jO3NHHZPaaBTeEV9wK8ZM5sIyM+i8XQ+EU 58Zvx9k27x/6cFcT4f56odCoiwLAMSQ9LNt04goDuxoQOhRG9yhgeMcJ+Q3mBwHZVcti cIWw==
X-Received: by 10.112.168.5 with SMTP id zs5mr15540427lbb.66.1366734942657; Tue, 23 Apr 2013 09:35:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.11.97 with HTTP; Tue, 23 Apr 2013 09:35:22 -0700 (PDT)
In-Reply-To: <1366732633.1720.14.camel@localhost>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>
From: Henning Rogge 
Date: Tue, 23 Apr 2013 18:35:22 +0200
Message-ID: 
To: Rex Buddenberg 
Content-Type: text/plain; charset=ISO-8859-1
Cc: MANET IETF 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 16:35:45 -0000

On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg  wrote:
> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:
>> Hi,
>>
>> as promised in the earlier review of DLEP-04, here are some more points
>> to discuss for DLEP link metrics.
>>
>>
>> Layer-2 traffic data
>> --------------------
>>
>> Many IP radios can easily keep track of the incoming and outgoing data
>> to its neighbors, both in terms of bytes and frames. This data is useful
>> for calculating routing metrics, so I would like to see statistic
>> metrics (as described in my private draft) as optional metrics for DLEP.
>
> At layer 3, routers are peer-peer.  But most radio networks at layer 2
> are not: a radio network segment (such as an LTE or 802.16 one) has a
> base station (BS) and several subscriber stations (SS).  BS has all
> kinds of this data readily at hand; a SS will only have metrics
> pertinent to that particular SS.  In these kinds of network segments,
> mining the SS that a router is attached to may not tell you important
> data -- rather, you want to mine the BS which may be attached to a
> different router.

Most MANET do not run on this "master/slave" style of networks, but we
should keep in mind that DLEP should also work for them.

>> This way manufacturers do not need to invent proprietary metric TLVs for
>> this data.
>
> While the data in the BS is not itself described in the standards (e.g.
> IEEE 802.16); the gozintas and gozoutas are very carefully described.
> There are about four dozen -- the upload map (UL-MAP) is the single most
> important one, but ranging messages will tell you a lot about link
> quality if you wiretap them ... or the database they go into.  We need
> not reinvent all these data notions.

Do you have a suggestion what are the most common/useful values
available in this kinds of networks?

>> Layer-2 mesh
>> ------------
>>
> Henning, we need to be careful about the term 'mesh'.  It's been badly
> abused and poorly defined ... and if you've been raised with
> fiber/copper underlying connectivity, the set of assumptions changes
> (you got that part), but it changes in some ways that you didn't get.

I used "mesh" as a layer-2 MANET technology... 802.11s for example, or
BATMAN Advanced as it is included in the Linux Kernel.

>> It seems that many IP radios try to establish a transparent layer-2 mesh
>> between the radios on the same channel. The fact that the linklayer
>> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
>> it allows an implementation to optimize its flooding and forwarding
>> routings (by not using two-hop routes within the layer-2 mesh domain).
>
> There are two issues here that need to be disentangled.
>
> The first is knowledge of connectivity at layer 2, and feeding it upward
> to the routing table.  OK, I'll live with that.
>
> But the second is the MAC.  With a shared media, you need one
> (conversely, with point-point media you don't).  So capacity of the
> layer 2 radio network is baseband capacity prorated across all the SS in
> the segment .... minus the overhead used by the MAC.  In the case of
> ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
> gets worse as the segment gets more congested ... so one of the metrics
> you would need to get hold of is how congested the network segment
> is ... so you don't overload and stall it.

I am not sure how this is connected to a "does/does-not layer-2 mesh"
TLV for DLEP.

>> I would suggest adding a new TLV to DLEP with a single byte value to
>> signal this feature to the router. Establishing a codepoint for "no
>> mesh" and one for "mesh" should be enough for the basic DLEP draft,
>> other optional codepoints that signal more features of the radio
>> available to the router could be defined in later RFCs.
>
> All the conventional radio networks commonly used in the internet
> (802.11, 802.16, LTE) have the BS/SS asymmetry.  The one place I know
> where this is not the case is in AIS, the distributed system whereby
> ships report their lat/long positions.  I've not analyzed that MAC in
> detail though.

Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does not
include this asymmetry.

Henning Rogge

From sratliff@cisco.com  Tue Apr 23 09:52:51 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F921F9729 for ; Tue, 23 Apr 2013 09:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LJPDTFhtf1o for ; Tue, 23 Apr 2013 09:52:50 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DA3A421F971D for ; Tue, 23 Apr 2013 09:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5420; q=dns/txt; s=iport; t=1366735970; x=1367945570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eq0mbNKGedpbsC5Q4jUsV6/dea6X3S/5VxYQA35oCfQ=; b=ieTjE60u2PQPhnOYxRl04gRxRwmwRjwNKEBJ4f7cFYq1iXQL1c887eSD EBx4/D0cjU1fPTj2zFKi7Cf4gVgJeuEqbPC1k0KUaFnKTZbZxNWuptOGp zc4N2sCXqAtJzF2MNpC0Wt11DAHWOkOe+86MFhKK4ZPu4qzlOoSwOWNa2 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAKy7dlGtJV2d/2dsb2JhbABRgwY2wRyBBBZ0gh8BAQEDAQEBATc0CwULAgEIDgoKFBAhBgslAgQOBQiHegMJBgyuAYZYDYg+BIxRgiQCMQeCaGEDlTaNYoUfgw6CKA
X-IronPort-AV: E=Sophos;i="4.87,536,1363132800"; d="scan'208";a="202040840"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2013 16:52:49 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3NGqnsh027779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Apr 2013 16:52:49 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 11:52:48 -0500
From: "Stan Ratliff (sratliff)" 
To: Henning Rogge 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQALFuziAeW0oH0a4VE5B/25X2JjkSjyAgAAKqQCAAATfAA==
Date: Tue, 23 Apr 2013 16:52:48 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.54.113]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8A9CE1068D31FF4BB1C357666846A9CD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MANET IETF 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 16:52:51 -0000

On Apr 23, 2013, at 12:35 PM, Henning Rogge wrote:

> On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg  w=
rote:
>> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:
>>> Hi,
>>>=20
>>> as promised in the earlier review of DLEP-04, here are some more points
>>> to discuss for DLEP link metrics.
>>>=20
>>>=20
>>> Layer-2 traffic data
>>> --------------------
>>>=20
>>> Many IP radios can easily keep track of the incoming and outgoing data
>>> to its neighbors, both in terms of bytes and frames. This data is usefu=
l
>>> for calculating routing metrics, so I would like to see statistic
>>> metrics (as described in my private draft) as optional metrics for DLEP=
.
>>=20
>> At layer 3, routers are peer-peer.  But most radio networks at layer 2
>> are not: a radio network segment (such as an LTE or 802.16 one) has a
>> base station (BS) and several subscriber stations (SS).  BS has all
>> kinds of this data readily at hand; a SS will only have metrics
>> pertinent to that particular SS.  In these kinds of network segments,
>> mining the SS that a router is attached to may not tell you important
>> data -- rather, you want to mine the BS which may be attached to a
>> different router.
>=20
> Most MANET do not run on this "master/slave" style of networks, but we
> should keep in mind that DLEP should also work for them.

Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.

>=20
>>> This way manufacturers do not need to invent proprietary metric TLVs fo=
r
>>> this data.
>>=20
>> While the data in the BS is not itself described in the standards (e.g.
>> IEEE 802.16); the gozintas and gozoutas are very carefully described.
>> There are about four dozen -- the upload map (UL-MAP) is the single most
>> important one, but ranging messages will tell you a lot about link
>> quality if you wiretap them ... or the database they go into.  We need
>> not reinvent all these data notions.
>=20
> Do you have a suggestion what are the most common/useful values
> available in this kinds of networks?

This is (to some extent) what I was afraid of - the notion of adding 4 doze=
n TLV's to DLEP is a bit daunting. ;-) Hopefully, we can reach consensus on=
 this issue before too much time expires.=20

>=20
>>> Layer-2 mesh
>>> ------------
>>>=20
>> Henning, we need to be careful about the term 'mesh'.  It's been badly
>> abused and poorly defined ... and if you've been raised with
>> fiber/copper underlying connectivity, the set of assumptions changes
>> (you got that part), but it changes in some ways that you didn't get.
>=20
> I used "mesh" as a layer-2 MANET technology... 802.11s for example, or
> BATMAN Advanced as it is included in the Linux Kernel.
>=20
>>> It seems that many IP radios try to establish a transparent layer-2 mes=
h
>>> between the radios on the same channel. The fact that the linklayer
>>> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
>>> it allows an implementation to optimize its flooding and forwarding
>>> routings (by not using two-hop routes within the layer-2 mesh domain).
>>=20
>> There are two issues here that need to be disentangled.
>>=20
>> The first is knowledge of connectivity at layer 2, and feeding it upward
>> to the routing table.  OK, I'll live with that.
>>=20
>> But the second is the MAC.  With a shared media, you need one
>> (conversely, with point-point media you don't).  So capacity of the
>> layer 2 radio network is baseband capacity prorated across all the SS in
>> the segment .... minus the overhead used by the MAC.  In the case of
>> ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
>> gets worse as the segment gets more congested ... so one of the metrics
>> you would need to get hold of is how congested the network segment
>> is ... so you don't overload and stall it.
>=20
> I am not sure how this is connected to a "does/does-not layer-2 mesh"
> TLV for DLEP.

In the case described above, I could see SS-to-SS connectivity (via the BS)=
 to be a kind-of-sort-of "mesh" connection. Goes back to the statement that=
 "mesh" is poorly defined.=20

>=20
>>> I would suggest adding a new TLV to DLEP with a single byte value to
>>> signal this feature to the router. Establishing a codepoint for "no
>>> mesh" and one for "mesh" should be enough for the basic DLEP draft,
>>> other optional codepoints that signal more features of the radio
>>> available to the router could be defined in later RFCs.
>>=20
>> All the conventional radio networks commonly used in the internet
>> (802.11, 802.16, LTE) have the BS/SS asymmetry.  The one place I know
>> where this is not the case is in AIS, the distributed system whereby
>> ships report their lat/long positions.  I've not analyzed that MAC in
>> detail though.
>=20
> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does not
> include this asymmetry.

That reminds me of a statement a college professor made. Something along th=
e lines of "No one in their right mind will ever use 802.11 adhoc. For anyt=
hing."  So please forgive me if I find the Wifi/Adhoc example irrelevant.

Regards,
Stan


>=20
> Henning Rogge
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From prvs=78250619bd=bcheng@ll.mit.edu  Tue Apr 23 09:56:46 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1AE21F974A for ; Tue, 23 Apr 2013 09:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RTjdIlo6Tim for ; Tue, 23 Apr 2013 09:56:42 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8121F96F7 for ; Tue, 23 Apr 2013 09:56:41 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r3NGudcn021226 for ; Tue, 23 Apr 2013 12:56:40 -0400
From: "Cheng, Bow-Nan - 0665 - MITLL" 
To: "manet@ietf.org" 
Date: Tue, 23 Apr 2013 12:56:36 -0400
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: Ac5AQ4W0w6Tl3LZ/SE+CTcrMtyeBbA==
Message-ID: 
In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50221D1F@XCH-BLV-503.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3449566596_19898571"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-23_06:2013-04-23, 2013-04-23, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304230154
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 16:56:46 -0000

--B_3449566596_19898571
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I like the concept of having some sort of "hop-count" metric to support
the layer 2 "mesh routing". The reason for this instead of a boolean
yes/no is that the layer 3 routing protocol can filter on 1-hop routes to
prevent double-routing.





On 4/23/13 9:25 AM, "Duke, Martin"  wrote:

>I support the addition of this metric, as we're dealing with radios that
>have this capability. But while we're spending a byte anyway, why not
>simply report the layer-2 hop count to the neighbor?
>
>Martin Duke
>Boeing
>
>-----Original Message-----
>From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
>Henning Rogge
>Sent: Tuesday, April 23, 2013 2:13 AM
>To: manet@ietf.org
>Subject: [manet] DLEP link metric discussion
>
>Hi,
>
>as promised in the earlier review of DLEP-04, here are some more points
>to discuss for DLEP link metrics.
>
>
>Layer-2 traffic data
>--------------------
>
>Many IP radios can easily keep track of the incoming and outgoing data
>to its neighbors, both in terms of bytes and frames. This data is useful
>for calculating routing metrics, so I would like to see statistic
>metrics (as described in my private draft) as optional metrics for DLEP.
>
>This way manufacturers do not need to invent proprietary metric TLVs for
>this data.
>
>
>
>Layer-2 mesh
>------------
>
>It seems that many IP radios try to establish a transparent layer-2 mesh
>between the radios on the same channel. The fact that the linklayer
>forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
>it allows an implementation to optimize its flooding and forwarding
>routings (by not using two-hop routes within the layer-2 mesh domain).
>
>I would suggest adding a new TLV to DLEP with a single byte value to
>signal this feature to the router. Establishing a codepoint for "no
>mesh" and one for "mesh" should be enough for the basic DLEP draft,
>other optional codepoints that signal more features of the radio
>available to the router could be defined in later RFCs.
>
>
>
>
>
>9.X Mesh
>
>The Mesh TLV is used in Peer Discovery and Peer Update messages to
>indicate if the radio use a transparent layer-2 mesh to forward the
>traffic.
>
>The Mesh TLV contains the following fields:
>
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =3DTBD  |Length =3D 1     |Mesh Capability|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type    -  TBD
>
>    Length      -  1
>
>    Mesh Capability -  Value 0 means the radio does not use mesh
>forwarding on this DLEP interface. Value 1 means the radio does use mesh
>forwarding, but do not provide further data about the feature.
>
>
>
>Henning Rogge
>--
>Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>Kommunikationssysteme (KOM)
>Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>Telefon +49 228 9435-961,   Fax +49 228 9435 685
>mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www.ietf.org/mailman/listinfo/manet

--B_3449566596_19898571
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUBAYJKoZIhvcNAQcCoIIT9TCCE/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EecwggTNMIIDtaADAgECAgpmR0phAAAAAFLvMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR
BgNVBAMTCk1JVExMIENBLTIwHhcNMTIwOTI2MTgwODE3WhcNMTMwOTI2MTgwODE3WjBgMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG
UGVvcGxlMR8wHQYDVQQDExZDaGVuZy5Cb3ctTmFuLjUwMDEwNzM5MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA0LdTMTV8InyZdZ0vdcELnmJ9TDZExAe1BZ/RUnaOUocBklSr
2GNhq10z3FCDuPU5MSLRPplWU2kVe4iZMTPizeGTbUaKk5lXH7ebZMOiuM4Nj/zUz+rg4S6A
4YwvTnNZwjtUfyxHap7khBmmVruX7YPk+XKaJg8QQuCoGp7uNWmVPR1a4rnusVop05BuMJMX
xvfLgH1+5/LiSxSse67srzOyYijiTwOqC41t5yCvDJ80DxlXbSsGnqGIp6FyRcMv9Bdgtrrm
nH24z+TcQYixSBfgRmIwMJ8Y9l950RYytXIJxYsxMefM2I2WeAm5ii0bpdXLQaoZ+fgg6H/O
QnGy7QIDAQABo4IBljCCAZIwHQYDVR0OBBYEFCdenk/MFEee1t9lrnD2yvkq0o8sMA4GA1Ud
DwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3JkVeGYp+JDAzBgNVHR8ELDAq
MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EyMGIGCCsGAQUFBwEB
BFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EyMCMG
CCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8EAjAAMD0GCSsG
AQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFk
AgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL
KoZIhvcSAgEDAQgwHAYDVR0RBBUwE4ERYmNoZW5nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEL
BQADggEBAJBwHIp50DE1iqaCZCM//pYWNGyrh+qv83P+GBKHeJMMROD1bTxXDrQF3qr1+ZNm
378Oz31rEo6l154BbgjdvMVocYqPP8x+Cr+CsAHFvTNAvPDCF1UmgWmMP6pWO4+wGX+k2MBI
TxSrJDaSxX0SI4cdNLwJLO63D4JdcvJeqVNNoOCIZYMoieQVP4r3hHmki/zJP73wl77uK/LW
Ff0rC2s3kkZ769SPG4ul6LTYSIRSMnliKpFy5Ay+A9Wx+EgUeIGzIwDPhirP1jO+OZFij7RL
DcgODGSZoN2NkeXkM8iGVFEBfVKdDauU+6oGYx1A5mo2I5hde8IMpO0LcWLgYCMwggS3MIID
n6ADAgECAgEUMA0GCSqGSIb3DQEBCwUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg
TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwHhcNMDkxMjE0MTIwMDAwWhcNMTUxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0G
A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpN
SVRMTCBDQS0yMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApwTLI2FIh+w3oDMH
BWFmTOjpJ2M0YBDuYDYDxPSSZ0IHwwfqNaNVUzAVnCWD1yCOAsoS4Q70o3wr0zyOB5kQyiKe
VF+TdgQs8LuwSSTMFCRxWkuETAAu572IejCBIsaZdmlgqZGF++G9gngw0K4hpalwr8ZoNkIT
5TZpODjaS//NCsfcCioVfzU4XueLBc2dqc/WFBF+QxNGudoRbwNfRMxob+31HLnFIystM1z0
O9C2MDlly5acQKJSnIMEVbEuv3LHvGB/X8vCALFygF4pIEGhbORCYoCyAyj0yrUWn+ecirDk
UqaA6ztXL7p7QOT5yB/6gBXwArxkUxCtUTS4fQIDAQABo4IBlTCCAZEwEgYDVR0TAQH/BAgw
BgEB/wIBADAdBgNVHQ4EFgQUjkp9iaFjFxyBiDRXNyZFXhmKfiQwHwYDVR0jBBgwFoAUZ6p6
z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/BAQDAgGGMGEGCCsGAQUFBwEBBFUwUzAtBggr
BgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5sbC5taXQuZWR1MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu
bGwubWl0LmVkdS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjAN
BgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xIC
AQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsq
hkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAiHcGodD9cfwLoMIv54Qaug7PEFwKpM0i
2ay/gwA1o5Oh2BTaOuMdwaNeXOqGlvxnE6WQArd0rT2tzr7IAJygrZPNW0NFldjGi/9KplGM
jd259TYlq0A/GiwLLL/Wi2OXVMpRjjta9+3fW91/mLRcrYNBUQn5eWq2AGIVNUgwh8EnA9qO
uyLP6mAURjCGHAnG+zx+VKLQUsITvtVgsSKg/mHEbrMg95BHHOHVuiBt+mFYce2iJMOQFJnh
R+8ZdBNV/tCOEPnJjDXTIgK2Mea2Bt+AGQfn++9H3Y1j1FKU0/NmqYYoiJrrVskKZqBFgbJ7
F951U0XRwlYvgn9wseGA1jCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkG
A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL
STEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5
NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/V
UkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012E
CHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4Yq
SevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02R
XDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqD
AgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDD
Q+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX
9Nqg1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mL
WbZ4G+g4HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z
4zbj3YCXzt3dVqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6Mq
lhZx9ipDcUZ/ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0
ADCCBNAwggO4oAMCAQICCh/XPXQAAAAALD0wDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEG
A1UEAxMKTUlUTEwgQ0EtMjAeFw0xMTExMzAxOTI1MjJaFw0xMjExMjkxOTI1MjJaMGAxCzAJ
BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ
ZW9wbGUxHzAdBgNVBAMTFkNoZW5nLkJvdy1OYW4uNTAwMTA3MzkwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDdxmrHWxnUaFSfiNUM8BV5wFyFsFt1SiKmvJN0Ui77veb97y2D
ffUdKIOZYmIvZ2g9saQBXkwUxPYDqh8FzEw3QNIOVcLuDytMVKMyS1BGSOSTw/daRiL9ZMT0
ZMz3+adWtG8LHWb0vZcbXI8R2/nBZfiBWd+0cKj9RKjBuRfYxr/DL4kn2r2d1EsrGqR7CM5o
SeUAduukVNgoCb4G3XDS37MnkSMSB1OWgMLFGn9oShzAxHTyZmdhAfCdafUgwLzjjE6usPQr
5zOuoegdUw7gALD/XbXn9pKFfT12p4YgKFrfCBt0CkMTOzG7GQkgn/Xcl+aYvzb53bG6IdZ3
/8HvAgMBAAGjggGZMIIBlTAdBgNVHQ4EFgQUFrle2xdmVOWJjyy2lmom3/rMKeIwDgYDVR0P
AQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCow
KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEE
VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYI
KwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYB
BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQC
AQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzAN
BgsqhkiG9xICAQMBCDAcBgNVHREEFTATgRFiY2hlbmdAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAdnUkMV+GYalb1DvK3d1sLeQB2adomR3BR+A+f+1S22CoOZwaIyxDa48zf5id
xCVfnKWY6fn/AuB4oGEW7qndwwEQe9tL5jUky4EMWLsw3HRLtt0Jj/dz6p0rQN0THwNcPgI7
TCU97INZW1TVNmYhAbAcWZpskNXS8IKdkD9wvombF0VI8gXZqrXuQkrI2bXe0ojDZrdGgfbt
/TO/nxz5awxR4EoECQD6uYCtxngx26DkvLoVUab5dYqlAxirJdC0gpvSbRVBNuv+FgU6xQsN
eLknKxcNyOZ9f3if4u04b4B/0k9qZjmvBKtYT6PIyN+iiotFcmvOJhbQcViYND+lQzGCAeUw
ggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZkdKYQAAAABS7zAJBgUr
DgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFFfN0veTWyqxHmBOcGGl2ztmJ6FTMBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDQyMzE2NTYzNlowDQYJKoZI
hvcNAQEBBQAEggEAgYttNYVrXE1cRdrDgyNlrplhK0szR3lKtsg2dI8szJPfQfV838I8q8aj
KnIXmXKA8w36m0RHkYRifNkXgufSTniHqs7+TS5ywSE2C+0CvqSIYTgkC7uQfU1YDIIgUd65
Oe1wY7/Odj29B3e9hJEOFFykxecknWnCmcE5J/Po++4h2XBc+nfL6RggIWbLX0fIbIFqbb6U
5ueepEjvzdndsvqQ1KnKKBWxAbJ3qv6EYMWFYYwG5LkSsdF6Fq1TIfb+TSncw33R/S0Uy9aG
EU576Qo7RGjTRil7aOCRCge1QhHG67idZrmMsK6R2pedtcVLGL4ENFriRLsZdfokhTfqfQ==

--B_3449566596_19898571--

From buddenbergr@gmail.com  Tue Apr 23 10:44:31 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282E121F8C1A for ; Tue, 23 Apr 2013 10:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GiCUMFUW5La for ; Tue, 23 Apr 2013 10:44:30 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id C196C21F8BE9 for ; Tue, 23 Apr 2013 10:44:22 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id g10so584036pdj.20 for ; Tue, 23 Apr 2013 10:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=YJ4MG5iGUZ/3Wy7kv4QJX/Y30Fg0izxKA/S5lNzLKsw=; b=Dqy2INvOwZsbIz8Hj8CERW4KxnMDJcrXY25vBQayG2cGp2DJRWNkE11m4LheuuwCQa oYi5Z5BE6S0uT/KDp7JsMFlFEcvTwg0EfF3IvMh3DbNxMtM0Xg/aOOlW2Pd2do3vBIEX lN9mcVmCFEdThhL4S664FCstMHIOxhZEfrpAJSbJs6R0qLffbBfQKZQc5aQnAyWqVXt9 hsIONntXTKxS3kCbMFj1GeyJKYa8mIhWcp42v/5PI9G1ZfYi3Kxi3fJlV1u8N5Q0xHkq FdPl+ZtPOJH3C/SjM1EAUJ+mStLJSQ0omvT0w0VfUy+ZiRGvxH6mKlDdvoHK23kHCP0+ pQUw==
X-Received: by 10.68.113.65 with SMTP id iw1mr42246334pbb.31.1366739062581; Tue, 23 Apr 2013 10:44:22 -0700 (PDT)
Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPS id do4sm30380353pbc.8.2013.04.23.10.44.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Apr 2013 10:44:00 -0700 (PDT)
Message-ID: <1366739039.1720.41.camel@localhost>
From: Rex Buddenberg 
To: "Stan Ratliff (sratliff)" 
Date: Tue, 23 Apr 2013 10:43:59 -0700
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: MANET IETF 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 17:44:31 -0000

On Tue, 2013-04-23 at 16:52 +0000, Stan Ratliff (sratliff) wrote:
> 
> >> While the data in the BS is not itself described in the standards
> (e.g.
> >> IEEE 802.16); the gozintas and gozoutas are very carefully
> described.
> >> There are about four dozen -- the upload map (UL-MAP) is the single
> most
> >> important one, but ranging messages will tell you a lot about link
> >> quality if you wiretap them ... or the database they go into.  We
> need
> >> not reinvent all these data notions.
> > 
> > Do you have a suggestion what are the most common/useful values
> > available in this kinds of networks?
> 
> This is (to some extent) what I was afraid of - the notion of adding 4
> dozen TLV's to DLEP is a bit daunting. ;-) Hopefully, we can reach
> consensus on this issue before too much time expires. 

Agree that 4 dozen is daunting; and some of these messages are necessary
to the internal workings of the network segment and need not be visible
outside.  I'd suggest that the place to look is in the MIB which is
where the values represented in these messages would roost.


From jasteven@rockwellcollins.com  Tue Apr 23 12:14:50 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D7B21F974C for ; Tue, 23 Apr 2013 12:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exPCYSfhwrUh for ; Tue, 23 Apr 2013 12:14:46 -0700 (PDT)
Received: from secvs02.rockwellcollins.com (secvs02.rockwellcollins.com [205.175.225.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6064521F9748 for ; Tue, 23 Apr 2013 12:14:46 -0700 (PDT)
Received: from nosuchhost.198.131.in-addr.arpa (HELO collinscrsmtp02.rockwellcollins.com) ([131.198.63.133]) by mail-virt.rockwellcollins.com with ESMTP; 23 Apr 2013 14:14:45 -0500
In-Reply-To: 
References: 
X-Disclaimed: 59746
To: manet@ietf.org
MIME-Version: 1.0
X-KeepSent: 78D714DC:9ACF7A7C-86257B56:0069339E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP1 November 30, 2010
From: jasteven@rockwellcollins.com
Message-ID: 
Date: Tue, 23 Apr 2013 14:14:44 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5.2FP2 HF162|May 16, 2011) at 04/23/2013 02:14:46 PM, Serialize complete at 04/23/2013 02:14:46 PM
Content-Type: multipart/alternative; boundary="=_alternative 0069B84986257B56_="
Subject: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed or not
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 19:14:50 -0000

This is a multipart message in MIME format.
--=_alternative 0069B84986257B56_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

|On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg wrote:
|> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:
|>
|>> It seems that many IP radios try to establish a transparent layer-2=20
mesh
|>> between the radios on the same channel. The fact that the linklayer
|>> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
|>> it allows an implementation to optimize its flooding and forwarding
|>> routings (by not using two-hop routes within the layer-2 mesh domain).
|>
|> There are two issues here that need to be disentangled.
|>
|> The first is knowledge of connectivity at layer 2, and feeding it=20
upward
|> to the routing table.  OK, I'll live with that.
|>
|> But the second is the MAC.  With a shared media, you need one
|> (conversely, with point-point media you don't).  So capacity of the
|> layer 2 radio network is baseband capacity prorated across all the SS=20
in
|> the segment .... minus the overhead used by the MAC.  In the case of
|> ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
|> gets worse as the segment gets more congested ... so one of the metrics
|> you would need to get hold of is how congested the network segment
|> is ... so you don't overload and stall it.
|
|I am not sure how this is connected to a "does/does-not layer-2 mesh"
|TLV for DLEP.

I claim that
1. Performance is sometimes worse when IP routers arbitrarily work around=20
multihop (mesh) routing below IP - so router-to-router interfaces, such as =

DLEP, should support mesh wireless networks, and
2. IP routers can make an informed decision based upon metric information=20
without having to know if the layer-2 is a mesh radio network or not.


1.  Performance is sometimes worse when IP routers work around multihop=20
(mesh) routing below IP - so router-to-router interfaces, such as DLEP,=20
should support mesh wireless networks.

All of the IP broadcast (and some of the directional) military ad hoc=20
networking waveforms that I know of perform multihop (mesh) networking at=20
layer 2 below IP (analogous to how 802.3 bridge is multihop below IP).=20
Note that I use the term ?networking waveform? to be equivalent to a radio =

with layer 2 mesh networking and MAC.

The multihop routing below IP is to enable optimized cross-layer=20
optimization between the mesh routing and the MAC to minimize interference =

and, in many cases, to optimize spatial reuse of spectrum, especially for=20
multicast/broadcast traffic in broadcast (omnidirectional) MACs.

Some example multihop routing/MAC cross-layer techniques include:
- multicast/broadcast spectrum (time slot) allocations to maximize spatial =

reuse capacity depending upon traffic and topology
- network coding from overhead transmissions from multiple nodes
- passive (rather than active) acknowledgement using overheard=20
transmission of next radio hop
- adaptive routing on transmission by transmission basis depending upon=20
what next few spectrum allocations are coming up

For example, consider a 5 node IP network {A, B, C, D, E} with 2=20
networking waveforms radios (i.e. multihop ad hoc layer 2 networks) at=20
each node.  The first radio has a narrowband (low data rate) waveform with =

long transmission range with following links {A-B, B-C, C-D, C-E, and=20
D-E}.  The second radio has a wideband (high data rate) waveform with=20
short transmission range with the following links {C=3DD, C=3DE, and D=3DE}=
.=20
Note that although nodes A and B have wideband radios, they don?t have any =

wideband links due to the long distance.

     Narrowband waveform connectivity:
                              +---+
                              |   |
          +---------+---------+-+-+
          |         |         | | |
          A         B         C D E
          +         +         +=3D+=3D+
                              +=3D=3D=3D+
     Wideband waveform connectivity:

The IP narrowband metric from node X to Y is (x-y).  E.g. the narrowband=20
IP link from node C to E is (c-e).

The IP wideband metric from node X to Y is (X-Y).  E.g. the wideband link=20
from node C to E is (C-E).

Now the layer 2 networks optimize the shared spectrum through cross layer=20
optimization, so that sometimes (a-c) is better than (a-b) and (b-c)=20
depending upon scenario.  Similarly, (C=3DE) is sometimes better than (C=3D=
D)=20
and (D=3DE).

However, because the wideband layer 2 network has better performance,
(a-c) and (C=3DE) is better than (a-e).

Thus, the IP Router at radio node A will select node C as the next IP hop=20
in the IP route to E.


2. IP routers can make an informed decision based upon metric information=20
without having to know if the layer-2 is a mesh radio network or not.

I think that radio-to-router interfaces, such as DLEP, should allow the=20
networking waveform in the radio to advertise the MAC address of the next=20
IP neighbor whether than IP neighbor is one or more IP hops away. (From my =

reading of draft-ietf-manet-dlep-04.pdf, I think that DLEP would support=20
either IP neighbors that are one RF hop away or multiple RF hops away.)

Thus, in the example above, the IP router at A can get radio link=20
information to the IP routers at the other nodes, whether they are one or=20
more radio-hops away.  The routers can then look at the metrics to make=20
the choice on whether to go in a single IP hop route or multiple IP hop=20
route across the networks.

I.e. if (a-c) is better than (a-b) and (b-c), then the router at A would=20
route directly to IP router at C rather than routing via IP router at B=20
using the knowledge of the metrics without having to know that the radio=20
was a mesh network.



Jim Stevens






--=_alternative 0069B84986257B56_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

|On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg wrote:<=
br>
|> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:

|>

|>> It seems that many IP radios try to establ=
ish
a transparent layer-2 mesh

|>> between the radios on the same channel. The fact that the linklay=
er

|>> forms a mesh is useful knowledge for a layer-3 MANET routing
protocol,

|>> it allows an implementation to optimize its flooding and forwardi=
ng

|>> routings (by not using two-hop routes within the layer-2 mesh
domain).

|>

|> There are two issues here that need to be disentangled.

|>

|> The first is knowledge of connectivity at layer 2, and feeding it
upward

|> to the routing table.  OK, I'll live with that.

|>

|> But the second is the MAC.  With a shared media, you need one

|> (conversely, with point-point media you don't).  So capacity
of the

|> layer 2 radio network is baseband capacity prorated across all the
SS in

|> the segment .... minus the overhead used by the MAC.  In the
case of

|> ethernet derivatives (like WiFi), that overhead may reach 80%!  =
And
it

|> gets worse as the segment gets more congested ... so one of the metri=
cs

|> you would need to get hold of is how congested the network segment

|> is ... so you don't overload and stall it.

|

|I am not sure how this is connected to a "does/does-not layer-2 mesh&=
quot;

|TLV for DLEP.



I claim that

1. Performance is sometimes worse when IP routers
arbitrarily work around multihop (mesh) routing below IP - so router-to-rou=
ter
interfaces, such as DLEP, should support mesh wireless networks, and=


2. IP routers can make an informed decision based
upon metric information without having to know if the layer-2 is a mesh
radio network or not.





1.  Performance is sometimes worse when IP rout=
ers
work around multihop (mesh) routing below IP - so router-to-router interfac=
es,
such as DLEP, should support mesh wireless networks.



All of the IP broadcast (and some of the directional)
military ad hoc networking waveforms that I know of perform multihop (mesh)
networking at layer 2 below IP (analogous to how 802.3 bridge is multihop
below IP).  Note that I use the term “networking waveform”=
 to be
equivalent to a radio with layer 2 mesh networking and MAC.



The multihop routing below IP is to enable optimized
cross-layer optimization between the mesh routing and the MAC to minimize
interference and, in many cases, to optimize spatial reuse of spectrum,
especially for multicast/broadcast traffic in broadcast (omnidirectional)
MACs.



Some example multihop routing/MAC cross-layer techni=
ques
include:

- multicast/broadcast spectrum (time slot) allocatio=
ns
to maximize spatial reuse capacity depending upon traffic and topology

- network coding from overhead transmissions from
multiple nodes

- passive (rather than active) acknowledgement using
overheard transmission of next radio hop

- adaptive routing on transmission by transmission
basis depending upon what next few spectrum allocations are coming up



For example, consider a 5 node IP network {A, B, C,
D, E} with 2 networking waveforms radios (i.e. multihop ad hoc layer 2
networks) at each node.  The first radio has a narrowband (low data
rate) waveform with long transmission range with following links {A-B,
B-C, C-D, C-E, and D-E}.  The second radio has a wideband (high data
rate) waveform with short transmission range with the following links {C=3D=
D,
C=3DE, and D=3DE}.  Note that although nodes A and B have wideband rad=
ios,
they don’t have any wideband links due to the long distance.



     Narrowband waveform connectivity=
:

              &nb=
sp;
              +---+

              &nb=
sp;
              |   |

          +---------+------=
---+-+-+

          |    
    |         | | |

          A    
    B         C D E

          +    
    +         +=3D+=3D+

              &nb=
sp;
              +=3D=3D=3D+

     Wideband waveform connectivity:<=
/font>



The IP narrowband metric from node X to Y is (x-y).
 E.g. the narrowband IP link from node C to E is (c-e).



The IP wideband metric from node X to Y is (X-Y).
 E.g. the wideband link from node C to E is (C-E).



Now the layer 2 networks optimize the shared spectrum
through cross layer optimization, so that sometimes (a-c) is better than
(a-b) and (b-c) depending upon scenario.  Similarly, (C=3DE) is someti=
mes
better than (C=3DD) and (D=3DE).



However, because the wideband layer 2 network has
better performance,

(a-c) and (C=3DE) is better than (a-e).



Thus, the IP Router at radio node A will select node
C as the next IP hop in the IP route to E.





2. IP routers can make an informed decision based
upon metric information without having to know if the layer-2 is a mesh
radio network or not.



I think that radio-to-router interfaces, such as DLE=
P,
should allow the networking waveform in the radio to advertise the MAC
address of the next IP neighbor whether than IP neighbor is one or more
IP hops away. (From my reading of draft-ietf-manet-dlep-04.pdf, I think
that DLEP would support either IP neighbors that are one RF hop away or
multiple RF hops away.)



Thus, in the example above, the IP router at A can
get radio link information to the IP routers at the other nodes, whether
they are one or more radio-hops away.  The routers can then look at
the metrics to make the choice on whether to go in a single IP hop route
or multiple IP hop route across the networks.



I.e. if (a-c) is better than (a-b) and (b-c), then
the router at A would route directly to IP router at C rather than routing
via IP router at B using the knowledge of the metrics without having to
know that the radio was a mesh network.







Jim Stevens












--=_alternative 0069B84986257B56_=--

From sratliff@cisco.com  Tue Apr 23 12:54:13 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5D21F8EAC for ; Tue, 23 Apr 2013 12:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbTKOZMBKsZ5 for ; Tue, 23 Apr 2013 12:54:12 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4F21F8E98 for ; Tue, 23 Apr 2013 12:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17528; q=dns/txt; s=iport; t=1366746850; x=1367956450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=82fiMyKXNOIFfvzyQF+6hmyGw1gIud8/wDlIElRdjHo=; b=a1pDj4ZRDWBMqS1z0NKaQLEu123lefBFNXGD7KZ7uZLCP3q2DONEgi/A I5hn0e55yywtFsp9jEGpsOAeAcoGlYSAIYs96+3+YLmkNMPfLPojQ/+O6 yD5ORxEIci2/QWH2GCJrHXTPnID07+tBbxUmVvTCpU1CT9mv4fD34NpNE U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAKHkdlGtJV2a/2dsb2JhbABRgwbBVIEFFnSCHwEBAQR5EAIBCBcLHQcyFAkIAgQOBQiIDK5djzaOdzEHgmhhA6g3gw6CKA
X-IronPort-AV: E=Sophos;i="4.87,536,1363132800";  d="scan'208,217";a="199197338"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 23 Apr 2013 19:54:08 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3NJs8rT003109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Apr 2013 19:54:08 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 14:54:07 -0500
From: "Stan Ratliff (sratliff)" 
To: "  " 
Thread-Topic: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed	or not
Thread-Index: AQHOQFbWI8aQ3pVTqEarOY6ro74Ec5jki8MA
Date: Tue, 23 Apr 2013 19:54:06 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C473A@xmb-aln-x03.cisco.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.54.113]
Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100C473Axmbalnx03ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed	or not
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 19:54:13 -0000

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100C473Axmbalnx03ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Jim,

On Apr 23, 2013, at 3:14 PM, >
 > wrote:

|On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg wrote:
|> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote:
|>
|>> It seems that many IP radios try to establish a transparent layer-2 mes=
h
|>> between the radios on the same channel. The fact that the linklayer
|>> forms a mesh is useful knowledge for a layer-3 MANET routing protocol,
|>> it allows an implementation to optimize its flooding and forwarding
|>> routings (by not using two-hop routes within the layer-2 mesh domain).
|>
|> There are two issues here that need to be disentangled.
|>
|> The first is knowledge of connectivity at layer 2, and feeding it upward
|> to the routing table.  OK, I'll live with that.
|>
|> But the second is the MAC.  With a shared media, you need one
|> (conversely, with point-point media you don't).  So capacity of the
|> layer 2 radio network is baseband capacity prorated across all the SS in
|> the segment .... minus the overhead used by the MAC.  In the case of
|> ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
|> gets worse as the segment gets more congested ... so one of the metrics
|> you would need to get hold of is how congested the network segment
|> is ... so you don't overload and stall it.
|
|I am not sure how this is connected to a "does/does-not layer-2 mesh"
|TLV for DLEP.

I claim that
1. Performance is sometimes worse when IP routers arbitrarily work around m=
ultihop (mesh) routing below IP - so router-to-router interfaces, such as D=
LEP, should support mesh wireless networks, and
2. IP routers can make an informed decision based upon metric information w=
ithout having to know if the layer-2 is a mesh radio network or not.


1.  Performance is sometimes worse when IP routers work around multihop (me=
sh) routing below IP - so router-to-router interfaces, such as DLEP, should=
 support mesh wireless networks.

All of the IP broadcast (and some of the directional) military ad hoc netwo=
rking waveforms that I know of perform multihop (mesh) networking at layer =
2 below IP (analogous to how 802.3 bridge is multihop below IP).  Note that=
 I use the term =93networking waveform=94 to be equivalent to a radio with =
layer 2 mesh networking and MAC.

The multihop routing below IP is to enable optimized cross-layer optimizati=
on between the mesh routing and the MAC to minimize interference and, in ma=
ny cases, to optimize spatial reuse of spectrum, especially for multicast/b=
roadcast traffic in broadcast (omnidirectional) MACs.

Some example multihop routing/MAC cross-layer techniques include:
- multicast/broadcast spectrum (time slot) allocations to maximize spatial =
reuse capacity depending upon traffic and topology
- network coding from overhead transmissions from multiple nodes
- passive (rather than active) acknowledgement using overheard transmission=
 of next radio hop
- adaptive routing on transmission by transmission basis depending upon wha=
t next few spectrum allocations are coming up

For example, consider a 5 node IP network {A, B, C, D, E} with 2 networking=
 waveforms radios (i.e. multihop ad hoc layer 2 networks) at each node.  Th=
e first radio has a narrowband (low data rate) waveform with long transmiss=
ion range with following links {A-B, B-C, C-D, C-E, and D-E}.  The second r=
adio has a wideband (high data rate) waveform with short transmission range=
 with the following links {C=3DD, C=3DE, and D=3DE}.  Note that although no=
des A and B have wideband radios, they don=92t have any wideband links due =
to the long distance.

     Narrowband waveform connectivity:
                              +---+
                              |   |
          +---------+---------+-+-+
          |         |         | | |
          A         B         C D E
          +         +         +=3D+=3D+
                              +=3D=3D=3D+
     Wideband waveform connectivity:

The IP narrowband metric from node X to Y is (x-y).  E.g. the narrowband IP=
 link from node C to E is (c-e).

The IP wideband metric from node X to Y is (X-Y).  E.g. the wideband link f=
rom node C to E is (C-E).

Now the layer 2 networks optimize the shared spectrum through cross layer o=
ptimization, so that sometimes (a-c) is better than (a-b) and (b-c) dependi=
ng upon scenario.  Similarly, (C=3DE) is sometimes better than (C=3DD) and =
(D=3DE).

However, because the wideband layer 2 network has better performance,
(a-c) and (C=3DE) is better than (a-e).

Thus, the IP Router at radio node A will select node C as the next IP hop i=
n the IP route to E.


2. IP routers can make an informed decision based upon metric information w=
ithout having to know if the layer-2 is a mesh radio network or not.

I think that radio-to-router interfaces, such as DLEP, should allow the net=
working waveform in the radio to advertise the MAC address of the next IP n=
eighbor whether than IP neighbor is one or more IP hops away. (From my read=
ing of draft-ietf-manet-dlep-04.pdf, I think that DLEP would support either=
 IP neighbors that are one RF hop away or multiple RF hops away.)

Yes, that's correct. In the current 04 version of DLEP, the router "doesn't=
 know, doesn't care" if the destination MAC is 1 or > 1 RF hops away. At le=
ast in the Cisco implementation, there is an implicit trust in the radio to=
 alter metrics accordingly - e.g. if you get into a situation where multipl=
e radio stations funnel through a single device in the middle of your netwo=
rk, the radios SHOULD downgrade metrics so as to avoid network collapse.


Thus, in the example above, the IP router at A can get radio link informati=
on to the IP routers at the other nodes, whether they are one or more radio=
-hops away.  The routers can then look at the metrics to make the choice on=
 whether to go in a single IP hop route or multiple IP hop route across the=
 networks.

I.e. if (a-c) is better than (a-b) and (b-c), then the router at A would ro=
ute directly to IP router at C rather than routing via IP router at B using=
 the knowledge of the metrics without having to know that the radio was a m=
esh network.



Jim Stevens




This helps me put my finger on what's bothering me about the proposal for a=
 Mesh TLV - essentially, the radio is working its fanny off to create a top=
ology, and we're trying to give the router to ability to say (in effect), "=
No, I don't think so", based on the value of this TLV. It just smells like =
a layer violation to me (or one that's about to happen).  If you're going t=
o trust the radio to carry the traffic, you should trust the radio to do it=
 in the most efficient manner possible, and trust the radio to give you the=
 correct metrics, based on the physical topology.

Regards,
Stan


--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100C473Axmbalnx03ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Jim, 






On Apr 23, 2013, at 3:14 PM, <jasteven@rockwellcollins.com>





|On Tue, Apr 23, 2013 at 5:5=
7 PM, Rex Buddenberg wrote:

|> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote: 

|> 

|>> It seems that many IP radios try to establis=
h a transparent layer-2 mesh

|>> between the radios on the same channel. The fact that the linklay=
er

|>> forms a mesh is useful knowledge for a layer-3 MANET routing prot=
ocol,

|>> it allows an implementation to optimize its flooding and forwardi=
ng

|>> routings (by not using two-hop routes within the layer-2 mesh dom=
ain).

|>

|> There are two issues here that need to be disentangled.

|>

|> The first is knowledge of connectivity at layer 2, and feeding it upw=
ard

|> to the routing table.  OK, I'll live with that.

|>

|> But the second is the MAC.  With a shared media, you need one
|> (conversely, with point-point media you don't).  So capacity of =
the

|> layer 2 radio network is baseband capacity prorated across all the SS=
 in

|> the segment .... minus the overhead used by the MAC.  In the cas=
e of

|> ethernet derivatives (like WiFi), that overhead may reach 80%!  =
And it

|> gets worse as the segment gets more congested ... so one of the metri=
cs

|> you would need to get hold of is how congested the network segment
|> is ... so you don't overload and stall it.

|

|I am not sure how this is connected to a "does/does-not layer-2 mesh&=
quot;

|TLV for DLEP. 



I claim that 

1. Performance is sometimes worse when IP routers arbi=
trarily work around multihop (mesh) routing below IP - so router-to-router =
interfaces, such as DLEP, should support mesh wireless networks, and=



2. IP routers can make an informed decision based upon=
 metric information without having to know if the layer-2 is a mesh radio n=
etwork or not.






1.  Performance is sometimes worse when IP router=
s work around multihop (mesh) routing below IP - so router-to-router interf=
aces, such as DLEP, should support mesh wireless networks.




All of the IP broadcast (and some of the directional) =
military ad hoc networking waveforms that I know of perform multihop (mesh)=
 networking at layer 2 below IP (analogous to how 802.3 bridge is multihop =
below IP).  Note that I use the term
 =93networking waveform=94 to be equivalent to a radio with layer 2 mesh ne=
tworking and MAC.




The multihop routing below IP is to enable optimized c=
ross-layer optimization between the mesh routing and the MAC to minimize in=
terference and, in many cases, to optimize spatial reuse of spectrum, espec=
ially for multicast/broadcast traffic
 in broadcast (omnidirectional) MACs. 



Some example multihop routing/MAC cross-layer techniqu=
es include:


- multicast/broadcast spectrum (time slot) allocations=
 to maximize spatial reuse capacity depending upon traffic and topology


- network coding from overhead transmissions from mult=
iple nodes


- passive (rather than active) acknowledgement using o=
verheard transmission of next radio hop


- adaptive routing on transmission by transmission bas=
is depending upon what next few spectrum allocations are coming up




For example, consider a 5 node IP network {A, B, C, D,=
 E} with 2 networking waveforms radios (i.e. multihop ad hoc layer 2 networ=
ks) at each node.  The first radio has a narrowband (low data rate) wa=
veform with long transmission range with
 following links {A-B, B-C, C-D, C-E, and D-E}.  The second radio has =
a wideband (high data rate) waveform with short transmission range with the=
 following links {C=3DD, C=3DE, and D=3DE}.  Note that although nodes =
A and B have wideband radios, they don=92t have any
 wideband links due to the long distance. 



     Narrowband waveform connectivity:<=
/font> 

               =
;               +---+ 

               =
;               |   | <=
br>
          +---------+=
---------+-+-+ 

          |     &nb=
sp;   |         | | | 

          A     &nb=
sp;   B         C D E 

          +    =
     +         +=3D+=3D+ 

               =
;               +=3D=3D=3D+ 

     Wideband waveform connectivity: 



The IP narrowband metric from node X to Y is (x-y). &n=
bsp;E.g. the narrowband IP link from node C to E is (c-e).




The IP wideband metric from node X to Y is (X-Y). &nbs=
p;E.g. the wideband link from node C to E is (C-E).




Now the layer 2 networks optimize the shared spectrum =
through cross layer optimization, so that sometimes (a-c) is better than (a=
-b) and (b-c) depending upon scenario.  Similarly, (C=3DE) is sometime=
s better than (C=3DD) and (D=3DE).




However, because the wideband layer 2 network has bett=
er performance,


(a-c) and (C=3DE) is better than (a-e). 


Thus, the IP Router at radio node A will select node C=
 as the next IP hop in the IP route to E.






2. IP routers can make an informed decision based upon=
 metric information without having to know if the layer-2 is a mesh radio n=
etwork or not.




I think that radio-to-router interfaces, such as DLEP,=
 should allow the networking waveform in the radio to advertise the MAC add=
ress of the next IP neighbor whether than IP neighbor is one or more IP hop=
s away. (From my reading of draft-ietf-manet-dlep-04.pdf,
 I think that DLEP would support either IP neighbors that are one RF hop aw=
ay or multiple RF hops away.)









Yes, that's correct. In the current 04 version of DLEP, the router "do=
esn't know, doesn't care" if the destination MAC is 1 or > 1 RF hop=
s away. At least in the Cisco implementation, there is an implicit trust in=
 the radio to alter metrics accordingly - e.g.
 if you get into a situation where multiple radio stations funnel through a=
 single device in the middle of your network, the radios SHOULD downgrade m=
etrics so as to avoid network collapse. 







Thus, in the example above, the IP router at A can get=
 radio link information to the IP routers at the other nodes, whether they =
are one or more radio-hops away.  The routers can then look at the met=
rics to make the choice on whether to go
 in a single IP hop route or multiple IP hop route across the networks.




I.e. if (a-c) is better than (a-b) and (b-c), then the=
 router at A would route directly to IP router at C rather than routing via=
 IP router at B using the knowledge of the metrics without having to know t=
hat the radio was a mesh network.








Jim Stevens 
















This helps me put my finger on what's bothering me about the proposal =
for a Mesh TLV - essentially, the radio is working its fanny off to create =
a topology, and we're trying to give the router to ability to say (in effec=
t), "No, I don't think so", based
 on the value of this TLV. It just smells like a layer violation to me (or =
one that's about to happen).  If you're going to trust the radio to ca=
rry the traffic, you should trust the radio to do it in the most efficient =
manner possible, and trust the radio
 to give you the correct metrics, based on the physical topology. 






Regards,


Stan









--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100C473Axmbalnx03ciscoc_--

From buddenbergr@gmail.com  Tue Apr 23 13:21:47 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEC21F95D0 for ; Tue, 23 Apr 2013 13:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level: 
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojyG+ETh1m30 for ; Tue, 23 Apr 2013 13:21:44 -0700 (PDT)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E121F95EB for ; Tue, 23 Apr 2013 13:21:42 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id kx10so719758pab.14 for ; Tue, 23 Apr 2013 13:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=QExbc2VDY2QcL4eOhnCM3xubDMab/kX6jr7IHUT1kjM=; b=brO45MRMej+NUOBKEF4pP5vrkvZdXWHrnNz+EkMzHkX/JB4WHqFKoJwspVNMvEbELQ rs2xNP7S1VCek/SC9PKAnZ1ujkT9JTrPWANyXsIMuYmvliUdSI/ovaqvKZ8U++yfbsMh kMqHkEW++y8SpTLVN4ZNjvbrSgUoyfYtAF9QFsilc9SkGvdRB8dk0a/Z97PZ2XNSRtoh ywNQEUEZ3ZVryb9l2MXW7CwvFVg+mLntbJjfO38JGs5gFZAsSdD2u84qE/XOkqKvfyPM 3jG70vIzfZtBeItb5ansOWQ7hb0tS8hYg7oUscmpj+hC7es7qwLnaT4zTHIgHbFHCgHl sK7g==
X-Received: by 10.68.43.35 with SMTP id t3mr43983496pbl.202.1366748500563; Tue, 23 Apr 2013 13:21:40 -0700 (PDT)
Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPS id xz4sm30775680pbb.18.2013.04.23.13.21.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Apr 2013 13:21:39 -0700 (PDT)
Message-ID: <1366748498.1720.68.camel@localhost>
From: Rex Buddenberg 
To: "Stan Ratliff (sratliff)" 
Date: Tue, 23 Apr 2013 13:21:38 -0700
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C473A@xmb-aln-x03.cisco.com>
References:   <2ED1D3801ACAAB459FDB4EAC9EAD090C100C473A@xmb-aln-x03.cisco.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Cc: "" , " " 
Subject: Re: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed	or not
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 20:21:47 -0000

Stan,

This triggers some phobias beyond just hop count.  I'm unclear about
whether this is a 'standards' issue or a 'best practices' issues, but we
ought to understand some implications.

The fundamental advantage of IP and routers is that they execute
_reliable_crossover_ from one route to another by design.  This is what
makes packet switching superior to circuit switching (and Paul Baran was
right!)  In textbook, reliable crossover is the second principle of high
availability engineering.

20 years ago, lots of campus networks were bridged networks (with the
only router at the campus <--> outside world spot).  Each building had a
bridge in it.  
     As the network grew, and as reliance on it grew, we started adding
alternate routes to the campus network.  (First principle of high Ao
engineering, btw).  This caused ringing in the bridged ethernets --
frames would circulate forever.  So IEEE 802.1 cooked up the spanning
tree algorithm so that bridges could construct rudimentary routing
tables (at layer 2) and control the ringing -- BY KILLING OFF THE
REDUNDANT CONNECTIONS.  Direct violation of Principle 2.  
     We worked out of this mostly by replacing the bridges with routers
because layer 3 knows better.  


> This helps me put my finger on what's bothering me about the proposal
> for a Mesh TLV - essentially ...
> 
So yeah, I echo your worry here, but for different reasons.




On Tue, 2013-04-23 at 19:54 +0000, Stan Ratliff (sratliff) wrote:
> Jim,  
> 
> On Apr 23, 2013, at 3:14 PM, 
>   wrote:
> 
> > |On Tue, Apr 23, 2013 at 5:57 PM, Rex Buddenberg wrote:
> > |> On Tue, 2013-04-23 at 11:12 +0200, Henning Rogge wrote: 
> > |> 
> > |>> It seems that many IP radios try to establish a transparent
> > layer-2 mesh
> > |>> between the radios on the same channel. The fact that the
> > linklayer
> > |>> forms a mesh is useful knowledge for a layer-3 MANET routing
> > protocol,
> > |>> it allows an implementation to optimize its flooding and
> > forwarding
> > |>> routings (by not using two-hop routes within the layer-2 mesh
> > domain).
> > |>
> > |> There are two issues here that need to be disentangled.
> > |>
> > |> The first is knowledge of connectivity at layer 2, and feeding it
> > upward
> > |> to the routing table.  OK, I'll live with that.
> > |>
> > |> But the second is the MAC.  With a shared media, you need one
> > |> (conversely, with point-point media you don't).  So capacity of
> > the
> > |> layer 2 radio network is baseband capacity prorated across all
> > the SS in
> > |> the segment .... minus the overhead used by the MAC.  In the case
> > of
> > |> ethernet derivatives (like WiFi), that overhead may reach 80%!
> >  And it
> > |> gets worse as the segment gets more congested ... so one of the
> > metrics
> > |> you would need to get hold of is how congested the network
> > segment
> > |> is ... so you don't overload and stall it.
> > |
> > |I am not sure how this is connected to a "does/does-not layer-2
> > mesh"
> > |TLV for DLEP. 
> > 
> > I claim that 
> > 1. Performance is sometimes worse when IP routers arbitrarily work
> > around multihop (mesh) routing below IP - so router-to-router
> > interfaces, such as DLEP, should support mesh wireless networks,
> > and 
> > 2. IP routers can make an informed decision based upon metric
> > information without having to know if the layer-2 is a mesh radio
> > network or not. 
> > 
> > 
> > 1.  Performance is sometimes worse when IP routers work around
> > multihop (mesh) routing below IP - so router-to-router interfaces,
> > such as DLEP, should support mesh wireless networks. 
> > 
> > All of the IP broadcast (and some of the directional) military ad
> > hoc networking waveforms that I know of perform multihop (mesh)
> > networking at layer 2 below IP (analogous to how 802.3 bridge is
> > multihop below IP).  Note that I use the term “networking waveform”
> > to be equivalent to a radio with layer 2 mesh networking and MAC. 
> > 
> > The multihop routing below IP is to enable optimized cross-layer
> > optimization between the mesh routing and the MAC to minimize
> > interference and, in many cases, to optimize spatial reuse of
> > spectrum, especially for multicast/broadcast traffic in broadcast
> > (omnidirectional) MACs. 
> > 
> > Some example multihop routing/MAC cross-layer techniques include: 
> > - multicast/broadcast spectrum (time slot) allocations to maximize
> > spatial reuse capacity depending upon traffic and topology 
> > - network coding from overhead transmissions from multiple nodes 
> > - passive (rather than active) acknowledgement using overheard
> > transmission of next radio hop 
> > - adaptive routing on transmission by transmission basis depending
> > upon what next few spectrum allocations are coming up 
> > 
> > For example, consider a 5 node IP network {A, B, C, D, E} with 2
> > networking waveforms radios (i.e. multihop ad hoc layer 2 networks)
> > at each node.  The first radio has a narrowband (low data rate)
> > waveform with long transmission range with following links {A-B,
> > B-C, C-D, C-E, and D-E}.  The second radio has a wideband (high data
> > rate) waveform with short transmission range with the following
> > links {C=D, C=E, and D=E}.  Note that although nodes A and B have
> > wideband radios, they don’t have any wideband links due to the long
> > distance. 
> > 
> >      Narrowband waveform connectivity: 
> >                               +---+ 
> >                               |   | 
> >           +---------+---------+-+-+ 
> >           |         |         | | | 
> >           A         B         C D E 
> >           +         +         +=+=+ 
> >                               +===+ 
> >      Wideband waveform connectivity: 
> > 
> > The IP narrowband metric from node X to Y is (x-y).  E.g. the
> > narrowband IP link from node C to E is (c-e). 
> > 
> > The IP wideband metric from node X to Y is (X-Y).  E.g. the wideband
> > link from node C to E is (C-E). 
> > 
> > Now the layer 2 networks optimize the shared spectrum through cross
> > layer optimization, so that sometimes (a-c) is better than (a-b) and
> > (b-c) depending upon scenario.  Similarly, (C=E) is sometimes better
> > than (C=D) and (D=E). 
> > 
> > However, because the wideband layer 2 network has better
> > performance, 
> > (a-c) and (C=E) is better than (a-e). 
> > 
> > Thus, the IP Router at radio node A will select node C as the next
> > IP hop in the IP route to E. 
> > 
> > 
> > 2. IP routers can make an informed decision based upon metric
> > information without having to know if the layer-2 is a mesh radio
> > network or not. 
> > 
> > I think that radio-to-router interfaces, such as DLEP, should allow
> > the networking waveform in the radio to advertise the MAC address of
> > the next IP neighbor whether than IP neighbor is one or more IP hops
> > away. (From my reading of draft-ietf-manet-dlep-04.pdf, I think that
> > DLEP would support either IP neighbors that are one RF hop away or
> > multiple RF hops away.) 
> 
> 
> Yes, that's correct. In the current 04 version of DLEP, the router
> "doesn't know, doesn't care" if the destination MAC is 1 or > 1 RF
> hops away. At least in the Cisco implementation, there is an implicit
> trust in the radio to alter metrics accordingly - e.g. if you get into
> a situation where multiple radio stations funnel through a single
> device in the middle of your network, the radios SHOULD downgrade
> metrics so as to avoid network collapse. 
> 
> > 
> > Thus, in the example above, the IP router at A can get radio link
> > information to the IP routers at the other nodes, whether they are
> > one or more radio-hops away.  The routers can then look at the
> > metrics to make the choice on whether to go in a single IP hop route
> > or multiple IP hop route across the networks. 
> > 
> > I.e. if (a-c) is better than (a-b) and (b-c), then the router at A
> > would route directly to IP router at C rather than routing via IP
> > router at B using the knowledge of the metrics without having to
> > know that the radio was a mesh network. 
> > 
> > 
> > 
> > Jim Stevens 
> > 
> > 
> > 
> 
> 
> This helps me put my finger on what's bothering me about the proposal
> for a Mesh TLV - essentially, the radio is working its fanny off to
> create a topology, and we're trying to give the router to ability to
> say (in effect), "No, I don't think so", based on the value of this
> TLV. It just smells like a layer violation to me (or one that's about
> to happen).  If you're going to trust the radio to carry the traffic,
> you should trust the radio to do it in the most efficient manner
> possible, and trust the radio to give you the correct metrics, based
> on the physical topology. 
> 
> 
> Regards,
> Stan
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



From jasteven@rockwellcollins.com  Tue Apr 23 14:52:24 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0321F9497 for ; Tue, 23 Apr 2013 14:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwKBZAuvtp5P for ; Tue, 23 Apr 2013 14:52:20 -0700 (PDT)
Received: from secvs02.rockwellcollins.com (secvs02.rockwellcollins.com [205.175.225.241]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7521F8D79 for ; Tue, 23 Apr 2013 14:52:19 -0700 (PDT)
Received: from nosuchhost.198.131.in-addr.arpa (HELO collinscrsmtp02.rockwellcollins.com) ([131.198.63.133]) by mail-virt.rockwellcollins.com with ESMTP; 23 Apr 2013 16:52:17 -0500
In-Reply-To: <1366748498.1720.68.camel@localhost>
References: 	  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C473A@xmb-aln-x03.cisco.com> <1366748498.1720.68.camel@localhost>
X-Disclaimed: 39206
To: Rex Buddenberg 
MIME-Version: 1.0
X-KeepSent: A8BE3990:0EB1F74E-86257B56:00772A74; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP1 November 30, 2010
From: jasteven@rockwellcollins.com
Message-ID: 
Date: Tue, 23 Apr 2013 16:52:17 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5.2FP2 HF162|May 16, 2011) at 04/23/2013 04:52:18 PM, Serialize complete at 04/23/2013 04:52:18 PM
Content-Type: multipart/alternative; boundary="=_alternative 007824C586257B56_="
Cc: "" 
Subject: Re: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed	or not
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 21:52:24 -0000

This is a multipart message in MIME format.
--=_alternative 007824C586257B56_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

|On Tue, Apr 23, 2013 at 04/23/2013 03:21 PM, Rex Buddenberg wrote:
|Stan,
|
|This triggers some phobias beyond just hop count.  I'm unclear about
|whether this is a 'standards' issue or a 'best practices' issues, but we
|ought to understand some implications.
|
|The fundamental advantage of IP and routers is that they execute
|=5Freliable=5Fcrossover=5F from one route to another by design.  This is w=
hat
|makes packet switching superior to circuit switching (and Paul Baran was
|right!)  In textbook, reliable crossover is the second principle of high
|availability engineering.
|
|20 years ago, lots of campus networks were bridged networks (with the
|only router at the campus <--> outside world spot).  Each building had a
|bridge in it.=20
|     As the network grew, and as reliance on it grew, we started adding
|alternate routes to the campus network.  (First principle of high Ao
|engineering, btw).  This caused ringing in the bridged ethernets --
|frames would circulate forever.  So IEEE 802.1 cooked up the spanning
|tree algorithm so that bridges could construct rudimentary routing
|tables (at layer 2) and control the ringing -- BY KILLING OFF THE
|REDUNDANT CONNECTIONS.  Direct violation of Principle 2.=20
|     We worked out of this mostly by replacing the bridges with routers
|because layer 3 knows better.
|
|
|> This helps me put my finger on what's bothering me about the proposal
|> for a Mesh TLV - essentially ...
|>=20
|So yeah, I echo your worry here, but for different reasons.

Rex,

I think I understand and agree with the different point you are making,=20
but I?m not sure I caught or understood them all.

1 I think you are arguing (and I agree) against the problem of flood=20
storms that can arise from un- (or under-constrained) forwarding/flooding=20
of traffic, such as with pure bridging alone.

2 I think you are arguing (and I agree) that a some routing protocols can=20
cause reliability problems by their very design (such as the delay for the =

original IEEE 802.1D spanning tree algorithm to adapt to link changes as=20
compared to the more recent IEEE 802.1aq algorithm that supports multiple=20
paths).

3 I think the major point you are arguing (and I agree) is that IP routers =

have a more global network view than layer 2 networks do (by definition)=20
and can do a better job of global network routing across multiple networks =

(in fact the very basis for the original DARPA CATANET model that became=20
the Internet).

4 I?m not sure, but you appear to be arguing against layer 2 routing below =

IP in wireless network, possibly in all cases.

I agree that there are some wireless layer 2s that don?t do a good job of=20
ad hoc routing below IP.  I think single radio channel 802.11 in multi-hop =

ad hoc mode is a good example.

However, there are other wireless layer 2s that do a good job because they =

were designed to optimize for specific conditions.  And these wireless=20
layer 2s can do a better job of optimizing performance *within* that=20
wireless network than IP can without that specific MAC cross-layer=20
information.

5.  I?m not sure, but you also seem to imply you have other things or=20
implications that I didn't catch.

Regards,
Jim

--=_alternative 007824C586257B56_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

|On Tue, Apr 23, 2013 at 04/23/2013 03:21 PM, Rex Budden=
berg
wrote:

|Stan,

|

|This triggers some phobias beyond just hop count.  I'm unclear about<=
br>
|whether this is a 'standards' issue or a 'best practices' issues, but
we

|ought to understand some implications.

|

|The fundamental advantage of IP and routers is that they execute

|=5Freliable=5Fcrossover=5F from one route to another by design.  This=
 is
what

|makes packet switching superior to circuit switching (and Paul Baran was
|right!)  In textbook, reliable crossover is the second principle
of high

|availability engineering.

|

|20 years ago, lots of campus networks were bridged networks (with the

|only router at the campus <--> outside world spot).  Each build=
ing
had a

|bridge in it.  

|     As the network grew, and as reliance on it grew, we started
adding

|alternate routes to the campus network.  (First principle of high
Ao

|engineering, btw).  This caused ringing in the bridged ethernets
--

|frames would circulate forever.  So IEEE 802.1 cooked up the spanning=


|tree algorithm so that bridges could construct rudimentary routing

|tables (at layer 2) and control the ringing -- BY KILLING OFF THE

|REDUNDANT CONNECTIONS.  Direct violation of Principle 2.  

|     We worked out of this mostly by replacing the bridges with
routers

|because layer 3 knows better.

|

|

|> This helps me put my finger on what's bothering me about the proposal=


|> for a Mesh TLV - essentially ...

|> 

|So yeah, I echo your worry here, but for different reasons.



Rex,



I think I understand and agree with the different
point you are making, but I’m not sure I caught or understood them al=
l.



1 I think you are arguing (and I agree) against the
problem of flood storms that can arise from un- (or under-constrained)
forwarding/flooding of traffic, such as with pure bridging alone.



2 I think you are arguing (and I agree) that a some
routing protocols can cause reliability problems by their very design (such
as the delay for the original IEEE 802.1D spanning tree algorithm to adapt
to link changes as compared to the more recent IEEE 802.1aq algorithm that
supports multiple paths).



3 I think the major point you are arguing (and I agr=
ee)
is that IP routers have a more global network view than layer 2 networks
do (by definition) and can do a better job of global network routing across
multiple networks (in fact the very basis for the original DARPA CATANET
model that became the Internet).



4 I’m not sure, but you appear to be arguing a=
gainst
layer 2 routing below IP in wireless network, possibly in all cases.=




I agree that there are some wireless layer 2s that
don’t do a good job of ad hoc routing below IP.  I think single =
radio
channel 802.11 in multi-hop ad hoc mode is a good example.



However, there are other wireless layer 2s that do
a good job because they were designed to optimize for specific conditions.
 And these wireless layer 2s can do a better job of optimizing perform=
ance
*within* that wireless network than IP can without that specific MAC cross-=
layer
information.



5.  I’m not sure, but you also seem to im=
ply
you have other things or implications that I didn't catch.



Regards,

Jim

--=_alternative 007824C586257B56_=--

From buddenbergr@gmail.com  Tue Apr 23 15:46:46 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981921F9404 for ; Tue, 23 Apr 2013 15:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WrZwMaaOlv2 for ; Tue, 23 Apr 2013 15:46:45 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9656521F93F9 for ; Tue, 23 Apr 2013 15:46:45 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id 10so724238pdc.28 for ; Tue, 23 Apr 2013 15:46:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=0fznlbYFtMLcMz76pgHmxL/erlmrGtd+glva0c6XiLI=; b=QAk+I9hco/Y01pSAv8GgxAiMxvzqqis+nWhiXREU2DZy3HhSvURRNoGORkEfUdHlGB V2/lEZ0qHkVg4pr4aB5oOsCGsn7bxCLafjxZK0OLo2G9h89zTclF60xR6rCPKALLRdpA DTZzrYg7gsE60PIA5vL+B6nQHp1/us0m9Ri2/p0VZ1a9PKAZn0lkxKOnyRerpXV/5MXi E2b1ruh7ctFfUEaQ6QBu9UmhuvI0wy3tPKKZE8YHT7PdPih8n7+wOFGKNCGnO6LIEA9+ e6TeGU8I0ygSQJiopbLFOq2XR3gH9oUsrzhHh8rpq5WlrZIUmkLNYqA9es0JHtlh9elh n81w==
X-Received: by 10.66.14.1 with SMTP id l1mr16141489pac.150.1366757205316; Tue, 23 Apr 2013 15:46:45 -0700 (PDT)
Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id ze11sm696524pab.22.2013.04.23.15.46.43 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Apr 2013 15:46:44 -0700 (PDT)
Message-ID: <1366757202.1720.87.camel@localhost>
From: Rex Buddenberg 
To: jasteven@rockwellcollins.com
Date: Tue, 23 Apr 2013 15:46:42 -0700
In-Reply-To: 
References:   <2ED1D3801ACAAB459FDB4EAC9EAD090C100C473A@xmb-aln-x03.cisco.com> <1366748498.1720.68.camel@localhost> 
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Cc: manet@ietf.org
Subject: Re: [manet] Subject: DLEP link metric discussion - is "mesh" TLV needed	or not
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 22:46:46 -0000

Jim,

good catches, imo, in line below:

On Tue, 2013-04-23 at 16:52 -0500, jasteven@rockwellcollins.com wrote:
> |On Tue, Apr 23, 2013 at 04/23/2013 03:21 PM, Rex Buddenberg wrote: 
> |Stan,
> |
> |This triggers some phobias beyond just hop count.  I'm unclear about
> |whether this is a 'standards' issue or a 'best practices' issues, but
> we
> |ought to understand some implications.
> |
> |The fundamental advantage of IP and routers is that they execute
> |_reliable_crossover_ from one route to another by design.  This is
> what
> |makes packet switching superior to circuit switching (and Paul Baran
> was
> |right!)  In textbook, reliable crossover is the second principle of
> high
> |availability engineering.
> |
> |20 years ago, lots of campus networks were bridged networks (with the
> |only router at the campus <--> outside world spot).  Each building
> had a
> |bridge in it.  
> |     As the network grew, and as reliance on it grew, we started
> adding
> |alternate routes to the campus network.  (First principle of high Ao
> |engineering, btw).  This caused ringing in the bridged ethernets --
> |frames would circulate forever.  So IEEE 802.1 cooked up the spanning
> |tree algorithm so that bridges could construct rudimentary routing
> |tables (at layer 2) and control the ringing -- BY KILLING OFF THE
> |REDUNDANT CONNECTIONS.  Direct violation of Principle 2.  
> |     We worked out of this mostly by replacing the bridges with
> routers
> |because layer 3 knows better.
> |
> |
> |> This helps me put my finger on what's bothering me about the
> proposal
> |> for a Mesh TLV - essentially ...
> |> 
> |So yeah, I echo your worry here, but for different reasons. 
> 
> Rex, 
> 
> I think I understand and agree with the different point you are
> making, but I’m not sure I caught or understood them all. 
> 
> 1 I think you are arguing (and I agree) against the problem of flood
> storms that can arise from un- (or under-constrained)
> forwarding/flooding of traffic, such as with pure bridging alone. 

Almost.  And probably close enough.  ethernet frames have no TTL like IP
datagrams, so they'll get forwarded across bridges forever.  I guess
that's 'unconstrained';-)
> 
> 2 I think you are arguing (and I agree) that a some routing protocols
> can cause reliability problems by their very design (such as the delay
> for the original IEEE 802.1D spanning tree algorithm to adapt to link
> changes as compared to the more recent IEEE 802.1aq algorithm that
> supports multiple paths). 

loud and clear; you got it.
> 
> 3 I think the major point you are arguing (and I agree) is that IP
> routers have a more global network view than layer 2 networks do (by
> definition) and can do a better job of global network routing across
> multiple networks (in fact the very basis for the original DARPA
> CATANET model that became the Internet). 

Yeah, again, we're agreeing.  I like your term 'global view'.  layer 2
forwarding requires much more homogeneity of the hops than routing does.
I'm not sure this impacts the DLEP discussion, but we're agreeing.
> 
> 4 I’m not sure, but you appear to be arguing against layer 2 routing
> below IP in wireless network, possibly in all cases. 

As a matter of best practices, I think that multiple-hop layer 2 is
generally not a good idea (I can be convinced of specific exceptions).  
  As a matter of economics and scale, past attempts have generally not
been wildly successful and durable.  
  As a matter of standards and protocol design, those observations may
not apply.
> 
> I agree that there are some wireless layer 2s that don’t do a good job
> of ad hoc routing below IP.  I think single radio channel 802.11 in
> multi-hop ad hoc mode is a good example. 

Stan made this point.  Obviously there are times when this may be the
only option you have.  But as soon as you understand the
4-orders-of-magnitude argument, you understand that you don't want them
very often.

Actually, I'd be more interested in the industry uptake on multi-hop
802.16.  The standard's there, it's ratified ... anybody selling,
buying, using it?


> 
> However, there are other wireless layer 2s that do a good job because
> they were designed to optimize for specific conditions.  And these
> wireless layer 2s can do a better job of optimizing performance
> *within* that wireless network than IP can without that specific MAC
> cross-layer information. 
> 
> 5.  I’m not sure, but you also seem to imply you have other things or
> implications that I didn't catch. 

Jim, I'm not opposed to DLEP.  Contrary.  But the 'color me skeptical'
attitude comes from the fact that we've been here before.  Attempts in
IEEE 802 to enhance the ethertype function have flamed out (one of the
few cases where a PAR has been formally withdrawn).  And several cases
of cross-2/3 layer communication within IETF have not come to fruition
either (some of the non-starts have been within MANET WG if my memory
cells aren't too foggy).  If we're going to do better, we need to learn
from them.  If that's what you're reading that I'm implying, then right
on.




> 
> Regards, 
> Jim



From Chris.Dearlove@baesystems.com  Wed Apr 24 01:47:35 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34A21F8F0F for ; Wed, 24 Apr 2013 01:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG28x6wY8XVc for ; Wed, 24 Apr 2013 01:47:34 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF421F8EEB for ; Wed, 24 Apr 2013 01:47:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,540,1363132800"; d="scan'208";a="281395212"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Apr 2013 09:47:33 +0100
Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3O8lWU1002213 for ; Wed, 24 Apr 2013 09:47:32 +0100
X-IronPort-AV: E=Sophos;i="4.87,540,1363132800"; d="scan'208";a="14059350"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 24 Apr 2013 09:47:32 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 09:47:32 +0100
From: "Dearlove, Christopher (UK)" 
To: "ietf@jiaziyi.com" , "manet@ietf.org" 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicw
Date: Wed, 24 Apr 2013 08:47:32 +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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 08:47:35 -0000

Jiazi

Thanks for that, I'll just comment on the one point where I disagree.

Putting some vague words in that protocols may indicate fields not to be co=
vered is the sort of thing that I can predict will cause us problems at the=
 IESG. And it's not really a good plan for a generic mechanism that can - a=
t at present - be run independently of the routing protocol to acquire a pr=
otocol dependence. Rather I think that any routing protocols with a specifi=
c need to exclude data (which, all else being equal is a bad thing of cours=
e) should consider defining a new type extension - preferably one defined w=
ith some generic capability (could it, for example, list TLV types to be ex=
cluded?) But that's for the future. One thing I have learned is that design=
 in advance of what might hypothetically be needed generally gets it wrong,=
 so it would be good to wait until exactly what's needed is clear, and then=
 define a new case.

Christopher

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of i=
etf@jiaziyi.com
Sent: 23 April 2013 15:37
To: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

(sorry if you receive duplicate of this message. Some of my mails to=20
the mailing list are rejected, and I'm trying to figure out with our=20
secretary...)

Hi,

I had a review of the draft. I think it's in good shape, and ready for=20
WGLC.

a few comments:

In section 6 & 7, I didn't find the definition of notation
=09+
Not in this draft, either rfc 5444.

page 13,  source code address =3D=3D> source node address?

section 9.1 bullet 1 states that the  and=20
 must be zeroed before calculating ICV. I'm thinking=20
about that we might need to mention that some protocol-specific mutable=20
fields must be zeroed here also. For example, in LOADng, as a reactive=20
protocol, metric fields are defined as "mutable" (in the meantime, I=20
still have some thoughts on those mutable fields that I need to discuss=20
with other LOADng authors, but it's not that relevant here).

best

Jiazi


On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group=20
of the IETF.

=09Title           : Integrity Check Value and Timestamp TLV Definitions=20
for Mobile Ad Hoc Networks (MANETs)
=09Author(s)       : Ulrich Herberg
                         Thomas Heide Clausen
                         Christopher Dearlove
=09Filename        : draft-ietf-manet-rfc6622-bis-02.txt
=09Pages           : 24
=09Date            : 2013-04-15

Abstract:
  This document revises, extends and replaces RFC 6622.  It describes
  general and flexible TLVs for representing cryptographic Integrity
  Check Values (ICVs) and timestamps, using the generalized Mobile Ad
  Hoc Network (MANET) packet/message format defined in RFC 5444.  It
  defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
  for affixing ICVs and timestamps to a packet, a message, and one or
  more addresses, respectively.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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


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


From henning.rogge@fkie.fraunhofer.de  Wed Apr 24 02:14:39 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6090521F8D2B for ; Wed, 24 Apr 2013 02:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+Xtng+8aX+k for ; Wed, 24 Apr 2013 02:14:38 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6E77221F8F41 for ; Wed, 24 Apr 2013 02:14:36 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUvmV-0007HK-3L; Wed, 24 Apr 2013 11:14:27 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UUvmV-0004uh-0b; Wed, 24 Apr 2013 11:14:27 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 24 Apr 2013 11:14:26 +0200
Message-ID: <5177A271.6010403@fkie.fraunhofer.de>
Date: Wed, 24 Apr 2013 11:14:25 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Taylor, Rick" 
References: <51765087.6000302@fkie.fraunhofer.de> <11680519-94d5-44cd-96ef-1f106d1bf830@SUCNPTEXC01.COM.AD.UK.DS.CORP> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040309030806020608060105"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17077/Wed Apr 24 06:39:24 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: e1416103c0dc32859b3a1b60dee92644
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 09:14:39 -0000

--------------ms040309030806020608060105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/23/2013 04:08 PM, Taylor, Rick wrote:
> The difference between a 1 byte Boolean value and a layer2-hopcount
> is how big should the TLV data packet be... 8-bits?  16-bits?  etc.

In addition to this, the layer-2 hopcount would be "per neighbor" while=20
the boolean flag is "once per DLEP session".

> I vote for 1 byte Boolean.
>
> Also, exposing layer-2 topology information could lead to people
> requesting a TLV to notify a change of layer-2 hopcount.  I would
> keep the lid on the can of worms.

Exposing a complete layer-2 topology including metrics can be useful in=20
special cases, but not for the common router.

I would like to include the two basic values "0 - no mesh" and "1 -=20
transparent layer-2 mesh" into the core RFC.

(maybe we have to work on the name of the TLV and the description of the =

values to make it more clear what we are talking about)

After we finished the core RFC for DLEP, we can talk about adding things =

like "2 - layer-2 mesh reporting hopcount" and "3 - layer-2 mesh=20
exporting topology" in an extension draft. The DLEP message format is=20
flexible enough to handle this.

Henning Rogge

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


--------------ms040309030806020608060105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjQwOTE0MjVaMCMGCSqGSIb3DQEJBDEWBBSiBuFnCJY7Ncl4tYJzp/2uv5BNvjBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAt8L5uVL3KcyNk2B547yO5wxl1Iv6ryX+SLFpecu/vPnY
NLZuI19Vqc6NrjRvIaoaL3DMnHFUra/L4FaS34+WxKGcoKWM4zeaToeuxDXiVKJEeoxwbEbx
F8rn6/NOGQGP0WeG/NghkEK0jPK7hG8ecwMusE/102UNt3CUMXNjqHa1DtKHTMCgLWvEmIER
Fg5FHfpAzhQ+C3FVUKrD+6ZnhL9RcwpzyGHD6eFCSCapReyfaItRj50rWdNvK/I8Hft6Udm5
LqcK7mo8gCiLLHmqPXsqgHx5u5oHIpC/CkuaJcc6tLH79c8vdlaDeZRxaL1LCe/08EJ3oMVM
jPyBMjj2agAAAAAAAA==
--------------ms040309030806020608060105--

From henning.rogge@fkie.fraunhofer.de  Wed Apr 24 02:26:15 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2421F8BE8 for ; Wed, 24 Apr 2013 02:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O5S+8S4Lo3z for ; Wed, 24 Apr 2013 02:26:14 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 77DD121F8BDD for ; Wed, 24 Apr 2013 02:26:14 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUvxt-0003qf-Qg for manet@ietf.org; Wed, 24 Apr 2013 11:26:13 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UUvxt-0005Is-O4 for manet@ietf.org; Wed, 24 Apr 2013 11:26:13 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 24 Apr 2013 11:26:13 +0200
Message-ID: <5177A534.2040406@fkie.fraunhofer.de>
Date: Wed, 24 Apr 2013 11:26:12 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000204040204070401030903"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17077/Wed Apr 24 06:39:24 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 0d126ea63bcfa5b5f6df7dc7419ae219
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 09:26:16 -0000

--------------ms000204040204070401030903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/23/2013 06:52 PM, Stan Ratliff (sratliff) wrote:
> Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.

Yes, that would be bad.

>>>> Layer-2 mesh ------------
>>>>
>>> Henning, we need to be careful about the term 'mesh'.  It's been
>>> badly abused and poorly defined ... and if you've been raised
>>> with fiber/copper underlying connectivity, the set of assumptions
>>> changes (you got that part), but it changes in some ways that you
>>> didn't get.
>>
>> I used "mesh" as a layer-2 MANET technology... 802.11s for example,
>> or BATMAN Advanced as it is included in the Linux Kernel.
>>
>>>> It seems that many IP radios try to establish a transparent
>>>> layer-2 mesh between the radios on the same channel. The fact
>>>> that the linklayer forms a mesh is useful knowledge for a
>>>> layer-3 MANET routing protocol, it allows an implementation to
>>>> optimize its flooding and forwarding routings (by not using
>>>> two-hop routes within the layer-2 mesh domain).
>>>
>>> There are two issues here that need to be disentangled.
>>>
>>> The first is knowledge of connectivity at layer 2, and feeding it
>>> upward to the routing table.  OK, I'll live with that.
>>>
>>> But the second is the MAC.  With a shared media, you need one
>>> (conversely, with point-point media you don't).  So capacity of
>>> the layer 2 radio network is baseband capacity prorated across
>>> all the SS in the segment .... minus the overhead used by the
>>> MAC.  In the case of ethernet derivatives (like WiFi), that
>>> overhead may reach 80%!  And it gets worse as the segment gets
>>> more congested ... so one of the metrics you would need to get
>>> hold of is how congested the network segment is ... so you don't
>>> overload and stall it.
>>
>> I am not sure how this is connected to a "does/does-not layer-2
>> mesh" TLV for DLEP.
>
> In the case described above, I could see SS-to-SS connectivity (via
> the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the
> statement that "mesh" is poorly defined.

Maybe it would make more sense to distinguish layer-2 networks where

a) Layer-3 has to look for multihop paths within the radio domain

b) layer-2 networks which either have no alternative paths to=20
destinations or do multihop retransmissions themselves

in case b, a MANET protocol could simplify the flooding and routing by=20
not considering multihop-forwarding on the radio interface (only to=20
other destinations beyond other interfaces).

>> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does
>> not include this asymmetry.
>
> That reminds me of a statement a college professor made. Something
> along the lines of "No one in their right mind will ever use 802.11
> adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc
> example irrelevant.

I think we can agree to disagree on this statement.

Henning Rogge

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


--------------ms000204040204070401030903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjQwOTI2MTJaMCMGCSqGSIb3DQEJBDEWBBTkwVid5Gyy0HmEkgovi62WMjsKNzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEACClq8ru/hvJLWR6ODEvoJCXrQKeJIUyuH0UR4zHo/VvL
cbLDIsIptBoML3L1Cbc9tP/WzlP9D7/cA9LF5Pz7ruf+HiQCykD+S55Se8toBh2Hhx1PHbT2
9j5c/7jeLOluI2t+JQMd3pyWLJ3R1QN7SfeDeoHPWX/EFgQtDX19znaXNlKzFrOULFmQ4stW
OnYHFK4tNkvznfs618uHaImZN9ATXJVpgfG5gZaB4aMwayUn6xPpxOo9OYP16tRNVQQvNVSU
Emyav15Wu35hfq4slhrbf39l1b5kaCQAhGY3NyNeVxIP2ljYWCJ+CxMkIKsjW/pgNDQFklPg
/jPGeQAfCgAAAAAAAA==
--------------ms000204040204070401030903--

From yi.jiazi@gmail.com  Wed Apr 24 03:54:41 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09121F8EC9 for ; Wed, 24 Apr 2013 03:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5DaYQdAqupn for ; Wed, 24 Apr 2013 03:54:37 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFDF21F8EC1 for ; Wed, 24 Apr 2013 03:54:36 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id c10so1973265wiw.8 for ; Wed, 24 Apr 2013 03:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=++ckhKqVbj2zfAtO9lgWIH6JmKeAAy5uB/tJdEv4irA=; b=Iv/3+TdYi8M5c1HSZ8Oipooxt6MhuXyx1e4uhzWyWWl9ZRRPSSE+bliTV4P0tftOG4 c30KyC7wo/t5TVmlmL97ZXsno+akizZY3WLU690EDbx3mTlPImtDvikaDu7ZRMO1JLtf dHm7cIgLVhlI3zhes1bbrn74DN0wZUdcoDCbtvjn/UwqYJHu0dpuLvvda7tncDCUa2Ho +0LRsmwN1pwZoJBHk0pp25yuLwXXINJvjR7KE+luAJ95kl8hXOpMatBdGzw3SAQf8kPF 81e3BdqchUm5hEII/Ekgkohd8KHnRjvc3AylvqgQBOGSwHQxxpIWU0OJO7eLCraEU1iw 1bfA==
X-Received: by 10.194.92.197 with SMTP id co5mr37529813wjb.41.1366800876237; Wed, 24 Apr 2013 03:54:36 -0700 (PDT)
Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPSA id ek4sm31592238wib.11.2013.04.24.03.54.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 03:54:35 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: 
Date: Wed, 24 Apr 2013 12:54:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>
References:  
To: "Dearlove, Christopher (UK)" 
X-Mailer: Apple Mail (2.1503)
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 10:54:41 -0000

Chris,=20

I do understand your concern. We had this kind of discussion on mutable =
fields before, and this is something I'm still mulling over.=20
The reason why I propose this for discussion is:

	- this rfc6622bis is for rfc5444, which is a general format for =
all manet protocols.=20
	- The reactive protocol like LOADng does explicitly define such =
"mutable" fields. It is something at hand, not in the far future.=20

In the meantime, I do agree that the necessity and how to take care of =
such mutable fields should be considered carefully.=20
So I would agree that we keep the current rfc6622bis draft as it is for =
the moment, and I'll have more discussions with other LOADng authors on =
this.=20

best=20

Jiazi

On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" =
 wrote:

> Jiazi
>=20
> Thanks for that, I'll just comment on the one point where I disagree.
>=20
> Putting some vague words in that protocols may indicate fields not to =
be covered is the sort of thing that I can predict will cause us =
problems at the IESG. And it's not really a good plan for a generic =
mechanism that can - at at present - be run independently of the routing =
protocol to acquire a protocol dependence. Rather I think that any =
routing protocols with a specific need to exclude data (which, all else =
being equal is a bad thing of course) should consider defining a new =
type extension - preferably one defined with some generic capability =
(could it, for example, list TLV types to be excluded?) But that's for =
the future. One thing I have learned is that design in advance of what =
might hypothetically be needed generally gets it wrong, so it would be =
good to wait until exactly what's needed is clear, and then define a new =
case.
>=20
> Christopher
>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf =
Of ietf@jiaziyi.com
> Sent: 23 April 2013 15:37
> To: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> (sorry if you receive duplicate of this message. Some of my mails to=20=

> the mailing list are rejected, and I'm trying to figure out with our=20=

> secretary...)
>=20
> Hi,
>=20
> I had a review of the draft. I think it's in good shape, and ready for=20=

> WGLC.
>=20
> a few comments:
>=20
> In section 6 & 7, I didn't find the definition of notation
> 	+
> Not in this draft, either rfc 5444.
>=20
> page 13,  source code address =3D=3D> source node address?
>=20
> section 9.1 bullet 1 states that the  and=20
>  must be zeroed before calculating ICV. I'm thinking=20
> about that we might need to mention that some protocol-specific =
mutable=20
> fields must be zeroed here also. For example, in LOADng, as a reactive=20=

> protocol, metric fields are defined as "mutable" (in the meantime, I=20=

> still have some thoughts on those mutable fields that I need to =
discuss=20
> with other LOADng authors, but it's not that relevant here).
>=20
> best
>=20
> Jiazi
>=20
>=20
> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group=20=

> of the IETF.
>=20
> 	Title           : Integrity Check Value and Timestamp TLV =
Definitions=20
> for Mobile Ad Hoc Networks (MANETs)
> 	Author(s)       : Ulrich Herberg
>                         Thomas Heide Clausen
>                         Christopher Dearlove
> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> 	Pages           : 24
> 	Date            : 2013-04-15
>=20
> Abstract:
>  This document revises, extends and replaces RFC 6622.  It describes
>  general and flexible TLVs for representing cryptographic Integrity
>  Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>  Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>  defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>  for affixing ICVs and timestamps to a packet, a message, and one or
>  more addresses, respectively.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20
>=20
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>=20


From rick.taylor@cassidian.com  Wed Apr 24 05:13:48 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5221F90F1 for ; Wed, 24 Apr 2013 05:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NBs0Zp6YeGP for ; Wed, 24 Apr 2013 05:13:46 -0700 (PDT)
Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 42AAC21F90EB for ; Wed, 24 Apr 2013 05:13:43 -0700 (PDT)
Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 24 Apr 2013 14:13:41 +0200
Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Wed, 24 Apr 2013 14:13:40 +0200
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Apr 2013 14:13:40 +0200
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Apr 2013 14:13:40 +0200
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 13:13:39 +0100
From: "Taylor, Rick" 
To: Henning Rogge , "manet@ietf.org" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3C2QiFp03LlkCfeEVaxZbdLZjlPyyw
Date: Wed, 24 Apr 2013 12:13:38 +0000
Message-ID: 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.23.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Apr 2013 12:13:40.0506 (UTC) FILETIME=[281DE7A0:01CE40E5]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19820.007
X-TM-AS-Result: No--44.886900-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 12:13:48 -0000

As one of the instigators of the 'Should there be a meshing flag in DLEP' q=
uestions I thought I should add a bit of history.

My team have been implementing layer-3 routing over 802.11s style 'mesh' ra=
dios which support DLEP-00.  Unfortunately, the radio implementation is pri=
mitive and based on an early DLEP draft and so has some issues, the prime e=
xample being that the neighbour metrics supplied to the router by the radio=
s did not match the underlying topology of the layer-2 mesh.

A quick example: (The bow-tie)

A           E
  \       /
   C -- D
  /       \
B           F

>From the manufacturer's reading of DLEP-00, the reported CDR from A to F di=
d not account for any loading placed on C and D from traffic travelling E t=
o B.  Hence the layer3 routing decisions ended up flooding the intermediate=
 nodes resulting in network collapse.

In trying to see a way forwards, we came to two proposals:

A) DLEP should allow some way for a radio to state that it is participating=
 in a mesh that performs multi-hop layer-2 packet forwarding, and as such, =
the router should not attempt layer-3 multi-hop routing within the mesh.  T=
his is the proposal picked up by Henning, the Boolean mesh TLV.

B) The DLEP specification should include explicit statements forcing manufa=
cturers to correctly handle the 'bow-tie' example above when reporting metr=
ics, allowing a layer-3 router to pick a multi-hop route within the mesh th=
at matches the layer-2 packet paths.  This I believe is Stan's position.

As I see it B) is the most 'correct' solution but it relies on careful word=
ing in the specification that is understandable not only in English, but al=
so to non-native speakers (I know this out of scope for an IETF document, b=
ut it is a reality).  Also, incorrect implementations are fatal to routers.

Option A) is a cludge/compromise/cop-out, but it does give manufacturers a =
way to specify that they do something they consider clever (or too complica=
ted to get the metrics right) at layer-2, and layer-3 routers should avoid =
performing multi-hop routing *within* the radio-net.

As a pragmatist, I feel that DLEP should aim for B, but allow option A.

Rick Taylor

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Henning Rogge
> Sent: 24 April 2013 10:26
> To: manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>
> On 04/23/2013 06:52 PM, Stan Ratliff (sratliff) wrote:
> > Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.
>
> Yes, that would be bad.
>
> >>>> Layer-2 mesh ------------
> >>>>
> >>> Henning, we need to be careful about the term 'mesh'.  It's been
> >>> badly abused and poorly defined ... and if you've been raised
> >>> with fiber/copper underlying connectivity, the set of assumptions
> >>> changes (you got that part), but it changes in some ways that you
> >>> didn't get.
> >>
> >> I used "mesh" as a layer-2 MANET technology... 802.11s for example,
> >> or BATMAN Advanced as it is included in the Linux Kernel.
> >>
> >>>> It seems that many IP radios try to establish a transparent
> >>>> layer-2 mesh between the radios on the same channel. The fact
> >>>> that the linklayer forms a mesh is useful knowledge for a
> >>>> layer-3 MANET routing protocol, it allows an implementation to
> >>>> optimize its flooding and forwarding routings (by not using
> >>>> two-hop routes within the layer-2 mesh domain).
> >>>
> >>> There are two issues here that need to be disentangled.
> >>>
> >>> The first is knowledge of connectivity at layer 2, and feeding it
> >>> upward to the routing table.  OK, I'll live with that.
> >>>
> >>> But the second is the MAC.  With a shared media, you need one
> >>> (conversely, with point-point media you don't).  So capacity of
> >>> the layer 2 radio network is baseband capacity prorated across
> >>> all the SS in the segment .... minus the overhead used by the
> >>> MAC.  In the case of ethernet derivatives (like WiFi), that
> >>> overhead may reach 80%!  And it gets worse as the segment gets
> >>> more congested ... so one of the metrics you would need to get
> >>> hold of is how congested the network segment is ... so you don't
> >>> overload and stall it.
> >>
> >> I am not sure how this is connected to a "does/does-not layer-2
> >> mesh" TLV for DLEP.
> >
> > In the case described above, I could see SS-to-SS connectivity (via
> > the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the
> > statement that "mesh" is poorly defined.
>
> Maybe it would make more sense to distinguish layer-2 networks where
>
> a) Layer-3 has to look for multihop paths within the radio domain
>
> b) layer-2 networks which either have no alternative paths to
> destinations or do multihop retransmissions themselves
>
> in case b, a MANET protocol could simplify the flooding and routing by
> not considering multihop-forwarding on the radio interface (only to
> other destinations beyond other interfaces).
>
> >> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does
> >> not include this asymmetry.
> >
> > That reminds me of a statement a college professor made. Something
> > along the lines of "No one in their right mind will ever use 802.11
> > adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc
> > example irrelevant.
>
> I think we can agree to disagree on this statement.
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de

The information contained within this e-mail and any files attached to this=
 e-mail is private and in addition may include commercially sensitive infor=
mation. The contents of this e-mail are for the intended recipient only and=
 therefore if you wish to disclose the information contained within this e-=
mail or attached files, please contact the sender prior to any such disclos=
ure. If you are not the intended recipient, any disclosure, copying or dist=
ribution is prohibited. Please also contact the sender and inform them of t=
he error and delete the e-mail, including any attached files from your syst=
em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, =
Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

From teco@inf-net.nl  Wed Apr 24 08:04:14 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6221F8607 for ; Wed, 24 Apr 2013 08:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnCkiZQa6N8Y for ; Wed, 24 Apr 2013 08:04:13 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8921F85D7 for ; Wed, 24 Apr 2013 08:04:12 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id o7so1717440wea.18 for ; Wed, 24 Apr 2013 08:04:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QV1kyFN8IH1z9ld6un26TYyzwT1Mp+7WNMGuXBPlkZc=; b=YW0UwBDpf5xyCbsHK/mJBeJQkR29RbaXbMzcmJcyo7WU09EMTNCIhzf1yw13pBtyPB lVXllCIY50jSv2wvgMueD3bLHfRR2E4GGopkOKsAT2W4StN1s/RYQZxe8Umn7GWcU/pK 9+JrI3YiR/4ftuGjTiyZZQOQ0oryCn+qV14yph9MRrG2vS/KZcxTJTl7ekSzBlIjBT3T vRWzlDT9mfNnHhJMhT3ImIRI5Wqeu8+7qZ2I0PNpY47pPAShJ+PQq2VnI1gB/g19A46U rk0oOHNhjz/cDGtRC65hHqmCIcRJpRdr3LpegJuTCkDuX25v+Lou0+5sINjI8qt7Lejg Qs/Q==
X-Received: by 10.180.38.105 with SMTP id f9mr68175902wik.15.1366815851620; Wed, 24 Apr 2013 08:04:11 -0700 (PDT)
Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id nf9sm15310353wic.3.2013.04.24.08.04.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 08:04:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Teco Boot 
In-Reply-To: 
Date: Wed, 24 Apr 2013 17:04:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>  
To: Rick Taylor , Henning Rogge 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQlT3LMPZyO4usJoy0JxQNfYxrou6WBpMBdhOy6Mt+3CETYLu079KlS8fD/JAPFKSVKnPUSy
Cc: " List" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 15:04:14 -0000

I'm not sure I get the problem.

DLEP provides info on L2 / sub-IP links to a connected router. In the =
example, radio-A provides info to connected router-A on links to a =
router-B, router-E and router-F (not clear in the example radio-C and =
radio-D have connected routers). The reported metric *should be composed =
from info from al links of the L2 / sub-IP path*. If the radio cannot =
provide such, but instead provides only info on parts of the path (such =
as for radio A reports only link A-C), I wonder what the router can do =
with such information (other than discard...).

@Henning: If NHDP tells that each neighbor has connectivity to all other =
neighbors on that IP link, wouldn't that be "full connected"? Are you =
looking for this FullConnected TLV?

Teco=20


Op 24 apr. 2013, om 14:13 heeft Taylor, Rick het volgende geschreven:

> As one of the instigators of the 'Should there be a meshing flag in =
DLEP' questions I thought I should add a bit of history.
>=20
> My team have been implementing layer-3 routing over 802.11s style =
'mesh' radios which support DLEP-00.  Unfortunately, the radio =
implementation is primitive and based on an early DLEP draft and so has =
some issues, the prime example being that the neighbour metrics supplied =
to the router by the radios did not match the underlying topology of the =
layer-2 mesh.
>=20
> A quick example: (The bow-tie)
>=20
> A           E
>  \       /
>   C -- D
>  /       \
> B           F
>=20
> =46rom the manufacturer's reading of DLEP-00, the reported CDR from A =
to F did not account for any loading placed on C and D from traffic =
travelling E to B.  Hence the layer3 routing decisions ended up flooding =
the intermediate nodes resulting in network collapse.
>=20
> In trying to see a way forwards, we came to two proposals:
>=20
> A) DLEP should allow some way for a radio to state that it is =
participating in a mesh that performs multi-hop layer-2 packet =
forwarding, and as such, the router should not attempt layer-3 multi-hop =
routing within the mesh.  This is the proposal picked up by Henning, the =
Boolean mesh TLV.
>=20
> B) The DLEP specification should include explicit statements forcing =
manufacturers to correctly handle the 'bow-tie' example above when =
reporting metrics, allowing a layer-3 router to pick a multi-hop route =
within the mesh that matches the layer-2 packet paths.  This I believe =
is Stan's position.
>=20
> As I see it B) is the most 'correct' solution but it relies on careful =
wording in the specification that is understandable not only in English, =
but also to non-native speakers (I know this out of scope for an IETF =
document, but it is a reality).  Also, incorrect implementations are =
fatal to routers.
>=20
> Option A) is a cludge/compromise/cop-out, but it does give =
manufacturers a way to specify that they do something they consider =
clever (or too complicated to get the metrics right) at layer-2, and =
layer-3 routers should avoid performing multi-hop routing *within* the =
radio-net.
>=20
> As a pragmatist, I feel that DLEP should aim for B, but allow option =
A.
>=20
> Rick Taylor
>=20
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =
Behalf Of
>> Henning Rogge
>> Sent: 24 April 2013 10:26
>> To: manet@ietf.org
>> Subject: Re: [manet] DLEP link metric discussion
>>=20
>> On 04/23/2013 06:52 PM, Stan Ratliff (sratliff) wrote:
>>> Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.
>>=20
>> Yes, that would be bad.
>>=20
>>>>>> Layer-2 mesh ------------
>>>>>>=20
>>>>> Henning, we need to be careful about the term 'mesh'.  It's been
>>>>> badly abused and poorly defined ... and if you've been raised
>>>>> with fiber/copper underlying connectivity, the set of assumptions
>>>>> changes (you got that part), but it changes in some ways that you
>>>>> didn't get.
>>>>=20
>>>> I used "mesh" as a layer-2 MANET technology... 802.11s for example,
>>>> or BATMAN Advanced as it is included in the Linux Kernel.
>>>>=20
>>>>>> It seems that many IP radios try to establish a transparent
>>>>>> layer-2 mesh between the radios on the same channel. The fact
>>>>>> that the linklayer forms a mesh is useful knowledge for a
>>>>>> layer-3 MANET routing protocol, it allows an implementation to
>>>>>> optimize its flooding and forwarding routings (by not using
>>>>>> two-hop routes within the layer-2 mesh domain).
>>>>>=20
>>>>> There are two issues here that need to be disentangled.
>>>>>=20
>>>>> The first is knowledge of connectivity at layer 2, and feeding it
>>>>> upward to the routing table.  OK, I'll live with that.
>>>>>=20
>>>>> But the second is the MAC.  With a shared media, you need one
>>>>> (conversely, with point-point media you don't).  So capacity of
>>>>> the layer 2 radio network is baseband capacity prorated across
>>>>> all the SS in the segment .... minus the overhead used by the
>>>>> MAC.  In the case of ethernet derivatives (like WiFi), that
>>>>> overhead may reach 80%!  And it gets worse as the segment gets
>>>>> more congested ... so one of the metrics you would need to get
>>>>> hold of is how congested the network segment is ... so you don't
>>>>> overload and stall it.
>>>>=20
>>>> I am not sure how this is connected to a "does/does-not layer-2
>>>> mesh" TLV for DLEP.
>>>=20
>>> In the case described above, I could see SS-to-SS connectivity (via
>>> the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the
>>> statement that "mesh" is poorly defined.
>>=20
>> Maybe it would make more sense to distinguish layer-2 networks where
>>=20
>> a) Layer-3 has to look for multihop paths within the radio domain
>>=20
>> b) layer-2 networks which either have no alternative paths to
>> destinations or do multihop retransmissions themselves
>>=20
>> in case b, a MANET protocol could simplify the flooding and routing =
by
>> not considering multihop-forwarding on the radio interface (only to
>> other destinations beyond other interfaces).
>>=20
>>>> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does
>>>> not include this asymmetry.
>>>=20
>>> That reminds me of a statement a college professor made. Something
>>> along the lines of "No one in their right mind will ever use 802.11
>>> adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc
>>> example irrelevant.
>>=20
>> I think we can agree to disagree on this statement.
>>=20
>> Henning Rogge
>>=20
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>=20
> The information contained within this e-mail and any files attached to =
this e-mail is private and in addition may include commercially =
sensitive information. The contents of this e-mail are for the intended =
recipient only and therefore if you wish to disclose the information =
contained within this e-mail or attached files, please contact the =
sender prior to any such disclosure. If you are not the intended =
recipient, any disclosure, copying or distribution is prohibited. Please =
also contact the sender and inform them of the error and delete the =
e-mail, including any attached files from your system. Cassidian =
Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, =
Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From Martin.Duke@boeing.com  Wed Apr 24 09:10:13 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1B21F8EF2 for ; Wed, 24 Apr 2013 09:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sco0tFVbQlgw for ; Wed, 24 Apr 2013 09:10:12 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1440521F8F41 for ; Wed, 24 Apr 2013 09:10:11 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r3OGAAhc028944 for ; Wed, 24 Apr 2013 09:10:11 -0700
Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r3OGA8RE028904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 24 Apr 2013 09:10:08 -0700
Received: from XCH-BLV-101.nw.nos.boeing.com (130.247.25.116) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 24 Apr 2013 09:10:07 -0700
Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.36]) by XCH-BLV-101.nw.nos.boeing.com ([fe80::9959:dc1d:1361:f258%16]) with mapi id 14.02.0328.011; Wed, 24 Apr 2013 09:10:07 -0700
From: "Duke, Martin" 
To: "teco@inf-net.nl" , "Rick.Taylor@cassidian.com" , "henning.rogge@fkie.fraunhofer.de" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CEHp/iu20C0eCAfN8pC7SSJjlPyywgACugoD//5hKkA==
Date: Wed, 24 Apr 2013 16:10:06 +0000
Message-ID: <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl>
In-Reply-To: <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 16:10:13 -0000

Some responses to some various points in this discussion (I was the one tha=
t originally argued to replace the 1-Byte Mesh Boolean with a 1-Byte hop co=
unt integer).

1) I concede that explicitly stating hop count will create more updates, bu=
t are we really that constrained in control plane bandwidth between radio a=
nd router? Who cares if we send a few local messages per second in this cha=
nnel?

2) I'm hesitant to say that the mesh Boolean should *strictly prevent* the =
router from doing its own forwarding through the mesh. It's true that some =
routers are unsophisticated and some radios have fancy cross-layer mechanis=
ms. It's also true that some radios aren't that sophisticated, and that rou=
ters (in principle) may be doing all kinds of innovative traffic engineerin=
g using multi-topology routing, load balancing, integrated services, or wha=
t have you. It's much better to empower the interface to communicate enough=
 information to support any approach, and let network architects decide who=
's ultimately in charge depending on known capabilities of routers and radi=
os.

3) In particular, I'm concerned (as others have stated) that link metrics l=
ike throughput and latency, when reported for multi-hop neighbors, aren't g=
oing to be very accurate. Whether or not we use explicit hop counts, I insi=
st that the mesh Boolean be *per-neighbor*, so the router can distinguish b=
etween true single-hop neighbors (which presumably have reliable statistics=
) and far-flung mesh destinations.

Martin

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T=
eco Boot
Sent: Wednesday, April 24, 2013 8:04 AM
To: Rick Taylor; Henning Rogge
Cc:  List
Subject: Re: [manet] DLEP link metric discussion

I'm not sure I get the problem.

DLEP provides info on L2 / sub-IP links to a connected router. In the examp=
le, radio-A provides info to connected router-A on links to a router-B, rou=
ter-E and router-F (not clear in the example radio-C and radio-D have conne=
cted routers). The reported metric *should be composed from info from al li=
nks of the L2 / sub-IP path*. If the radio cannot provide such, but instead=
 provides only info on parts of the path (such as for radio A reports only =
link A-C), I wonder what the router can do with such information (other tha=
n discard...).

@Henning: If NHDP tells that each neighbor has connectivity to all other ne=
ighbors on that IP link, wouldn't that be "full connected"? Are you looking=
 for this FullConnected TLV?

Teco=20


Op 24 apr. 2013, om 14:13 heeft Taylor, Rick het volgende geschreven:

> As one of the instigators of the 'Should there be a meshing flag in DLEP'=
 questions I thought I should add a bit of history.
>=20
> My team have been implementing layer-3 routing over 802.11s style 'mesh' =
radios which support DLEP-00.  Unfortunately, the radio implementation is p=
rimitive and based on an early DLEP draft and so has some issues, the prime=
 example being that the neighbour metrics supplied to the router by the rad=
ios did not match the underlying topology of the layer-2 mesh.
>=20
> A quick example: (The bow-tie)
>=20
> A           E
>  \       /
>   C -- D
>  /       \
> B           F
>=20
> From the manufacturer's reading of DLEP-00, the reported CDR from A to F =
did not account for any loading placed on C and D from traffic travelling E=
 to B.  Hence the layer3 routing decisions ended up flooding the intermedia=
te nodes resulting in network collapse.
>=20
> In trying to see a way forwards, we came to two proposals:
>=20
> A) DLEP should allow some way for a radio to state that it is participati=
ng in a mesh that performs multi-hop layer-2 packet forwarding, and as such=
, the router should not attempt layer-3 multi-hop routing within the mesh. =
 This is the proposal picked up by Henning, the Boolean mesh TLV.
>=20
> B) The DLEP specification should include explicit statements forcing manu=
facturers to correctly handle the 'bow-tie' example above when reporting me=
trics, allowing a layer-3 router to pick a multi-hop route within the mesh =
that matches the layer-2 packet paths.  This I believe is Stan's position.
>=20
> As I see it B) is the most 'correct' solution but it relies on careful wo=
rding in the specification that is understandable not only in English, but =
also to non-native speakers (I know this out of scope for an IETF document,=
 but it is a reality).  Also, incorrect implementations are fatal to router=
s.
>=20
> Option A) is a cludge/compromise/cop-out, but it does give manufacturers =
a way to specify that they do something they consider clever (or too compli=
cated to get the metrics right) at layer-2, and layer-3 routers should avoi=
d performing multi-hop routing *within* the radio-net.
>=20
> As a pragmatist, I feel that DLEP should aim for B, but allow option A.
>=20
> Rick Taylor
>=20
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On=20
>> Behalf Of Henning Rogge
>> Sent: 24 April 2013 10:26
>> To: manet@ietf.org
>> Subject: Re: [manet] DLEP link metric discussion
>>=20
>> On 04/23/2013 06:52 PM, Stan Ratliff (sratliff) wrote:
>>> Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.
>>=20
>> Yes, that would be bad.
>>=20
>>>>>> Layer-2 mesh ------------
>>>>>>=20
>>>>> Henning, we need to be careful about the term 'mesh'.  It's been=20
>>>>> badly abused and poorly defined ... and if you've been raised with=20
>>>>> fiber/copper underlying connectivity, the set of assumptions=20
>>>>> changes (you got that part), but it changes in some ways that you=20
>>>>> didn't get.
>>>>=20
>>>> I used "mesh" as a layer-2 MANET technology... 802.11s for example,=20
>>>> or BATMAN Advanced as it is included in the Linux Kernel.
>>>>=20
>>>>>> It seems that many IP radios try to establish a transparent
>>>>>> layer-2 mesh between the radios on the same channel. The fact=20
>>>>>> that the linklayer forms a mesh is useful knowledge for a
>>>>>> layer-3 MANET routing protocol, it allows an implementation to=20
>>>>>> optimize its flooding and forwarding routings (by not using=20
>>>>>> two-hop routes within the layer-2 mesh domain).
>>>>>=20
>>>>> There are two issues here that need to be disentangled.
>>>>>=20
>>>>> The first is knowledge of connectivity at layer 2, and feeding it=20
>>>>> upward to the routing table.  OK, I'll live with that.
>>>>>=20
>>>>> But the second is the MAC.  With a shared media, you need one=20
>>>>> (conversely, with point-point media you don't).  So capacity of=20
>>>>> the layer 2 radio network is baseband capacity prorated across all=20
>>>>> the SS in the segment .... minus the overhead used by the MAC.  In=20
>>>>> the case of ethernet derivatives (like WiFi), that overhead may=20
>>>>> reach 80%!  And it gets worse as the segment gets more congested=20
>>>>> ... so one of the metrics you would need to get hold of is how=20
>>>>> congested the network segment is ... so you don't overload and=20
>>>>> stall it.
>>>>=20
>>>> I am not sure how this is connected to a "does/does-not layer-2=20
>>>> mesh" TLV for DLEP.
>>>=20
>>> In the case described above, I could see SS-to-SS connectivity (via=20
>>> the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the=20
>>> statement that "mesh" is poorly defined.
>>=20
>> Maybe it would make more sense to distinguish layer-2 networks where
>>=20
>> a) Layer-3 has to look for multihop paths within the radio domain
>>=20
>> b) layer-2 networks which either have no alternative paths to=20
>> destinations or do multihop retransmissions themselves
>>=20
>> in case b, a MANET protocol could simplify the flooding and routing=20
>> by not considering multihop-forwarding on the radio interface (only=20
>> to other destinations beyond other interfaces).
>>=20
>>>> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does=20
>>>> not include this asymmetry.
>>>=20
>>> That reminds me of a statement a college professor made. Something=20
>>> along the lines of "No one in their right mind will ever use 802.11=20
>>> adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc=20
>>> example irrelevant.
>>=20
>> I think we can agree to disagree on this statement.
>>=20
>> Henning Rogge
>>=20
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20
>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20
>> Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>=20
> The information contained within this e-mail and any files attached to=20
> this e-mail is private and in addition may include commercially=20
> sensitive information. The contents of this e-mail are for the=20
> intended recipient only and therefore if you wish to disclose the=20
> information contained within this e-mail or attached files, please=20
> contact the sender prior to any such disclosure. If you are not the=20
> intended recipient, any disclosure, copying or distribution is=20
> prohibited. Please also contact the sender and inform them of the=20
> error and delete the e-mail, including any attached files from your=20
> system. Cassidian Limited, Registered Office : Quadrant House, Celtic=20
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036=20
> http://www.cassidian.com=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

From yi.jiazi@gmail.com  Wed Apr 24 09:12:25 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5421F8DA6 for ; Wed, 24 Apr 2013 09:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2iGa5cF39Jp for ; Wed, 24 Apr 2013 09:12:24 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 337EB21F946C for ; Wed, 24 Apr 2013 09:12:24 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id s47so1015375wey.22 for ; Wed, 24 Apr 2013 09:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=YVkUjMw5nmww/gX4BjZ6yR/gramz0JwZpaYGLTlqVtA=; b=h2WK+5faYCTQzDpfOv4ZQBUpnZRAavBXFbS/1xNhmFtMVDrcWmXBSMZsB0/yOGSX4K a1XohzsabxQgPZdYdcf5aiSejNwOkXfHWbQDvjTbMZ2eCcFAF9t2mQJOls2are+E7wVJ EH7MY8Jhgi+P6TUcIctLfd0bW+BKxs1N1hC4ZDtbdg2rTiuuRbgZs5OGScKSRcTpRsVf SRZNA5ds4hnc14WqtMU2+gd1gpPddFo13dnk0+8rEEEC6At1y2KWHawWbrk1QKcpAcgH 2P1LliD82ogfm8l6VqYH6aA8Lu/HwzHoBli5YopNKnonE0N26zRadEC7eNmGuVrfuMhX wQTg==
X-Received: by 10.180.206.205 with SMTP id lq13mr69560206wic.21.1366819943327;  Wed, 24 Apr 2013 09:12:23 -0700 (PDT)
Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPSA id s2sm5154473wib.4.2013.04.24.09.12.21 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:12:22 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>
Date: Wed, 24 Apr 2013 18:12:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>
To: "Dearlove, Christopher (UK)" 
X-Mailer: Apple Mail (2.1503)
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 16:12:25 -0000

Hi,=20

After several mail exchange with some of the other authors, I think it =
would be better to keep the draft as it is on the mutable fields, =
because how to define/use protocol-specific mutable fields is not very =
clear at this point.=20
If necessary, it would probably be better to put them in another =
document, after we figuring out exactly how to handle those fields.=20

best

Jiazi

On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:

> Chris,=20
>=20
> I do understand your concern. We had this kind of discussion on =
mutable fields before, and this is something I'm still mulling over.=20
> The reason why I propose this for discussion is:
>=20
> 	- this rfc6622bis is for rfc5444, which is a general format for =
all manet protocols.=20
> 	- The reactive protocol like LOADng does explicitly define such =
"mutable" fields. It is something at hand, not in the far future.=20
>=20
> In the meantime, I do agree that the necessity and how to take care of =
such mutable fields should be considered carefully.=20
> So I would agree that we keep the current rfc6622bis draft as it is =
for the moment, and I'll have more discussions with other LOADng authors =
on this.=20
>=20
> best=20
>=20
> Jiazi
>=20
> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" =
 wrote:
>=20
>> Jiazi
>>=20
>> Thanks for that, I'll just comment on the one point where I disagree.
>>=20
>> Putting some vague words in that protocols may indicate fields not to =
be covered is the sort of thing that I can predict will cause us =
problems at the IESG. And it's not really a good plan for a generic =
mechanism that can - at at present - be run independently of the routing =
protocol to acquire a protocol dependence. Rather I think that any =
routing protocols with a specific need to exclude data (which, all else =
being equal is a bad thing of course) should consider defining a new =
type extension - preferably one defined with some generic capability =
(could it, for example, list TLV types to be excluded?) But that's for =
the future. One thing I have learned is that design in advance of what =
might hypothetically be needed generally gets it wrong, so it would be =
good to wait until exactly what's needed is clear, and then define a new =
case.
>>=20
>> Christopher
>>=20
>> --=20
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>=20
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>=20
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =
Behalf Of ietf@jiaziyi.com
>> Sent: 23 April 2013 15:37
>> To: manet@ietf.org
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>=20
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>> (sorry if you receive duplicate of this message. Some of my mails to=20=

>> the mailing list are rejected, and I'm trying to figure out with our=20=

>> secretary...)
>>=20
>> Hi,
>>=20
>> I had a review of the draft. I think it's in good shape, and ready =
for=20
>> WGLC.
>>=20
>> a few comments:
>>=20
>> In section 6 & 7, I didn't find the definition of notation
>> 	+
>> Not in this draft, either rfc 5444.
>>=20
>> page 13,  source code address =3D=3D> source node address?
>>=20
>> section 9.1 bullet 1 states that the  and=20
>>  must be zeroed before calculating ICV. I'm thinking=20=

>> about that we might need to mention that some protocol-specific =
mutable=20
>> fields must be zeroed here also. For example, in LOADng, as a =
reactive=20
>> protocol, metric fields are defined as "mutable" (in the meantime, I=20=

>> still have some thoughts on those mutable fields that I need to =
discuss=20
>> with other LOADng authors, but it's not that relevant here).
>>=20
>> best
>>=20
>> Jiazi
>>=20
>>=20
>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts=20
>> directories.
>> This draft is a work item of the Mobile Ad-hoc Networks Working Group=20=

>> of the IETF.
>>=20
>> 	Title           : Integrity Check Value and Timestamp TLV =
Definitions=20
>> for Mobile Ad Hoc Networks (MANETs)
>> 	Author(s)       : Ulrich Herberg
>>                        Thomas Heide Clausen
>>                        Christopher Dearlove
>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>> 	Pages           : 24
>> 	Date            : 2013-04-15
>>=20
>> Abstract:
>> This document revises, extends and replaces RFC 6622.  It describes
>> general and flexible TLVs for representing cryptographic Integrity
>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>> for affixing ICVs and timestamps to a packet, a message, and one or
>> more addresses, respectively.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>>=20
>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended
>> recipient please delete it from your system and notify the sender.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>>=20
>=20


From Chris.Dearlove@baesystems.com  Wed Apr 24 09:19:57 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E3D21F8AA6 for ; Wed, 24 Apr 2013 09:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHXbHudsx8Zi for ; Wed, 24 Apr 2013 09:19:56 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDCF21F8A53 for ; Wed, 24 Apr 2013 09:19:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,542,1363132800"; d="scan'208";a="281571629"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Apr 2013 17:19:53 +0100
Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3OGJr9X012733 for ; Wed, 24 Apr 2013 17:19:53 +0100
X-IronPort-AV: E=Sophos;i="4.87,542,1363132800"; d="scan'208";a="14129892"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 24 Apr 2013 17:19:51 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 17:19:52 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi Yi 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g
Date: Wed, 24 Apr 2013 16:19:51 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 16:19:57 -0000

Thanks for that. I'm hoping we can proceed push out 6622bis, and the securi=
ty document.

As a contribution to that future concept, I'll note that 6622(bis) is indep=
endent of the protocol. That I think is a desirable thing.

One idea (I'm not sold on it, it's just for consideration) is that if you a=
re considering that, for example, you don't want to include a metric in you=
r ICV, and that metric is in TLV type X (probably a full type with type ext=
ension, but that's another of those details) then as a new variant type ext=
ension ICV, you could add something to say "remove all TLVs with type exten=
sions X, Y, Z before calculating ICV). Or maybe that needs to be a range. O=
r ... but first work out exactly what you want, then how it cleanly general=
ises (where a good generalisation is easier to implement than the special c=
ase).

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
Sent: 24 April 2013 17:12
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi,=20

After several mail exchange with some of the other authors, I think it woul=
d be better to keep the draft as it is on the mutable fields, because how t=
o define/use protocol-specific mutable fields is not very clear at this poi=
nt.=20
If necessary, it would probably be better to put them in another document, =
after we figuring out exactly how to handle those fields.=20

best

Jiazi

On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:

> Chris,=20
>=20
> I do understand your concern. We had this kind of discussion on mutable f=
ields before, and this is something I'm still mulling over.=20
> The reason why I propose this for discussion is:
>=20
> 	- this rfc6622bis is for rfc5444, which is a general format for all mane=
t protocols.=20
> 	- The reactive protocol like LOADng does explicitly define such "mutable=
" fields. It is something at hand, not in the far future.=20
>=20
> In the meantime, I do agree that the necessity and how to take care of su=
ch mutable fields should be considered carefully.=20
> So I would agree that we keep the current rfc6622bis draft as it is for t=
he moment, and I'll have more discussions with other LOADng authors on this=
.=20
>=20
> best=20
>=20
> Jiazi
>=20
> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)"  wrote:
>=20
>> Jiazi
>>=20
>> Thanks for that, I'll just comment on the one point where I disagree.
>>=20
>> Putting some vague words in that protocols may indicate fields not to be=
 covered is the sort of thing that I can predict will cause us problems at =
the IESG. And it's not really a good plan for a generic mechanism that can =
- at at present - be run independently of the routing protocol to acquire a=
 protocol dependence. Rather I think that any routing protocols with a spec=
ific need to exclude data (which, all else being equal is a bad thing of co=
urse) should consider defining a new type extension - preferably one define=
d with some generic capability (could it, for example, list TLV types to be=
 excluded?) But that's for the future. One thing I have learned is that des=
ign in advance of what might hypothetically be needed generally gets it wro=
ng, so it would be good to wait until exactly what's needed is clear, and t=
hen define a new case.
>>=20
>> Christopher
>>=20
>> --=20
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>=20
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr=
e, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>=20
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O=
f ietf@jiaziyi.com
>> Sent: 23 April 2013 15:37
>> To: manet@ietf.org
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>=20
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>> (sorry if you receive duplicate of this message. Some of my mails to=20
>> the mailing list are rejected, and I'm trying to figure out with our=20
>> secretary...)
>>=20
>> Hi,
>>=20
>> I had a review of the draft. I think it's in good shape, and ready for=20
>> WGLC.
>>=20
>> a few comments:
>>=20
>> In section 6 & 7, I didn't find the definition of notation
>> 	+
>> Not in this draft, either rfc 5444.
>>=20
>> page 13,  source code address =3D=3D> source node address?
>>=20
>> section 9.1 bullet 1 states that the  and=20
>>  must be zeroed before calculating ICV. I'm thinking=20
>> about that we might need to mention that some protocol-specific mutable=
=20
>> fields must be zeroed here also. For example, in LOADng, as a reactive=20
>> protocol, metric fields are defined as "mutable" (in the meantime, I=20
>> still have some thoughts on those mutable fields that I need to discuss=
=20
>> with other LOADng authors, but it's not that relevant here).
>>=20
>> best
>>=20
>> Jiazi
>>=20
>>=20
>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts=20
>> directories.
>> This draft is a work item of the Mobile Ad-hoc Networks Working Group=20
>> of the IETF.
>>=20
>> 	Title           : Integrity Check Value and Timestamp TLV Definitions=20
>> for Mobile Ad Hoc Networks (MANETs)
>> 	Author(s)       : Ulrich Herberg
>>                        Thomas Heide Clausen
>>                        Christopher Dearlove
>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>> 	Pages           : 24
>> 	Date            : 2013-04-15
>>=20
>> Abstract:
>> This document revises, extends and replaces RFC 6622.  It describes
>> general and flexible TLVs for representing cryptographic Integrity
>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>> for affixing ICVs and timestamps to a packet, a message, and one or
>> more addresses, respectively.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>>=20
>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended
>> recipient please delete it from your system and notify the sender.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>>=20
>=20



From yi.jiazi@gmail.com  Wed Apr 24 09:55:25 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7021F8FA4 for ; Wed, 24 Apr 2013 09:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJO5jdSoS3la for ; Wed, 24 Apr 2013 09:55:23 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1488621F8A53 for ; Wed, 24 Apr 2013 09:55:22 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id h11so8099539wiv.2 for ; Wed, 24 Apr 2013 09:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=0m5zvPNvXuLZB1tTVUUQ6I7UpKDovBtRpWz/AVu+k6A=; b=WIDLST4ywO4vWeEOghDLsT1ptrgjSqXEoVOefYcCqf7Fs7gZG6cDaOQUrXW0A4FYlj RoaEHXC8odsIT7PO2xZoT+EJmW4p3PagXUONVAJZgadpSENsItZw65x0REBe3JpCLSyp D3Fj1hHcLHJYTBCrFvHU0PuWDG0sXnBCi+4/cpL52tEQ3bOUbuwgaO/+Fs16hm9+xynp 8di7YPBanwpW8c5ZNZ1Pvy0jVGLS8Dcnd/3Kjt1j7iaUeUWBmNz+mK10agB4ahstPtOF hV8f6WXWSBqVez/CioccrjszFTNH8bNVLGGNEPPZlv+Add0dnfI8ko5Zhi40VShJV6z1 h6nw==
X-Received: by 10.180.205.135 with SMTP id lg7mr54183952wic.11.1366822521668;  Wed, 24 Apr 2013 09:55:21 -0700 (PDT)
Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPSA id q20sm5370435wiv.7.2013.04.24.09.55.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:55:20 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: 
Date: Wed, 24 Apr 2013 18:55:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>  
To: "Dearlove, Christopher (UK)" 
X-Mailer: Apple Mail (2.1503)
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 16:55:25 -0000

Thanks Chris for sharing your thought.=20

Yes, those are all possibilities to consider. And a more fundamental =
issue I'm thinking about is the framework for securing re-active =
protocols, because it's much harder than pro-acitve ones. For example, =
do we want to require hop-by-hop authentication? Zeroing the metric =
field opens possible attack vector also... anyway, we can discuss this =
in other topics in the future.=20

In the meantime, I reviewed the draft =
draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I =
would support it for WGLC.=20

Just one question:

In the draft:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 The following constraints apply to these parameters:

   o  MAX_HELLO_TIMESTAMP_DIFF > 0

   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

   o  MAX_TC_TIMESTAMP_DIFF > 0

   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

   The second and fourth of those constraints assume ideal time
   synchronization of the clocks in all routers in the network.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My understanding is that, "the time difference equals 0" is for ideal =
time synchronization. So it should be The first and third assume ideal =
time synchronization? Or I missed something here?=20

best

Jiazi

On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" =
 wrote:

> Thanks for that. I'm hoping we can proceed push out 6622bis, and the =
security document.
>=20
> As a contribution to that future concept, I'll note that 6622(bis) is =
independent of the protocol. That I think is a desirable thing.
>=20
> One idea (I'm not sold on it, it's just for consideration) is that if =
you are considering that, for example, you don't want to include a =
metric in your ICV, and that metric is in TLV type X (probably a full =
type with type extension, but that's another of those details) then as a =
new variant type extension ICV, you could add something to say "remove =
all TLVs with type extensions X, Y, Z before calculating ICV). Or maybe =
that needs to be a range. Or ... but first work out exactly what you =
want, then how it cleanly generalises (where a good generalisation is =
easier to implement than the special case).
>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
>=20
> -----Original Message-----
> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
> Sent: 24 April 2013 17:12
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Hi,=20
>=20
> After several mail exchange with some of the other authors, I think it =
would be better to keep the draft as it is on the mutable fields, =
because how to define/use protocol-specific mutable fields is not very =
clear at this point.=20
> If necessary, it would probably be better to put them in another =
document, after we figuring out exactly how to handle those fields.=20
>=20
> best
>=20
> Jiazi
>=20
> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
>=20
>> Chris,=20
>>=20
>> I do understand your concern. We had this kind of discussion on =
mutable fields before, and this is something I'm still mulling over.=20
>> The reason why I propose this for discussion is:
>>=20
>> 	- this rfc6622bis is for rfc5444, which is a general format for =
all manet protocols.=20
>> 	- The reactive protocol like LOADng does explicitly define such =
"mutable" fields. It is something at hand, not in the far future.=20
>>=20
>> In the meantime, I do agree that the necessity and how to take care =
of such mutable fields should be considered carefully.=20
>> So I would agree that we keep the current rfc6622bis draft as it is =
for the moment, and I'll have more discussions with other LOADng authors =
on this.=20
>>=20
>> best=20
>>=20
>> Jiazi
>>=20
>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" =
 wrote:
>>=20
>>> Jiazi
>>>=20
>>> Thanks for that, I'll just comment on the one point where I =
disagree.
>>>=20
>>> Putting some vague words in that protocols may indicate fields not =
to be covered is the sort of thing that I can predict will cause us =
problems at the IESG. And it's not really a good plan for a generic =
mechanism that can - at at present - be run independently of the routing =
protocol to acquire a protocol dependence. Rather I think that any =
routing protocols with a specific need to exclude data (which, all else =
being equal is a bad thing of course) should consider defining a new =
type extension - preferably one defined with some generic capability =
(could it, for example, list TLV types to be excluded?) But that's for =
the future. One thing I have learned is that design in advance of what =
might hypothetically be needed generally gets it wrong, so it would be =
good to wait until exactly what's needed is clear, and then define a new =
case.
>>>=20
>>> Christopher
>>>=20
>>> --=20
>>> Christopher Dearlove
>>> Senior Principal Engineer, Communications Group
>>> Communications, Networks and Image Analysis Capability
>>> BAE Systems Advanced Technology Centre
>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>>=20
>>> BAE Systems (Operations) Limited
>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
>>> Registered in England & Wales No: 1996687
>>>=20
>>> -----Original Message-----
>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =
Behalf Of ietf@jiaziyi.com
>>> Sent: 23 April 2013 15:37
>>> To: manet@ietf.org
>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>>=20
>>> ----------------------! WARNING ! ----------------------
>>> This message originates from outside our organisation,
>>> either from an external partner or from the internet.
>>> Keep this in mind if you answer this message.
>>> Follow the 'Report Suspicious Emails' link on IT matters
>>> for instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>=20
>>> (sorry if you receive duplicate of this message. Some of my mails to=20=

>>> the mailing list are rejected, and I'm trying to figure out with our=20=

>>> secretary...)
>>>=20
>>> Hi,
>>>=20
>>> I had a review of the draft. I think it's in good shape, and ready =
for=20
>>> WGLC.
>>>=20
>>> a few comments:
>>>=20
>>> In section 6 & 7, I didn't find the definition of notation
>>> 	+
>>> Not in this draft, either rfc 5444.
>>>=20
>>> page 13,  source code address =3D=3D> source node address?
>>>=20
>>> section 9.1 bullet 1 states that the  and=20
>>>  must be zeroed before calculating ICV. I'm thinking=20=

>>> about that we might need to mention that some protocol-specific =
mutable=20
>>> fields must be zeroed here also. For example, in LOADng, as a =
reactive=20
>>> protocol, metric fields are defined as "mutable" (in the meantime, I=20=

>>> still have some thoughts on those mutable fields that I need to =
discuss=20
>>> with other LOADng authors, but it's not that relevant here).
>>>=20
>>> best
>>>=20
>>> Jiazi
>>>=20
>>>=20
>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts=20=

>>> directories.
>>> This draft is a work item of the Mobile Ad-hoc Networks Working =
Group=20
>>> of the IETF.
>>>=20
>>> 	Title           : Integrity Check Value and Timestamp TLV =
Definitions=20
>>> for Mobile Ad Hoc Networks (MANETs)
>>> 	Author(s)       : Ulrich Herberg
>>>                       Thomas Heide Clausen
>>>                       Christopher Dearlove
>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>> 	Pages           : 24
>>> 	Date            : 2013-04-15
>>>=20
>>> Abstract:
>>> This document revises, extends and replaces RFC 6622.  It describes
>>> general and flexible TLVs for representing cryptographic Integrity
>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>> defines two Packet TLVs, two Message TLVs, and two Address Block =
TLVs
>>> for affixing ICVs and timestamps to a packet, a message, and one or
>>> more addresses, respectively.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>=20
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>>=20
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the intended
>>> recipient please delete it from your system and notify the sender.
>>> You should not copy it or use it for any purpose nor disclose or
>>> distribute its contents to any other person.
>>> ********************************************************************
>>>=20
>>=20
>=20
>=20


From sratliff@cisco.com  Wed Apr 24 10:18:18 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6F21F9662 for ; Wed, 24 Apr 2013 10:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVcxntxStYDy for ; Wed, 24 Apr 2013 10:18:17 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4750521F9652 for ; Wed, 24 Apr 2013 10:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10941; q=dns/txt; s=iport; t=1366823897; x=1368033497; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GadFxr6MXwQm3LDWcQlefUU7Az3BTSkW5b8G2CcZTnE=; b=BCtJNR1KN4AyPpqvitA5YpuX1DU5ldqMWF4s7VWE9HP4nwZSKic3Ky5P rZqp68AiYTreRaEsuumXzujWTxF/LD9ep1z+U4r2npq5Xm0qWXYnAZ8L4 tp9WIeSNSyKFgCJ7TL0drlrB0NeTp7Za8fva13KP/is/iO8h8YGa3KHH8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAFoReFGtJV2Z/2dsb2JhbABQgwY2vmCBABZ0gh8BAQEDAQEBAVIZCwUHBAIBCBEEAQEBCgsSBycLFAkIAgQOBQgTh3MGDL42jXgGfwILIQUHBgSCYGEDiFifZIMOgWoJFx4
X-IronPort-AV: E=Sophos;i="4.87,542,1363132800"; d="scan'208";a="202590400"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 24 Apr 2013 17:18:16 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3OHIFTU017940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Apr 2013 17:18:16 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 12:18:15 -0500
From: "Stan Ratliff (sratliff)" 
To: "Duke, Martin" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CuziAeW0oH0a4VE5B/25X2JjlPyywgACM+4CAABJtAIAAEwoA
Date: Wed, 24 Apr 2013 17:18:14 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com>
In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.150.34.157]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 17:18:19 -0000

What if we simply state that latency and bandwidth MUST reflect the full RF=
 path? And that, where appropriate, latency MUST include delay introduced a=
t any intermediate nodes?=20

I could be wrong about this, but it seems like I'm hearing a lot of "Well, =
the metrics aren't ALWAYS right, so we need all of these other indicators t=
o tell us (or at least give us a hint) whether or not they MIGHT be wrong."=
 I'd much rather more clearly define the metrics, and let the individual ra=
dio vendors innovate in the Layer1/2 space.=20

Regards,
Stan

On Apr 24, 2013, at 12:10 PM, Duke, Martin wrote:

> Some responses to some various points in this discussion (I was the one t=
hat originally argued to replace the 1-Byte Mesh Boolean with a 1-Byte hop =
count integer).
>=20
> 1) I concede that explicitly stating hop count will create more updates, =
but are we really that constrained in control plane bandwidth between radio=
 and router? Who cares if we send a few local messages per second in this c=
hannel?
>=20
> 2) I'm hesitant to say that the mesh Boolean should *strictly prevent* th=
e router from doing its own forwarding through the mesh. It's true that som=
e routers are unsophisticated and some radios have fancy cross-layer mechan=
isms. It's also true that some radios aren't that sophisticated, and that r=
outers (in principle) may be doing all kinds of innovative traffic engineer=
ing using multi-topology routing, load balancing, integrated services, or w=
hat have you. It's much better to empower the interface to communicate enou=
gh information to support any approach, and let network architects decide w=
ho's ultimately in charge depending on known capabilities of routers and ra=
dios.
>=20
> 3) In particular, I'm concerned (as others have stated) that link metrics=
 like throughput and latency, when reported for multi-hop neighbors, aren't=
 going to be very accurate. Whether or not we use explicit hop counts, I in=
sist that the mesh Boolean be *per-neighbor*, so the router can distinguish=
 between true single-hop neighbors (which presumably have reliable statisti=
cs) and far-flung mesh destinations.
>=20
> Martin
>=20
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of=
 Teco Boot
> Sent: Wednesday, April 24, 2013 8:04 AM
> To: Rick Taylor; Henning Rogge
> Cc:  List
> Subject: Re: [manet] DLEP link metric discussion
>=20
> I'm not sure I get the problem.
>=20
> DLEP provides info on L2 / sub-IP links to a connected router. In the exa=
mple, radio-A provides info to connected router-A on links to a router-B, r=
outer-E and router-F (not clear in the example radio-C and radio-D have con=
nected routers). The reported metric *should be composed from info from al =
links of the L2 / sub-IP path*. If the radio cannot provide such, but inste=
ad provides only info on parts of the path (such as for radio A reports onl=
y link A-C), I wonder what the router can do with such information (other t=
han discard...).
>=20
> @Henning: If NHDP tells that each neighbor has connectivity to all other =
neighbors on that IP link, wouldn't that be "full connected"? Are you looki=
ng for this FullConnected TLV?
>=20
> Teco=20
>=20
>=20
> Op 24 apr. 2013, om 14:13 heeft Taylor, Rick het volgende geschreven:
>=20
>> As one of the instigators of the 'Should there be a meshing flag in DLEP=
' questions I thought I should add a bit of history.
>>=20
>> My team have been implementing layer-3 routing over 802.11s style 'mesh'=
 radios which support DLEP-00.  Unfortunately, the radio implementation is =
primitive and based on an early DLEP draft and so has some issues, the prim=
e example being that the neighbour metrics supplied to the router by the ra=
dios did not match the underlying topology of the layer-2 mesh.
>>=20
>> A quick example: (The bow-tie)
>>=20
>> A           E
>> \       /
>>  C -- D
>> /       \
>> B           F
>>=20
>> From the manufacturer's reading of DLEP-00, the reported CDR from A to F=
 did not account for any loading placed on C and D from traffic travelling =
E to B.  Hence the layer3 routing decisions ended up flooding the intermedi=
ate nodes resulting in network collapse.
>>=20
>> In trying to see a way forwards, we came to two proposals:
>>=20
>> A) DLEP should allow some way for a radio to state that it is participat=
ing in a mesh that performs multi-hop layer-2 packet forwarding, and as suc=
h, the router should not attempt layer-3 multi-hop routing within the mesh.=
  This is the proposal picked up by Henning, the Boolean mesh TLV.
>>=20
>> B) The DLEP specification should include explicit statements forcing man=
ufacturers to correctly handle the 'bow-tie' example above when reporting m=
etrics, allowing a layer-3 router to pick a multi-hop route within the mesh=
 that matches the layer-2 packet paths.  This I believe is Stan's position.
>>=20
>> As I see it B) is the most 'correct' solution but it relies on careful w=
ording in the specification that is understandable not only in English, but=
 also to non-native speakers (I know this out of scope for an IETF document=
, but it is a reality).  Also, incorrect implementations are fatal to route=
rs.
>>=20
>> Option A) is a cludge/compromise/cop-out, but it does give manufacturers=
 a way to specify that they do something they consider clever (or too compl=
icated to get the metrics right) at layer-2, and layer-3 routers should avo=
id performing multi-hop routing *within* the radio-net.
>>=20
>> As a pragmatist, I feel that DLEP should aim for B, but allow option A.
>>=20
>> Rick Taylor
>>=20
>>> -----Original Message-----
>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On=20
>>> Behalf Of Henning Rogge
>>> Sent: 24 April 2013 10:26
>>> To: manet@ietf.org
>>> Subject: Re: [manet] DLEP link metric discussion
>>>=20
>>> On 04/23/2013 06:52 PM, Stan Ratliff (sratliff) wrote:
>>>> Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.
>>>=20
>>> Yes, that would be bad.
>>>=20
>>>>>>> Layer-2 mesh ------------
>>>>>>>=20
>>>>>> Henning, we need to be careful about the term 'mesh'.  It's been=20
>>>>>> badly abused and poorly defined ... and if you've been raised with=20
>>>>>> fiber/copper underlying connectivity, the set of assumptions=20
>>>>>> changes (you got that part), but it changes in some ways that you=20
>>>>>> didn't get.
>>>>>=20
>>>>> I used "mesh" as a layer-2 MANET technology... 802.11s for example,=20
>>>>> or BATMAN Advanced as it is included in the Linux Kernel.
>>>>>=20
>>>>>>> It seems that many IP radios try to establish a transparent
>>>>>>> layer-2 mesh between the radios on the same channel. The fact=20
>>>>>>> that the linklayer forms a mesh is useful knowledge for a
>>>>>>> layer-3 MANET routing protocol, it allows an implementation to=20
>>>>>>> optimize its flooding and forwarding routings (by not using=20
>>>>>>> two-hop routes within the layer-2 mesh domain).
>>>>>>=20
>>>>>> There are two issues here that need to be disentangled.
>>>>>>=20
>>>>>> The first is knowledge of connectivity at layer 2, and feeding it=20
>>>>>> upward to the routing table.  OK, I'll live with that.
>>>>>>=20
>>>>>> But the second is the MAC.  With a shared media, you need one=20
>>>>>> (conversely, with point-point media you don't).  So capacity of=20
>>>>>> the layer 2 radio network is baseband capacity prorated across all=20
>>>>>> the SS in the segment .... minus the overhead used by the MAC.  In=20
>>>>>> the case of ethernet derivatives (like WiFi), that overhead may=20
>>>>>> reach 80%!  And it gets worse as the segment gets more congested=20
>>>>>> ... so one of the metrics you would need to get hold of is how=20
>>>>>> congested the network segment is ... so you don't overload and=20
>>>>>> stall it.
>>>>>=20
>>>>> I am not sure how this is connected to a "does/does-not layer-2=20
>>>>> mesh" TLV for DLEP.
>>>>=20
>>>> In the case described above, I could see SS-to-SS connectivity (via=20
>>>> the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the=20
>>>> statement that "mesh" is poorly defined.
>>>=20
>>> Maybe it would make more sense to distinguish layer-2 networks where
>>>=20
>>> a) Layer-3 has to look for multihop paths within the radio domain
>>>=20
>>> b) layer-2 networks which either have no alternative paths to=20
>>> destinations or do multihop retransmissions themselves
>>>=20
>>> in case b, a MANET protocol could simplify the flooding and routing=20
>>> by not considering multihop-forwarding on the radio interface (only=20
>>> to other destinations beyond other interfaces).
>>>=20
>>>>> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does=20
>>>>> not include this asymmetry.
>>>>=20
>>>> That reminds me of a statement a college professor made. Something=20
>>>> along the lines of "No one in their right mind will ever use 802.11=20
>>>> adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc=20
>>>> example irrelevant.
>>>=20
>>> I think we can agree to disagree on this statement.
>>>=20
>>> Henning Rogge
>>>=20
>>> --
>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20
>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20
>>> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20
>>> Germany
>>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>=20
>> The information contained within this e-mail and any files attached to=20
>> this e-mail is private and in addition may include commercially=20
>> sensitive information. The contents of this e-mail are for the=20
>> intended recipient only and therefore if you wish to disclose the=20
>> information contained within this e-mail or attached files, please=20
>> contact the sender prior to any such disclosure. If you are not the=20
>> intended recipient, any disclosure, copying or distribution is=20
>> prohibited. Please also contact the sender and inform them of the=20
>> error and delete the e-mail, including any attached files from your=20
>> system. Cassidian Limited, Registered Office : Quadrant House, Celtic=20
>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036=20
>> http://www.cassidian.com=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From teco@inf-net.nl  Wed Apr 24 11:51:51 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8621F8EF5 for ; Wed, 24 Apr 2013 11:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI-dkCPc9rai for ; Wed, 24 Apr 2013 11:51:50 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8073A21F9080 for ; Wed, 24 Apr 2013 11:51:47 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id l13so2437196wie.6 for ; Wed, 24 Apr 2013 11:51:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=EAqn8IXr+Kd3IL4ERhMnECZFkeH2PTurDC5H9RyseCU=; b=MXnx8HFvohKPKoFRtdtJurgocCPR6VylaCuXJsd1gj3D1da8alu3C94GOlANUst9M5 qYBisv7lbw2zB5Sica4mN6mBws33rkTHZTFIcowzQNmhRsbykK+l+FRxfNzvYjpSsV6u BJ3I1cyvZwcAasi+7m3XpMn6EVEAhWei+rjdVEt7D7jOqVN/C+f9oryDK2tvLeQOAJP4 Jev7NblOm8zth96YGqIX60012NIxgEZAetNlmpBeT4JUyfAZXkOHmFBvhP5tdcG4p10t jYWisaXtcywmGo9evQ8CA5om1auvAqFqm23dLuMNGlcQE9E4ceZ21V0Wt3ruOegxNPkO ODZg==
X-Received: by 10.180.77.10 with SMTP id o10mr38062671wiw.10.1366829505006; Wed, 24 Apr 2013 11:51:45 -0700 (PDT)
Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id dj7sm4472289wib.6.2013.04.24.11.51.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 11:51:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Teco Boot 
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com>
Date: Wed, 24 Apr 2013 20:51:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com>
To: Stan Ratliff (sratliff) 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQnNKnBPZHRtmXRhRbJZIFrD90xJn/gzTFleha0oJs7w86Fe3MpkLH4d2OmLTCh1SBfQP6oE
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 18:51:51 -0000

Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende =
geschreven:

> What if we simply state that latency and bandwidth MUST reflect the =
full RF path? And that, where appropriate, latency MUST include delay =
introduced at any intermediate nodes?=20

Why can there be any metric on parts on what is needed?

Teco



From sratliff@cisco.com  Wed Apr 24 20:49:20 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3323C21F851E for ; Wed, 24 Apr 2013 20:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoaXM9vLLlno for ; Wed, 24 Apr 2013 20:49:19 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE521F8484 for ; Wed, 24 Apr 2013 20:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=862; q=dns/txt; s=iport; t=1366861759; x=1368071359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZGl5H3ug40Hmff7hIy7aigKch6ujfLz/92UtI1Br024=; b=ibKYhA+Hw2CjMFCt/UJ8oswONHKe7P0aidmSkGVV7R3dtfkVlD5Sxg4p RFK41e7oaXl0aBw+weOUHng9cynAL3E9bOlh7iGhuz+cJz0Klvy5eq55q XbsZFU4eunwiIqGI5xJDqzkAHKKG+hDU+DS9KLSuTsjZ1N0TWM5Pk8ERG A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJeneFGtJV2Z/2dsb2JhbABRgwa+YoECFnSCHwEBAQMBeRACAQgiJDIlAgQODYgGBr5mjW6BDwIxB4JrYQOIWJ9kgw6BczU
X-IronPort-AV: E=Sophos;i="4.87,547,1363132800"; d="scan'208";a="202762254"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 25 Apr 2013 03:48:55 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3P3mtU6004482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 03:48:55 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 22:48:54 -0500
From: "Stan Ratliff (sratliff)" 
To: Teco Boot 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CuziAeW0oH0a4VE5B/25X2JjlPyywgACM+4CAABJtAIAAEwoAgAAaHQCAAJYWgA==
Date: Thu, 25 Apr 2013 03:48:54 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C5C0E@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl>
In-Reply-To: <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.179.212]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3F89FE438BF4D9408BF3B5F8E1302B2B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 03:49:20 -0000

On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:

>=20
> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende gesc=
hreven:
>=20
>> What if we simply state that latency and bandwidth MUST reflect the full=
 RF path? And that, where appropriate, latency MUST include delay introduce=
d at any intermediate nodes?=20
>=20
> Why can there be any metric on parts on what is needed?

There shouldn't be. But earlier in this thread, there was an example of a r=
adio vendor that was apparently reporting first-hop bandwidth instead of fu=
ll-path bandwidth. At least that's what I gathered from the email. I'm conc=
erned about the notion that the router needs to (has to?) know if the physi=
cal RF is multihop - frankly, I don't think that kind of visibility should =
be necessary.=20

Regards,
Stan


>=20
> Teco
>=20
>=20


From rick.taylor@cassidian.com  Thu Apr 25 02:18:25 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7621F9452 for ; Thu, 25 Apr 2013 02:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SHOP=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hE+ojsmQFqV for ; Thu, 25 Apr 2013 02:18:24 -0700 (PDT)
Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2821F8FF2 for ; Thu, 25 Apr 2013 02:18:22 -0700 (PDT)
Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 25 Apr 2013 11:18:14 +0200
Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Thu, 25 Apr 2013 11:18:05 +0200
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 11:18:04 +0200
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 11:18:04 +0200
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 10:18:03 +0100
From: "Taylor, Rick" 
To: "Stan Ratliff (sratliff)" , Teco Boot 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3C2QiFp03LlkCfeEVaxZbdLZjlPyywgACM+4CAABJtAIAAEwoAgAAaHQCAAJYWgP///s3Q
Date: Thu, 25 Apr 2013 09:18:03 +0000
Message-ID: 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <0bddc650-ff03-4135-9f28-a71cbaee4f11@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <0bddc650-ff03-4135-9f28-a71cbaee4f11@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.23.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Apr 2013 09:18:04.0540 (UTC) FILETIME=[CA9AD3C0:01CE4195]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19822.005
X-TM-AS-Result: No--32.276900-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 09:18:25 -0000

I'll reply to several points in one go... Sorry for the top post.

@Martin:
I agree that there is enough bandwidth between local radio and router to su=
pport extra messages concerning layer-2 topology.  My concern was with the =
amount of extra specification required in DLEP, and the extra load placed o=
n radio manufacturer's implementations.  IMHO, a simple protocol has a much=
 better chance of achieving widespread uptake by industry than a more compl=
ex one.

I imagined a router using the Boolean mesh flag as an indicator that someth=
ing multi-hop is happening at layer-2 and that it *might* want to rethink i=
ts layer-3 strategy, rather than *strictly prevent* the router from doing w=
hat it wants.

I can't think of an example of a meshed radio system where some neighbours =
are 'meshed' and some are not.  If one alters the meaning of the Boolean fl=
ag from 'Radio net is meshed' to 'Neighbour is one-hop away' then, yes, it =
must be per-neighbour, but I believe this is a different approach to the pr=
oblem.

@Stan:
I completely agree in principle.  If modems report all link metrics correct=
ly (i.e. taking account of layer-2 topology) then there isn't a problem.  B=
ut there are already radios in the wild that get it wrong, and the response=
s to my requests to correct the issue have been 'That's really hard to do w=
ith the limited resources on our devices'.

@All:
I'm just trying to discover the consensus of the group on whether a pragmat=
ic compromise/work-around is acceptable, or if people feel the protocol sho=
uld insist on 'correct' behaviour from radios.

Perhaps a third way might be changing the semantics of the Boolean 'mesh' f=
lag to mean 'The multi-hop metrics are estimates' and include Martin's hop-=
count TLV so a router can determine if specific link metrics are accurate o=
r estimated.

Rick Taylor

> -----Original Message-----
> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
> Sent: 25 April 2013 04:49
> To: Teco Boot
> Cc: Duke, Martin; Taylor, Rick; henning.rogge@fkie.fraunhofer.de;
> manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>
>
> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
>
> >
> > Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende
> geschreven:
> >
> >> What if we simply state that latency and bandwidth MUST reflect the
> full RF path? And that, where appropriate, latency MUST include delay
> introduced at any intermediate nodes?
> >
> > Why can there be any metric on parts on what is needed?
>
> There shouldn't be. But earlier in this thread, there was an example of a
> radio vendor that was apparently reporting first-hop bandwidth instead of
> full-path bandwidth. At least that's what I gathered from the email. I'm
> concerned about the notion that the router needs to (has to?) know if the
> physical RF is multihop - frankly, I don't think that kind of visibility
> should be necessary.
>
> Regards,
> Stan
>
>
> >
> > Teco
> >
> >

The information contained within this e-mail and any files attached to this=
 e-mail is private and in addition may include commercially sensitive infor=
mation. The contents of this e-mail are for the intended recipient only and=
 therefore if you wish to disclose the information contained within this e-=
mail or attached files, please contact the sender prior to any such disclos=
ure. If you are not the intended recipient, any disclosure, copying or dist=
ribution is prohibited. Please also contact the sender and inform them of t=
he error and delete the e-mail, including any attached files from your syst=
em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, =
Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

From Chris.Dearlove@baesystems.com  Thu Apr 25 02:26:47 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00B821F91B7 for ; Thu, 25 Apr 2013 02:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwwtzSTY9jJi for ; Thu, 25 Apr 2013 02:26:46 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A0B9321F8A80 for ; Thu, 25 Apr 2013 02:26:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,548,1363132800"; d="scan'208";a="332101702"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 25 Apr 2013 10:26:44 +0100
Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3P9QilO002364 for ; Thu, 25 Apr 2013 10:26:44 +0100
X-IronPort-AV: E=Sophos;i="4.87,548,1363132800"; d="scan'208";a="14425759"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 25 Apr 2013 10:26:44 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 10:26:44 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi Yi 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgA==
Date: Thu, 25 Apr 2013 09:26:44 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>   
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 09:26:47 -0000

I think you missed something. Though there is a point we might have to cons=
ider that I'll get to.

These are constraints on your internal parameters. Let me just consider the=
 HELLO ones, obviously the TC ones are similar.

The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to be=
 older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only m=
akes sense for a positive age, hence the first constraint. That doesn't mat=
ter about synchronisation. It's actually a fairly obvious thing that almost=
 doesn't need saying (but also see a bit later).

Now sticking for the moment to an assumption that we can measure the age of=
 a packet/message, we want to bound how much slack we should allow. And tha=
t's the second constraint. (Right this moment I'm not sure why we picked RE=
FRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either way=
.) But this is where synchronisation comes in (and why the_DIFF suffix). We=
 measure the age by comparing our clock with the timestamp. If synchronised=
 then that's the age, done.

If there's a synchronisation error, let's suppose we received at t2, it cla=
ims to be sent at t1, but (based on our clock) was actually sent at t1+e. S=
o our test is

(t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF

but the age of the message, A is t2 - t1 - e, so

A <=3D MAX_HELLO_TIMESTAMP_DIFF - e

So if we want to only reject messages that are definitely too late, we need=
 to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume e i=
s symmetrically distributed +ve and -ve. In turn this means that we should =
allow an extra margin of e on the constraint MAX_HELLO_TIMESTAMP_DIFF < REF=
RESH_INTERVAL.

Now the point of interest. What if we receive a message with an apparent ne=
gative age? If that's greater than the minimum value of e (or -e) that's fi=
ne. But more than that? Should we reject such messages?

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
Sent: 24 April 2013 17:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Thanks Chris for sharing your thought.=20

Yes, those are all possibilities to consider. And a more fundamental issue =
I'm thinking about is the framework for securing re-active protocols, becau=
se it's much harder than pro-acitve ones. For example, do we want to requir=
e hop-by-hop authentication? Zeroing the metric field opens possible attack=
 vector also... anyway, we can discuss this in other topics in the future.=
=20

In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec-02, =
and I think it is fairly clear. I would support it for WGLC.=20

Just one question:

In the draft:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 The following constraints apply to these parameters:

   o  MAX_HELLO_TIMESTAMP_DIFF > 0

   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

   o  MAX_TC_TIMESTAMP_DIFF > 0

   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

   The second and fourth of those constraints assume ideal time
   synchronization of the clocks in all routers in the network.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My understanding is that, "the time difference equals 0" is for ideal time =
synchronization. So it should be The first and third assume ideal time sync=
hronization? Or I missed something here?=20

best

Jiazi

On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)"  wrote:

> Thanks for that. I'm hoping we can proceed push out 6622bis, and the secu=
rity document.
>=20
> As a contribution to that future concept, I'll note that 6622(bis) is ind=
ependent of the protocol. That I think is a desirable thing.
>=20
> One idea (I'm not sold on it, it's just for consideration) is that if you=
 are considering that, for example, you don't want to include a metric in y=
our ICV, and that metric is in TLV type X (probably a full type with type e=
xtension, but that's another of those details) then as a new variant type e=
xtension ICV, you could add something to say "remove all TLVs with type ext=
ensions X, Y, Z before calculating ICV). Or maybe that needs to be a range.=
 Or ... but first work out exactly what you want, then how it cleanly gener=
alises (where a good generalisation is easier to implement than the special=
 case).
>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre=
, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
>=20
> -----Original Message-----
> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
> Sent: 24 April 2013 17:12
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Hi,=20
>=20
> After several mail exchange with some of the other authors, I think it wo=
uld be better to keep the draft as it is on the mutable fields, because how=
 to define/use protocol-specific mutable fields is not very clear at this p=
oint.=20
> If necessary, it would probably be better to put them in another document=
, after we figuring out exactly how to handle those fields.=20
>=20
> best
>=20
> Jiazi
>=20
> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
>=20
>> Chris,=20
>>=20
>> I do understand your concern. We had this kind of discussion on mutable =
fields before, and this is something I'm still mulling over.=20
>> The reason why I propose this for discussion is:
>>=20
>> 	- this rfc6622bis is for rfc5444, which is a general format for all man=
et protocols.=20
>> 	- The reactive protocol like LOADng does explicitly define such "mutabl=
e" fields. It is something at hand, not in the far future.=20
>>=20
>> In the meantime, I do agree that the necessity and how to take care of s=
uch mutable fields should be considered carefully.=20
>> So I would agree that we keep the current rfc6622bis draft as it is for =
the moment, and I'll have more discussions with other LOADng authors on thi=
s.=20
>>=20
>> best=20
>>=20
>> Jiazi
>>=20
>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)"  wrote:
>>=20
>>> Jiazi
>>>=20
>>> Thanks for that, I'll just comment on the one point where I disagree.
>>>=20
>>> Putting some vague words in that protocols may indicate fields not to b=
e covered is the sort of thing that I can predict will cause us problems at=
 the IESG. And it's not really a good plan for a generic mechanism that can=
 - at at present - be run independently of the routing protocol to acquire =
a protocol dependence. Rather I think that any routing protocols with a spe=
cific need to exclude data (which, all else being equal is a bad thing of c=
ourse) should consider defining a new type extension - preferably one defin=
ed with some generic capability (could it, for example, list TLV types to b=
e excluded?) But that's for the future. One thing I have learned is that de=
sign in advance of what might hypothetically be needed generally gets it wr=
ong, so it would be good to wait until exactly what's needed is clear, and =
then define a new case.
>>>=20
>>> Christopher
>>>=20
>>> --=20
>>> Christopher Dearlove
>>> Senior Principal Engineer, Communications Group
>>> Communications, Networks and Image Analysis Capability
>>> BAE Systems Advanced Technology Centre
>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>>=20
>>> BAE Systems (Operations) Limited
>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent=
re, Farnborough, Hants, GU14 6YU, UK
>>> Registered in England & Wales No: 1996687
>>>=20
>>> -----Original Message-----
>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf =
Of ietf@jiaziyi.com
>>> Sent: 23 April 2013 15:37
>>> To: manet@ietf.org
>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>>=20
>>> ----------------------! WARNING ! ----------------------
>>> This message originates from outside our organisation,
>>> either from an external partner or from the internet.
>>> Keep this in mind if you answer this message.
>>> Follow the 'Report Suspicious Emails' link on IT matters
>>> for instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>=20
>>> (sorry if you receive duplicate of this message. Some of my mails to=20
>>> the mailing list are rejected, and I'm trying to figure out with our=20
>>> secretary...)
>>>=20
>>> Hi,
>>>=20
>>> I had a review of the draft. I think it's in good shape, and ready for=
=20
>>> WGLC.
>>>=20
>>> a few comments:
>>>=20
>>> In section 6 & 7, I didn't find the definition of notation
>>> 	+
>>> Not in this draft, either rfc 5444.
>>>=20
>>> page 13,  source code address =3D=3D> source node address?
>>>=20
>>> section 9.1 bullet 1 states that the  and=20
>>>  must be zeroed before calculating ICV. I'm thinking=20
>>> about that we might need to mention that some protocol-specific mutable=
=20
>>> fields must be zeroed here also. For example, in LOADng, as a reactive=
=20
>>> protocol, metric fields are defined as "mutable" (in the meantime, I=20
>>> still have some thoughts on those mutable fields that I need to discuss=
=20
>>> with other LOADng authors, but it's not that relevant here).
>>>=20
>>> best
>>>=20
>>> Jiazi
>>>=20
>>>=20
>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts=20
>>> directories.
>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group=20
>>> of the IETF.
>>>=20
>>> 	Title           : Integrity Check Value and Timestamp TLV Definitions=
=20
>>> for Mobile Ad Hoc Networks (MANETs)
>>> 	Author(s)       : Ulrich Herberg
>>>                       Thomas Heide Clausen
>>>                       Christopher Dearlove
>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>> 	Pages           : 24
>>> 	Date            : 2013-04-15
>>>=20
>>> Abstract:
>>> This document revises, extends and replaces RFC 6622.  It describes
>>> general and flexible TLVs for representing cryptographic Integrity
>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>>> for affixing ICVs and timestamps to a packet, a message, and one or
>>> more addresses, respectively.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>=20
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>>=20
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the intended
>>> recipient please delete it from your system and notify the sender.
>>> You should not copy it or use it for any purpose nor disclose or
>>> distribute its contents to any other person.
>>> ********************************************************************
>>>=20
>>=20
>=20
>=20



From john.dowdell@cassidian.com  Thu Apr 25 05:29:23 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0135B21F881C for ; Thu, 25 Apr 2013 05:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LvvfZg9ERkh for ; Thu, 25 Apr 2013 05:29:22 -0700 (PDT)
Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB121F86DE for ; Thu, 25 Apr 2013 05:29:19 -0700 (PDT)
Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 25 Apr 2013 14:29:09 +0200
Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Thu, 25 Apr 2013 14:29:09 +0200
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 14:29:09 +0200
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 14:29:08 +0200
Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 13:29:07 +0100
From: "Dowdell, John" 
To: "Stan Ratliff (sratliff)" , Teco Boot 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CxcOWz8znJkmNVgXqXAsrg5jlPyywgACM+4CAABJtAIAAEwoAgAAaHQCAAJYWgIAANXXQ
Date: Thu, 25 Apr 2013 12:29:06 +0000
Message-ID: <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.23.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Apr 2013 12:29:08.0607 (UTC) FILETIME=[7BB8A0F0:01CE41B0]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19822.007
X-TM-AS-Result: No--14.701500-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 12:29:23 -0000

Stan, Teco

The multihop/mesh problem has a few facets, if for the purposes of this dis=
cussion we define a mesh radio being one that is capable of doing its own l=
ayer 2 forwarding. Yes I know there is more to it than that, but I think th=
is is what is important here.

Consider that you wish to take a journey across town on the bus. Two busses=
 are available for you to use to your destination, Bus A and Bus B. Bus A i=
s the express bus, and stops at a small number of points along the way. Bus=
 B is the slow bus and stops at many points along the way. Unusually, this =
bus company is allowed to throw you off the bus before your destination if =
VIPs want to get on at some intermediate stop and there are not enough seat=
s, and standing is not allowed.

In making your choice of which bus to catch, you are not interested that ei=
ther bus stops at any place before your destination. You are however intere=
sted in how long each bus takes to get to your destination (latency), and y=
ou are also interested in whether you will be able to get a seat on the bus=
 for the whole of the journey (congestion).

I would suggest therefore that a router would be interested to learn that a=
 path to a destination is via a mesh radio, if only because it then knows t=
hat it will face competition for the bandwidth that the modem reports is av=
ailable. How the congestion is managed is not DLEP's job.

BUT to re-iterate a point that Rick made earlier, the bus company needs to =
truthfully report the number of seats available on each bus for you to make=
 able to make an informed decision. Knowing that VIPs are likely to get on =
is an advantage, but I'm not sure that it is strictly necessary.

Bon Voyage

John

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S=
tan Ratliff (sratliff)
Sent: 25 April 2013 04:49
To: Teco Boot
Cc: manet@ietf.org
Subject: Re: [manet] DLEP link metric discussion


On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:

>
> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende gesc=
hreven:
>
>> What if we simply state that latency and bandwidth MUST reflect the full=
 RF path? And that, where appropriate, latency MUST include delay introduce=
d at any intermediate nodes?
>
> Why can there be any metric on parts on what is needed?

There shouldn't be. But earlier in this thread, there was an example of a r=
adio vendor that was apparently reporting first-hop bandwidth instead of fu=
ll-path bandwidth. At least that's what I gathered from the email. I'm conc=
erned about the notion that the router needs to (has to?) know if the physi=
cal RF is multihop - frankly, I don't think that kind of visibility should =
be necessary.

Regards,
Stan


>
> Teco
>
>

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
The information contained within this e-mail and any files attached to this=
 e-mail is private and in addition may include commercially sensitive infor=
mation. The contents of this e-mail are for the intended recipient only and=
 therefore if you wish to disclose the information contained within this e-=
mail or attached files, please contact the sender prior to any such disclos=
ure. If you are not the intended recipient, any disclosure, copying or dist=
ribution is prohibited. Please also contact the sender and inform them of t=
he error and delete the e-mail, including any attached files from your syst=
em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, =
Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

From teco@inf-net.nl  Thu Apr 25 08:12:05 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5022621F8E96 for ; Thu, 25 Apr 2013 08:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHag0A+xDdxH for ; Thu, 25 Apr 2013 08:12:04 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D32BB21F8FF2 for ; Thu, 25 Apr 2013 08:12:03 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id l13so3527653wie.6 for ; Thu, 25 Apr 2013 08:12:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=oVTLkFsZrwUg/4iCfR2Yj4+aj7vUx5/xK20bVdV8Z2Q=; b=Gm3vM2azcft72mmLHVk+XIykTJI1dCTlU3Glja6jYQ1DJC/z3hrFCdWEnEJXnOTQj7 5M7eyKF+osyQVR52Rhi6I6o/6OgodxoW8V5BSqVb42M2dSVZUQAx7l+6+CHbIhSWZxKq W7+gP3mBsUtjZoHjXqa10OgZBNysYo+70BHC8ueJlCTDt5vy0+GRcDTYNX/XIS6bafTZ nI1SwNyfVjNOIHx5Er6cMncKHqFr6u0obby4Oa08eDHbxhUyZ1X/Vozz/ymMnwYBGFG1 hLfb4mrqSfRaKe9IAtc10gYr0GrtwcjDmcDXUIOoBBU0feXqc2dZZqceaNY6K4x+bmnK LsWA==
X-Received: by 10.180.108.176 with SMTP id hl16mr4213635wib.25.1366902722510;  Thu, 25 Apr 2013 08:12:02 -0700 (PDT)
Received: from [172.20.10.3] ([84.241.221.161]) by mx.google.com with ESMTPSA id q18sm39131748wiw.8.2013.04.25.08.11.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 08:12:01 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Teco Boot 
In-Reply-To: <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Date: Thu, 25 Apr 2013 17:11:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <234FE232-7842-4EAC-8E20-5DE2C9D8EF59@inf-net.nl>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP> <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP>
To: "Dowdell, John" 
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQlYPOB0hwAXTElIeGW6mxTUDgwuGzA+Y2x9k8XeL+76HAKUHrb2xonCbKTwNuKl5MwN4V/g
Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 15:12:05 -0000

Hi John,

Your example brings up some new elements: need for a congestion TLV (in =
scope for DLEP?) and multi topology / traffic engineering (not in scope =
for DLEP, this is handled at IP routing). On congestion: would this be a =
per DSCP metric?

On your definition for the mesh radio: can I assume the provided IP link =
is full connected and IP broadcast/multicast capable? If so, we don't =
need to rebroadcast for flooding or forward over same interface. This is =
important information for the routers and I support the request for a =
TLV for it. Doesn't need to be in the core spec, routers can use such =
links to run their MANET protocol, although it is not that efficient as =
it could be.

The discussion on "is provided metric for first L2 hop of a multi-hop L2 =
path" is a different subject. I think this is a real world problem, as =
hub&spoke type of L2 topologies are widely used and spokes are typically =
unaware of far end RF links. Multi-hop L2 mesh topologies are also in =
place. I think DLEP should be capable to transfer any info for the L2 =
path to the locally connected router. Could be hopcount, total airtime, =
1st L2 hop link metrics, to name a few I am aware of.

Teco


Op 25 apr. 2013, om 14:29 heeft "Dowdell, John" =
 het volgende geschreven:

> Stan, Teco
>=20
> The multihop/mesh problem has a few facets, if for the purposes of =
this discussion we define a mesh radio being one that is capable of =
doing its own layer 2 forwarding. Yes I know there is more to it than =
that, but I think this is what is important here.
>=20
> Consider that you wish to take a journey across town on the bus. Two =
busses are available for you to use to your destination, Bus A and Bus =
B. Bus A is the express bus, and stops at a small number of points along =
the way. Bus B is the slow bus and stops at many points along the way. =
Unusually, this bus company is allowed to throw you off the bus before =
your destination if VIPs want to get on at some intermediate stop and =
there are not enough seats, and standing is not allowed.
>=20
> In making your choice of which bus to catch, you are not interested =
that either bus stops at any place before your destination. You are =
however interested in how long each bus takes to get to your destination =
(latency), and you are also interested in whether you will be able to =
get a seat on the bus for the whole of the journey (congestion).
>=20
> I would suggest therefore that a router would be interested to learn =
that a path to a destination is via a mesh radio, if only because it =
then knows that it will face competition for the bandwidth that the =
modem reports is available. How the congestion is managed is not DLEP's =
job.
>=20
> BUT to re-iterate a point that Rick made earlier, the bus company =
needs to truthfully report the number of seats available on each bus for =
you to make able to make an informed decision. Knowing that VIPs are =
likely to get on is an advantage, but I'm not sure that it is strictly =
necessary.
>=20
> Bon Voyage
>=20
> John
>=20
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf =
Of Stan Ratliff (sratliff)
> Sent: 25 April 2013 04:49
> To: Teco Boot
> Cc: manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>=20
>=20
> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
>=20
>>=20
>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende =
geschreven:
>>=20
>>> What if we simply state that latency and bandwidth MUST reflect the =
full RF path? And that, where appropriate, latency MUST include delay =
introduced at any intermediate nodes?
>>=20
>> Why can there be any metric on parts on what is needed?
>=20
> There shouldn't be. But earlier in this thread, there was an example =
of a radio vendor that was apparently reporting first-hop bandwidth =
instead of full-path bandwidth. At least that's what I gathered from the =
email. I'm concerned about the notion that the router needs to (has to?) =
know if the physical RF is multihop - frankly, I don't think that kind =
of visibility should be necessary.
>=20
> Regards,
> Stan
>=20
>=20
>>=20
>> Teco
>>=20
>>=20
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> The information contained within this e-mail and any files attached to =
this e-mail is private and in addition may include commercially =
sensitive information. The contents of this e-mail are for the intended =
recipient only and therefore if you wish to disclose the information =
contained within this e-mail or attached files, please contact the =
sender prior to any such disclosure. If you are not the intended =
recipient, any disclosure, copying or distribution is prohibited. Please =
also contact the sender and inform them of the error and delete the =
e-mail, including any attached files from your system. Cassidian =
Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, =
Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com


From A.Hardy@2009.ljmu.ac.uk  Thu Apr 25 08:29:39 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AE421F86D9 for ; Thu, 25 Apr 2013 08:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTuOeTHvWfdc for ; Thu, 25 Apr 2013 08:29:32 -0700 (PDT)
Received: from EXHUBCAS2.jmu.ac.uk (exhubcas2.jmu.ac.uk [150.204.215.11]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF221F8265 for ; Thu, 25 Apr 2013 08:29:19 -0700 (PDT)
Received: from EXHUBCAS0.jmu.ac.uk (150.204.55.21) by EXHUBCAS2.jmu.ac.uk (150.204.215.11) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 16:29:10 +0100
Received: from [192.168.1.66] (87.194.103.86) by smtp.ljmu.ac.uk (150.204.55.28) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 16:29:09 +0100
Message-ID: <51794BBE.5020606@2009.ljmu.ac.uk>
Date: Thu, 25 Apr 2013 16:29:02 +0100
From: Andrew Hardy 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "manet@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [87.194.103.86]
Subject: [manet] AODV RFC "local repair" Interpretation
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 15:29:39 -0000

My impression from reading the AODV RFC is that "local repair", if
configured, is intended to be initiated
just for failing to send a data packet.

I would very much like to know if others feel there is a common view on
the interpretation/intention?

Andrew




In more detail:

Some have suggested the RFC is not 100% clear on this, and could be
interpreted either way, but that the sentence "that 'data' packets
should be buffered", seems to indicate the Local Repair only applies for
data packets.

Some think this makes sense, since the case where a RREP packet is lost
is handled by the source node initiating a new route discovery, after
the given timeout. Other statements in the RFC, e.g. regarding
precursor, also make more sense when applied to the "data packets only"
application of Local Repair.





________________________________
Important Notice: the information in this email and any attachments is for =
the sole use of the intended recipient(s). If you are not an intended recip=
ient, or a person responsible for delivering it to an intended recipient, y=
ou should delete it from your system immediately without disclosing its con=
tents elsewhere and advise the sender by returning the email or by telephon=
ing a number contained in the body of the email. No responsibility is accep=
ted for loss or damage arising from viruses or changes made to this message=
 after it was sent. The views contained in this email are those of the auth=
or and not necessarily those of Liverpool John Moores University.

From john.dowdell@cassidian.com  Thu Apr 25 08:36:47 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969C921F941D for ; Thu, 25 Apr 2013 08:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG2-e89kJ9bi for ; Thu, 25 Apr 2013 08:36:46 -0700 (PDT)
Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 176A921F8BDD for ; Thu, 25 Apr 2013 08:36:45 -0700 (PDT)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 25 Apr 2013 17:36:43 +0200
Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381);  Thu, 25 Apr 2013 17:36:44 +0200
Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 17:36:44 +0200
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 25 Apr 2013 17:36:43 +0200
Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 16:36:43 +0100
From: "Dowdell, John" 
To: Teco Boot 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CxcOWz8znJkmNVgXqXAsrg5jlPyywgACM+4CAABJtAIAAEwoAgAAaHQCAAJYWgIAAbIZggAACsPA=
Date: Thu, 25 Apr 2013 15:36:42 +0000
Message-ID: <603F5FD847B5174CBDA37A9DC00532FB09FEA76F@SUCNPTEXM02.com.ad.uk.ds.corp>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP> <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP> <5a8fce6a-5ae4-4944-9fed-53c6e34589c4@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <5a8fce6a-5ae4-4944-9fed-53c6e34589c4@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.23.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Apr 2013 15:36:43.0888 (UTC) FILETIME=[B0643700:01CE41CA]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19824.000
X-TM-AS-Result: No--23.863500-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 15:36:47 -0000

Hi Teco

I believe the mesh radios would directly connect to all similar radios with=
in range, and will mesh to other radios through ones that are in range. The=
 meshing protocol is likely to take care of all forwarding, rebroadcast and=
 multicast forwarding actions (though I'm not completely sure about multica=
st forwarding). I believe (though not completely sure)some mesh radios we a=
re testing with work out the bandwidth to a destination by looking at each =
hop in turn and presenting the aggregate result to the source router.

I would agree that point to point or hub and spoke radio system would not c=
are about bandwidth on other links, though the management system might coll=
ect this information.

Regards

John

-----Original Message-----
From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 25 April 2013 16:12
To: Dowdell, John
Cc: Stan Ratliff (sratliff); manet@ietf.org
Subject: Re: [manet] DLEP link metric discussion

Hi John,

Your example brings up some new elements: need for a congestion TLV (in sco=
pe for DLEP?) and multi topology / traffic engineering (not in scope for DL=
EP, this is handled at IP routing). On congestion: would this be a per DSCP=
 metric?

On your definition for the mesh radio: can I assume the provided IP link is=
 full connected and IP broadcast/multicast capable? If so, we don't need to=
 rebroadcast for flooding or forward over same interface. This is important=
 information for the routers and I support the request for a TLV for it. Do=
esn't need to be in the core spec, routers can use such links to run their =
MANET protocol, although it is not that efficient as it could be.

The discussion on "is provided metric for first L2 hop of a multi-hop L2 pa=
th" is a different subject. I think this is a real world problem, as hub&sp=
oke type of L2 topologies are widely used and spokes are typically unaware =
of far end RF links. Multi-hop L2 mesh topologies are also in place. I thin=
k DLEP should be capable to transfer any info for the L2 path to the locall=
y connected router. Could be hopcount, total airtime, 1st L2 hop link metri=
cs, to name a few I am aware of.

Teco


Op 25 apr. 2013, om 14:29 heeft "Dowdell, John"  het volgende geschreven:

> Stan, Teco
>
> The multihop/mesh problem has a few facets, if for the purposes of this d=
iscussion we define a mesh radio being one that is capable of doing its own=
 layer 2 forwarding. Yes I know there is more to it than that, but I think =
this is what is important here.
>
> Consider that you wish to take a journey across town on the bus. Two buss=
es are available for you to use to your destination, Bus A and Bus B. Bus A=
 is the express bus, and stops at a small number of points along the way. B=
us B is the slow bus and stops at many points along the way. Unusually, thi=
s bus company is allowed to throw you off the bus before your destination i=
f VIPs want to get on at some intermediate stop and there are not enough se=
ats, and standing is not allowed.
>
> In making your choice of which bus to catch, you are not interested that =
either bus stops at any place before your destination. You are however inte=
rested in how long each bus takes to get to your destination (latency), and=
 you are also interested in whether you will be able to get a seat on the b=
us for the whole of the journey (congestion).
>
> I would suggest therefore that a router would be interested to learn that=
 a path to a destination is via a mesh radio, if only because it then knows=
 that it will face competition for the bandwidth that the modem reports is =
available. How the congestion is managed is not DLEP's job.
>
> BUT to re-iterate a point that Rick made earlier, the bus company needs t=
o truthfully report the number of seats available on each bus for you to ma=
ke able to make an informed decision. Knowing that VIPs are likely to get o=
n is an advantage, but I'm not sure that it is strictly necessary.
>
> Bon Voyage
>
> John
>
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of=
 Stan Ratliff (sratliff)
> Sent: 25 April 2013 04:49
> To: Teco Boot
> Cc: manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>
>
> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
>
>>
>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende ges=
chreven:
>>
>>> What if we simply state that latency and bandwidth MUST reflect the ful=
l RF path? And that, where appropriate, latency MUST include delay introduc=
ed at any intermediate nodes?
>>
>> Why can there be any metric on parts on what is needed?
>
> There shouldn't be. But earlier in this thread, there was an example of a=
 radio vendor that was apparently reporting first-hop bandwidth instead of =
full-path bandwidth. At least that's what I gathered from the email. I'm co=
ncerned about the notion that the router needs to (has to?) know if the phy=
sical RF is multihop - frankly, I don't think that kind of visibility shoul=
d be necessary.
>
> Regards,
> Stan
>
>
>>
>> Teco
>>
>>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> The information contained within this e-mail and any files attached to th=
is e-mail is private and in addition may include commercially sensitive inf=
ormation. The contents of this e-mail are for the intended recipient only a=
nd therefore if you wish to disclose the information contained within this =
e-mail or attached files, please contact the sender prior to any such discl=
osure. If you are not the intended recipient, any disclosure, copying or di=
stribution is prohibited. Please also contact the sender and inform them of=
 the error and delete the e-mail, including any attached files from your sy=
stem. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs=
, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c=
om

The information contained within this e-mail and any files attached to this=
 e-mail is private and in addition may include commercially sensitive infor=
mation. The contents of this e-mail are for the intended recipient only and=
 therefore if you wish to disclose the information contained within this e-=
mail or attached files, please contact the sender prior to any such disclos=
ure. If you are not the intended recipient, any disclosure, copying or dist=
ribution is prohibited. Please also contact the sender and inform them of t=
he error and delete the e-mail, including any attached files from your syst=
em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, =
Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

From sratliff@cisco.com  Thu Apr 25 09:00:00 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F821F911E for ; Thu, 25 Apr 2013 08:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level: 
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MWcy+H6+YsI for ; Thu, 25 Apr 2013 08:59:56 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3994821F873D for ; Thu, 25 Apr 2013 08:59:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7848; q=dns/txt; s=iport; t=1366905593; x=1368115193; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e2aZeFsTYvgaV+yCgKUV2EV5adQzfjTLIWwzXvEFhJ0=; b=S2L1vPRop3b7s69SNNZ+5DyKcOzdIr7GjrCxstk4gQtIhFKfwIgtq6yp NDtbAwn4u6F03pIJKHLTesMQS1YP81FDUlyBmr2b3CvnqQNzfl3GujFT9 Tl41Sutw5XuR3Y/JVJg7J1uNon4WH2qAEZQaqOYq/XDEZTlYwDjKGPEaA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALFReVGtJXG+/2dsb2JhbABRgwY2vi6BBBZ0gh8BAQEDAQEBAVIZCwUHBAIBCBEEAQEBCh0HJwsUCQgCBAoEBQiIBgYMvkaNcwoGfwIGKwcCBIJnYQOoPoMOgWoJFx4
X-IronPort-AV: E=Sophos;i="4.87,551,1363132800"; d="scan'208";a="200068296"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2013 15:59:52 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3PFxqFk015887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 15:59:52 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 10:59:51 -0500
From: "Stan Ratliff (sratliff)" 
To: "Dowdell, John" 
Thread-Topic: [manet] DLEP link metric discussion
Thread-Index: AQHOQM3CuziAeW0oH0a4VE5B/25X2JjlPyywgACM+4CAABJtAIAAEwoAgAAaHQCAAJYWgIAAbIZggAACsPCAAF0DgA==
Date: Thu, 25 Apr 2013 15:59:51 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C65EF@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP> <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP> <5a8fce6a-5ae4-4944-9fed-53c6e34589c4@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB09FEA76F@SUCNPTEXM02.com.ad.uk.ds.corp>
In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB09FEA76F@SUCNPTEXM02.com.ad.uk.ds.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.179.212]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <52F973A04F3BE844AF42581C65CBA5A6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 16:00:00 -0000

Guys,=20

This is just my opinion, but this is a *classic* case of the tail wagging t=
he dog. The whole discussion is predicated around a radio implementation th=
at is giving incorrect metrics to a router. IIRC, one of the quotes from th=
e radio vendor (I might be paraphrasing here) was "Yeah, but this is hard"=
=85. Really? And we're going to put a bunch of extra stuff into DLEP becaus=
e of that? Here's the right answer - fix the radio. If the radio reports "a=
ppropriate" metrics (predicated on its inherent understanding of the physic=
al topology), then the whole mess just goes away. The existing implementati=
on works.=20

Regards,
Stan

On Apr 25, 2013, at 11:36 AM, Dowdell, John wrote:

> Hi Teco
>=20
> I believe the mesh radios would directly connect to all similar radios wi=
thin range, and will mesh to other radios through ones that are in range. T=
he meshing protocol is likely to take care of all forwarding, rebroadcast a=
nd multicast forwarding actions (though I'm not completely sure about multi=
cast forwarding). I believe (though not completely sure)some mesh radios we=
 are testing with work out the bandwidth to a destination by looking at eac=
h hop in turn and presenting the aggregate result to the source router.
>=20
> I would agree that point to point or hub and spoke radio system would not=
 care about bandwidth on other links, though the management system might co=
llect this information.
>=20
> Regards
>=20
> John
>=20
> -----Original Message-----
> From: Teco Boot [mailto:teco@inf-net.nl]
> Sent: 25 April 2013 16:12
> To: Dowdell, John
> Cc: Stan Ratliff (sratliff); manet@ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>=20
> Hi John,
>=20
> Your example brings up some new elements: need for a congestion TLV (in s=
cope for DLEP?) and multi topology / traffic engineering (not in scope for =
DLEP, this is handled at IP routing). On congestion: would this be a per DS=
CP metric?
>=20
> On your definition for the mesh radio: can I assume the provided IP link =
is full connected and IP broadcast/multicast capable? If so, we don't need =
to rebroadcast for flooding or forward over same interface. This is importa=
nt information for the routers and I support the request for a TLV for it. =
Doesn't need to be in the core spec, routers can use such links to run thei=
r MANET protocol, although it is not that efficient as it could be.
>=20
> The discussion on "is provided metric for first L2 hop of a multi-hop L2 =
path" is a different subject. I think this is a real world problem, as hub&=
spoke type of L2 topologies are widely used and spokes are typically unawar=
e of far end RF links. Multi-hop L2 mesh topologies are also in place. I th=
ink DLEP should be capable to transfer any info for the L2 path to the loca=
lly connected router. Could be hopcount, total airtime, 1st L2 hop link met=
rics, to name a few I am aware of.
>=20
> Teco
>=20
>=20
> Op 25 apr. 2013, om 14:29 heeft "Dowdell, John"  het volgende geschreven:
>=20
>> Stan, Teco
>>=20
>> The multihop/mesh problem has a few facets, if for the purposes of this =
discussion we define a mesh radio being one that is capable of doing its ow=
n layer 2 forwarding. Yes I know there is more to it than that, but I think=
 this is what is important here.
>>=20
>> Consider that you wish to take a journey across town on the bus. Two bus=
ses are available for you to use to your destination, Bus A and Bus B. Bus =
A is the express bus, and stops at a small number of points along the way. =
Bus B is the slow bus and stops at many points along the way. Unusually, th=
is bus company is allowed to throw you off the bus before your destination =
if VIPs want to get on at some intermediate stop and there are not enough s=
eats, and standing is not allowed.
>>=20
>> In making your choice of which bus to catch, you are not interested that=
 either bus stops at any place before your destination. You are however int=
erested in how long each bus takes to get to your destination (latency), an=
d you are also interested in whether you will be able to get a seat on the =
bus for the whole of the journey (congestion).
>>=20
>> I would suggest therefore that a router would be interested to learn tha=
t a path to a destination is via a mesh radio, if only because it then know=
s that it will face competition for the bandwidth that the modem reports is=
 available. How the congestion is managed is not DLEP's job.
>>=20
>> BUT to re-iterate a point that Rick made earlier, the bus company needs =
to truthfully report the number of seats available on each bus for you to m=
ake able to make an informed decision. Knowing that VIPs are likely to get =
on is an advantage, but I'm not sure that it is strictly necessary.
>>=20
>> Bon Voyage
>>=20
>> John
>>=20
>> -----Original Message-----
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O=
f Stan Ratliff (sratliff)
>> Sent: 25 April 2013 04:49
>> To: Teco Boot
>> Cc: manet@ietf.org
>> Subject: Re: [manet] DLEP link metric discussion
>>=20
>>=20
>> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
>>=20
>>>=20
>>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende ge=
schreven:
>>>=20
>>>> What if we simply state that latency and bandwidth MUST reflect the fu=
ll RF path? And that, where appropriate, latency MUST include delay introdu=
ced at any intermediate nodes?
>>>=20
>>> Why can there be any metric on parts on what is needed?
>>=20
>> There shouldn't be. But earlier in this thread, there was an example of =
a radio vendor that was apparently reporting first-hop bandwidth instead of=
 full-path bandwidth. At least that's what I gathered from the email. I'm c=
oncerned about the notion that the router needs to (has to?) know if the ph=
ysical RF is multihop - frankly, I don't think that kind of visibility shou=
ld be necessary.
>>=20
>> Regards,
>> Stan
>>=20
>>=20
>>>=20
>>> Teco
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>> The information contained within this e-mail and any files attached to t=
his e-mail is private and in addition may include commercially sensitive in=
formation. The contents of this e-mail are for the intended recipient only =
and therefore if you wish to disclose the information contained within this=
 e-mail or attached files, please contact the sender prior to any such disc=
losure. If you are not the intended recipient, any disclosure, copying or d=
istribution is prohibited. Please also contact the sender and inform them o=
f the error and delete the e-mail, including any attached files from your s=
ystem. Cassidian Limited, Registered Office : Quadrant House, Celtic Spring=
s, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.=
com
>=20
> The information contained within this e-mail and any files attached to th=
is e-mail is private and in addition may include commercially sensitive inf=
ormation. The contents of this e-mail are for the intended recipient only a=
nd therefore if you wish to disclose the information contained within this =
e-mail or attached files, please contact the sender prior to any such discl=
osure. If you are not the intended recipient, any disclosure, copying or di=
stribution is prohibited. Please also contact the sender and inform them of=
 the error and delete the e-mail, including any attached files from your sy=
stem. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs=
, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c=
om


From abdussalambaryun@gmail.com  Thu Apr 25 12:45:12 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0A21F86CA for ; Thu, 25 Apr 2013 12:45:12 -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=[AWL=-0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPMyPsx+qq27 for ; Thu, 25 Apr 2013 12:45:10 -0700 (PDT)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6721F8518 for ; Thu, 25 Apr 2013 12:45:09 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id u10so2005649pdi.11 for ; Thu, 25 Apr 2013 12:45:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=E804ClXUgcpc4XIhx/m0k54hT8Ds4owWnh7BoUtGRzw=; b=EWK+sINK34lpsBLgy7p/e85q059Nyq9xIq+jvptya1qmcpyAyw9ixg3blIZj4/b+Mu t2UMfyemvWNHC+Qm0O5ATnq0guy6OVCITxGsSJnm6mdgAdSRU0T0jHqEH0c3nIRcZnxk yswPCRb4Xqitp4fFrom1GGr8SImMwogwMjYsKfKhzT9zE/DrSVgIOBQ6cSX3in6e5+L8 2natgkH4xjejed/qo8gmeC1mtTHyoyBB0GqAcsmfLd2sDprfpOgSXT7ItL1T754XFXCN geUsR9iyIFxfvf5M8Q5CrvXh6LJ1aEx3UygxfApc6CYrJYsc86/flGYOPQKnowN/5xj8 ghTA==
MIME-Version: 1.0
X-Received: by 10.66.160.162 with SMTP id xl2mr23776874pab.215.1366919109516;  Thu, 25 Apr 2013 12:45:09 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Thu, 25 Apr 2013 12:45:09 -0700 (PDT)
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C36A9@xmb-aln-x03.cisco.com>
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C36A9@xmb-aln-x03.cisco.com>
Date: Thu, 25 Apr 2013 21:45:09 +0200
Message-ID: 
From: Abdussalam Baryun 
To: "" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Stan Ratliff 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 19:45:12 -0000

Hi Stan,

> a general recommendation to "talk about it more" doesn't help me a lot.

I want to investigate or know opinions of how much AODVv2 can *use*
this document or add to it. My input means fast born documents into
WGLC does not help either. I would like to see input from AODVv2
*users* regarding this new document,

AB

On 4/23/13, Stan Ratliff (sratliff)  wrote:
> AB,
>
> On Apr 23, 2013, at 9:50 AM, Abdussalam Baryun wrote:
>
>> IMO, this document is not related only to OLSRv2 and it was not
>> presented in any WG meeting (obsoletes RFC6622), it is better to get
>> more discussions and feedback for its progress,
>
> Do you have a list of concerns, or specific areas of the document you fee=
l
> need additional discussion? To be completely honest, a general
> recommendation to "talk about it more" doesn't help me a lot.
>
> Regards,
> Stan
>
>
>>
>> AB
>>
>> On 4/22/13, Henning Rogge  wrote:
>>> Hi,
>>>
>>> thank you to the Authors for updating the document quickly.
>>>
>>> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
>>> again... so lets try to get rid of it.
>>>
>>> I think draft 02 is much more explicit about a lot of things and clears
>>> up the difference between the two ICV TLV extensions well.
>>>
>>> How do we push forward now?
>>>
>>> Henning Rogge
>>>
>>>
>>> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>  This draft is a work item of the Mobile Ad-hoc Networks Working Group
>>>> of
>>>> the IETF.
>>>>
>>>> 	Title           : Integrity Check Value and Timestamp TLV Definitions
>>>> for
>>>> Mobile Ad Hoc Networks (MANETs)
>>>> 	Author(s)       : Ulrich Herberg
>>>>                           Thomas Heide Clausen
>>>>                           Christopher Dearlove
>>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>>> 	Pages           : 24
>>>> 	Date            : 2013-04-15
>>>>
>>>> Abstract:
>>>>    This document revises, extends and replaces RFC 6622.  It describes
>>>>    general and flexible TLVs for representing cryptographic Integrity
>>>>    Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>>    Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>>    defines two Packet TLVs, two Message TLVs, and two Address Block
>>>> TLVs
>>>>    for affixing ICVs and timestamps to a packet, a message, and one or
>>>>    more addresses, respectively.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>
>>>
>>> --
>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>>> Kommunikationssysteme (KOM)
>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>>
>>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>

From bebemaster@gmail.com  Thu Apr 25 13:29:28 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0421F961B for ; Thu, 25 Apr 2013 13:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.201
X-Spam-Level: 
X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0nD9JspoFll for ; Thu, 25 Apr 2013 13:29:27 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 083E321F8F12 for ; Thu, 25 Apr 2013 13:29:25 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id x10so3117589lbi.22 for ; Thu, 25 Apr 2013 13:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=6za6aPgG/vQb0fz+xfJtI5MIIQxUV1hD4N2Z/PRXxkE=; b=tPcxR7a11FS6uR1HgRPrbzTX8KjGnn6lTOjzt+wXilH2A5FPaG3lnjeNwHYUNN0nfx U2FRA7uErOYGjzbloD7nulkObQTztpYxZ3KoNGI0Vdwd6R+bIKVab+8NhCLCp2sXSlsB 8j79s7XR8scha/PLo55WHP42mrr0Ukwyw4RkYzZESOjZSQu6sibtztkARv3ISTtO7y7k DJ63bsCeV1SWx8RtT6VVXi0Tm5Txll2vjKrpshhNR/eCN4npDY6vk/m0uf7fOHia8TZh orq3M6H9Ak3+VclTUvquy2CLZT4hW+YWMBsr+fEIBJCG6C1B69/8jL4MGnCYpPZjLLsj NrZA==
MIME-Version: 1.0
X-Received: by 10.112.5.196 with SMTP id u4mr14209897lbu.78.1366921764724; Thu, 25 Apr 2013 13:29:24 -0700 (PDT)
Received: by 10.152.125.134 with HTTP; Thu, 25 Apr 2013 13:29:24 -0700 (PDT)
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C65EF@xmb-aln-x03.cisco.com>
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <5095bc49-8a77-4847-aedc-0ca00f902d41@SUCNPTEXC01.COM.AD.UK.DS.CORP> <332b7c87-b17a-4b36-9ca1-ddcd4e16dec2@SUCNPTEXC01.COM.AD.UK.DS.CORP> <5a8fce6a-5ae4-4944-9fed-53c6e34589c4@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB09FEA76F@SUCNPTEXM02.com.ad.uk.ds.corp> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C65EF@xmb-aln-x03.cisco.com>
Date: Thu, 25 Apr 2013 16:29:24 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=14dae94ed81938e5a804db3546c2
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 20:29:29 -0000

--14dae94ed81938e5a804db3546c2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Stan I don't think this is only about radios not being able to report
accurate information.  (Although I do think we live in the real world and
many MANY radio vendors will just report the link rate without taking
multiple hop throughput into consideration.)

With a mesh network broadcasts/multicast messages can be much more
expensive than unicast messages.  A router with multiple radio interfaces,
one of which is connected to all known destinations due to it having layer
two routing, won't know the real cost of broadcasting on that interface.
Unless we build a TLV to handle that into dlep but that seems even more
complicated than just having an interface report that it is running some
mesh at layer 2.

At the very least, having a specification in which radio vendors report
that they are running a mesh, might make them think a little bit more about
the bigger picture; Having their radios integrated into a larger
heterogeneous network.


On Thu, Apr 25, 2013 at 11:59 AM, Stan Ratliff (sratliff) <
sratliff@cisco.com> wrote:

> Guys,
>
> This is just my opinion, but this is a *classic* case of the tail wagging
> the dog. The whole discussion is predicated around a radio implementation
> that is giving incorrect metrics to a router. IIRC, one of the quotes fro=
m
> the radio vendor (I might be paraphrasing here) was "Yeah, but this is
> hard"=85. Really? And we're going to put a bunch of extra stuff into DLEP
> because of that? Here's the right answer - fix the radio. If the radio
> reports "appropriate" metrics (predicated on its inherent understanding o=
f
> the physical topology), then the whole mess just goes away. The existing
> implementation works.
>
> Regards,
> Stan
>
> On Apr 25, 2013, at 11:36 AM, Dowdell, John wrote:
>
> > Hi Teco
> >
> > I believe the mesh radios would directly connect to all similar radios
> within range, and will mesh to other radios through ones that are in rang=
e.
> The meshing protocol is likely to take care of all forwarding, rebroadcas=
t
> and multicast forwarding actions (though I'm not completely sure about
> multicast forwarding). I believe (though not completely sure)some mesh
> radios we are testing with work out the bandwidth to a destination by
> looking at each hop in turn and presenting the aggregate result to the
> source router.
> >
> > I would agree that point to point or hub and spoke radio system would
> not care about bandwidth on other links, though the management system mig=
ht
> collect this information.
> >
> > Regards
> >
> > John
> >
> > -----Original Message-----
> > From: Teco Boot [mailto:teco@inf-net.nl]
> > Sent: 25 April 2013 16:12
> > To: Dowdell, John
> > Cc: Stan Ratliff (sratliff); manet@ietf.org
> > Subject: Re: [manet] DLEP link metric discussion
> >
> > Hi John,
> >
> > Your example brings up some new elements: need for a congestion TLV (in
> scope for DLEP?) and multi topology / traffic engineering (not in scope f=
or
> DLEP, this is handled at IP routing). On congestion: would this be a per
> DSCP metric?
> >
> > On your definition for the mesh radio: can I assume the provided IP lin=
k
> is full connected and IP broadcast/multicast capable? If so, we don't nee=
d
> to rebroadcast for flooding or forward over same interface. This is
> important information for the routers and I support the request for a TLV
> for it. Doesn't need to be in the core spec, routers can use such links t=
o
> run their MANET protocol, although it is not that efficient as it could b=
e.
> >
> > The discussion on "is provided metric for first L2 hop of a multi-hop L=
2
> path" is a different subject. I think this is a real world problem, as
> hub&spoke type of L2 topologies are widely used and spokes are typically
> unaware of far end RF links. Multi-hop L2 mesh topologies are also in
> place. I think DLEP should be capable to transfer any info for the L2 pat=
h
> to the locally connected router. Could be hopcount, total airtime, 1st L2
> hop link metrics, to name a few I am aware of.
> >
> > Teco
> >
> >
> > Op 25 apr. 2013, om 14:29 heeft "Dowdell, John"
>  het volgende geschreven:
> >
> >> Stan, Teco
> >>
> >> The multihop/mesh problem has a few facets, if for the purposes of thi=
s
> discussion we define a mesh radio being one that is capable of doing its
> own layer 2 forwarding. Yes I know there is more to it than that, but I
> think this is what is important here.
> >>
> >> Consider that you wish to take a journey across town on the bus. Two
> busses are available for you to use to your destination, Bus A and Bus B.
> Bus A is the express bus, and stops at a small number of points along the
> way. Bus B is the slow bus and stops at many points along the way.
> Unusually, this bus company is allowed to throw you off the bus before yo=
ur
> destination if VIPs want to get on at some intermediate stop and there ar=
e
> not enough seats, and standing is not allowed.
> >>
> >> In making your choice of which bus to catch, you are not interested
> that either bus stops at any place before your destination. You are howev=
er
> interested in how long each bus takes to get to your destination (latency=
),
> and you are also interested in whether you will be able to get a seat on
> the bus for the whole of the journey (congestion).
> >>
> >> I would suggest therefore that a router would be interested to learn
> that a path to a destination is via a mesh radio, if only because it then
> knows that it will face competition for the bandwidth that the modem
> reports is available. How the congestion is managed is not DLEP's job.
> >>
> >> BUT to re-iterate a point that Rick made earlier, the bus company need=
s
> to truthfully report the number of seats available on each bus for you to
> make able to make an informed decision. Knowing that VIPs are likely to g=
et
> on is an advantage, but I'm not sure that it is strictly necessary.
> >>
> >> Bon Voyage
> >>
> >> John
> >>
> >> -----Original Message-----
> >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
> Of Stan Ratliff (sratliff)
> >> Sent: 25 April 2013 04:49
> >> To: Teco Boot
> >> Cc: manet@ietf.org
> >> Subject: Re: [manet] DLEP link metric discussion
> >>
> >>
> >> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
> >>
> >>>
> >>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende
> geschreven:
> >>>
> >>>> What if we simply state that latency and bandwidth MUST reflect the
> full RF path? And that, where appropriate, latency MUST include delay
> introduced at any intermediate nodes?
> >>>
> >>> Why can there be any metric on parts on what is needed?
> >>
> >> There shouldn't be. But earlier in this thread, there was an example o=
f
> a radio vendor that was apparently reporting first-hop bandwidth instead =
of
> full-path bandwidth. At least that's what I gathered from the email. I'm
> concerned about the notion that the router needs to (has to?) know if the
> physical RF is multihop - frankly, I don't think that kind of visibility
> should be necessary.
> >>
> >> Regards,
> >> Stan
> >>
> >>
> >>>
> >>> Teco
> >>>
> >>>
> >>
> >> _______________________________________________
> >> manet mailing list
> >> manet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/manet
> >> The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained with=
in
> this e-mail or attached files, please contact the sender prior to any suc=
h
> disclosure. If you are not the intended recipient, any disclosure, copyin=
g
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files fro=
m
> your system. Cassidian Limited, Registered Office : Quadrant House, Celti=
c
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com
> >
> > The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained with=
in
> this e-mail or attached files, please contact the sender prior to any suc=
h
> disclosure. If you are not the intended recipient, any disclosure, copyin=
g
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files fro=
m
> your system. Cassidian Limited, Registered Office : Quadrant House, Celti=
c
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--14dae94ed81938e5a804db3546c2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Stan I don't think this is only about radios not =
being able to report accurate information.=A0 (Although I do think we live =
in the real world and many MANY radio vendors will just report the link rat=
e without taking multiple hop throughput into consideration.) 


With a mesh network broadcasts/multicast messages can be much more expe=
nsive than unicast messages.=A0 A router with multiple radio interfaces, on=
e of which is connected to all known destinations due to it having layer tw=
o routing, won't know the real cost of broadcasting on that interface.=
=A0 Unless we build a TLV to handle that into dlep but that seems even more=
 complicated than just having an interface report that it is running some m=
esh at layer 2.


At the very least, having a specification in which radio vendors =
report that they are running a mesh, might make them think a little bit mor=
e about the bigger picture; Having their radios integrated into a larger he=
terogeneous network.




On Thu,=
 Apr 25, 2013 at 11:59 AM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:


Guys,



This is just my opinion, but this is a *classic* case of the tail wagging t=
he dog. The whole discussion is predicated around a radio implementation th=
at is giving incorrect metrics to a router. IIRC, one of the quotes from th=
e radio vendor (I might be paraphrasing here) was "Yeah, but this is h=
ard"=85. Really? And we're going to put a bunch of extra stuff int=
o DLEP because of that? Here's the right answer - fix the radio. If the=
 radio reports "appropriate" metrics (predicated on its inherent =
understanding of the physical topology), then the whole mess just goes away=
. The existing implementation works.




Regards,

Stan




On Apr 25, 2013, at 11:36 AM, Dowdell, John wrote:



> Hi Teco

>

> I believe the mesh radios would directly connect to all similar radios=
 within range, and will mesh to other radios through ones that are in range=
. The meshing protocol is likely to take care of all forwarding, rebroadcas=
t and multicast forwarding actions (though I'm not completely sure abou=
t multicast forwarding). I believe (though not completely sure)some mesh ra=
dios we are testing with work out the bandwidth to a destination by looking=
 at each hop in turn and presenting the aggregate result to the source rout=
er.


>

> I would agree that point to point or hub and spoke radio system would =
not care about bandwidth on other links, though the management system might=
 collect this information.

>

> Regards

>

> John

>

> -----Original Message-----

> From: Teco Boot [mailto:teco@inf-ne=
t.nl]

> Sent: 25 April 2013 16:12

> To: Dowdell, John

> Cc: Stan Ratliff (sratliff); manet@i=
etf.org

> Subject: Re: [manet] DLEP link metric discussion

>

> Hi John,

>

> Your example brings up some new elements: need for a congestion TLV (i=
n scope for DLEP?) and multi topology / traffic engineering (not in scope f=
or DLEP, this is handled at IP routing). On congestion: would this be a per=
 DSCP metric?


>

> On your definition for the mesh radio: can I assume the provided IP li=
nk is full connected and IP broadcast/multicast capable? If so, we don'=
t need to rebroadcast for flooding or forward over same interface. This is =
important information for the routers and I support the request for a TLV f=
or it. Doesn't need to be in the core spec, routers can use such links =
to run their MANET protocol, although it is not that efficient as it could =
be.


>

> The discussion on "is provided metric for first L2 hop of a multi=
-hop L2 path" is a different subject. I think this is a real world pro=
blem, as hub&spoke type of L2 topologies are widely used and spokes are=
 typically unaware of far end RF links. Multi-hop L2 mesh topologies are al=
so in place. I think DLEP should be capable to transfer any info for the L2=
 path to the locally connected router. Could be hopcount, total airtime, 1s=
t L2 hop link metrics, to name a few I am aware of.


>

> Teco

>

>

> Op 25 apr. 2013, om 14:29 heeft "Dowdell, John" <John.Dow=
dell@Cassidian.com> het volgende geschreven:

>

>> Stan, Teco

>>

>> The multihop/mesh problem has a few facets, if for the purposes of=
 this discussion we define a mesh radio being one that is capable of doing =
its own layer 2 forwarding. Yes I know there is more to it than that, but I=
 think this is what is important here.


>>

>> Consider that you wish to take a journey across town on the bus. T=
wo busses are available for you to use to your destination, Bus A and Bus B=
. Bus A is the express bus, and stops at a small number of points along the=
 way. Bus B is the slow bus and stops at many points along the way. Unusual=
ly, this bus company is allowed to throw you off the bus before your destin=
ation if VIPs want to get on at some intermediate stop and there are not en=
ough seats, and standing is not allowed.


>>

>> In making your choice of which bus to catch, you are not intereste=
d that either bus stops at any place before your destination. You are howev=
er interested in how long each bus takes to get to your destination (latenc=
y), and you are also interested in whether you will be able to get a seat o=
n the bus for the whole of the journey (congestion).


>>

>> I would suggest therefore that a router would be interested to lea=
rn that a path to a destination is via a mesh radio, if only because it the=
n knows that it will face competition for the bandwidth that the modem repo=
rts is available. How the congestion is managed is not DLEP's job.


>>

>> BUT to re-iterate a point that Rick made earlier, the bus company =
needs to truthfully report the number of seats available on each bus for yo=
u to make able to make an informed decision. Knowing that VIPs are likely t=
o get on is an advantage, but I'm not sure that it is strictly necessar=
y.


>>

>> Bon Voyage

>>

>> John

>>

>> -----Original Message-----

>> From: manet-bounces@ietf=
.org [mailto:manet-bounces@ie=
tf.org] On Behalf Of Stan Ratliff (sratliff)

>> Sent: 25 April 2013 04:49

>> To: Teco Boot

>> Cc: manet@ietf.org

>> Subject: Re: [manet] DLEP link metric discussion

>>

>>

>> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:

>>

>>>

>>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het vo=
lgende geschreven:

>>>

>>>> What if we simply state that latency and bandwidth MUST re=
flect the full RF path? And that, where appropriate, latency MUST include d=
elay introduced at any intermediate nodes?

>>>

>>> Why can there be any metric on parts on what is needed?

>>

>> There shouldn't be. But earlier in this thread, there was an e=
xample of a radio vendor that was apparently reporting first-hop bandwidth =
instead of full-path bandwidth. At least that's what I gathered from th=
e email. I'm concerned about the notion that the router needs to (has t=
o?) know if the physical RF is multihop - frankly, I don't think that k=
ind of visibility should be necessary.


>>

>> Regards,

>> Stan

>>

>>

>>>

>>> Teco

>>>

>>>

>>

>> _______________________________________________

>> manet mailing list

>> manet@ietf.org

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

>> The information contained within this e-mail and any files attache=
d to this e-mail is private and in addition may include commercially sensit=
ive information. The contents of this e-mail are for the intended recipient=
 only and therefore if you wish to disclose the information contained withi=
n this e-mail or attached files, please contact the sender prior to any suc=
h disclosure. If you are not the intended recipient, any disclosure, copyin=
g or distribution is prohibited. Please also contact the sender and inform =
them of the error and delete the e-mail, including any attached files from =
your system. Cassidian Limited, Registered Office : Quadrant House, Celtic =
Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com


>

> The information contained within this e-mail and any files attached to=
 this e-mail is private and in addition may include commercially sensitive =
information. The contents of this e-mail are for the intended recipient onl=
y and therefore if you wish to disclose the information contained within th=
is e-mail or attached files, please contact the sender prior to any such di=
sclosure. If you are not the intended recipient, any disclosure, copying or=
 distribution is prohibited. Please also contact the sender and inform them=
 of the error and delete the e-mail, including any attached files from your=
 system. Cassidian Limited, Registered Office : Quadrant House, Celtic Spri=
ngs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com




_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--14dae94ed81938e5a804db3546c2--

From abdussalambaryun@gmail.com  Thu Apr 25 14:16:07 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6CD21F96F4 for ; Thu, 25 Apr 2013 14:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXYf3qnp8zpL for ; Thu, 25 Apr 2013 14:16:07 -0700 (PDT)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9C621F96F2 for ; Thu, 25 Apr 2013 14:16:07 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id kl13so2097443pab.15 for ; Thu, 25 Apr 2013 14:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d+hx5hJYgLKl5/F6y3xidtrRkBsIUdtpha5NP3VmoIA=; b=WvD2S6aJhybdepBnqQ/qXNDQfG/ZRSPpSd8YFVQFS2vF1MQfPYxxzKvzzPDi2wdwZ8 0MZZqPDKh27pAyPO2hsUKm7rKVZD3lSH5QpeG7sd/P7jQHc5AknsMThHQwiDBWPtilLT zAdvj8TEp/b4076WZTNFWVfOumgDp6J6J3FQGMLLryizzuz5CgnPGzFioXaWSetecsza OYejVdHiw6HNqGMLDlIF2gTp+lFI8+rtnB92+Xi1/tzH0mBmaC1NkDFyTjubBS4cHzK6 mT2XlRW78tfFSNLP3N/AOE06tmYeUgq8R209VV4tw14G6mtJpnOaGp0XYzDj/H5XEb4A jikA==
MIME-Version: 1.0
X-Received: by 10.66.160.162 with SMTP id xl2mr24059039pab.215.1366924566764;  Thu, 25 Apr 2013 14:16:06 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Thu, 25 Apr 2013 14:16:06 -0700 (PDT)
In-Reply-To: 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100C54EA@xmb-aln-x03.cisco.com> <89BD6FD1-9D80-43D5-BDA2-EDC2CA3899FA@inf-net.nl> <0bddc650-ff03-4135-9f28-a71cbaee4f11@SUCNPTEXC01.COM.AD.UK.DS.CORP> 
Date: Thu, 25 Apr 2013 23:16:06 +0200
Message-ID: 
From: Abdussalam Baryun 
To: "Taylor, Rick" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 21:16:07 -0000

On 4/25/13, Taylor, Rick  wrote:
> @All:
> I'm just trying to discover the consensus of the group on whether a
> pragmatic compromise/work-around is acceptable, or if people feel the
> protocol should insist on 'correct' behaviour from radios.

IMHO, I don't think that hopcount is necessary, the layer-2 topology
features may be reported by another standard not DLEP. If routers were
designed not to care about layer 2 topology, then why DLEP reports. We
discussed this before and many don't want to consider layer 2 or even
definition. The DLEP serves the MANET routing protocols, so Henning's
simple proposal is enough for routing optimization.

Only routers (not current ietf manet standards, maybe changed in
future) that consider layer 2 functions should need such hopcount
info.

AB

From sratliff@cisco.com  Thu Apr 25 20:42:16 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFC621E803F for ; Thu, 25 Apr 2013 20:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1nDY5nir-h5 for ; Thu, 25 Apr 2013 20:42:14 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9932F21E803D for ; Thu, 25 Apr 2013 20:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4495; q=dns/txt; s=iport; t=1366947734; x=1368157334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GZzAOHZ+igA2CTiUw7dG6WWU1ZrUKiYOHFdaLHMkeVU=; b=R9oJ+tXsj85O58Jwl5kRq4/8YteQMSR4ROEUfKX8pbngL1u3QAU2oOby 6erVjOfWvhMJFVKcEOGVK1c8KzXch6uwXppwoM56KXZsJKr2HhSbj0FuZ RfSX3vwhteohjUmAsiCdswUHoIwsaKQEmJd69MRt4GV5M2FxhQMhTedhO k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikFADr3eVGtJV2Z/2dsb2JhbABRgwc2RL1tgQcWdIIfAQEBAwEBAQFrCwULAgEIGAodBycLFBECBA4FCAGIBQYHBb50jwICMQeCbWEDiFmPaI99gw6CKA
X-IronPort-AV: E=Sophos;i="4.87,554,1363132800"; d="scan'208";a="203259313"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2013 03:42:14 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3Q3gDSn014266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 03:42:13 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 22:42:13 -0500
From: "Stan Ratliff (sratliff)" 
To: Abdussalam Baryun 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOP1lqPggRoPSGOUukBlfHXFaqD5jkKCGAgAAEdQCAA4NRgIAAhUoA
Date: Fri, 26 Apr 2013 03:42:12 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100C8224@xmb-aln-x03.cisco.com>
References: <20130415155915.4011.3274.idtracker@ietfa.amsl.com> <51753476.2070802@fkie.fraunhofer.de>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C36A9@xmb-aln-x03.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.179.211]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7BEEAEEF28CA3649A913A24C00BA4A0A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 03:42:16 -0000

AB,=20

I understand. However, there have been multiple requests from WG participan=
ts to move this document to WGLC, and only your comment for additional disc=
ussion. Therefore, it looks like "rough consensus" is behind moving to WGLC=
.=20

Regards,
Stan

On Apr 25, 2013, at 3:45 PM, Abdussalam Baryun wrote:

> Hi Stan,
>=20
>> a general recommendation to "talk about it more" doesn't help me a lot.
>=20
> I want to investigate or know opinions of how much AODVv2 can *use*
> this document or add to it. My input means fast born documents into
> WGLC does not help either. I would like to see input from AODVv2
> *users* regarding this new document,
>=20
> AB
>=20
> On 4/23/13, Stan Ratliff (sratliff)  wrote:
>> AB,
>>=20
>> On Apr 23, 2013, at 9:50 AM, Abdussalam Baryun wrote:
>>=20
>>> IMO, this document is not related only to OLSRv2 and it was not
>>> presented in any WG meeting (obsoletes RFC6622), it is better to get
>>> more discussions and feedback for its progress,
>>=20
>> Do you have a list of concerns, or specific areas of the document you fe=
el
>> need additional discussion? To be completely honest, a general
>> recommendation to "talk about it more" doesn't help me a lot.
>>=20
>> Regards,
>> Stan
>>=20
>>=20
>>>=20
>>> AB
>>>=20
>>> On 4/22/13, Henning Rogge  wrote:
>>>> Hi,
>>>>=20
>>>> thank you to the Authors for updating the document quickly.
>>>>=20
>>>> We thought we finally got the OLSRv2 RFC running, but hit a roadblock
>>>> again... so lets try to get rid of it.
>>>>=20
>>>> I think draft 02 is much more explicit about a lot of things and clear=
s
>>>> up the difference between the two ICV TLV extensions well.
>>>>=20
>>>> How do we push forward now?
>>>>=20
>>>> Henning Rogge
>>>>=20
>>>>=20
>>>> On 04/15/2013 05:59 PM, internet-drafts@ietf.org wrote:
>>>>>=20
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
>>>>> of
>>>>> the IETF.
>>>>>=20
>>>>> 	Title           : Integrity Check Value and Timestamp TLV Definition=
s
>>>>> for
>>>>> Mobile Ad Hoc Networks (MANETs)
>>>>> 	Author(s)       : Ulrich Herberg
>>>>>                          Thomas Heide Clausen
>>>>>                          Christopher Dearlove
>>>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>>>> 	Pages           : 24
>>>>> 	Date            : 2013-04-15
>>>>>=20
>>>>> Abstract:
>>>>>   This document revises, extends and replaces RFC 6622.  It describes
>>>>>   general and flexible TLVs for representing cryptographic Integrity
>>>>>   Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>>>   Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>>>   defines two Packet TLVs, two Message TLVs, and two Address Block
>>>>> TLVs
>>>>>   for affixing ICVs and timestamps to a packet, a message, and one or
>>>>>   more addresses, respectively.
>>>>>=20
>>>>>=20
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>>>=20
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>>>=20
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>>>=20
>>>>>=20
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>=20
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>>>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>>>> Kommunikationssysteme (KOM)
>>>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>>>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>>>=20
>>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>=20
>>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From henning.rogge@fkie.fraunhofer.de  Fri Apr 26 01:28:17 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D2B21F97A6 for ; Fri, 26 Apr 2013 01:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Alu-0d8u9zgm for ; Fri, 26 Apr 2013 01:28:17 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1E21F85DC for ; Fri, 26 Apr 2013 01:28:16 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UVe0r-00017m-DL; Fri, 26 Apr 2013 10:28:13 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UVe0r-0000B6-AS; Fri, 26 Apr 2013 10:28:13 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 26 Apr 2013 10:28:12 +0200
Message-ID: <517A3A94.5090902@fkie.fraunhofer.de>
Date: Fri, 26 Apr 2013 10:28:04 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: Teco Boot 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl>
In-Reply-To: <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010403030307040107080801"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17094/Fri Apr 26 04:35:27 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: cf4e294f566e9b0166dbdd65a574298f
Cc: " List" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 08:28:18 -0000

--------------ms010403030307040107080801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/24/2013 05:04 PM, Teco Boot wrote:
> I'm not sure I get the problem.
>
> DLEP provides info on L2 / sub-IP links to a connected router. In the
> example, radio-A provides info to connected router-A on links to a
> router-B, router-E and router-F (not clear in the example radio-C and
> radio-D have connected routers). The reported metric *should be
> composed from info from al links of the L2 / sub-IP path*. If the
> radio cannot provide such, but instead provides only info on parts of
> the path (such as for radio A reports only link A-C), I wonder what
> the router can do with such information (other than discard...).
>
> @Henning: If NHDP tells that each neighbor has connectivity to all
> other neighbors on that IP link, wouldn't that be "full connected"?
> Are you looking for this FullConnected TLV?

Yes, a "fully connected" might have a similar effect.

In fact, I plan to use this information to make sure the flooding=20
algorithm doesn't get the idea to forward OLSRv2 TCs within the layer-2=20
mesh domain, because its a huge waste of resources.

Henning Rogge

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


--------------ms010403030307040107080801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjYwODI4MTBaMCMGCSqGSIb3DQEJBDEWBBQGuzpzEsCiriWGPNTf+2P3rp4irDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAZQxFgkz8E9OKp7p5OZtIG91MfBBfJoqv12E8/lcpJF7V
Yf65DGK1YxQY95Kwry8ryTEwV+5DSqBAHsqxx66eMOUm6zezw8YKGxXMz3HCO/SbFtEybbCX
NJXUHTNKhtGbqFTF4qiasYkGkj8hGerYEV63DfoTByQbq4yIKxl+44CxPnS6E4QfpWaGlaiK
C5ghYiOys1+5c50C+BcFLsYdg2Elod+wy9jBKjUO0OEZ+6/9mhPL5z2xi38Y7S5yJTbz95Mi
MGR1q4S+RIOoOyE0xbDihBskE8bwBWi3pi0pqRrfzYJCyXwCxHA1f6NfcjKhSntmz8x9/QFs
2vgbdAIIzAAAAAAAAA==
--------------ms010403030307040107080801--

From henning.rogge@fkie.fraunhofer.de  Fri Apr 26 01:31:20 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF921F97CD for ; Fri, 26 Apr 2013 01:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSqr4MEcT+Zi for ; Fri, 26 Apr 2013 01:31:19 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D098C21F981D for ; Fri, 26 Apr 2013 01:31:16 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UVe3k-0002lK-Bg; Fri, 26 Apr 2013 10:31:12 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UVe3k-0000JM-90; Fri, 26 Apr 2013 10:31:12 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 26 Apr 2013 10:31:11 +0200
Message-ID: <517A3B4F.4080706@fkie.fraunhofer.de>
Date: Fri, 26 Apr 2013 10:31:11 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Duke, Martin" 
References: <51765087.6000302@fkie.fraunhofer.de> <1366732633.1720.14.camel@localhost>  <2ED1D3801ACAAB459FDB4EAC9EAD090C100C3EC6@xmb-aln-x03.cisco.com>   <8E651B8C-6C6D-44DA-B0DC-FA4B479E8241@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com>
In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50227CCA@XCH-BLV-503.nw.nos.boeing.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020108070403050107040105"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17094/Fri Apr 26 04:35:27 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: d11929bbb37d0bf82123645737fe3651
Cc: "manet@ietf.org" 
Subject: Re: [manet] DLEP link metric discussion
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 08:31:20 -0000

--------------ms020108070403050107040105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/24/2013 06:10 PM, Duke, Martin wrote:
> 2) I'm hesitant to say that the mesh Boolean should *strictly
> prevent* the router from doing its own forwarding through the mesh.
> It's true that some routers are unsophisticated and some radios have
> fancy cross-layer mechanisms. It's also true that some radios aren't
> that sophisticated, and that routers (in principle) may be doing all
> kinds of innovative traffic engineering using multi-topology routing,
> load balancing, integrated services, or what have you. It's much
> better to empower the interface to communicate enough information to
> support any approach, and let network architects decide who's
> ultimately in charge depending on known capabilities of routers and
> radios.

The Boolean flag would be a hint to the router, which can be used to=20
optimize the routers protocol implementation. But its still the decision =

of the router what to do with the information (or to ignore it at all).

Henning Rogge

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


--------------ms020108070403050107040105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjYwODMxMTFaMCMGCSqGSIb3DQEJBDEWBBQrQJfABIEYM828ggQ+KxcgiKPcbjBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAQ0y1oZVGZA5boglI8LgZgctL6XXzWX/iTzlAmr1jzBv8
8OpHBXTnNrYAYLqTxK2Cl9R3KclHJwT98SxSF1Ij6LMZ1YBQhV3vlIXVRfuoZDCVDOuigcy1
ZBIMWqFcyn+TAzQ9/YCqma5P7KBHjJMPd1dBRhwcuFJNG8zaY7NZfxmahCG2LR7SYYHah+9W
65AyKdiQLUqPlEmG2rQB6NBI0t92uApFqGZlsmT8cbIo/+UaU0NKEfAhnVT4cC2bR/3Go0Cf
FyFiLD9RPmgRw/CEz7Ck2MEXXfLJTQR2HjpCDq/OiJW+xMtLDFokJ7+yFu1+GwFf9OdsrLt5
v9wDPaD39QAAAAAAAA==
--------------ms020108070403050107040105--

From yi.jiazi@gmail.com  Fri Apr 26 05:10:43 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9201121F98B4 for ; Fri, 26 Apr 2013 05:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC3n281TEZgp for ; Fri, 26 Apr 2013 05:10:42 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D121F95D0 for ; Fri, 26 Apr 2013 05:10:41 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id c10so526109wiw.8 for ; Fri, 26 Apr 2013 05:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=VKfpEp+13x6f2cGxFHZwLYT70/XaJl0lUQ0zuxIbV64=; b=TPtB5kZZtGsn4Fe6vf7UmFDc7/EGC+vnV9XpRUgmlyzVpKI+ADTdwINsGeth+qDdtO yKcYUjlP4Xqp6SaNYKvMP9/GVQJVh3YfAdJR9REqSxvYsTRKEDUJ8SwQGAm7zgdLj8tr 5pXY1wN1ra+6IHTWyNXjiyDGoRGgm0lLDg94V6pZ3GY1bi+WLmTjg+82goAmPI6y+q3b Hz4kNm+j/DkdbydB8DwJcLCOIzxuJDa3bkEA6UibSzGZZqkIHJUzu7PrTqlkOIjPG7GK WnD2J9n7yYPYx3BO4rE+cy4O0r36J2tARG8K59EUVKtWZ4Z7VMLE/oXZ4RiQGLqgW4Ci BhfQ==
X-Received: by 10.194.82.34 with SMTP id f2mr23736340wjy.25.1366978240932; Fri, 26 Apr 2013 05:10:40 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPSA id q18sm3069805wiw.8.2013.04.26.05.10.39 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 05:10:39 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: 
Date: Fri, 26 Apr 2013 14:10:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>    
To: "Dearlove, Christopher (UK)" 
X-Mailer: Apple Mail (2.1503)
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 12:10:43 -0000

Hi,=20

On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" =
 wrote:

> I think you missed something. Though there is a point we might have to =
consider that I'll get to.
>=20
> These are constraints on your internal parameters. Let me just =
consider the HELLO ones, obviously the TC ones are similar.
>=20
> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears =
to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously =
that only makes sense for a positive age, hence the first constraint. =
That doesn't matter about synchronisation. It's actually a fairly =
obvious thing that almost doesn't need saying (but also see a bit =
later).

Yes. I agree. If we assume "network can be synchronized with sufficient =
precision", then the value can only be positive.=20
Of course, if the network is not well synchronized, a negative is =
possible.=20


>=20
> Now sticking for the moment to an assumption that we can measure the =
age of a packet/message, we want to bound how much slack we should =
allow. And that's the second constraint. (Right this moment I'm not sure =
why we picked REFRESH_INTERVAL rather than HELLO_INTERVAL, but it =
actually works either way.) But this is where synchronisation comes in =
(and why the_DIFF suffix). We measure the age by comparing our clock =
with the timestamp. If synchronised then that's the age, done.


I'm just a little confused by why "assuming ideal time synchronization" =
is related to the constraints of=20

	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"=20

I didn't quite get the relation here.=20
What I understand is that, the "age" calculated by=20

	local_router_time - HELLO_timestamp=20

is only related to transmission delay of the message (if no attack =
happens).  When it is regarded "too old" (age > =
MAX_HELLO_TIMESTAMP_DIFF), it is discarded.=20


>=20
> If there's a synchronisation error, let's suppose we received at t2, =
it claims to be sent at t1, but (based on our clock) was actually sent =
at t1+e. So our test is
>=20
> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF
>=20
> but the age of the message, A is t2 - t1 - e, so
>=20
> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e
>=20
> So if we want to only reject messages that are definitely too late, we =
need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e =
(assume e is symmetrically distributed +ve and -ve. In turn this means =
that we should allow an extra margin of e on the constraint =
MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.
>=20
> Now the point of interest. What if we receive a message with an =
apparent negative age? If that's greater than the minimum value of e (or =
-e) that's fine. But more than that? Should we reject such messages?

Apparently, if the network is not synchronized, a negative age can =
happen. What I understand is that, this document won't take care of =
synchronization and related error? Because those would be another big =
problem to deal with...

best

Jiazi

>=20
> --=20
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>=20
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>=20
>=20
> -----Original Message-----
> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
> Sent: 24 April 2013 17:55
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>=20
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Thanks Chris for sharing your thought.=20
>=20
> Yes, those are all possibilities to consider. And a more fundamental =
issue I'm thinking about is the framework for securing re-active =
protocols, because it's much harder than pro-acitve ones. For example, =
do we want to require hop-by-hop authentication? Zeroing the metric =
field opens possible attack vector also... anyway, we can discuss this =
in other topics in the future.=20
>=20
> In the meantime, I reviewed the draft =
draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I =
would support it for WGLC.=20
>=20
> Just one question:
>=20
> In the draft:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The following constraints apply to these parameters:
>=20
>   o  MAX_HELLO_TIMESTAMP_DIFF > 0
>=20
>   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
>=20
>   o  MAX_TC_TIMESTAMP_DIFF > 0
>=20
>   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
>=20
>   The second and fourth of those constraints assume ideal time
>   synchronization of the clocks in all routers in the network.=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> My understanding is that, "the time difference equals 0" is for ideal =
time synchronization. So it should be The first and third assume ideal =
time synchronization? Or I missed something here?=20
>=20
> best
>=20
> Jiazi
>=20
> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" =
 wrote:
>=20
>> Thanks for that. I'm hoping we can proceed push out 6622bis, and the =
security document.
>>=20
>> As a contribution to that future concept, I'll note that 6622(bis) is =
independent of the protocol. That I think is a desirable thing.
>>=20
>> One idea (I'm not sold on it, it's just for consideration) is that if =
you are considering that, for example, you don't want to include a =
metric in your ICV, and that metric is in TLV type X (probably a full =
type with type extension, but that's another of those details) then as a =
new variant type extension ICV, you could add something to say "remove =
all TLVs with type extensions X, Y, Z before calculating ICV). Or maybe =
that needs to be a range. Or ... but first work out exactly what you =
want, then how it cleanly generalises (where a good generalisation is =
easier to implement than the special case).
>>=20
>> --=20
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>=20
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>=20
>>=20
>> -----Original Message-----
>> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
>> Sent: 24 April 2013 17:12
>> To: Dearlove, Christopher (UK)
>> Cc: manet@ietf.org
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>=20
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>> Hi,=20
>>=20
>> After several mail exchange with some of the other authors, I think =
it would be better to keep the draft as it is on the mutable fields, =
because how to define/use protocol-specific mutable fields is not very =
clear at this point.=20
>> If necessary, it would probably be better to put them in another =
document, after we figuring out exactly how to handle those fields.=20
>>=20
>> best
>>=20
>> Jiazi
>>=20
>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
>>=20
>>> Chris,=20
>>>=20
>>> I do understand your concern. We had this kind of discussion on =
mutable fields before, and this is something I'm still mulling over.=20
>>> The reason why I propose this for discussion is:
>>>=20
>>> 	- this rfc6622bis is for rfc5444, which is a general format for =
all manet protocols.=20
>>> 	- The reactive protocol like LOADng does explicitly define such =
"mutable" fields. It is something at hand, not in the far future.=20
>>>=20
>>> In the meantime, I do agree that the necessity and how to take care =
of such mutable fields should be considered carefully.=20
>>> So I would agree that we keep the current rfc6622bis draft as it is =
for the moment, and I'll have more discussions with other LOADng authors =
on this.=20
>>>=20
>>> best=20
>>>=20
>>> Jiazi
>>>=20
>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" =
 wrote:
>>>=20
>>>> Jiazi
>>>>=20
>>>> Thanks for that, I'll just comment on the one point where I =
disagree.
>>>>=20
>>>> Putting some vague words in that protocols may indicate fields not =
to be covered is the sort of thing that I can predict will cause us =
problems at the IESG. And it's not really a good plan for a generic =
mechanism that can - at at present - be run independently of the routing =
protocol to acquire a protocol dependence. Rather I think that any =
routing protocols with a specific need to exclude data (which, all else =
being equal is a bad thing of course) should consider defining a new =
type extension - preferably one defined with some generic capability =
(could it, for example, list TLV types to be excluded?) But that's for =
the future. One thing I have learned is that design in advance of what =
might hypothetically be needed generally gets it wrong, so it would be =
good to wait until exactly what's needed is clear, and then define a new =
case.
>>>>=20
>>>> Christopher
>>>>=20
>>>> --=20
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>>>> chris.dearlove@baesystems.com | http://www.baesystems.com
>>>>=20
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>=20
>>>> -----Original Message-----
>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =
Behalf Of ietf@jiaziyi.com
>>>> Sent: 23 April 2013 15:37
>>>> To: manet@ietf.org
>>>> Subject: Re: [manet] I-D Action: =
draft-ietf-manet-rfc6622-bis-02.txt
>>>>=20
>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters
>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>=20
>>>> (sorry if you receive duplicate of this message. Some of my mails =
to=20
>>>> the mailing list are rejected, and I'm trying to figure out with =
our=20
>>>> secretary...)
>>>>=20
>>>> Hi,
>>>>=20
>>>> I had a review of the draft. I think it's in good shape, and ready =
for=20
>>>> WGLC.
>>>>=20
>>>> a few comments:
>>>>=20
>>>> In section 6 & 7, I didn't find the definition of notation
>>>> 	+
>>>> Not in this draft, either rfc 5444.
>>>>=20
>>>> page 13,  source code address =3D=3D> source node address?
>>>>=20
>>>> section 9.1 bullet 1 states that the  and=20
>>>>  must be zeroed before calculating ICV. I'm thinking=20=

>>>> about that we might need to mention that some protocol-specific =
mutable=20
>>>> fields must be zeroed here also. For example, in LOADng, as a =
reactive=20
>>>> protocol, metric fields are defined as "mutable" (in the meantime, =
I=20
>>>> still have some thoughts on those mutable fields that I need to =
discuss=20
>>>> with other LOADng authors, but it's not that relevant here).
>>>>=20
>>>> best
>>>>=20
>>>> Jiazi
>>>>=20
>>>>=20
>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>>>=20
>>>>=20
>>>> A New Internet-Draft is available from the on-line Internet-Drafts=20=

>>>> directories.
>>>> This draft is a work item of the Mobile Ad-hoc Networks Working =
Group=20
>>>> of the IETF.
>>>>=20
>>>> 	Title           : Integrity Check Value and Timestamp TLV =
Definitions=20
>>>> for Mobile Ad Hoc Networks (MANETs)
>>>> 	Author(s)       : Ulrich Herberg
>>>>                      Thomas Heide Clausen
>>>>                      Christopher Dearlove
>>>> 	Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>>> 	Pages           : 24
>>>> 	Date            : 2013-04-15
>>>>=20
>>>> Abstract:
>>>> This document revises, extends and replaces RFC 6622.  It describes
>>>> general and flexible TLVs for representing cryptographic Integrity
>>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>> defines two Packet TLVs, two Message TLVs, and two Address Block =
TLVs
>>>> for affixing ICVs and timestamps to a packet, a message, and one or
>>>> more addresses, respectively.
>>>>=20
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>>=20
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>>=20
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>>=20
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>=20
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>=20
>>>>=20
>>>> =
********************************************************************
>>>> This email and any attachments are confidential to the intended
>>>> recipient and may also be privileged. If you are not the intended
>>>> recipient please delete it from your system and notify the sender.
>>>> You should not copy it or use it for any purpose nor disclose or
>>>> distribute its contents to any other person.
>>>> =
********************************************************************
>>>>=20
>>>=20
>>=20
>>=20
>=20
>=20


From Chris.Dearlove@baesystems.com  Fri Apr 26 05:21:41 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7021F9830 for ; Fri, 26 Apr 2013 05:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV8RXzGYUHH2 for ; Fri, 26 Apr 2013 05:21:41 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 67B6221F982F for ; Fri, 26 Apr 2013 05:21:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="332512576"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2013 13:21:39 +0100
Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QCLdXg019741 for ; Fri, 26 Apr 2013 13:21:39 +0100
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="14563163"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 26 Apr 2013 13:21:39 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 13:21:39 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi Yi 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAARGCA=
Date: Fri, 26 Apr 2013 12:21:38 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>     
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=us-ascii
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 12:21:41 -0000

Jiazi:
> I'm just a little confused by why "assuming ideal time synchronization" is related to the constraints of 
>
>	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL" 

I'm going to do the TC example:

MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL

just so I can get some easier numbers to play with. But the essentials are the same.

Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum time of 2 seconds for a message to propagate across the network. So we could in principle in this case discard any message that arrives more than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to 2 seconds if we had perfect timings.

Now let's consider that our clocks might be adrift by 2 seconds. Now consider what MAX_TC_TIMESTAMP_DIFF is: it's the parameter you use to compare your time measurement, and the timestamp in the message. It's a practical parameter, one you use in that way, not an abstract parameter. So now a perfectly good TC message might arrive with a timestamp 2 seconds early (by our reckoning) and having travelled for up to 2 seconds. So the practical parameter we need, MAX_TC_TIMESTAMP_DIFF is 4 seconds.

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


From yi.jiazi@gmail.com  Fri Apr 26 05:47:48 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6421F9911 for ; Fri, 26 Apr 2013 05:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9UOWZO3xsPC for ; Fri, 26 Apr 2013 05:47:48 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9204321F990F for ; Fri, 26 Apr 2013 05:47:47 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id z2so3569858wey.29 for ; Fri, 26 Apr 2013 05:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=pNFIU0JJLKzEGPyiP851IQm7zpMyGnepqd7fhIOSbtA=; b=MP+SMXnFg0sov2YrM3UWUc/iF/c2XOcwJshPJIodBoWU300j08StMHXL3nf9tInQkp Bhd41kt+ekLvGfi1hrFKbxDZ42W9NR61p2AfUhWbmeA+9YXTdceMMsujpS7vxb36GgW3 SMJKYm3xr7NEnjqSJJr36YmNG/TFc2MYyyRrud2jQNScwp8wb8Tlinzo1m323JgJbP31 EJCKRSlLf9Zkjcu325Y2oQ7ObdTivHcXGnrT8XNQGsAYdyL816m4vIo6kbwxzOLqKtF0 MS7eSHxvWhcOZa8cfhOeUjCcbFzZX1SmCR1q8UPaDZaSpeJQKmMJTXRqmRzF4cdQvAGm K9Jg==
X-Received: by 10.180.79.69 with SMTP id h5mr3790245wix.14.1366980459793; Fri, 26 Apr 2013 05:47:39 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPSA id ek4sm3250990wib.11.2013.04.26.05.47.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 05:47:39 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: 
Date: Fri, 26 Apr 2013 14:47:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>      
To: "Dearlove, Christopher (UK)" 
X-Mailer: Apple Mail (2.1503)
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 12:47:48 -0000

Hi,


On Apr 26, 2013, at 2:21 PM, "Dearlove, Christopher (UK)" =
 wrote:

> Jiazi:
>> I'm just a little confused by why "assuming ideal time =
synchronization" is related to the constraints of=20
>>=20
>> 	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"=20
>=20
> I'm going to do the TC example:
>=20
> MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL
>=20
> just so I can get some easier numbers to play with. But the essentials =
are the same.
>=20
> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum =
time of 2 seconds for a message to propagate across the network. So we =
could in principle in this case discard any message that arrives more =
than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to 2 seconds =
if we had perfect timings.

Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think =
TC_INTERVAL makes more sense).=20
But according to the draft, if we had perfect timings, it is set to =
T_HOLD_TIME (or TC_INTERVAL)?

=3D=3D=3D=3D=3D=3D=3D=3D=3D
The second and fourth (MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME) of those =
constraints assume ideal time
   synchronization of the clocks in all routers in the network.
=3D=3D=3D=3D=3D=3D=3D

Of course, it can be set to T_HOLD_TIME, because it's actually a looser =
constraint.=20
My only problem is, there is no direct relationship between perfect =
timing, and setting the value to T_HOLDE_TIME (for TC). Maybe I'm too =
nit-picking here? :-P

>=20
> Now let's consider that our clocks might be adrift by 2 seconds. Now =
consider what MAX_TC_TIMESTAMP_DIFF is: it's the parameter you use to =
compare your time measurement, and the timestamp in the message. It's a =
practical parameter, one you use in that way, not an abstract parameter. =
So now a perfectly good TC message might arrive with a timestamp 2 =
seconds early (by our reckoning) and having travelled for up to 2 =
seconds. So the practical parameter we need, MAX_TC_TIMESTAMP_DIFF is 4 =
seconds.

Yes, and I have no problem with this.=20

Jiazi

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


From henning.rogge@fkie.fraunhofer.de  Fri Apr 26 05:55:39 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60021F990E for ; Fri, 26 Apr 2013 05:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WjgLbiQfns1 for ; Fri, 26 Apr 2013 05:55:38 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA4321F982E for ; Fri, 26 Apr 2013 05:55:27 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UViBS-00064K-DG for manet@ietf.org; Fri, 26 Apr 2013 14:55:26 +0200
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UViBS-00084Q-AZ for manet@ietf.org; Fri, 26 Apr 2013 14:55:26 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 26 Apr 2013 14:55:25 +0200
Message-ID: <517A793D.606@fkie.fraunhofer.de>
Date: Fri, 26 Apr 2013 14:55:25 +0200
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>       
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040408090308040608080900"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.7/17096/Fri Apr 26 12:39:09 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 12:55:39 -0000

--------------ms040408090308040608080900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/26/2013 02:47 PM, Jiazi Yi wrote:
>> Jiazi:
>>> I'm just a little confused by why "assuming ideal time
>>> synchronization" is related to the constraints of
>>>
>>> "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"
>>
>> I'm going to do the TC example:
>>
>> MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL
>>
>> just so I can get some easier numbers to play with. But the
>> essentials are the same.
>>
>> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum
>> time of 2 seconds for a message to propagate across the network. So
>> we could in principle in this case discard any message that arrives
>> more than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to
>> 2 seconds if we had perfect timings.
>
> Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think
> TC_INTERVAL makes more sense). But according to the draft, if we had
> perfect timings, it is set to T_HOLD_TIME (or TC_INTERVAL)?
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D The second and fourth (MAX_TC_TIMESTAMP_DIF=
F < T_HOLD_TIME)
> of those constraints assume ideal time synchronization of the clocks
> in all routers in the network. =3D=3D=3D=3D=3D=3D=3D
>
> Of course, it can be set to T_HOLD_TIME, because it's actually a
> looser constraint. My only problem is, there is no direct
> relationship between perfect timing, and setting the value to
> T_HOLDE_TIME (for TC). Maybe I'm too nit-picking here? :-P

TCs also can get lost... so the maximum acceptable time-difference=20
should be TC_VALIDITY_TIME.

Henning Rogge

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


--------------ms040408090308040608080900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC
BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha
Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw
HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg
Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3
9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/
o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS
DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe
3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI
ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA
FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF
gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o
dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy
bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF
AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh
gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe
1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l
kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG
fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu
oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV
BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G
A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw
MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY
RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg
MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S
rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML
3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux
gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt
uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY
qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV
HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v
Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js
LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv
b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp
LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl
ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b
yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l
VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ
C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm
M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6
5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh
MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy
IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV
BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ
ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs
lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP
DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H
xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c
5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj
ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll
LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY
MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu
cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh
dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB
+jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl
L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et
MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11
c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH
AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp
LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor
O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp
eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1
KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8
MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK
575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq
hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE
CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg
Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx
FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE
lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E
B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ
ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/
9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC
aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu
aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d
r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy
YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl
ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr
BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw
Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11
c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v
Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh
LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI
KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw
Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S
j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA
aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8
knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC
/VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP
/cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG
EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh
dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ
BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA0MjYxMjU1MjVaMCMGCSqGSIb3DQEJBDEWBBQd0id5nOmv+TS0W2UhrhoKQUEV6TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAluVPZ+P9dcGdoWtPHc2IDTTdFnacuzCobCzX1GaeL/LX
0daksgHcY/SYxt8YIkxpfGa022VpD5x27plWDllSmO+/vGqYB778XLTbzKxsSKAXbdKr6x0/
9Vjk56dSXN916UoeFFPU3uNLSadrBJkPp0/1vbj3o/ZA4NjEOwDFNGqWy2zW1GqsC30O+/oa
eeX4HCgpNsl18KkzIcvN2PvoO1ssz8o6sp22KNYVEsIBjTQroCNAgNXKq0ypTJqX2m1r/dnr
7ESFJ4EZ3RgMA2BYszjO8uSgD5wjvdSKQJvHWp0eK/qCc8JTaNTS/03JGo9TsDarTlc5owUF
68bH5znNlQAAAAAAAA==
--------------ms040408090308040608080900--

From Chris.Dearlove@baesystems.com  Fri Apr 26 06:19:07 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9A121F9926 for ; Fri, 26 Apr 2013 06:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV-iYAOR751e for ; Fri, 26 Apr 2013 06:19:06 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id DBC9721F980A for ; Fri, 26 Apr 2013 06:19:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="282088127"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Apr 2013 14:19:05 +0100
Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QDJ48E004794 for ; Fri, 26 Apr 2013 14:19:04 +0100
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="14330038"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 26 Apr 2013 14:19:04 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 14:19:04 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi Yi 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAARGCD///k9AIAAGTPg
Date: Fri, 26 Apr 2013 13:19:03 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>       
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 13:19:07 -0000

I don't see anything that support your comment that according to the draft,=
 if we had perfect timings, it is set to T_HOLD_TIME. What makes you say th=
at?

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Jiazi Yi [mailto:yi.jiazi@gmail.com]=20
Sent: 26 April 2013 13:48
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi,


On Apr 26, 2013, at 2:21 PM, "Dearlove, Christopher (UK)"  wrote:

> Jiazi:
>> I'm just a little confused by why "assuming ideal time synchronization" =
is related to the constraints of=20
>>=20
>> 	"MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"=20
>=20
> I'm going to do the TC example:
>=20
> MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL
>=20
> just so I can get some easier numbers to play with. But the essentials ar=
e the same.
>=20
> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum time o=
f 2 seconds for a message to propagate across the network. So we could in p=
rinciple in this case discard any message that arrives more than 2 seconds =
late. so we could set MAX_TC_TIMESTAMP_DIFF to 2 seconds if we had perfect =
timings.

Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think TC_INTERVA=
L makes more sense).=20
But according to the draft, if we had perfect timings, it is set to T_HOLD_=
TIME (or TC_INTERVAL)?

=3D=3D=3D=3D=3D=3D=3D=3D=3D
The second and fourth (MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME) of those constr=
aints assume ideal time
   synchronization of the clocks in all routers in the network.
=3D=3D=3D=3D=3D=3D=3D

Of course, it can be set to T_HOLD_TIME, because it's actually a looser con=
straint.=20
My only problem is, there is no direct relationship between perfect timing,=
 and setting the value to T_HOLDE_TIME (for TC). Maybe I'm too nit-picking =
here? :-P

>=20
> Now let's consider that our clocks might be adrift by 2 seconds. Now cons=
ider what MAX_TC_TIMESTAMP_DIFF is: it's the parameter you use to compare y=
our time measurement, and the timestamp in the message. It's a practical pa=
rameter, one you use in that way, not an abstract parameter. So now a perfe=
ctly good TC message might arrive with a timestamp 2 seconds early (by our =
reckoning) and having travelled for up to 2 seconds. So the practical param=
eter we need, MAX_TC_TIMESTAMP_DIFF is 4 seconds.

Yes, and I have no problem with this.=20

Jiazi

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



From yi.jiazi@gmail.com  Fri Apr 26 06:23:52 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9721F991E for ; Fri, 26 Apr 2013 06:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxpH+oMePSkM for ; Fri, 26 Apr 2013 06:23:51 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52021F991B for ; Fri, 26 Apr 2013 06:23:45 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id l13so611765wie.0 for ; Fri, 26 Apr 2013 06:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=lu+Dd9pskHcofDdTkxBzo2wUghsbPq4B2S6mFID5ocA=; b=mAtvsSdkNZgwn2H20VgG+KdtVLXrVOh+IdMX4RMkkfcQ4z3Bo558y7ZUmOSJovFoNE kJ+pU6QKkh6K6Tb46AOxb1PVcuCw+baoxLBPffdpIw4euHHR5B3yWC2yHX8Ylx6a/rTj oC5vxyIUYrURLnZVRdV7hQNrgwIRNGgzdYvw/LFWSdKRuqIwjBTOx/y9uDPnCEDBRubH Hc1Aqo3710aLvTKQGAU4s5S9jBZAyxVwkhHjkETQ+iHeDOBpnu0kupSn4mnoadpAhWsn K+0mzDExAcgQFFsPGSemmr+UMbfqlywkZlrmwQehpZQ40kQTcqV5nyiUESpVtq3oS4YS tYZA==
X-Received: by 10.180.92.41 with SMTP id cj9mr4046880wib.7.1366982624918; Fri, 26 Apr 2013 06:23:44 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPSA id nf9sm3498980wic.3.2013.04.26.06.23.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 06:23:44 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: <517A793D.606@fkie.fraunhofer.de>
Date: Fri, 26 Apr 2013 15:23:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <63C4F28E-ABE3-44A3-B7A9-9D066C7F3A27@gmail.com>
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>        <517A793D.606@fkie.fraunhofer.de>
To: Henning Rogge 
X-Mailer: Apple Mail (2.1503)
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 13:23:53 -0000

> TCs also can get lost... so the maximum acceptable time-difference =
should be TC_VALIDITY_TIME.

I'm not sure we are talking about the same time-difference?

The acceptable time-difference between two consecutive TC messages is =
T_HOLD_TIME (the  TC_VALIDITY_TIME you mentioned, to update the =
information base).=20

However, in this case, it's more the time-difference between *the* TC =
message is sent out, and *the* message is received (with or without =
sync)?

Jiazi

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


From Chris.Dearlove@baesystems.com  Fri Apr 26 06:43:13 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88B21F9982 for ; Fri, 26 Apr 2013 06:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYA598z5yiTL for ; Fri, 26 Apr 2013 06:43:12 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70621F9981 for ; Fri, 26 Apr 2013 06:43:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="332535908"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2013 14:43:10 +0100
Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QDhAAG003204 for ; Fri, 26 Apr 2013 14:43:10 +0100
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="14570644"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 26 Apr 2013 14:43:09 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 14:43:10 +0100
From: "Dearlove, Christopher (UK)" 
To: Henning Rogge , "manet@ietf.org" 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAARGCD///k9AIAAAiuAgAAdInA=
Date: Fri, 26 Apr 2013 13:43:10 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>        <517A793D.606@fkie.fraunhofer.de>
In-Reply-To: <517A793D.606@fkie.fraunhofer.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 13:43:13 -0000

T_HOLD_TIME is what you've described as TC_VALIDITY_TIME.

But I'm not convinced, because this is about message replay, not message lo=
ss. What I am convinced of is that REFRESH_TIME and T_HOLD_TIME are not a m=
atched pair.

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H=
enning Rogge
Sent: 26 April 2013 13:55
To: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

On 04/26/2013 02:47 PM, Jiazi Yi wrote:
>> Jiazi:
>>> I'm just a little confused by why "assuming ideal time
>>> synchronization" is related to the constraints of
>>>
>>> "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"
>>
>> I'm going to do the TC example:
>>
>> MAX_TC_TIMESTAMP_DIFF < TC_INTERVAL
>>
>> just so I can get some easier numbers to play with. But the
>> essentials are the same.
>>
>> Now let's suppose TC_INTERVAL is 5 seconds, and it takes a maximum
>> time of 2 seconds for a message to propagate across the network. So
>> we could in principle in this case discard any message that arrives
>> more than 2 seconds late. so we could set MAX_TC_TIMESTAMP_DIFF to
>> 2 seconds if we had perfect timings.
>
> Yes. I fully agree (btw, in the draft, it's T_HOLD_TIME? I think
> TC_INTERVAL makes more sense). But according to the draft, if we had
> perfect timings, it is set to T_HOLD_TIME (or TC_INTERVAL)?
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D The second and fourth (MAX_TC_TIMESTAMP_DIFF =
< T_HOLD_TIME)
> of those constraints assume ideal time synchronization of the clocks
> in all routers in the network. =3D=3D=3D=3D=3D=3D=3D
>
> Of course, it can be set to T_HOLD_TIME, because it's actually a
> looser constraint. My only problem is, there is no direct
> relationship between perfect timing, and setting the value to
> T_HOLDE_TIME (for TC). Maybe I'm too nit-picking here? :-P

TCs also can get lost... so the maximum acceptable time-difference=20
should be TC_VALIDITY_TIME.

Henning Rogge

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


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


From Chris.Dearlove@baesystems.com  Fri Apr 26 06:46:04 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E9C21F9900 for ; Fri, 26 Apr 2013 06:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNdVt9-1DiJP for ; Fri, 26 Apr 2013 06:46:03 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 953DF21F93D8 for ; Fri, 26 Apr 2013 06:46:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="282094897"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Apr 2013 14:46:03 +0100
Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QDk2bM020968 for ; Fri, 26 Apr 2013 14:46:02 +0100
X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="14332365"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 26 Apr 2013 14:46:02 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 14:46:02 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi Yi , Henning Rogge 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAARGCD///k9AIAAAiuAgAAH6wCAABZS0A==
Date: Fri, 26 Apr 2013 13:46:02 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>        <517A793D.606@fkie.fraunhofer.de> <63C4F28E-ABE3-44A3-B7A9-9D066C7F3A27@gmail.com>
In-Reply-To: <63C4F28E-ABE3-44A3-B7A9-9D066C7F3A27@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 13:46:04 -0000

Which means that we don't have something perfect to compare it with. But th=
ese are indicative figures - they are inequalities - so in fact either TC_I=
NTERVAL or T_HOLD_TIME would work, it's just a matter of which is clearer. =
I think the better answer is TC_INTERVAL, but with a comment about being si=
gnificantly smaller.

(It's a strange ad hoc network that sends messages more often than they pro=
pagate across it.)

--=20
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J=
iazi Yi
Sent: 26 April 2013 14:24
To: Henning Rogge
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

> TCs also can get lost... so the maximum acceptable time-difference should=
 be TC_VALIDITY_TIME.

I'm not sure we are talking about the same time-difference?

The acceptable time-difference between two consecutive TC messages is T_HOL=
D_TIME (the  TC_VALIDITY_TIME you mentioned, to update the information base=
).=20

However, in this case, it's more the time-difference between *the* TC messa=
ge is sent out, and *the* message is received (with or without sync)?

Jiazi

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

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


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


From abdussalambaryun@gmail.com  Fri Apr 26 07:28:37 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6308A21F994E for ; Fri, 26 Apr 2013 07:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.549,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfxRN4waef5K for ; Fri, 26 Apr 2013 07:28:35 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 412EE21F994C for ; Fri, 26 Apr 2013 07:28:35 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id 4so2484487pdd.17 for ; Fri, 26 Apr 2013 07:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rW5OjsO2fnY7htTzI7w0EOk8D0vvWqwqYhpdOkssdfw=; b=0+0YLy2obnlo8Av7plvx22oSvn83EMqoqOxhRUEPZSyVVeTHkcLK33poL9bt4jGVjM SnpH43IfmefpFnctl7Ju/JXFNzAXSIsCmFeRBda2Mupa7dcWFw9OWN34gKeN4LcsB+38 B8EtgNFztvM8qFIyq5yeiuUqf+emNmztj17Ir0rNnjB6ajGV/26q0PczrOdmVsZVRJQJ dq0qUpl0GvRYjhfHMmv68qyoTHHHuM6N2SMLVjJmCO4uwX7HUi8Dpy26zTpT52137WLB PRmctIzYvSey8bve0/aFhTEMFXSEzoq/jVvvzkawIPMikEAxyFMl7jiOcjqAxBn6zqps esZw==
MIME-Version: 1.0
X-Received: by 10.66.76.170 with SMTP id l10mr47472772paw.190.1366986514929; Fri, 26 Apr 2013 07:28:34 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Fri, 26 Apr 2013 07:28:34 -0700 (PDT)
In-Reply-To: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>     
Date: Fri, 26 Apr 2013 15:28:34 +0100
Message-ID: 
From: Abdussalam Baryun 
To: Jiazi Yi 
Content-Type: multipart/alternative; boundary=f46d042fdb8aa2a03804db4459b1
Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 14:28:37 -0000

--f46d042fdb8aa2a03804db4459b1
Content-Type: text/plain; charset=ISO-8859-1

I agree with you, the document should state synchronization issues/concerns,

AB


On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi  wrote:

> Hi,
>
> On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
>
> > I think you missed something. Though there is a point we might have to
> consider that I'll get to.
> >
> > These are constraints on your internal parameters. Let me just consider
> the HELLO ones, obviously the TC ones are similar.
> >
> > The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to
> be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only
> makes sense for a positive age, hence the first constraint. That doesn't
> matter about synchronisation. It's actually a fairly obvious thing that
> almost doesn't need saying (but also see a bit later).
>
> Yes. I agree. If we assume "network can be synchronized with sufficient
> precision", then the value can only be positive.
> Of course, if the network is not well synchronized, a negative is possible.
>
>
> >
> > Now sticking for the moment to an assumption that we can measure the age
> of a packet/message, we want to bound how much slack we should allow. And
> that's the second constraint. (Right this moment I'm not sure why we picked
> REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either
> way.) But this is where synchronisation comes in (and why the_DIFF suffix).
> We measure the age by comparing our clock with the timestamp. If
> synchronised then that's the age, done.
>
>
> I'm just a little confused by why "assuming ideal time synchronization" is
> related to the constraints of
>
>         "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"
>
> I didn't quite get the relation here.
> What I understand is that, the "age" calculated by
>
>         local_router_time - HELLO_timestamp
>
> is only related to transmission delay of the message (if no attack
> happens).  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF),
> it is discarded.
>
>
> >
> > If there's a synchronisation error, let's suppose we received at t2, it
> claims to be sent at t1, but (based on our clock) was actually sent at
> t1+e. So our test is
> >
> > (t2 - t1) <= MAX_HELLO_TIMESTAMP_DIFF
> >
> > but the age of the message, A is t2 - t1 - e, so
> >
> > A <= MAX_HELLO_TIMESTAMP_DIFF - e
> >
> > So if we want to only reject messages that are definitely too late, we
> need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume
> e is symmetrically distributed +ve and -ve. In turn this means that we
> should allow an extra margin of e on the constraint
> MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.
> >
> > Now the point of interest. What if we receive a message with an apparent
> negative age? If that's greater than the minimum value of e (or -e) that's
> fine. But more than that? Should we reject such messages?
>
> Apparently, if the network is not synchronized, a negative age can happen.
> What I understand is that, this document won't take care of synchronization
> and related error? Because those would be another big problem to deal
> with...
>
> best
>
> Jiazi
>
> >
> > --
> > Christopher Dearlove
> > Senior Principal Engineer, Communications Group
> > Communications, Networks and Image Analysis Capability
> > BAE Systems Advanced Technology Centre
> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> > Tel: +44 1245 242194 |  Fax: +44 1245 242124
> > chris.dearlove@baesystems.com | http://www.baesystems.com
> >
> > BAE Systems (Operations) Limited
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> > Registered in England & Wales No: 1996687
> >
> >
> > -----Original Message-----
> > From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> > Sent: 24 April 2013 17:55
> > To: Dearlove, Christopher (UK)
> > Cc: manet@ietf.org
> > Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >
> > ----------------------! WARNING ! ----------------------
> > This message originates from outside our organisation,
> > either from an external partner or from the internet.
> > Keep this in mind if you answer this message.
> > Follow the 'Report Suspicious Emails' link on IT matters
> > for instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Thanks Chris for sharing your thought.
> >
> > Yes, those are all possibilities to consider. And a more fundamental
> issue I'm thinking about is the framework for securing re-active protocols,
> because it's much harder than pro-acitve ones. For example, do we want to
> require hop-by-hop authentication? Zeroing the metric field opens possible
> attack vector also... anyway, we can discuss this in other topics in the
> future.
> >
> > In the meantime, I reviewed the draft
> draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I
> would support it for WGLC.
> >
> > Just one question:
> >
> > In the draft:
> > =============
> > The following constraints apply to these parameters:
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
> >
> >   o  MAX_TC_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
> >
> >   The second and fourth of those constraints assume ideal time
> >   synchronization of the clocks in all routers in the network.
> > ======================
> >
> > My understanding is that, "the time difference equals 0" is for ideal
> time synchronization. So it should be The first and third assume ideal time
> synchronization? Or I missed something here?
> >
> > best
> >
> > Jiazi
> >
> > On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
> >
> >> Thanks for that. I'm hoping we can proceed push out 6622bis, and the
> security document.
> >>
> >> As a contribution to that future concept, I'll note that 6622(bis) is
> independent of the protocol. That I think is a desirable thing.
> >>
> >> One idea (I'm not sold on it, it's just for consideration) is that if
> you are considering that, for example, you don't want to include a metric
> in your ICV, and that metric is in TLV type X (probably a full type with
> type extension, but that's another of those details) then as a new variant
> type extension ICV, you could add something to say "remove all TLVs with
> type extensions X, Y, Z before calculating ICV). Or maybe that needs to be
> a range. Or ... but first work out exactly what you want, then how it
> cleanly generalises (where a good generalisation is easier to implement
> than the special case).
> >>
> >> --
> >> Christopher Dearlove
> >> Senior Principal Engineer, Communications Group
> >> Communications, Networks and Image Analysis Capability
> >> BAE Systems Advanced Technology Centre
> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>
> >> BAE Systems (Operations) Limited
> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> >> Registered in England & Wales No: 1996687
> >>
> >>
> >> -----Original Message-----
> >> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> >> Sent: 24 April 2013 17:12
> >> To: Dearlove, Christopher (UK)
> >> Cc: manet@ietf.org
> >> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >>
> >> ----------------------! WARNING ! ----------------------
> >> This message originates from outside our organisation,
> >> either from an external partner or from the internet.
> >> Keep this in mind if you answer this message.
> >> Follow the 'Report Suspicious Emails' link on IT matters
> >> for instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> Hi,
> >>
> >> After several mail exchange with some of the other authors, I think it
> would be better to keep the draft as it is on the mutable fields, because
> how to define/use protocol-specific mutable fields is not very clear at
> this point.
> >> If necessary, it would probably be better to put them in another
> document, after we figuring out exactly how to handle those fields.
> >>
> >> best
> >>
> >> Jiazi
> >>
> >> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
> >>
> >>> Chris,
> >>>
> >>> I do understand your concern. We had this kind of discussion on
> mutable fields before, and this is something I'm still mulling over.
> >>> The reason why I propose this for discussion is:
> >>>
> >>>     - this rfc6622bis is for rfc5444, which is a general format for
> all manet protocols.
> >>>     - The reactive protocol like LOADng does explicitly define such
> "mutable" fields. It is something at hand, not in the far future.
> >>>
> >>> In the meantime, I do agree that the necessity and how to take care of
> such mutable fields should be considered carefully.
> >>> So I would agree that we keep the current rfc6622bis draft as it is
> for the moment, and I'll have more discussions with other LOADng authors on
> this.
> >>>
> >>> best
> >>>
> >>> Jiazi
> >>>
> >>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
> >>>
> >>>> Jiazi
> >>>>
> >>>> Thanks for that, I'll just comment on the one point where I disagree.
> >>>>
> >>>> Putting some vague words in that protocols may indicate fields not to
> be covered is the sort of thing that I can predict will cause us problems
> at the IESG. And it's not really a good plan for a generic mechanism that
> can - at at present - be run independently of the routing protocol to
> acquire a protocol dependence. Rather I think that any routing protocols
> with a specific need to exclude data (which, all else being equal is a bad
> thing of course) should consider defining a new type extension - preferably
> one defined with some generic capability (could it, for example, list TLV
> types to be excluded?) But that's for the future. One thing I have learned
> is that design in advance of what might hypothetically be needed generally
> gets it wrong, so it would be good to wait until exactly what's needed is
> clear, and then define a new case.
> >>>>
> >>>> Christopher
> >>>>
> >>>> --
> >>>> Christopher Dearlove
> >>>> Senior Principal Engineer, Communications Group
> >>>> Communications, Networks and Image Analysis Capability
> >>>> BAE Systems Advanced Technology Centre
> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>>>
> >>>> BAE Systems (Operations) Limited
> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> >>>> Registered in England & Wales No: 1996687
> >>>>
> >>>> -----Original Message-----
> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On
> Behalf Of ietf@jiaziyi.com
> >>>> Sent: 23 April 2013 15:37
> >>>> To: manet@ietf.org
> >>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >>>>
> >>>> ----------------------! WARNING ! ----------------------
> >>>> This message originates from outside our organisation,
> >>>> either from an external partner or from the internet.
> >>>> Keep this in mind if you answer this message.
> >>>> Follow the 'Report Suspicious Emails' link on IT matters
> >>>> for instructions on reporting suspicious email messages.
> >>>> --------------------------------------------------------
> >>>>
> >>>> (sorry if you receive duplicate of this message. Some of my mails to
> >>>> the mailing list are rejected, and I'm trying to figure out with our
> >>>> secretary...)
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had a review of the draft. I think it's in good shape, and ready for
> >>>> WGLC.
> >>>>
> >>>> a few comments:
> >>>>
> >>>> In section 6 & 7, I didn't find the definition of notation
> >>>>    +
> >>>> Not in this draft, either rfc 5444.
> >>>>
> >>>> page 13,  source code address ==> source node address?
> >>>>
> >>>> section 9.1 bullet 1 states that the  and
> >>>>  must be zeroed before calculating ICV. I'm thinking
> >>>> about that we might need to mention that some protocol-specific
> mutable
> >>>> fields must be zeroed here also. For example, in LOADng, as a reactive
> >>>> protocol, metric fields are defined as "mutable" (in the meantime, I
> >>>> still have some thoughts on those mutable fields that I need to
> discuss
> >>>> with other LOADng authors, but it's not that relevant here).
> >>>>
> >>>> best
> >>>>
> >>>> Jiazi
> >>>>
> >>>>
> >>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
> >>>>
> >>>>
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>>> directories.
> >>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
> >>>> of the IETF.
> >>>>
> >>>>    Title           : Integrity Check Value and Timestamp TLV
> Definitions
> >>>> for Mobile Ad Hoc Networks (MANETs)
> >>>>    Author(s)       : Ulrich Herberg
> >>>>                      Thomas Heide Clausen
> >>>>                      Christopher Dearlove
> >>>>    Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> >>>>    Pages           : 24
> >>>>    Date            : 2013-04-15
> >>>>
> >>>> Abstract:
> >>>> This document revises, extends and replaces RFC 6622.  It describes
> >>>> general and flexible TLVs for representing cryptographic Integrity
> >>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
> >>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
> >>>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
> >>>> for affixing ICVs and timestamps to a packet, a message, and one or
> >>>> more addresses, respectively.
> >>>>
> >>>>
> >>>> The IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
> >>>>
> >>>> There's also a htmlized version available at:
> >>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>> A diff from the previous version is available at:
> >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>>
> >>>> ********************************************************************
> >>>> This email and any attachments are confidential to the intended
> >>>> recipient and may also be privileged. If you are not the intended
> >>>> recipient please delete it from your system and notify the sender.
> >>>> You should not copy it or use it for any purpose nor disclose or
> >>>> distribute its contents to any other person.
> >>>> ********************************************************************
> >>>>
> >>>
> >>
> >>
> >
> >
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--f46d042fdb8aa2a03804db4459b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I agree with you, the document should state synchroni=
zation issues/concerns,
=A0
AB


On Fri, Apr 26, 2013 at 1:=
10 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:


Hi,




On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co=
m> wrote:



> I think you missed something. Though there is a point we might have to=
 consider that I'll get to.

>

> These are constraints on your internal parameters. Let me just conside=
r the HELLO ones, obviously the TC ones are similar.

>

> The basic use of MAX_HELLO_TIMESTAMP_DIFF is =A0"if the message a=
ppears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obvi=
ously that only makes sense for a positive age, hence the first constraint.=
 That doesn't matter about synchronisation. It's actually a fairly =
obvious thing that almost doesn't need saying (but also see a bit later=
).





Yes. I agree. If we assume "network can be synchronized with suf=
ficient precision", then the value can only be positive.

Of course, if the network is not well synchronized, a negative is possible.=







>

> Now sticking for the moment to an assumption that we can measure the a=
ge of a packet/message, we want to bound how much slack we should allow. An=
d that's the second constraint. (Right this moment I'm not sure why=
 we picked REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually wor=
ks either way.) But this is where synchronisation comes in (and why the_DIF=
F suffix). We measure the age by comparing our clock with the timestamp. If=
 synchronised then that's the age, done.







I'm just a little confused by why "assuming ideal time synch=
ronization" is related to the constraints of



=A0 =A0 =A0 =A0 "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"<=
br>


I didn't quite get the relation here.

What I understand is that, the "age" calculated by



=A0 =A0 =A0 =A0 local_router_time - HELLO_timestamp



is only related to transmission delay of the message (if no attack happens)=
. =A0When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_=
DIFF), it is discarded.






>

> If there's a synchronisation error, let's suppose we received =
at t2, it claims to be sent at t1, but (based on our clock) was actually se=
nt at t1+e. So our test is

>

> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF

>

> but the age of the message, A is t2 - t1 - e, so

>

> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e

>

> So if we want to only reject messages that are definitely too late, we=
 need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assum=
e e is symmetrically distributed +ve and -ve. In turn this means that we sh=
ould allow an extra margin of e on the constraint MAX_HELLO_TIMESTAMP_DIFF =
< REFRESH_INTERVAL.


>

> Now the point of interest. What if we receive a message with an appare=
nt negative age? If that's greater than the minimum value of e (or -e) =
that's fine. But more than that? Should we reject such messages?





Apparently, if the network is not synchronized, a negative age can ha=
ppen. What I understand is that, this document won't take care of synch=
ronization and related error? Because those would be another big problem to=
 deal with...




best



Jiazi




>

> --

> Christopher Dearlove

> Senior Principal Engineer, Communications Group

> Communications, Networks and Image Analysis Capability

> BAE Systems Advanced Technology Centre

> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

> Tel: +44=
 1245 242194 | =A0Fax: +44 1245 242124

> chris.dearlove@baesys=
tems.com | http=
://www.baesystems.com

>

> BAE Systems (Operations) Limited

> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK

> Registered in England & Wales No: 1996687

>

>

> -----Original Message-----

> From: Jiazi Yi [mailto:yi.jiazi@=
gmail.com]

> Sent: 24 April 2013 17:55

> To: Dearlove, Christopher (UK)

> Cc: manet@ietf.org

> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>

> ----------------------! WARNING ! ----------------------

> This message originates from outside our organisation,

> either from an external partner or from the internet.

> Keep this in mind if you answer this message.

> Follow the 'Report Suspicious Emails' link on IT matters

> for instructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Thanks Chris for sharing your thought.

>

> Yes, those are all possibilities to consider. And a more fundamental i=
ssue I'm thinking about is the framework for securing re-active protoco=
ls, because it's much harder than pro-acitve ones. For example, do we w=
ant to require hop-by-hop authentication? Zeroing the metric field opens po=
ssible attack vector also... anyway, we can discuss this in other topics in=
 the future.


>

> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec=
-02, and I think it is fairly clear. I would support it for WGLC.

>

> Just one question:

>

> In the draft:

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> The following constraints apply to these parameters:

>

> =A0 o =A0MAX_HELLO_TIMESTAMP_DIFF > 0

>

> =A0 o =A0MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

>

> =A0 o =A0MAX_TC_TIMESTAMP_DIFF > 0

>

> =A0 o =A0MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

>

> =A0 The second and fourth of those constraints assume ideal time

> =A0 synchronization of the clocks in all routers in the network.

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> My understanding is that, "the time difference equals 0" is =
for ideal time synchronization. So it should be The first and third assume =
ideal time synchronization? Or I missed something here?

>

> best

>

> Jiazi

>

> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" &l=
t;Chris.Dearlove@baesystem=
s.com> wrote:

>

>> Thanks for that. I'm hoping we can proceed push out 6622bis, a=
nd the security document.

>>

>> As a contribution to that future concept, I'll note that 6622(=
bis) is independent of the protocol. That I think is a desirable thing.

>>

>> One idea (I'm not sold on it, it's just for consideration)=
 is that if you are considering that, for example, you don't want to in=
clude a metric in your ICV, and that metric is in TLV type X (probably a fu=
ll type with type extension, but that's another of those details) then =
as a new variant type extension ICV, you could add something to say "r=
emove all TLVs with type extensions X, Y, Z before calculating ICV). Or may=
be that needs to be a range. Or ... but first work out exactly what you wan=
t, then how it cleanly generalises (where a good generalisation is easier t=
o implement than the special case).


>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer, Communications Group

>> Communications, Networks and Image Analysis Capability

>> BAE Systems Advanced Technology Centre

>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124

>> chris.dearlove@ba=
esystems.com | =
http://www.baesystems.com

>>

>> BAE Systems (Operations) Limited

>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=
 Centre, Farnborough, Hants, GU14 6YU, UK

>> Registered in England & Wales No: 1996687

>>

>>

>> -----Original Message-----

>> From: Jiazi Yi [mailto:yi.ji=
azi@gmail.com]

>> Sent: 24 April 2013 17:12

>> To: Dearlove, Christopher (UK)

>> Cc: manet@ietf.org

>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.t=
xt

>>

>> ----------------------! WARNING ! ----------------------

>> This message originates from outside our organisation,

>> either from an external partner or from the internet.

>> Keep this in mind if you answer this message.

>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> Hi,

>>

>> After several mail exchange with some of the other authors, I thin=
k it would be better to keep the draft as it is on the mutable fields, beca=
use how to define/use protocol-specific mutable fields is not very clear at=
 this point.


>> If necessary, it would probably be better to put them in another d=
ocument, after we figuring out exactly how to handle those fields.

>>

>> best

>>

>> Jiazi

>>

>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:

>>

>>> Chris,

>>>

>>> I do understand your concern. We had this kind of discussion o=
n mutable fields before, and this is something I'm still mulling over.<=
br>
>>> The reason why I propose this for discussion is:

>>>

>>> =A0 =A0 - this rfc6622bis is for rfc5444, which is a general f=
ormat for all manet protocols.

>>> =A0 =A0 - The reactive protocol like LOADng does explicitly de=
fine such "mutable" fields. It is something at hand, not in the f=
ar future.

>>>

>>> In the meantime, I do agree that the necessity and how to take=
 care of such mutable fields should be considered carefully.

>>> So I would agree that we keep the current rfc6622bis draft as =
it is for the moment, and I'll have more discussions with other LOADng =
authors on this.

>>>

>>> best

>>>

>>> Jiazi

>>>

>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)=
" <Chris.Dearlove@=
baesystems.com> wrote:

>>>

>>>> Jiazi

>>>>

>>>> Thanks for that, I'll just comment on the one point wh=
ere I disagree.

>>>>

>>>> Putting some vague words in that protocols may indicate fi=
elds not to be covered is the sort of thing that I can predict will cause u=
s problems at the IESG. And it's not really a good plan for a generic m=
echanism that can - at at present - be run independently of the routing pro=
tocol to acquire a protocol dependence. Rather I think that any routing pro=
tocols with a specific need to exclude data (which, all else being equal is=
 a bad thing of course) should consider defining a new type extension - pre=
ferably one defined with some generic capability (could it, for example, li=
st TLV types to be excluded?) But that's for the future. One thing I ha=
ve learned is that design in advance of what might hypothetically be needed=
 generally gets it wrong, so it would be good to wait until exactly what=
9;s needed is clear, and then define a new case.


>>>>

>>>> Christopher

>>>>

>>>> --

>>>> Christopher Dearlove

>>>> Senior Principal Engineer, Communications Group

>>>> Communications, Networks and Image Analysis Capability

>>>> BAE Systems Advanced Technology Centre

>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,=
 UK

>>>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124

>>>> chris.dea=
rlove@baesystems.com | http://www.baesystems.com

>>>>

>>>> BAE Systems (Operations) Limited

>>>> Registered Office: Warwick House, PO Box 87, Farnborough A=
erospace Centre, Farnborough, Hants, GU14 6YU, UK

>>>> Registered in England & Wales No: 1996687

>>>>

>>>> -----Original Message-----

>>>> From: manet-boun=
ces@ietf.org [mailto:manet-bo=
unces@ietf.org] On Behalf Of ietf@j=
iaziyi.com


>>>> Sent: 23 April 2013 15:37

>>>> To: manet@ietf.org
>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>>

>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,

>>>> either from an external partner or from the internet.

>>>> Keep this in mind if you answer this message.

>>>> Follow the 'Report Suspicious Emails' link on IT m=
atters

>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>

>>>> (sorry if you receive duplicate of this message. Some of m=
y mails to

>>>> the mailing list are rejected, and I'm trying to figur=
e out with our

>>>> secretary...)

>>>>

>>>> Hi,

>>>>

>>>> I had a review of the draft. I think it's in good shap=
e, and ready for

>>>> WGLC.

>>>>

>>>> a few comments:

>>>>

>>>> In section 6 & 7, I didn't find the definition of =
notation

>>>> =A0 =A0<foo>+

>>>> Not in this draft, either rfc 5444.

>>>>

>>>> page 13, =A0source code address =3D=3D> source node add=
ress?

>>>>

>>>> section 9.1 bullet 1 states that the <msg-hop-limit>=
 and

>>>> <msg-hop-count> must be zeroed before calculating IC=
V. I'm thinking

>>>> about that we might need to mention that some protocol-spe=
cific mutable

>>>> fields must be zeroed here also. For example, in LOADng, a=
s a reactive

>>>> protocol, metric fields are defined as "mutable"=
 (in the meantime, I

>>>> still have some thoughts on those mutable fields that I ne=
ed to discuss

>>>> with other LOADng authors, but it's not that relevant =
here).

>>>>

>>>> best

>>>>

>>>> Jiazi

>>>>

>>>>

>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:

>>>>

>>>>

>>>> A New Internet-Draft is available from the on-line Interne=
t-Drafts

>>>> directories.

>>>> This draft is a work item of the Mobile Ad-hoc Networks Wo=
rking Group

>>>> of the IETF.

>>>>

>>>> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Integrity Check Value a=
nd Timestamp TLV Definitions

>>>> for Mobile Ad Hoc Networks (MANETs)

>>>> =A0 =A0Author(s) =A0 =A0 =A0 : Ulrich Herberg

>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Cl=
ausen

>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christopher Dea=
rlove

>>>> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 24

>>>> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-15

>>>>

>>>> Abstract:

>>>> This document revises, extends and replaces RFC 6622. =A0I=
t describes

>>>> general and flexible TLVs for representing cryptographic I=
ntegrity

>>>> Check Values (ICVs) and timestamps, using the generalized =
Mobile Ad

>>>> Hoc Network (MANET) packet/message format defined in RFC 5=
444. =A0It

>>>> defines two Packet TLVs, two Message TLVs, and two Address=
 Block TLVs

>>>> for affixing ICVs and timestamps to a packet, a message, a=
nd one or

>>>> more addresses, respectively.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> https://datatracker.ietf.org/doc/draft-ie=
tf-manet-rfc6622-bis

>>>>

>>>> There's also a htmlized version available at:

>>>> http://tools.ietf.org/html/draft-ietf-manet-=
rfc6622-bis-02

>>>>

>>>> A diff from the previous version is available at:

>>>> http://www.ietf.org/rfcdiff?url2=3Dd=
raft-ietf-manet-rfc6622-bis-02

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

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

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

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

>>>>

>>>>

>>>> **********************************************************=
**********

>>>> This email and any attachments are confidential to the int=
ended

>>>> recipient and may also be privileged. If you are not the i=
ntended

>>>> recipient please delete it from your system and notify the=
 sender.

>>>> You should not copy it or use it for any purpose nor discl=
ose or

>>>> distribute its contents to any other person.

>>>> **********************************************************=
**********

>>>>

>>>

>>

>>

>

>



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--f46d042fdb8aa2a03804db4459b1--

From yi.jiazi@gmail.com  Fri Apr 26 07:39:57 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9921F99EB for ; Fri, 26 Apr 2013 07:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IZwbVCmQo90 for ; Fri, 26 Apr 2013 07:39:56 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0956A21F99E9 for ; Fri, 26 Apr 2013 07:39:55 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id h11so697406wiv.14 for ; Fri, 26 Apr 2013 07:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=FGoL7btbx2fiMFfjYnqRwdC489+/2O/Sg0Q8k238TG0=; b=WhcgFA0NIAoeyvVCpCG0aSh1zV0Wp7TrBLU4ToeAjo2jHwwwkWd/ltNVe99bsMczSU eV7fSoufM4p/nhiXumOK6Vf5ZLUaSJgfwJmSVmpcZ6YKOu7TBDUyn9zYeQMT+wkGrqtx NTdbk1R+OQ9vpnYEtQW1ApRCNcydnwm45OJ9RxeZ7lTQjsnNpl1TdSl5zVM8dFOL8aR7 Bp18n3MHeuP7ZLQanSOusdRa5F6d+304M/3lp+ljg7pnwiWA503/X1CuvJNhwVnxyQwH FaSbRAXq13ylhBCUvFtxkk6gjmSs8nv0Ak0auV9H/iwA/2i2ynksqVXwrc51sjqqiQmY XrdQ==
X-Received: by 10.180.72.227 with SMTP id g3mr3169218wiv.1.1366987189761; Fri, 26 Apr 2013 07:39:49 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPSA id s6sm3901295wij.4.2013.04.26.07.39.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 07:39:48 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jiazi Yi 
In-Reply-To: 
Date: Fri, 26 Apr 2013 16:39:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>      
To: Abdussalam Baryun 
X-Mailer: Apple Mail (2.1503)
Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 14:39:58 -0000

I didn't say that this document should state sync issues.=20
This document assumes that clock is synchronised. How to synchronise =
would be out the scope of this document.=20

best

Jiazi

On Apr 26, 2013, at 4:28 PM, Abdussalam Baryun =
 wrote:

> I agree with you, the document should state synchronization =
issues/concerns,
> =20
> AB
>=20
>=20
> On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi  wrote:
> Hi,
>=20
> On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" =
 wrote:
>=20
> > I think you missed something. Though there is a point we might have =
to consider that I'll get to.
> >
> > These are constraints on your internal parameters. Let me just =
consider the HELLO ones, obviously the TC ones are similar.
> >
> > The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message =
appears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". =
Obviously that only makes sense for a positive age, hence the first =
constraint. That doesn't matter about synchronisation. It's actually a =
fairly obvious thing that almost doesn't need saying (but also see a bit =
later).
>=20
> Yes. I agree. If we assume "network can be synchronized with =
sufficient precision", then the value can only be positive.
> Of course, if the network is not well synchronized, a negative is =
possible.
>=20
>=20
> >
> > Now sticking for the moment to an assumption that we can measure the =
age of a packet/message, we want to bound how much slack we should =
allow. And that's the second constraint. (Right this moment I'm not sure =
why we picked REFRESH_INTERVAL rather than HELLO_INTERVAL, but it =
actually works either way.) But this is where synchronisation comes in =
(and why the_DIFF suffix). We measure the age by comparing our clock =
with the timestamp. If synchronised then that's the age, done.
>=20
>=20
> I'm just a little confused by why "assuming ideal time =
synchronization" is related to the constraints of
>=20
>         "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"
>=20
> I didn't quite get the relation here.
> What I understand is that, the "age" calculated by
>=20
>         local_router_time - HELLO_timestamp
>=20
> is only related to transmission delay of the message (if no attack =
happens).  When it is regarded "too old" (age > =
MAX_HELLO_TIMESTAMP_DIFF), it is discarded.
>=20
>=20
> >
> > If there's a synchronisation error, let's suppose we received at t2, =
it claims to be sent at t1, but (based on our clock) was actually sent =
at t1+e. So our test is
> >
> > (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF
> >
> > but the age of the message, A is t2 - t1 - e, so
> >
> > A <=3D MAX_HELLO_TIMESTAMP_DIFF - e
> >
> > So if we want to only reject messages that are definitely too late, =
we need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e =
(assume e is symmetrically distributed +ve and -ve. In turn this means =
that we should allow an extra margin of e on the constraint =
MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.
> >
> > Now the point of interest. What if we receive a message with an =
apparent negative age? If that's greater than the minimum value of e (or =
-e) that's fine. But more than that? Should we reject such messages?
>=20
> Apparently, if the network is not synchronized, a negative age can =
happen. What I understand is that, this document won't take care of =
synchronization and related error? Because those would be another big =
problem to deal with...
>=20
> best
>=20
> Jiazi
>=20
> >
> > --
> > Christopher Dearlove
> > Senior Principal Engineer, Communications Group
> > Communications, Networks and Image Analysis Capability
> > BAE Systems Advanced Technology Centre
> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> > Tel: +44 1245 242194 |  Fax: +44 1245 242124
> > chris.dearlove@baesystems.com | http://www.baesystems.com
> >
> > BAE Systems (Operations) Limited
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
> > Registered in England & Wales No: 1996687
> >
> >
> > -----Original Message-----
> > From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> > Sent: 24 April 2013 17:55
> > To: Dearlove, Christopher (UK)
> > Cc: manet@ietf.org
> > Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >
> > ----------------------! WARNING ! ----------------------
> > This message originates from outside our organisation,
> > either from an external partner or from the internet.
> > Keep this in mind if you answer this message.
> > Follow the 'Report Suspicious Emails' link on IT matters
> > for instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Thanks Chris for sharing your thought.
> >
> > Yes, those are all possibilities to consider. And a more fundamental =
issue I'm thinking about is the framework for securing re-active =
protocols, because it's much harder than pro-acitve ones. For example, =
do we want to require hop-by-hop authentication? Zeroing the metric =
field opens possible attack vector also... anyway, we can discuss this =
in other topics in the future.
> >
> > In the meantime, I reviewed the draft =
draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I =
would support it for WGLC.
> >
> > Just one question:
> >
> > In the draft:
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > The following constraints apply to these parameters:
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
> >
> >   o  MAX_TC_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
> >
> >   The second and fourth of those constraints assume ideal time
> >   synchronization of the clocks in all routers in the network.
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > My understanding is that, "the time difference equals 0" is for =
ideal time synchronization. So it should be The first and third assume =
ideal time synchronization? Or I missed something here?
> >
> > best
> >
> > Jiazi
> >
> > On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" =
 wrote:
> >
> >> Thanks for that. I'm hoping we can proceed push out 6622bis, and =
the security document.
> >>
> >> As a contribution to that future concept, I'll note that 6622(bis) =
is independent of the protocol. That I think is a desirable thing.
> >>
> >> One idea (I'm not sold on it, it's just for consideration) is that =
if you are considering that, for example, you don't want to include a =
metric in your ICV, and that metric is in TLV type X (probably a full =
type with type extension, but that's another of those details) then as a =
new variant type extension ICV, you could add something to say "remove =
all TLVs with type extensions X, Y, Z before calculating ICV). Or maybe =
that needs to be a range. Or ... but first work out exactly what you =
want, then how it cleanly generalises (where a good generalisation is =
easier to implement than the special case).
> >>
> >> --
> >> Christopher Dearlove
> >> Senior Principal Engineer, Communications Group
> >> Communications, Networks and Image Analysis Capability
> >> BAE Systems Advanced Technology Centre
> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>
> >> BAE Systems (Operations) Limited
> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =
Centre, Farnborough, Hants, GU14 6YU, UK
> >> Registered in England & Wales No: 1996687
> >>
> >>
> >> -----Original Message-----
> >> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> >> Sent: 24 April 2013 17:12
> >> To: Dearlove, Christopher (UK)
> >> Cc: manet@ietf.org
> >> Subject: Re: [manet] I-D Action: =
draft-ietf-manet-rfc6622-bis-02.txt
> >>
> >> ----------------------! WARNING ! ----------------------
> >> This message originates from outside our organisation,
> >> either from an external partner or from the internet.
> >> Keep this in mind if you answer this message.
> >> Follow the 'Report Suspicious Emails' link on IT matters
> >> for instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> Hi,
> >>
> >> After several mail exchange with some of the other authors, I think =
it would be better to keep the draft as it is on the mutable fields, =
because how to define/use protocol-specific mutable fields is not very =
clear at this point.
> >> If necessary, it would probably be better to put them in another =
document, after we figuring out exactly how to handle those fields.
> >>
> >> best
> >>
> >> Jiazi
> >>
> >> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
> >>
> >>> Chris,
> >>>
> >>> I do understand your concern. We had this kind of discussion on =
mutable fields before, and this is something I'm still mulling over.
> >>> The reason why I propose this for discussion is:
> >>>
> >>>     - this rfc6622bis is for rfc5444, which is a general format =
for all manet protocols.
> >>>     - The reactive protocol like LOADng does explicitly define =
such "mutable" fields. It is something at hand, not in the far future.
> >>>
> >>> In the meantime, I do agree that the necessity and how to take =
care of such mutable fields should be considered carefully.
> >>> So I would agree that we keep the current rfc6622bis draft as it =
is for the moment, and I'll have more discussions with other LOADng =
authors on this.
> >>>
> >>> best
> >>>
> >>> Jiazi
> >>>
> >>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" =
 wrote:
> >>>
> >>>> Jiazi
> >>>>
> >>>> Thanks for that, I'll just comment on the one point where I =
disagree.
> >>>>
> >>>> Putting some vague words in that protocols may indicate fields =
not to be covered is the sort of thing that I can predict will cause us =
problems at the IESG. And it's not really a good plan for a generic =
mechanism that can - at at present - be run independently of the routing =
protocol to acquire a protocol dependence. Rather I think that any =
routing protocols with a specific need to exclude data (which, all else =
being equal is a bad thing of course) should consider defining a new =
type extension - preferably one defined with some generic capability =
(could it, for example, list TLV types to be excluded?) But that's for =
the future. One thing I have learned is that design in advance of what =
might hypothetically be needed generally gets it wrong, so it would be =
good to wait until exactly what's needed is clear, and then define a new =
case.
> >>>>
> >>>> Christopher
> >>>>
> >>>> --
> >>>> Christopher Dearlove
> >>>> Senior Principal Engineer, Communications Group
> >>>> Communications, Networks and Image Analysis Capability
> >>>> BAE Systems Advanced Technology Centre
> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>>>
> >>>> BAE Systems (Operations) Limited
> >>>> Registered Office: Warwick House, PO Box 87, Farnborough =
Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> >>>> Registered in England & Wales No: 1996687
> >>>>
> >>>> -----Original Message-----
> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =
Behalf Of ietf@jiaziyi.com
> >>>> Sent: 23 April 2013 15:37
> >>>> To: manet@ietf.org
> >>>> Subject: Re: [manet] I-D Action: =
draft-ietf-manet-rfc6622-bis-02.txt
> >>>>
> >>>> ----------------------! WARNING ! ----------------------
> >>>> This message originates from outside our organisation,
> >>>> either from an external partner or from the internet.
> >>>> Keep this in mind if you answer this message.
> >>>> Follow the 'Report Suspicious Emails' link on IT matters
> >>>> for instructions on reporting suspicious email messages.
> >>>> --------------------------------------------------------
> >>>>
> >>>> (sorry if you receive duplicate of this message. Some of my mails =
to
> >>>> the mailing list are rejected, and I'm trying to figure out with =
our
> >>>> secretary...)
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had a review of the draft. I think it's in good shape, and =
ready for
> >>>> WGLC.
> >>>>
> >>>> a few comments:
> >>>>
> >>>> In section 6 & 7, I didn't find the definition of notation
> >>>>    +
> >>>> Not in this draft, either rfc 5444.
> >>>>
> >>>> page 13,  source code address =3D=3D> source node address?
> >>>>
> >>>> section 9.1 bullet 1 states that the  and
> >>>>  must be zeroed before calculating ICV. I'm =
thinking
> >>>> about that we might need to mention that some protocol-specific =
mutable
> >>>> fields must be zeroed here also. For example, in LOADng, as a =
reactive
> >>>> protocol, metric fields are defined as "mutable" (in the =
meantime, I
> >>>> still have some thoughts on those mutable fields that I need to =
discuss
> >>>> with other LOADng authors, but it's not that relevant here).
> >>>>
> >>>> best
> >>>>
> >>>> Jiazi
> >>>>
> >>>>
> >>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
> >>>>
> >>>>
> >>>> A New Internet-Draft is available from the on-line =
Internet-Drafts
> >>>> directories.
> >>>> This draft is a work item of the Mobile Ad-hoc Networks Working =
Group
> >>>> of the IETF.
> >>>>
> >>>>    Title           : Integrity Check Value and Timestamp TLV =
Definitions
> >>>> for Mobile Ad Hoc Networks (MANETs)
> >>>>    Author(s)       : Ulrich Herberg
> >>>>                      Thomas Heide Clausen
> >>>>                      Christopher Dearlove
> >>>>    Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> >>>>    Pages           : 24
> >>>>    Date            : 2013-04-15
> >>>>
> >>>> Abstract:
> >>>> This document revises, extends and replaces RFC 6622.  It =
describes
> >>>> general and flexible TLVs for representing cryptographic =
Integrity
> >>>> Check Values (ICVs) and timestamps, using the generalized Mobile =
Ad
> >>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  =
It
> >>>> defines two Packet TLVs, two Message TLVs, and two Address Block =
TLVs
> >>>> for affixing ICVs and timestamps to a packet, a message, and one =
or
> >>>> more addresses, respectively.
> >>>>
> >>>>
> >>>> The IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
> >>>>
> >>>> There's also a htmlized version available at:
> >>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>> A diff from the previous version is available at:
> >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>>
> >>>> =
********************************************************************
> >>>> This email and any attachments are confidential to the intended
> >>>> recipient and may also be privileged. If you are not the intended
> >>>> recipient please delete it from your system and notify the =
sender.
> >>>> You should not copy it or use it for any purpose nor disclose or
> >>>> distribute its contents to any other person.
> >>>> =
********************************************************************
> >>>>
> >>>
> >>
> >>
> >
> >
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>=20


From Chris.Dearlove@baesystems.com  Fri Apr 26 07:40:31 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FFC21F9A02 for ; Fri, 26 Apr 2013 07:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfkjF2OtB4YI for ; Fri, 26 Apr 2013 07:40:29 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 98EE021F9A01 for ; Fri, 26 Apr 2013 07:40:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,559,1363132800";  d="scan'208,217";a="332553163"
Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2013 15:40:26 +0100
Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QEeQEw024803 for ; Fri, 26 Apr 2013 15:40:26 +0100
X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208,217";a="14575318"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 26 Apr 2013 15:40:26 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 15:40:26 +0100
From: "Dearlove, Christopher (UK)" 
To: Abdussalam Baryun , Jiazi Yi 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAAmhgCAABDsQA==
Date: Fri, 26 Apr 2013 14:40:25 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>      
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065129GLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 14:40:31 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065129GLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I don't believe that is what Jiazi said. Furthermore the document already d=
iscusses synchronization issues, from the need to relax constraints if sync=
hronisation is not possible, to a note in the Limitations section about wha=
t to do if synchronisation is not possible.

The actual nit here is nothing to do with synchronisation issues, but which=
 parameters to use as suggested bounds when synchronisation is ideal. I thi=
nk the choice should be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b)=
 H_HOLD_TIME and T_HOLD_TIME. In case (a) we should drop the "significantly=
 less" caveat. Note that what we are actually saying is that the parameter =
is greater than is how long the message might take to arrive, but we don't =
have that, we just have the indicated parameters. (A sophisticated implemen=
tation could choose to use the sender's versions of these read from INTERVA=
L_TIME and VALIDITY_TIME TLVs. But really, as this is guidance, it's not cr=
itical.)

Preferences: (a) or (b)? - We can put this in with other nits found.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 26 April 2013 15:29
To: Jiazi Yi
Cc: Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
I agree with you, the document should state synchronization issues/concerns=
,

AB

On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi > wrote:
Hi,

On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" > wrote:

> I think you missed something. Though there is a point we might have to co=
nsider that I'll get to.
>
> These are constraints on your internal parameters. Let me just consider t=
he HELLO ones, obviously the TC ones are similar.
>
> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to =
be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only=
 makes sense for a positive age, hence the first constraint. That doesn't m=
atter about synchronisation. It's actually a fairly obvious thing that almo=
st doesn't need saying (but also see a bit later).
Yes. I agree. If we assume "network can be synchronized with sufficient pre=
cision", then the value can only be positive.
Of course, if the network is not well synchronized, a negative is possible.


>
> Now sticking for the moment to an assumption that we can measure the age =
of a packet/message, we want to bound how much slack we should allow. And t=
hat's the second constraint. (Right this moment I'm not sure why we picked =
REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either w=
ay.) But this is where synchronisation comes in (and why the_DIFF suffix). =
We measure the age by comparing our clock with the timestamp. If synchronis=
ed then that's the age, done.

I'm just a little confused by why "assuming ideal time synchronization" is =
related to the constraints of

        "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"

I didn't quite get the relation here.
What I understand is that, the "age" calculated by

        local_router_time - HELLO_timestamp

is only related to transmission delay of the message (if no attack happens)=
.  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF), it is di=
scarded.


>
> If there's a synchronisation error, let's suppose we received at t2, it c=
laims to be sent at t1, but (based on our clock) was actually sent at t1+e.=
 So our test is
>
> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF
>
> but the age of the message, A is t2 - t1 - e, so
>
> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e
>
> So if we want to only reject messages that are definitely too late, we ne=
ed to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume e=
 is symmetrically distributed +ve and -ve. In turn this means that we shoul=
d allow an extra margin of e on the constraint MAX_HELLO_TIMESTAMP_DIFF < R=
EFRESH_INTERVAL.
>
> Now the point of interest. What if we receive a message with an apparent =
negative age? If that's greater than the minimum value of e (or -e) that's =
fine. But more than that? Should we reject such messages?
Apparently, if the network is not synchronized, a negative age can happen. =
What I understand is that, this document won't take care of synchronization=
 and related error? Because those would be another big problem to deal with=
...

best

Jiazi

>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | htt=
p://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre=
, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> Sent: 24 April 2013 17:55
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> Thanks Chris for sharing your thought.
>
> Yes, those are all possibilities to consider. And a more fundamental issu=
e I'm thinking about is the framework for securing re-active protocols, bec=
ause it's much harder than pro-acitve ones. For example, do we want to requ=
ire hop-by-hop authentication? Zeroing the metric field opens possible atta=
ck vector also... anyway, we can discuss this in other topics in the future=
.
>
> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec-02=
, and I think it is fairly clear. I would support it for WGLC.
>
> Just one question:
>
> In the draft:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The following constraints apply to these parameters:
>
>   o  MAX_HELLO_TIMESTAMP_DIFF > 0
>
>   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
>
>   o  MAX_TC_TIMESTAMP_DIFF > 0
>
>   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
>
>   The second and fourth of those constraints assume ideal time
>   synchronization of the clocks in all routers in the network.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> My understanding is that, "the time difference equals 0" is for ideal tim=
e synchronization. So it should be The first and third assume ideal time sy=
nchronization? Or I missed something here?
>
> best
>
> Jiazi
>
> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" > wrote:
>
>> Thanks for that. I'm hoping we can proceed push out 6622bis, and the sec=
urity document.
>>
>> As a contribution to that future concept, I'll note that 6622(bis) is in=
dependent of the protocol. That I think is a desirable thing.
>>
>> One idea (I'm not sold on it, it's just for consideration) is that if yo=
u are considering that, for example, you don't want to include a metric in =
your ICV, and that metric is in TLV type X (probably a full type with type =
extension, but that's another of those details) then as a new variant type =
extension ICV, you could add something to say "remove all TLVs with type ex=
tensions X, Y, Z before calculating ICV). Or maybe that needs to be a range=
. Or ... but first work out exactly what you want, then how it cleanly gene=
ralises (where a good generalisation is easier to implement than the specia=
l case).
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
tel:%2B44%201245%20242124>
>> chris.dearlove@baesystems.com | ht=
tp://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr=
e, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
>> Sent: 24 April 2013 17:12
>> To: Dearlove, Christopher (UK)
>> Cc: manet@ietf.org
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> Hi,
>>
>> After several mail exchange with some of the other authors, I think it w=
ould be better to keep the draft as it is on the mutable fields, because ho=
w to define/use protocol-specific mutable fields is not very clear at this =
point.
>> If necessary, it would probably be better to put them in another documen=
t, after we figuring out exactly how to handle those fields.
>>
>> best
>>
>> Jiazi
>>
>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi > wrote:
>>
>>> Chris,
>>>
>>> I do understand your concern. We had this kind of discussion on mutable=
 fields before, and this is something I'm still mulling over.
>>> The reason why I propose this for discussion is:
>>>
>>>     - this rfc6622bis is for rfc5444, which is a general format for all=
 manet protocols.
>>>     - The reactive protocol like LOADng does explicitly define such "mu=
table" fields. It is something at hand, not in the far future.
>>>
>>> In the meantime, I do agree that the necessity and how to take care of =
such mutable fields should be considered carefully.
>>> So I would agree that we keep the current rfc6622bis draft as it is for=
 the moment, and I'll have more discussions with other LOADng authors on th=
is.
>>>
>>> best
>>>
>>> Jiazi
>>>
>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" > wrote:
>>>
>>>> Jiazi
>>>>
>>>> Thanks for that, I'll just comment on the one point where I disagree.
>>>>
>>>> Putting some vague words in that protocols may indicate fields not to =
be covered is the sort of thing that I can predict will cause us problems a=
t the IESG. And it's not really a good plan for a generic mechanism that ca=
n - at at present - be run independently of the routing protocol to acquire=
 a protocol dependence. Rather I think that any routing protocols with a sp=
ecific need to exclude data (which, all else being equal is a bad thing of =
course) should consider defining a new type extension - preferably one defi=
ned with some generic capability (could it, for example, list TLV types to =
be excluded?) But that's for the future. One thing I have learned is that d=
esign in advance of what might hypothetically be needed generally gets it w=
rong, so it would be good to wait until exactly what's needed is clear, and=
 then define a new case.
>>>>
>>>> Christopher
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 24212=
4
>>>> chris.dearlove@baesystems.com | =
http://www.baesystems.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>> -----Original Message-----
>>>> From: manet-bounces@ietf.org [mailto:ma=
net-bounces@ietf.org] On Behalf Of ietf@jiaz=
iyi.com
>>>> Sent: 23 April 2013 15:37
>>>> To: manet@ietf.org
>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>>>
>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters
>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>
>>>> (sorry if you receive duplicate of this message. Some of my mails to
>>>> the mailing list are rejected, and I'm trying to figure out with our
>>>> secretary...)
>>>>
>>>> Hi,
>>>>
>>>> I had a review of the draft. I think it's in good shape, and ready for
>>>> WGLC.
>>>>
>>>> a few comments:
>>>>
>>>> In section 6 & 7, I didn't find the definition of notation
>>>>    +
>>>> Not in this draft, either rfc 5444.
>>>>
>>>> page 13,  source code address =3D=3D> source node address?
>>>>
>>>> section 9.1 bullet 1 states that the  and
>>>>  must be zeroed before calculating ICV. I'm thinking
>>>> about that we might need to mention that some protocol-specific mutabl=
e
>>>> fields must be zeroed here also. For example, in LOADng, as a reactive
>>>> protocol, metric fields are defined as "mutable" (in the meantime, I
>>>> still have some thoughts on those mutable fields that I need to discus=
s
>>>> with other LOADng authors, but it's not that relevant here).
>>>>
>>>> best
>>>>
>>>> Jiazi
>>>>
>>>>
>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
>>>> of the IETF.
>>>>
>>>>    Title           : Integrity Check Value and Timestamp TLV Definitio=
ns
>>>> for Mobile Ad Hoc Networks (MANETs)
>>>>    Author(s)       : Ulrich Herberg
>>>>                      Thomas Heide Clausen
>>>>                      Christopher Dearlove
>>>>    Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>>>    Pages           : 24
>>>>    Date            : 2013-04-15
>>>>
>>>> Abstract:
>>>> This document revises, extends and replaces RFC 6622.  It describes
>>>> general and flexible TLVs for representing cryptographic Integrity
>>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>>>> for affixing ICVs and timestamps to a packet, a message, and one or
>>>> more addresses, respectively.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> ********************************************************************
>>>> This email and any attachments are confidential to the intended
>>>> recipient and may also be privileged. If you are not the intended
>>>> recipient please delete it from your system and notify the sender.
>>>> You should not copy it or use it for any purpose nor disclose or
>>>> distribute its contents to any other person.
>>>> ********************************************************************
>>>>
>>>
>>
>>
>
>

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


--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065129GLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I don't believe that is w=
hat Jiazi said. Furthermore the document already discusses synchronization =
issues, from the need to relax constraints if synchronisation
 is not possible, to a note in the Limitations section about what to do if =
synchronisation is not possible.


 <=
/p>

The actual nit here is no=
thing to do with synchronisation issues, but which parameters to use as sug=
gested bounds when synchronisation is ideal. I think the
 choice should be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b) H_HOL=
D_TIME and T_HOLD_TIME. In case (a) we should drop the "significantly =
less" caveat. Note that what we are actually saying is that the parame=
ter is greater than is how long the message
 might take to arrive, but we don't have that, we just have the indicated p=
arameters. (A sophisticated implementation could choose to use the sender's=
 versions of these read from INTERVAL_TIME and VALIDITY_TIME TLVs. But real=
ly, as this is guidance, it's not
 critical.)


 <=
/p>

Preferences: (a) or (b)? =
- We can put this in with other nits found.


 <=
/p>

chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (O=
perations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687


 <=
/p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]


Sent: 26 April 2013 15:29

To: Jiazi Yi

Cc: Dearlove, Christopher (UK); manet@ietf.org

Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt=



 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see 
this process on how to deal with suspicious emails.<=
/i>










I agree with you, the document should state synchron=
ization issues/concerns,






 






AB








 




On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <yi.jiazi@gmail.com>=
; wrote:


Hi,






On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co=
m> wrote:



> I think you missed something. Though there is a point we might have to=
 consider that I'll get to.

>

> These are constraints on your internal parameters. Let me just conside=
r the HELLO ones, obviously the TC ones are similar.

>

> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the messag=
e appears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". O=
bviously that only makes sense for a positive age, hence the first constrai=
nt. That doesn't matter about synchronisation. It's
 actually a fairly obvious thing that almost doesn't need saying (but also =
see a bit later).




Yes. I agree. If we assume "network can be sync=
hronized with sufficient precision", then the value can only be positi=
ve.

Of course, if the network is not well synchronized, a negative is possible.=









>

> Now sticking for the moment to an assumption that we can measure the a=
ge of a packet/message, we want to bound how much slack we should allow. An=
d that's the second constraint. (Right this moment I'm not sure why we pick=
ed REFRESH_INTERVAL rather than HELLO_INTERVAL,
 but it actually works either way.) But this is where synchronisation comes=
 in (and why the_DIFF suffix). We measure the age by comparing our clock wi=
th the timestamp. If synchronised then that's the age, done.








I'm just a little confused by why "assuming ide=
al time synchronization" is related to the constraints of



        "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INT=
ERVAL"



I didn't quite get the relation here.

What I understand is that, the "age" calculated by



        local_router_time - HELLO_timestamp



is only related to transmission delay of the message (if no attack happens)=
.  When it is regarded "too old" (age > MAX_HELLO_TIMESTA=
MP_DIFF), it is discarded.








>

> If there's a synchronisation error, let's suppose we received at t2, i=
t claims to be sent at t1, but (based on our clock) was actually sent at t1=
+e. So our test is

>

> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF

>

> but the age of the message, A is t2 - t1 - e, so

>

> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e

>

> So if we want to only reject messages that are definitely too late, we=
 need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assum=
e e is symmetrically distributed +ve and -ve. In turn this means that w=
e should allow an extra margin of e on
 the constraint MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.

>

> Now the point of interest. What if we receive a message with an appare=
nt negative age? If that's greater than the minimum value of e (or -e) that=
's fine. But more than that? Should we reject such messages?




Apparently, if the network is not synchronized, a ne=
gative age can happen. What I understand is that, this document won't take =
care of synchronization and related error? Because those would be another b=
ig problem to deal with...



best



Jiazi








>

> --

> Christopher Dearlove

> Senior Principal Engineer, Communications Group

> Communications, Networks and Image Analysis Capability

> BAE Systems Advanced Technology Centre

> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

> Tel: +44 1245 242194 | &=
nbsp;Fax: 
+44 1245 242124

> chris.dearlove@baesys=
tems.com |
http://www.baesyste=
ms.com

>

> BAE Systems (Operations) Limited

> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK

> Registered in England & Wales No: 1996687

>

>

> -----Original Message-----

> From: Jiazi Yi [mailto:yi.jiazi@=
gmail.com]

> Sent: 24 April 2013 17:55

> To: Dearlove, Christopher (UK)

> Cc: manet@ietf.org

> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>

> ----------------------! WARNING ! ----------------------

> This message originates from outside our organisation,

> either from an external partner or from the internet.

> Keep this in mind if you answer this message.

> Follow the 'Report Suspicious Emails' link on IT matters

> for instructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Thanks Chris for sharing your thought.

>

> Yes, those are all possibilities to consider. And a more fundamental i=
ssue I'm thinking about is the framework for securing re-active protocols, =
because it's much harder than pro-acitve ones. For example, do we want to r=
equire hop-by-hop authentication? Zeroing
 the metric field opens possible attack vector also... anyway, we can discu=
ss this in other topics in the future.

>

> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec=
-02, and I think it is fairly clear. I would support it for WGLC.

>

> Just one question:

>

> In the draft:

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> The following constraints apply to these parameters:

>

>   o  MAX_HELLO_TIMESTAMP_DIFF > 0

>

>   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

>

>   o  MAX_TC_TIMESTAMP_DIFF > 0

>

>   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

>

>   The second and fourth of those constraints assume ideal time
>   synchronization of the clocks in all routers in the network.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> My understanding is that, "the time difference equals 0" is =
for ideal time synchronization. So it should be The first and third assume =
ideal time synchronization? Or I missed something here?

>

> best

>

> Jiazi

>

> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" &l=
t;Chris.Dearlove@baesystem=
s.com> wrote:

>

>> Thanks for that. I'm hoping we can proceed push out 6622bis, and t=
he security document.

>>

>> As a contribution to that future concept, I'll note that 6622(bis)=
 is independent of the protocol. That I think is a desirable thing.

>>

>> One idea (I'm not sold on it, it's just for consideration) is that=
 if you are considering that, for example, you don't want to include a metr=
ic in your ICV, and that metric is in TLV type X (probably a full type with=
 type extension, but that's another of
 those details) then as a new variant type extension ICV, you could add som=
ething to say "remove all TLVs with type extensions X, Y, Z before cal=
culating ICV). Or maybe that needs to be a range. Or ... but first work out=
 exactly what you want, then how it cleanly
 generalises (where a good generalisation is easier to implement than the s=
pecial case).

>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer, Communications Group

>> Communications, Networks and Image Analysis Capability

>> BAE Systems Advanced Technology Centre

>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

>> Tel: +44 1245 242194=
 |  Fax: 
+44 1245 242124

>> chris.dearlove@ba=
esystems.com |
http://www.baesyste=
ms.com

>>

>> BAE Systems (Operations) Limited

>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=
 Centre, Farnborough, Hants, GU14 6YU, UK

>> Registered in England & Wales No: 1996687

>>

>>

>> -----Original Message-----

>> From: Jiazi Yi [mailto:yi.ji=
azi@gmail.com]

>> Sent: 24 April 2013 17:12

>> To: Dearlove, Christopher (UK)

>> Cc: manet@ietf.org

>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.t=
xt

>>

>> ----------------------! WARNING ! ----------------------

>> This message originates from outside our organisation,

>> either from an external partner or from the internet.

>> Keep this in mind if you answer this message.

>> Follow the 'Report Suspicious Emails' link on IT matters

>> for instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> Hi,

>>

>> After several mail exchange with some of the other authors, I thin=
k it would be better to keep the draft as it is on the mutable fields, beca=
use how to define/use protocol-specific mutable fields is not very clear at=
 this point.

>> If necessary, it would probably be better to put them in another d=
ocument, after we figuring out exactly how to handle those fields.

>>

>> best

>>

>> Jiazi

>>

>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:

>>

>>> Chris,

>>>

>>> I do understand your concern. We had this kind of discussion o=
n mutable fields before, and this is something I'm still mulling over.

>>> The reason why I propose this for discussion is:

>>>

>>>     - this rfc6622bis is for rfc5444, which is a gen=
eral format for all manet protocols.

>>>     - The reactive protocol like LOADng does explici=
tly define such "mutable" fields. It is something at hand, not in=
 the far future.

>>>

>>> In the meantime, I do agree that the necessity and how to take=
 care of such mutable fields should be considered carefully.

>>> So I would agree that we keep the current rfc6622bis draft as =
it is for the moment, and I'll have more discussions with other LOADng auth=
ors on this.

>>>

>>> best

>>>

>>> Jiazi

>>>

>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)=
" <Chris.Dearlove@=
baesystems.com> wrote:

>>>

>>>> Jiazi

>>>>

>>>> Thanks for that, I'll just comment on the one point where =
I disagree.

>>>>

>>>> Putting some vague words in that protocols may indicate fi=
elds not to be covered is the sort of thing that I can predict will cause u=
s problems at the IESG. And it's not really a good plan for a generic mecha=
nism that can - at at present - be run independently
 of the routing protocol to acquire a protocol dependence. Rather I think t=
hat any routing protocols with a specific need to exclude data (which, all =
else being equal is a bad thing of course) should consider defining a new t=
ype extension - preferably one defined
 with some generic capability (could it, for example, list TLV types to be =
excluded?) But that's for the future. One thing I have learned is that desi=
gn in advance of what might hypothetically be needed generally gets it wron=
g, so it would be good to wait until
 exactly what's needed is clear, and then define a new case.

>>>>

>>>> Christopher

>>>>

>>>> --

>>>> Christopher Dearlove

>>>> Senior Principal Engineer, Communications Group

>>>> Communications, Networks and Image Analysis Capability

>>>> BAE Systems Advanced Technology Centre

>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,=
 UK

>>>> Tel: +44 1245 24=
2194 |  Fax: 
+44 1245 242124

>>>> chris.dea=
rlove@baesystems.com |
http://www.baesyste=
ms.com

>>>>

>>>> BAE Systems (Operations) Limited

>>>> Registered Office: Warwick House, PO Box 87, Farnborough A=
erospace Centre, Farnborough, Hants, GU14 6YU, UK

>>>> Registered in England & Wales No: 1996687

>>>>

>>>> -----Original Message-----

>>>> From: manet-boun=
ces@ietf.org [mailto:manet-bo=
unces@ietf.org] On Behalf Of
ietf@jiaziyi.com

>>>> Sent: 23 April 2013 15:37

>>>> To: manet@ietf.org
>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>>

>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,

>>>> either from an external partner or from the internet.

>>>> Keep this in mind if you answer this message.

>>>> Follow the 'Report Suspicious Emails' link on IT matters
>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>

>>>> (sorry if you receive duplicate of this message. Some of m=
y mails to

>>>> the mailing list are rejected, and I'm trying to figure ou=
t with our

>>>> secretary...)

>>>>

>>>> Hi,

>>>>

>>>> I had a review of the draft. I think it's in good shape, a=
nd ready for

>>>> WGLC.

>>>>

>>>> a few comments:

>>>>

>>>> In section 6 & 7, I didn't find the definition of nota=
tion

>>>>    <foo>+

>>>> Not in this draft, either rfc 5444.

>>>>

>>>> page 13,  source code address =3D=3D> source node =
address?

>>>>

>>>> section 9.1 bullet 1 states that the <msg-hop-limit>=
 and

>>>> <msg-hop-count> must be zeroed before calculating IC=
V. I'm thinking

>>>> about that we might need to mention that some protocol-spe=
cific mutable

>>>> fields must be zeroed here also. For example, in LOADng, a=
s a reactive

>>>> protocol, metric fields are defined as "mutable"=
 (in the meantime, I

>>>> still have some thoughts on those mutable fields that I ne=
ed to discuss

>>>> with other LOADng authors, but it's not that relevant here=
).

>>>>

>>>> best

>>>>

>>>> Jiazi

>>>>

>>>>

>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:

>>>>

>>>>

>>>> A New Internet-Draft is available from the on-line Interne=
t-Drafts

>>>> directories.

>>>> This draft is a work item of the Mobile Ad-hoc Networks Wo=
rking Group

>>>> of the IETF.

>>>>

>>>>    Title           : In=
tegrity Check Value and Timestamp TLV Definitions

>>>> for Mobile Ad Hoc Networks (MANETs)

>>>>    Author(s)       : Ulrich Herbe=
rg

>>>>                 &n=
bsp;    Thomas Heide Clausen

>>>>                 &n=
bsp;    Christopher Dearlove

>>>>    Filename        : draft-i=
etf-manet-rfc6622-bis-02.txt

>>>>    Pages           : 24=


>>>>    Date            =
;: 2013-04-15

>>>>

>>>> Abstract:

>>>> This document revises, extends and replaces RFC 6622. &nbs=
p;It describes

>>>> general and flexible TLVs for representing cryptographic I=
ntegrity

>>>> Check Values (ICVs) and timestamps, using the generalized =
Mobile Ad

>>>> Hoc Network (MANET) packet/message format defined in RFC 5=
444.  It

>>>> defines two Packet TLVs, two Message TLVs, and two Address=
 Block TLVs

>>>> for affixing ICVs and timestamps to a packet, a message, a=
nd one or

>>>> more addresses, respectively.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> 
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

>>>>

>>>> There's also a htmlized version available at:

>>>> 
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

>>>>

>>>> A diff from the previous version is available at:

>>>> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

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

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

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

>>>>

>>>>

>>>> **********************************************************=
**********

>>>> This email and any attachments are confidential to the int=
ended

>>>> recipient and may also be privileged. If you are not the i=
ntended

>>>> recipient please delete it from your system and notify the=
 sender.

>>>> You should not copy it or use it for any purpose nor discl=
ose or

>>>> distribute its contents to any other person.

>>>> **********************************************************=
**********

>>>>

>>>

>>

>>

>

>



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet








 








--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065129GLKXM0002VGREEN_--

From abdussalambaryun@gmail.com  Fri Apr 26 07:46:59 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BB21F9A00 for ; Fri, 26 Apr 2013 07:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.732
X-Spam-Level: 
X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.866,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3jMZpjD3pGS for ; Fri, 26 Apr 2013 07:46:57 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1E621F991A for ; Fri, 26 Apr 2013 07:46:57 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id ld11so234014pab.33 for ; Fri, 26 Apr 2013 07:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mOy/lAmaYAizuMIz9r/qy4/y/34nGhtnDq3ijaNcoJQ=; b=cZVvSaemoyxZrqIu4+dizxkaNbH49Kj+Pn1gpt7wzSvGjX+vv4+mOswgv5M5j3YhZz +FWh9JCqRySaERNayQggdlbHnqIRB/mAJ45BrK7FTPyAw9uQINMDUEZArrg6Fqw6nEuL 8cnQuYU8ActRr7hl6kJ7VZM2DSOFZqrhPfwbxmFdzJtbEKkddAXOc6+bXtbnaGtqXX3K +yKuXox2EHiKRMPUMoEIcV2v9KG6rnauo0Jnxn0LJINY6NAIvsnHz6w5ROdGbmcm7VEy bkXQWYgTmqrtdN9Btam+HEEtC/N1wJCWaAXFS4hJsyBwxAVcqEbaUT042PKSgqIF7KlD fb5g==
MIME-Version: 1.0
X-Received: by 10.68.213.1 with SMTP id no1mr59381675pbc.163.1366987616869; Fri, 26 Apr 2013 07:46:56 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Fri, 26 Apr 2013 07:46:56 -0700 (PDT)
In-Reply-To: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>       
Date: Fri, 26 Apr 2013 15:46:56 +0100
Message-ID: 
From: Abdussalam Baryun 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=e89a8ff1c6ba50e5ec04db449bca
Cc: "manet@ietf.org" , Jiazi Yi 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 14:46:59 -0000

--e89a8ff1c6ba50e5ec04db449bca
Content-Type: text/plain; charset=ISO-8859-1

In MANET practice nothing is ideal, maybe can be assumed in fixed wireless
networks. I mean to state; does the document suggest parameters for
non-synchronised network = practical manet.

AB


On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christopher (UK) <
Chris.Dearlove@baesystems.com> wrote:

>  I don't believe that is what Jiazi said. Furthermore the document
> already discusses synchronization issues, from the need to relax
> constraints if synchronisation is not possible, to a note in the
> Limitations section about what to do if synchronisation is not possible.**
> **
>
> ** **
>
> The actual nit here is nothing to do with synchronisation issues, but
> which parameters to use as suggested bounds when synchronisation is ideal.
> I think the choice should be between (a) HELLO_INTERVAL and TC_INTERVAL,
> and (b) H_HOLD_TIME and T_HOLD_TIME. In case (a) we should drop the
> "significantly less" caveat. Note that what we are actually saying is that
> the parameter is greater than is how long the message might take to arrive,
> but we don't have that, we just have the indicated parameters. (A
> sophisticated implementation could choose to use the sender's versions of
> these read from INTERVAL_TIME and VALIDITY_TIME TLVs. But really, as this
> is guidance, it's not critical.)****
>
> ** **
>
> Preferences: (a) or (b)? - We can put this in with other nits found.****
>
> ** **
>
> -- ****
>
> Christopher Dearlove****
>
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
> Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687****
>
> ** **
>
> *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> *Sent:* 26 April 2013 15:29
> *To:* Jiazi Yi
> *Cc:* Dearlove, Christopher (UK); manet@ietf.org
>
> *Subject:* Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt****
>
> ** **
>
> ** **
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.***
> *
>
> Keep this in mind if you answer this message.
> Please see this processon how to deal with suspicious emails.
> *****
>
>   I agree with you, the document should state synchronization
> issues/concerns,****
>
>  ****
>
> AB****
>
> ** **
>
> On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi  wrote:****
>
> Hi,****
>
>
> On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
>
> > I think you missed something. Though there is a point we might have to
> consider that I'll get to.
> >
> > These are constraints on your internal parameters. Let me just consider
> the HELLO ones, obviously the TC ones are similar.
> >
> > The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to
> be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only
> makes sense for a positive age, hence the first constraint. That doesn't
> matter about synchronisation. It's actually a fairly obvious thing that
> almost doesn't need saying (but also see a bit later).****
>
> Yes. I agree. If we assume "network can be synchronized with sufficient
> precision", then the value can only be positive.
> Of course, if the network is not well synchronized, a negative is possible.
> ****
>
>
>
> >
> > Now sticking for the moment to an assumption that we can measure the age
> of a packet/message, we want to bound how much slack we should allow. And
> that's the second constraint. (Right this moment I'm not sure why we picked
> REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either
> way.) But this is where synchronisation comes in (and why the_DIFF suffix).
> We measure the age by comparing our clock with the timestamp. If
> synchronised then that's the age, done.
>
> ****
>
> I'm just a little confused by why "assuming ideal time synchronization" is
> related to the constraints of
>
>         "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"
>
> I didn't quite get the relation here.
> What I understand is that, the "age" calculated by
>
>         local_router_time - HELLO_timestamp
>
> is only related to transmission delay of the message (if no attack
> happens).  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF),
> it is discarded.****
>
>
>
> >
> > If there's a synchronisation error, let's suppose we received at t2, it
> claims to be sent at t1, but (based on our clock) was actually sent at
> t1+e. So our test is
> >
> > (t2 - t1) <= MAX_HELLO_TIMESTAMP_DIFF
> >
> > but the age of the message, A is t2 - t1 - e, so
> >
> > A <= MAX_HELLO_TIMESTAMP_DIFF - e
> >
> > So if we want to only reject messages that are definitely too late, we
> need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume
> e is symmetrically distributed +ve and -ve. In turn this means that we
> should allow an extra margin of e on the constraint
> MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.
> >
> > Now the point of interest. What if we receive a message with an apparent
> negative age? If that's greater than the minimum value of e (or -e) that's
> fine. But more than that? Should we reject such messages?****
>
> Apparently, if the network is not synchronized, a negative age can happen.
> What I understand is that, this document won't take care of synchronization
> and related error? Because those would be another big problem to deal
> with...
>
> best
>
> Jiazi****
>
>
> >
> > --
> > Christopher Dearlove
> > Senior Principal Engineer, Communications Group
> > Communications, Networks and Image Analysis Capability
> > BAE Systems Advanced Technology Centre
> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> > Tel: +44 1245 242194 |  Fax: +44 1245 242124
> > chris.dearlove@baesystems.com | http://www.baesystems.com
> >
> > BAE Systems (Operations) Limited
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> > Registered in England & Wales No: 1996687
> >
> >
> > -----Original Message-----
> > From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> > Sent: 24 April 2013 17:55
> > To: Dearlove, Christopher (UK)
> > Cc: manet@ietf.org
> > Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >
> > ----------------------! WARNING ! ----------------------
> > This message originates from outside our organisation,
> > either from an external partner or from the internet.
> > Keep this in mind if you answer this message.
> > Follow the 'Report Suspicious Emails' link on IT matters
> > for instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Thanks Chris for sharing your thought.
> >
> > Yes, those are all possibilities to consider. And a more fundamental
> issue I'm thinking about is the framework for securing re-active protocols,
> because it's much harder than pro-acitve ones. For example, do we want to
> require hop-by-hop authentication? Zeroing the metric field opens possible
> attack vector also... anyway, we can discuss this in other topics in the
> future.
> >
> > In the meantime, I reviewed the draft
> draft-ietf-manet-nhdp-olsrv2-sec-02, and I think it is fairly clear. I
> would support it for WGLC.
> >
> > Just one question:
> >
> > In the draft:
> > =============
> > The following constraints apply to these parameters:
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
> >
> >   o  MAX_TC_TIMESTAMP_DIFF > 0
> >
> >   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
> >
> >   The second and fourth of those constraints assume ideal time
> >   synchronization of the clocks in all routers in the network.
> > ======================
> >
> > My understanding is that, "the time difference equals 0" is for ideal
> time synchronization. So it should be The first and third assume ideal time
> synchronization? Or I missed something here?
> >
> > best
> >
> > Jiazi
> >
> > On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
> >
> >> Thanks for that. I'm hoping we can proceed push out 6622bis, and the
> security document.
> >>
> >> As a contribution to that future concept, I'll note that 6622(bis) is
> independent of the protocol. That I think is a desirable thing.
> >>
> >> One idea (I'm not sold on it, it's just for consideration) is that if
> you are considering that, for example, you don't want to include a metric
> in your ICV, and that metric is in TLV type X (probably a full type with
> type extension, but that's another of those details) then as a new variant
> type extension ICV, you could add something to say "remove all TLVs with
> type extensions X, Y, Z before calculating ICV). Or maybe that needs to be
> a range. Or ... but first work out exactly what you want, then how it
> cleanly generalises (where a good generalisation is easier to implement
> than the special case).
> >>
> >> --
> >> Christopher Dearlove
> >> Senior Principal Engineer, Communications Group
> >> Communications, Networks and Image Analysis Capability
> >> BAE Systems Advanced Technology Centre
> >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>
> >> BAE Systems (Operations) Limited
> >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> >> Registered in England & Wales No: 1996687
> >>
> >>
> >> -----Original Message-----
> >> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> >> Sent: 24 April 2013 17:12
> >> To: Dearlove, Christopher (UK)
> >> Cc: manet@ietf.org
> >> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >>
> >> ----------------------! WARNING ! ----------------------
> >> This message originates from outside our organisation,
> >> either from an external partner or from the internet.
> >> Keep this in mind if you answer this message.
> >> Follow the 'Report Suspicious Emails' link on IT matters
> >> for instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> Hi,
> >>
> >> After several mail exchange with some of the other authors, I think it
> would be better to keep the draft as it is on the mutable fields, because
> how to define/use protocol-specific mutable fields is not very clear at
> this point.
> >> If necessary, it would probably be better to put them in another
> document, after we figuring out exactly how to handle those fields.
> >>
> >> best
> >>
> >> Jiazi
> >>
> >> On Apr 24, 2013, at 12:54 PM, Jiazi Yi  wrote:
> >>
> >>> Chris,
> >>>
> >>> I do understand your concern. We had this kind of discussion on
> mutable fields before, and this is something I'm still mulling over.
> >>> The reason why I propose this for discussion is:
> >>>
> >>>     - this rfc6622bis is for rfc5444, which is a general format for
> all manet protocols.
> >>>     - The reactive protocol like LOADng does explicitly define such
> "mutable" fields. It is something at hand, not in the far future.
> >>>
> >>> In the meantime, I do agree that the necessity and how to take care of
> such mutable fields should be considered carefully.
> >>> So I would agree that we keep the current rfc6622bis draft as it is
> for the moment, and I'll have more discussions with other LOADng authors on
> this.
> >>>
> >>> best
> >>>
> >>> Jiazi
> >>>
> >>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" <
> Chris.Dearlove@baesystems.com> wrote:
> >>>
> >>>> Jiazi
> >>>>
> >>>> Thanks for that, I'll just comment on the one point where I disagree.
> >>>>
> >>>> Putting some vague words in that protocols may indicate fields not to
> be covered is the sort of thing that I can predict will cause us problems
> at the IESG. And it's not really a good plan for a generic mechanism that
> can - at at present - be run independently of the routing protocol to
> acquire a protocol dependence. Rather I think that any routing protocols
> with a specific need to exclude data (which, all else being equal is a bad
> thing of course) should consider defining a new type extension - preferably
> one defined with some generic capability (could it, for example, list TLV
> types to be excluded?) But that's for the future. One thing I have learned
> is that design in advance of what might hypothetically be needed generally
> gets it wrong, so it would be good to wait until exactly what's needed is
> clear, and then define a new case.
> >>>>
> >>>> Christopher
> >>>>
> >>>> --
> >>>> Christopher Dearlove
> >>>> Senior Principal Engineer, Communications Group
> >>>> Communications, Networks and Image Analysis Capability
> >>>> BAE Systems Advanced Technology Centre
> >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >>>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com
> >>>>
> >>>> BAE Systems (Operations) Limited
> >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> >>>> Registered in England & Wales No: 1996687
> >>>>
> >>>> -----Original Message-----
> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On
> Behalf Of ietf@jiaziyi.com
> >>>> Sent: 23 April 2013 15:37
> >>>> To: manet@ietf.org
> >>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
> >>>>
> >>>> ----------------------! WARNING ! ----------------------
> >>>> This message originates from outside our organisation,
> >>>> either from an external partner or from the internet.
> >>>> Keep this in mind if you answer this message.
> >>>> Follow the 'Report Suspicious Emails' link on IT matters
> >>>> for instructions on reporting suspicious email messages.
> >>>> --------------------------------------------------------
> >>>>
> >>>> (sorry if you receive duplicate of this message. Some of my mails to
> >>>> the mailing list are rejected, and I'm trying to figure out with our
> >>>> secretary...)
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had a review of the draft. I think it's in good shape, and ready for
> >>>> WGLC.
> >>>>
> >>>> a few comments:
> >>>>
> >>>> In section 6 & 7, I didn't find the definition of notation
> >>>>    +
> >>>> Not in this draft, either rfc 5444.
> >>>>
> >>>> page 13,  source code address ==> source node address?
> >>>>
> >>>> section 9.1 bullet 1 states that the  and
> >>>>  must be zeroed before calculating ICV. I'm thinking
> >>>> about that we might need to mention that some protocol-specific
> mutable
> >>>> fields must be zeroed here also. For example, in LOADng, as a reactive
> >>>> protocol, metric fields are defined as "mutable" (in the meantime, I
> >>>> still have some thoughts on those mutable fields that I need to
> discuss
> >>>> with other LOADng authors, but it's not that relevant here).
> >>>>
> >>>> best
> >>>>
> >>>> Jiazi
> >>>>
> >>>>
> >>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
> >>>>
> >>>>
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>>> directories.
> >>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
> >>>> of the IETF.
> >>>>
> >>>>    Title           : Integrity Check Value and Timestamp TLV
> Definitions
> >>>> for Mobile Ad Hoc Networks (MANETs)
> >>>>    Author(s)       : Ulrich Herberg
> >>>>                      Thomas Heide Clausen
> >>>>                      Christopher Dearlove
> >>>>    Filename        : draft-ietf-manet-rfc6622-bis-02.txt
> >>>>    Pages           : 24
> >>>>    Date            : 2013-04-15
> >>>>
> >>>> Abstract:
> >>>> This document revises, extends and replaces RFC 6622.  It describes
> >>>> general and flexible TLVs for representing cryptographic Integrity
> >>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
> >>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
> >>>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
> >>>> for affixing ICVs and timestamps to a packet, a message, and one or
> >>>> more addresses, respectively.
> >>>>
> >>>>
> >>>> The IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
> >>>>
> >>>> There's also a htmlized version available at:
> >>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>> A diff from the previous version is available at:
> >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6622-bis-02
> >>>>
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>>
> >>>> ********************************************************************
> >>>> This email and any attachments are confidential to the intended
> >>>> recipient and may also be privileged. If you are not the intended
> >>>> recipient please delete it from your system and notify the sender.
> >>>> You should not copy it or use it for any purpose nor disclose or
> >>>> distribute its contents to any other person.
> >>>> ********************************************************************
> >>>>
> >>>
> >>
> >>
> >
> >
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet****
>
> ** **
>

--e89a8ff1c6ba50e5ec04db449bca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


In MANET practice nothing is ideal, maybe can be assu=
med in fixed wireless networks. I mean to state; does the document suggest =
parameters for non-synchronised network =3D practical manet.
=A0<=
/div>

AB


On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:













I don't believe =
that is what Jiazi said. Furthermore the document already discusses synchro=
nization issues, from the need to relax constraints if synchronisation
 is not possible, to a note in the Limitations section about what to do if =
synchronisation is not possible.


=A0


The actual nit here =
is nothing to do with synchronisation issues, but which parameters to use a=
s suggested bounds when synchronisation is ideal. I think the
 choice should be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b) H_HOL=
D_TIME and T_HOLD_TIME. In case (a) we should drop the "significantly =
less" caveat. Note that what we are actually saying is that the parame=
ter is greater than is how long the message
 might take to arrive, but we don't have that, we just have the indicat=
ed parameters. (A sophisticated implementation could choose to use the send=
er's versions of these read from INTERVAL_TIME and VALIDITY_TIME TLVs. =
But really, as this is guidance, it's not
 critical.)


=A0


Preferences: (a) or =
(b)? - We can put this in with other nits found.



=A0


--



Christopher Dearlove=



Senior Principal Eng=
ineer, Communications Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124



chris.dearlove@baesystems.com
 | http://www.baesy=
stems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687


=A0


From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]


Sent: 26 April 2013 15:29

To: Jiazi Yi

Cc: Dearlove, Christopher (UK); manet@ietf.org


Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt=



=A0




=A0




*** WARNING ***<=
/span>








This message originates from outside ou=
r organisation, either from an external partner or the internet.




Ke=
ep this in mind if you answer this message.


Please see 
this process on how to deal with suspicious emails.










I agree with you, the document should state synchron=
ization issues/concerns,






=A0






AB








=A0




On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <yi.jiazi@gmail.com>=
; wrote:


Hi,






On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <Chris.Dear=
love@baesystems.com> wrote:



> I think you missed something. Though there is a point we might have to=
 consider that I'll get to.

>

> These are constraints on your internal parameters. Let me just conside=
r the HELLO ones, obviously the TC ones are similar.

>

> The basic use of MAX_HELLO_TIMESTAMP_DIFF is =A0"if the message a=
ppears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obvi=
ously that only makes sense for a positive age, hence the first constraint.=
 That doesn't matter about synchronisation. It's
 actually a fairly obvious thing that almost doesn't need saying (but a=
lso see a bit later).




Yes. I agree. If we assume "network can be sync=
hronized with sufficient precision", then the value can only be positi=
ve.

Of course, if the network is not well synchronized, a negative is possible.=









>

> Now sticking for the moment to an assumption that we can measure the a=
ge of a packet/message, we want to bound how much slack we should allow. An=
d that's the second constraint. (Right this moment I'm not sure why=
 we picked REFRESH_INTERVAL rather than HELLO_INTERVAL,
 but it actually works either way.) But this is where synchronisation comes=
 in (and why the_DIFF suffix). We measure the age by comparing our clock wi=
th the timestamp. If synchronised then that's the age, done.








I'm just a little confused by why "assuming=
 ideal time synchronization" is related to the constraints of



=A0 =A0 =A0 =A0 "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"<=
br>


I didn't quite get the relation here.

What I understand is that, the "age" calculated by



=A0 =A0 =A0 =A0 local_router_time - HELLO_timestamp



is only related to transmission delay of the message (if no attack happens)=
. =A0When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_=
DIFF), it is discarded.








>

> If there's a synchronisation error, let's suppose we received =
at t2, it claims to be sent at t1, but (based on our clock) was actually se=
nt at t1+e. So our test is

>

> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF

>

> but the age of the message, A is t2 - t1 - e, so

>

> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e

>

> So if we want to only reject messages that are definitely too late, we=
 need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assum=
e e is symmetrically distributed +ve and -ve. In turn this means that we sh=
ould allow an extra margin of e on
 the constraint MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.

>

> Now the point of interest. What if we receive a message with an appare=
nt negative age? If that's greater than the minimum value of e (or -e) =
that's fine. But more than that? Should we reject such messages?=






Apparently, if the network is not synchronized, a ne=
gative age can happen. What I understand is that, this document won't t=
ake care of synchronization and related error? Because those would be anoth=
er big problem to deal with...




best



Jiazi








>

> --

> Christopher Dearlove

> Senior Principal Engineer, Communications Group

> Communications, Networks and Image Analysis Capability

> BAE Systems Advanced Technology Centre

> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

> Tel: +44 1245 =
242194 | =A0Fax: 
+44 1245 242124

> chr=
is.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>

> BAE Systems (Operations) Limited

> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK

> Registered in England & Wales No: 1996687

>

>

> -----Original Message-----

> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]

> Sent: 24 April 2013 17:55

> To: Dearlove, Christopher (UK)

> Cc: manet@ietf.org=


> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>

> ----------------------! WARNING ! ----------------------

> This message originates from outside our organisation,

> either from an external partner or from the internet.

> Keep this in mind if you answer this message.

> Follow the 'Report Suspicious Emails' link on IT matters

> for instructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Thanks Chris for sharing your thought.

>

> Yes, those are all possibilities to consider. And a more fundamental i=
ssue I'm thinking about is the framework for securing re-active protoco=
ls, because it's much harder than pro-acitve ones. For example, do we w=
ant to require hop-by-hop authentication? Zeroing
 the metric field opens possible attack vector also... anyway, we can discu=
ss this in other topics in the future.

>

> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec=
-02, and I think it is fairly clear. I would support it for WGLC.

>

> Just one question:

>

> In the draft:

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> The following constraints apply to these parameters:

>

> =A0 o =A0MAX_HELLO_TIMESTAMP_DIFF > 0

>

> =A0 o =A0MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

>

> =A0 o =A0MAX_TC_TIMESTAMP_DIFF > 0

>

> =A0 o =A0MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

>

> =A0 The second and fourth of those constraints assume ideal time

> =A0 synchronization of the clocks in all routers in the network.

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> My understanding is that, "the time difference equals 0" is =
for ideal time synchronization. So it should be The first and third assume =
ideal time synchronization? Or I missed something here?

>

> best

>

> Jiazi

>

> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" &l=
t;Chris.=
Dearlove@baesystems.com> wrote:

>

>> Thanks for that. I'm hoping we can proceed push out 6622bis, a=
nd the security document.

>>

>> As a contribution to that future concept, I'll note that 6622(=
bis) is independent of the protocol. That I think is a desirable thing.

>>

>> One idea (I'm not sold on it, it's just for consideration)=
 is that if you are considering that, for example, you don't want to in=
clude a metric in your ICV, and that metric is in TLV type X (probably a fu=
ll type with type extension, but that's another of
 those details) then as a new variant type extension ICV, you could add som=
ething to say "remove all TLVs with type extensions X, Y, Z before cal=
culating ICV). Or maybe that needs to be a range. Or ... but first work out=
 exactly what you want, then how it cleanly
 generalises (where a good generalisation is easier to implement than the s=
pecial case).

>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer, Communications Group

>> Communications, Networks and Image Analysis Capability

>> BAE Systems Advanced Technology Centre

>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

>> Tel: +44 1=
245 242194 | =A0Fax: 
+44 1245 242124

>> chris.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>>

>> BAE Systems (Operations) Limited

>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=
 Centre, Farnborough, Hants, GU14 6YU, UK

>> Registered in England & Wales No: 1996687

>>

>>

>> -----Original Message-----

>> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]

>> Sent: 24 April 2013 17:12

>> To: Dearlove, Christopher (UK)

>> Cc: manet@ietf=
.org

>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.t=
xt

>>

>> ----------------------! WARNING ! ----------------------

>> This message originates from outside our organisation,

>> either from an external partner or from the internet.

>> Keep this in mind if you answer this message.

>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> Hi,

>>

>> After several mail exchange with some of the other authors, I thin=
k it would be better to keep the draft as it is on the mutable fields, beca=
use how to define/use protocol-specific mutable fields is not very clear at=
 this point.


>> If necessary, it would probably be better to put them in another d=
ocument, after we figuring out exactly how to handle those fields.

>>

>> best

>>

>> Jiazi

>>

>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:

>>

>>> Chris,

>>>

>>> I do understand your concern. We had this kind of discussion o=
n mutable fields before, and this is something I'm still mulling over.<=
br>
>>> The reason why I propose this for discussion is:

>>>

>>> =A0 =A0 - this rfc6622bis is for rfc5444, which is a general f=
ormat for all manet protocols.

>>> =A0 =A0 - The reactive protocol like LOADng does explicitly de=
fine such "mutable" fields. It is something at hand, not in the f=
ar future.

>>>

>>> In the meantime, I do agree that the necessity and how to take=
 care of such mutable fields should be considered carefully.

>>> So I would agree that we keep the current rfc6622bis draft as =
it is for the moment, and I'll have more discussions with other LOADng =
authors on this.

>>>

>>> best

>>>

>>> Jiazi

>>>

>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)=
" <Chris.Dearlove@baesystems.com> wrote:

>>>

>>>> Jiazi

>>>>

>>>> Thanks for that, I'll just comment on the one point wh=
ere I disagree.

>>>>

>>>> Putting some vague words in that protocols may indicate fi=
elds not to be covered is the sort of thing that I can predict will cause u=
s problems at the IESG. And it's not really a good plan for a generic m=
echanism that can - at at present - be run independently
 of the routing protocol to acquire a protocol dependence. Rather I think t=
hat any routing protocols with a specific need to exclude data (which, all =
else being equal is a bad thing of course) should consider defining a new t=
ype extension - preferably one defined
 with some generic capability (could it, for example, list TLV types to be =
excluded?) But that's for the future. One thing I have learned is that =
design in advance of what might hypothetically be needed generally gets it =
wrong, so it would be good to wait until
 exactly what's needed is clear, and then define a new case.

>>>>

>>>> Christopher

>>>>

>>>> --

>>>> Christopher Dearlove

>>>> Senior Principal Engineer, Communications Group

>>>> Communications, Networks and Image Analysis Capability

>>>> BAE Systems Advanced Technology Centre

>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,=
 UK

>>>> Tel: +44 1245 242194 | =A0Fax: 
+44 1245 242124

>>>> chris.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>>>>

>>>> BAE Systems (Operations) Limited

>>>> Registered Office: Warwick House, PO Box 87, Farnborough A=
erospace Centre, Farnborough, Hants, GU14 6YU, UK

>>>> Registered in England & Wales No: 1996687

>>>>

>>>> -----Original Message-----

>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
ietf@jiaziyi.com<=
br>
>>>> Sent: 23 April 2013 15:37

>>>> To: ma=
net@ietf.org

>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>>

>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,

>>>> either from an external partner or from the internet.

>>>> Keep this in mind if you answer this message.

>>>> Follow the 'Report Suspicious Emails' link on IT m=
atters

>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>

>>>> (sorry if you receive duplicate of this message. Some of m=
y mails to

>>>> the mailing list are rejected, and I'm trying to figur=
e out with our

>>>> secretary...)

>>>>

>>>> Hi,

>>>>

>>>> I had a review of the draft. I think it's in good shap=
e, and ready for

>>>> WGLC.

>>>>

>>>> a few comments:

>>>>

>>>> In section 6 & 7, I didn't find the definition of =
notation

>>>> =A0 =A0<foo>+

>>>> Not in this draft, either rfc 5444.

>>>>

>>>> page 13, =A0source code address =3D=3D> source node add=
ress?

>>>>

>>>> section 9.1 bullet 1 states that the <msg-hop-limit>=
 and

>>>> <msg-hop-count> must be zeroed before calculating IC=
V. I'm thinking

>>>> about that we might need to mention that some protocol-spe=
cific mutable

>>>> fields must be zeroed here also. For example, in LOADng, a=
s a reactive

>>>> protocol, metric fields are defined as "mutable"=
 (in the meantime, I

>>>> still have some thoughts on those mutable fields that I ne=
ed to discuss

>>>> with other LOADng authors, but it's not that relevant =
here).

>>>>

>>>> best

>>>>

>>>> Jiazi

>>>>

>>>>

>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:

>>>>

>>>>

>>>> A New Internet-Draft is available from the on-line Interne=
t-Drafts

>>>> directories.

>>>> This draft is a work item of the Mobile Ad-hoc Networks Wo=
rking Group

>>>> of the IETF.

>>>>

>>>> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Integrity Check Value a=
nd Timestamp TLV Definitions

>>>> for Mobile Ad Hoc Networks (MANETs)

>>>> =A0 =A0Author(s) =A0 =A0 =A0 : Ulrich Herberg

>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Cl=
ausen

>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christopher Dea=
rlove

>>>> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 24

>>>> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-15

>>>>

>>>> Abstract:

>>>> This document revises, extends and replaces RFC 6622. =A0I=
t describes

>>>> general and flexible TLVs for representing cryptographic I=
ntegrity

>>>> Check Values (ICVs) and timestamps, using the generalized =
Mobile Ad

>>>> Hoc Network (MANET) packet/message format defined in RFC 5=
444. =A0It

>>>> defines two Packet TLVs, two Message TLVs, and two Address=
 Block TLVs

>>>> for affixing ICVs and timestamps to a packet, a message, a=
nd one or

>>>> more addresses, respectively.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> 
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

>>>>

>>>> There's also a htmlized version available at:

>>>> 
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

>>>>

>>>> A diff from the previous version is available at:

>>>> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@=
ietf.org

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

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@=
ietf.org

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

>>>>

>>>>

>>>> **********************************************************=
**********

>>>> This email and any attachments are confidential to the int=
ended

>>>> recipient and may also be privileged. If you are not the i=
ntended

>>>> recipient please delete it from your system and notify the=
 sender.

>>>> You should not copy it or use it for any purpose nor discl=
ose or

>>>> distribute its contents to any other person.

>>>> **********************************************************=
**********

>>>>

>>>

>>

>>

>

>



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet








=A0












--e89a8ff1c6ba50e5ec04db449bca--

From Chris.Dearlove@baesystems.com  Fri Apr 26 07:50:07 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904CA21F997D for ; Fri, 26 Apr 2013 07:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpt3mSwxdtbE for ; Fri, 26 Apr 2013 07:50:04 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0199621F997C for ; Fri, 26 Apr 2013 07:50:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,559,1363132800";  d="scan'208,217";a="282111738"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Apr 2013 15:50:01 +0100
Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3QEo0j8025604 for ; Fri, 26 Apr 2013 15:50:00 +0100
X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208,217";a="14337500"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 26 Apr 2013 15:49:59 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 15:49:59 +0100
From: "Dearlove, Christopher (UK)" 
To: Abdussalam Baryun 
Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
Thread-Index: AQHOQC/4dwosW8Q57kaBNPnQXb4xXJjlDicwgAAU3QCAAFjWAIAAER2g///65QCAASFvgIABs7WAgAAmhgCAABDsQP//9DYAgAAQ52A=
Date: Fri, 26 Apr 2013 14:49:58 +0000
Message-ID: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>        
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065145GLKXM0002VGREEN_"
MIME-Version: 1.0
Cc: "manet@ietf.org" , Jiazi Yi 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 14:50:07 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065145GLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You have read it, right? So you've read the section where it discusses what=
 happens in a non-synchronised network. 9.2 if you want a hint.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A=
bdussalam Baryun
Sent: 26 April 2013 15:47
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Jiazi Yi
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
In MANET practice nothing is ideal, maybe can be assumed in fixed wireless =
networks. I mean to state; does the document suggest parameters for non-syn=
chronised network =3D practical manet.

AB

On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christopher (UK) > wrote:
I don't believe that is what Jiazi said. Furthermore the document already d=
iscusses synchronization issues, from the need to relax constraints if sync=
hronisation is not possible, to a note in the Limitations section about wha=
t to do if synchronisation is not possible.

The actual nit here is nothing to do with synchronisation issues, but which=
 parameters to use as suggested bounds when synchronisation is ideal. I thi=
nk the choice should be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b)=
 H_HOLD_TIME and T_HOLD_TIME. In case (a) we should drop the "significantly=
 less" caveat. Note that what we are actually saying is that the parameter =
is greater than is how long the message might take to arrive, but we don't =
have that, we just have the indicated parameters. (A sophisticated implemen=
tation could choose to use the sender's versions of these read from INTERVA=
L_TIME and VALIDITY_TIME TLVs. But really, as this is guidance, it's not cr=
itical.)

Preferences: (a) or (b)? - We can put this in with other nits found.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http:=
//www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 26 April 2013 15:29
To: Jiazi Yi
Cc: Dearlove, Christopher (UK); manet@ietf.org

Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.

Keep this in mind if you answer this message.
Please see this process on how to=
 deal with suspicious emails.
I agree with you, the document should state synchronization issues/concerns=
,

AB

On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi > wrote:
Hi,

On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" > wrote:

> I think you missed something. Though there is a point we might have to co=
nsider that I'll get to.
>
> These are constraints on your internal parameters. Let me just consider t=
he HELLO ones, obviously the TC ones are similar.
>
> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the message appears to =
be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". Obviously that only=
 makes sense for a positive age, hence the first constraint. That doesn't m=
atter about synchronisation. It's actually a fairly obvious thing that almo=
st doesn't need saying (but also see a bit later).
Yes. I agree. If we assume "network can be synchronized with sufficient pre=
cision", then the value can only be positive.
Of course, if the network is not well synchronized, a negative is possible.


>
> Now sticking for the moment to an assumption that we can measure the age =
of a packet/message, we want to bound how much slack we should allow. And t=
hat's the second constraint. (Right this moment I'm not sure why we picked =
REFRESH_INTERVAL rather than HELLO_INTERVAL, but it actually works either w=
ay.) But this is where synchronisation comes in (and why the_DIFF suffix). =
We measure the age by comparing our clock with the timestamp. If synchronis=
ed then that's the age, done.
I'm just a little confused by why "assuming ideal time synchronization" is =
related to the constraints of

        "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL"

I didn't quite get the relation here.
What I understand is that, the "age" calculated by

        local_router_time - HELLO_timestamp

is only related to transmission delay of the message (if no attack happens)=
.  When it is regarded "too old" (age > MAX_HELLO_TIMESTAMP_DIFF), it is di=
scarded.


>
> If there's a synchronisation error, let's suppose we received at t2, it c=
laims to be sent at t1, but (based on our clock) was actually sent at t1+e.=
 So our test is
>
> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF
>
> but the age of the message, A is t2 - t1 - e, so
>
> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e
>
> So if we want to only reject messages that are definitely too late, we ne=
ed to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assume e=
 is symmetrically distributed +ve and -ve. In turn this means that we shoul=
d allow an extra margin of e on the constraint MAX_HELLO_TIMESTAMP_DIFF < R=
EFRESH_INTERVAL.
>
> Now the point of interest. What if we receive a message with an apparent =
negative age? If that's greater than the minimum value of e (or -e) that's =
fine. But more than that? Should we reject such messages?
Apparently, if the network is not synchronized, a negative age can happen. =
What I understand is that, this document won't take care of synchronization=
 and related error? Because those would be another big problem to deal with=
...

best

Jiazi

>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | htt=
p://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre=
, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
> Sent: 24 April 2013 17:55
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> Thanks Chris for sharing your thought.
>
> Yes, those are all possibilities to consider. And a more fundamental issu=
e I'm thinking about is the framework for securing re-active protocols, bec=
ause it's much harder than pro-acitve ones. For example, do we want to requ=
ire hop-by-hop authentication? Zeroing the metric field opens possible atta=
ck vector also... anyway, we can discuss this in other topics in the future=
.
>
> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec-02=
, and I think it is fairly clear. I would support it for WGLC.
>
> Just one question:
>
> In the draft:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The following constraints apply to these parameters:
>
>   o  MAX_HELLO_TIMESTAMP_DIFF > 0
>
>   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
>
>   o  MAX_TC_TIMESTAMP_DIFF > 0
>
>   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
>
>   The second and fourth of those constraints assume ideal time
>   synchronization of the clocks in all routers in the network.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> My understanding is that, "the time difference equals 0" is for ideal tim=
e synchronization. So it should be The first and third assume ideal time sy=
nchronization? Or I missed something here?
>
> best
>
> Jiazi
>
> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" > wrote:
>
>> Thanks for that. I'm hoping we can proceed push out 6622bis, and the sec=
urity document.
>>
>> As a contribution to that future concept, I'll note that 6622(bis) is in=
dependent of the protocol. That I think is a desirable thing.
>>
>> One idea (I'm not sold on it, it's just for consideration) is that if yo=
u are considering that, for example, you don't want to include a metric in =
your ICV, and that metric is in TLV type X (probably a full type with type =
extension, but that's another of those details) then as a new variant type =
extension ICV, you could add something to say "remove all TLVs with type ex=
tensions X, Y, Z before calculating ICV). Or maybe that needs to be a range=
. Or ... but first work out exactly what you want, then how it cleanly gene=
ralises (where a good generalisation is easier to implement than the specia=
l case).
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124<=
tel:%2B44%201245%20242124>
>> chris.dearlove@baesystems.com | ht=
tp://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr=
e, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]
>> Sent: 24 April 2013 17:12
>> To: Dearlove, Christopher (UK)
>> Cc: manet@ietf.org
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters
>> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> Hi,
>>
>> After several mail exchange with some of the other authors, I think it w=
ould be better to keep the draft as it is on the mutable fields, because ho=
w to define/use protocol-specific mutable fields is not very clear at this =
point.
>> If necessary, it would probably be better to put them in another documen=
t, after we figuring out exactly how to handle those fields.
>>
>> best
>>
>> Jiazi
>>
>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi > wrote:
>>
>>> Chris,
>>>
>>> I do understand your concern. We had this kind of discussion on mutable=
 fields before, and this is something I'm still mulling over.
>>> The reason why I propose this for discussion is:
>>>
>>>     - this rfc6622bis is for rfc5444, which is a general format for all=
 manet protocols.
>>>     - The reactive protocol like LOADng does explicitly define such "mu=
table" fields. It is something at hand, not in the far future.
>>>
>>> In the meantime, I do agree that the necessity and how to take care of =
such mutable fields should be considered carefully.
>>> So I would agree that we keep the current rfc6622bis draft as it is for=
 the moment, and I'll have more discussions with other LOADng authors on th=
is.
>>>
>>> best
>>>
>>> Jiazi
>>>
>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)" > wrote:
>>>
>>>> Jiazi
>>>>
>>>> Thanks for that, I'll just comment on the one point where I disagree.
>>>>
>>>> Putting some vague words in that protocols may indicate fields not to =
be covered is the sort of thing that I can predict will cause us problems a=
t the IESG. And it's not really a good plan for a generic mechanism that ca=
n - at at present - be run independently of the routing protocol to acquire=
 a protocol dependence. Rather I think that any routing protocols with a sp=
ecific need to exclude data (which, all else being equal is a bad thing of =
course) should consider defining a new type extension - preferably one defi=
ned with some generic capability (could it, for example, list TLV types to =
be excluded?) But that's for the future. One thing I have learned is that d=
esign in advance of what might hypothetically be needed generally gets it w=
rong, so it would be good to wait until exactly what's needed is clear, and=
 then define a new case.
>>>>
>>>> Christopher
>>>>
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer, Communications Group
>>>> Communications, Networks and Image Analysis Capability
>>>> BAE Systems Advanced Technology Centre
>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>>> Tel: +44 1245 242194 |  Fax: +44 1245 24212=
4
>>>> chris.dearlove@baesystems.com | =
http://www.baesystems.com
>>>>
>>>> BAE Systems (Operations) Limited
>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK
>>>> Registered in England & Wales No: 1996687
>>>>
>>>> -----Original Message-----
>>>> From: manet-bounces@ietf.org [mailto:ma=
net-bounces@ietf.org] On Behalf Of ietf@jiaz=
iyi.com
>>>> Sent: 23 April 2013 15:37
>>>> To: manet@ietf.org
>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>>>>
>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,
>>>> either from an external partner or from the internet.
>>>> Keep this in mind if you answer this message.
>>>> Follow the 'Report Suspicious Emails' link on IT matters
>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>
>>>> (sorry if you receive duplicate of this message. Some of my mails to
>>>> the mailing list are rejected, and I'm trying to figure out with our
>>>> secretary...)
>>>>
>>>> Hi,
>>>>
>>>> I had a review of the draft. I think it's in good shape, and ready for
>>>> WGLC.
>>>>
>>>> a few comments:
>>>>
>>>> In section 6 & 7, I didn't find the definition of notation
>>>>    +
>>>> Not in this draft, either rfc 5444.
>>>>
>>>> page 13,  source code address =3D=3D> source node address?
>>>>
>>>> section 9.1 bullet 1 states that the  and
>>>>  must be zeroed before calculating ICV. I'm thinking
>>>> about that we might need to mention that some protocol-specific mutabl=
e
>>>> fields must be zeroed here also. For example, in LOADng, as a reactive
>>>> protocol, metric fields are defined as "mutable" (in the meantime, I
>>>> still have some thoughts on those mutable fields that I need to discus=
s
>>>> with other LOADng authors, but it's not that relevant here).
>>>>
>>>> best
>>>>
>>>> Jiazi
>>>>
>>>>
>>>> On Apr 15, 2013, at 5:59 PM, internet-drafts@ietf.org wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
>>>> of the IETF.
>>>>
>>>>    Title           : Integrity Check Value and Timestamp TLV Definitio=
ns
>>>> for Mobile Ad Hoc Networks (MANETs)
>>>>    Author(s)       : Ulrich Herberg
>>>>                      Thomas Heide Clausen
>>>>                      Christopher Dearlove
>>>>    Filename        : draft-ietf-manet-rfc6622-bis-02.txt
>>>>    Pages           : 24
>>>>    Date            : 2013-04-15
>>>>
>>>> Abstract:
>>>> This document revises, extends and replaces RFC 6622.  It describes
>>>> general and flexible TLVs for representing cryptographic Integrity
>>>> Check Values (ICVs) and timestamps, using the generalized Mobile Ad
>>>> Hoc Network (MANET) packet/message format defined in RFC 5444.  It
>>>> defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
>>>> for affixing ICVs and timestamps to a packet, a message, and one or
>>>> more addresses, respectively.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> ********************************************************************
>>>> This email and any attachments are confidential to the intended
>>>> recipient and may also be privileged. If you are not the intended
>>>> recipient please delete it from your system and notify the sender.
>>>> You should not copy it or use it for any purpose nor disclose or
>>>> distribute its contents to any other person.
>>>> ********************************************************************
>>>>
>>>
>>
>>
>
>

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



--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065145GLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











You have read it, right? =
So you've read the section where it discusses what happens in a non-synchro=
nised network. 9.2 if you want a hint.


 <=
/p>

chris.dearlove@baesystems.com
 | http://www.baesystems.com



BAE Systems (O=
perations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687


 <=
/p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org=
]
On Behalf Of Abdussalam Baryun

Sent: 26 April 2013 15:47

To: Dearlove, Christopher (UK)

Cc: manet@ietf.org; Jiazi Yi

Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt=



 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Ke=
ep this in mind if you answer this message.

Pl=
ease see 
this process on how to deal with suspicious emails.<=
/i>










In MANET practice nothing is ideal, maybe can be ass=
umed in fixed wireless networks. I mean to state; does the document suggest=
 parameters for non-synchronised network =3D practical manet.





 






AB








 




On Fri, Apr 26, 2013 at 3:40 PM, Dearlove, Christoph=
er (UK) <Chris.Dearlove@baesystems.com> wrote:






I don't believe that is what Jiazi said=
. Furthermore the document already discusses synchronization
 issues, from the need to relax constraints if synchronisation is not possi=
ble, to a note in the Limitations section about what to do if synchronisati=
on is not possible.


 


The actual nit here is nothing to do wi=
th synchronisation issues, but which parameters to use as
 suggested bounds when synchronisation is ideal. I think the choice should =
be between (a) HELLO_INTERVAL and TC_INTERVAL, and (b) H_HOLD_TIME and T_HO=
LD_TIME. In case (a) we should drop the "significantly less" cave=
at. Note that what we are actually saying
 is that the parameter is greater than is how long the message might take t=
o arrive, but we don't have that, we just have the indicated parameters. (A=
 sophisticated implementation could choose to use the sender's versions of =
these read from INTERVAL_TIME and
 VALIDITY_TIME TLVs. But really, as this is guidance, it's not critical.)


 


Preferences: (a) or (b)? - We can put t=
his in with other nits found.




 


--



Christopher Dearlove<=
/p>

Senior Principal Engineer, Communicatio=
ns Group

Communications, Networks and Image Analysis Capability

BAE Systems Advanced Technology Centre

West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

Tel: +44 1245 2=
42194 |  Fax:
+44 1245 242124=



chris.dearlove@baesystems.com
 | http://www.baesy=
stems.com



BAE Systems (Operations) Limited

Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, =
Farnborough, Hants, GU14 6YU, UK

Registered in England & Wales No: 1996687


 




From: Abdussalam
 Baryun [mailto:abdussalambaryun@gmail.com]


Sent: 26 April 2013 15:29

To: Jiazi Yi

Cc: Dearlove, Christopher (UK); 
manet@ietf.org






Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt=





 





 =






*** WARNING ***







This message originates from outside our organ=
isation, either from an external partner or the internet.<=
/o:p>






Keep this in mind if you answer this message.




Please see

this process on how to deal with suspicious emails.














I agree with you, the document should state synchronization issues=
/concerns,






 






AB








 




On Fri, Apr 26, 2013 at 1:10 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:<=
/o:p>


Hi,






On Apr 25, 2013, at 11:26 AM, "Dearlove, Christopher (UK)" <Chris.Dear=
love@baesystems.com> wrote:



> I think you missed something. Though there is a point we might have to=
 consider that I'll get to.

>

> These are constraints on your internal parameters. Let me just conside=
r the HELLO ones, obviously the TC ones are similar.

>

> The basic use of MAX_HELLO_TIMESTAMP_DIFF is  "if the messag=
e appears to be older than MAX_HELLO_TIMESTAMP_DIFF, throw it away". O=
bviously that only makes sense for a positive age, hence the first constrai=
nt. That doesn't matter about synchronisation. It's
 actually a fairly obvious thing that almost doesn't need saying (but also =
see a bit later).




Yes. I agree. If we assume "network can be synchronized with =
sufficient precision", then the value can only be positive.

Of course, if the network is not well synchronized, a negative is possible.=









>

> Now sticking for the moment to an assumption that we can measure the a=
ge of a packet/message, we want to bound how much slack we should allow. An=
d that's the second constraint. (Right this moment I'm not sure why we pick=
ed REFRESH_INTERVAL rather than HELLO_INTERVAL,
 but it actually works either way.) But this is where synchronisation comes=
 in (and why the_DIFF suffix). We measure the age by comparing our clock wi=
th the timestamp. If synchronised then that's the age, done.




I'm just a little confused by why "assuming ideal time synchr=
onization" is related to the constraints of



        "MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INT=
ERVAL"



I didn't quite get the relation here.

What I understand is that, the "age" calculated by



        local_router_time - HELLO_timestamp



is only related to transmission delay of the message (if no attack happens)=
.  When it is regarded "too old" (age > MAX_HELLO_TIMESTA=
MP_DIFF), it is discarded.








>

> If there's a synchronisation error, let's suppose we received at t2, i=
t claims to be sent at t1, but (based on our clock) was actually sent at t1=
+e. So our test is

>

> (t2 - t1) <=3D MAX_HELLO_TIMESTAMP_DIFF

>

> but the age of the message, A is t2 - t1 - e, so

>

> A <=3D MAX_HELLO_TIMESTAMP_DIFF - e

>

> So if we want to only reject messages that are definitely too late, we=
 need to increase MAX_HELLO_TIMESTAMP_DIFF by the maximum value of e (assum=
e e is symmetrically distributed +ve and -ve. In turn this means that w=
e should allow an extra margin of e on
 the constraint MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL.

>

> Now the point of interest. What if we receive a message with an appare=
nt negative age? If that's greater than the minimum value of e (or -e) that=
's fine. But more than that? Should we reject such messages?




Apparently, if the network is not synchronized, a negative age can=
 happen. What I understand is that, this document won't take care of synchr=
onization and related error? Because
 those would be another big problem to deal with...



best



Jiazi








>

> --

> Christopher Dearlove

> Senior Principal Engineer, Communications Group

> Communications, Networks and Image Analysis Capability

> BAE Systems Advanced Technology Centre

> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

> Tel: +44 1=
245 242194 |  Fax:
+44 1245 242124=


> chr=
is.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>

> BAE Systems (Operations) Limited

> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen=
tre, Farnborough, Hants, GU14 6YU, UK

> Registered in England & Wales No: 1996687

>

>

> -----Original Message-----

> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]

> Sent: 24 April 2013 17:55

> To: Dearlove, Christopher (UK)

> Cc: manet@ietf.org=


> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
>

> ----------------------! WARNING ! ----------------------

> This message originates from outside our organisation,

> either from an external partner or from the internet.

> Keep this in mind if you answer this message.

> Follow the 'Report Suspicious Emails' link on IT matters

> for instructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Thanks Chris for sharing your thought.

>

> Yes, those are all possibilities to consider. And a more fundamental i=
ssue I'm thinking about is the framework for securing re-active protocols, =
because it's much harder than pro-acitve ones. For example, do we want to r=
equire hop-by-hop authentication? Zeroing
 the metric field opens possible attack vector also... anyway, we can discu=
ss this in other topics in the future.

>

> In the meantime, I reviewed the draft draft-ietf-manet-nhdp-olsrv2-sec=
-02, and I think it is fairly clear. I would support it for WGLC.

>

> Just one question:

>

> In the draft:

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> The following constraints apply to these parameters:

>

>   o  MAX_HELLO_TIMESTAMP_DIFF > 0

>

>   o  MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL

>

>   o  MAX_TC_TIMESTAMP_DIFF > 0

>

>   o  MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME

>

>   The second and fourth of those constraints assume ideal time
>   synchronization of the clocks in all routers in the network.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> My understanding is that, "the time difference equals 0" is =
for ideal time synchronization. So it should be The first and third assume =
ideal time synchronization? Or I missed something here?

>

> best

>

> Jiazi

>

> On Apr 24, 2013, at 6:19 PM, "Dearlove, Christopher (UK)" &l=
t;Chris.=
Dearlove@baesystems.com> wrote:

>

>> Thanks for that. I'm hoping we can proceed push out 6622bis, and t=
he security document.

>>

>> As a contribution to that future concept, I'll note that 6622(bis)=
 is independent of the protocol. That I think is a desirable thing.

>>

>> One idea (I'm not sold on it, it's just for consideration) is that=
 if you are considering that, for example, you don't want to include a metr=
ic in your ICV, and that metric is in TLV type X (probably a full type with=
 type extension, but that's another of
 those details) then as a new variant type extension ICV, you could add som=
ething to say "remove all TLVs with type extensions X, Y, Z before cal=
culating ICV). Or maybe that needs to be a range. Or ... but first work out=
 exactly what you want, then how it cleanly
 generalises (where a good generalisation is easier to implement than the s=
pecial case).

>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer, Communications Group

>> Communications, Networks and Image Analysis Capability

>> BAE Systems Advanced Technology Centre

>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK

>> Tel: +=
44 1245 242194 |  Fax:
+44 1245 242124=


>> chris.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>>

>> BAE Systems (Operations) Limited

>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=
 Centre, Farnborough, Hants, GU14 6YU, UK

>> Registered in England & Wales No: 1996687

>>

>>

>> -----Original Message-----

>> From: Jiazi Yi [mailto:yi.jiazi@gmail.com]

>> Sent: 24 April 2013 17:12

>> To: Dearlove, Christopher (UK)

>> Cc: manet@ietf=
.org

>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.t=
xt

>>

>> ----------------------! WARNING ! ----------------------

>> This message originates from outside our organisation,

>> either from an external partner or from the internet.

>> Keep this in mind if you answer this message.

>> Follow the 'Report Suspicious Emails' link on IT matters

>> for instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> Hi,

>>

>> After several mail exchange with some of the other authors, I thin=
k it would be better to keep the draft as it is on the mutable fields, beca=
use how to define/use protocol-specific mutable fields is not very clear at=
 this point.

>> If necessary, it would probably be better to put them in another d=
ocument, after we figuring out exactly how to handle those fields.

>>

>> best

>>

>> Jiazi

>>

>> On Apr 24, 2013, at 12:54 PM, Jiazi Yi <yi.jiazi@gmail.com> wrote:

>>

>>> Chris,

>>>

>>> I do understand your concern. We had this kind of discussion o=
n mutable fields before, and this is something I'm still mulling over.

>>> The reason why I propose this for discussion is:

>>>

>>>     - this rfc6622bis is for rfc5444, which is a gen=
eral format for all manet protocols.

>>>     - The reactive protocol like LOADng does explici=
tly define such "mutable" fields. It is something at hand, not in=
 the far future.

>>>

>>> In the meantime, I do agree that the necessity and how to take=
 care of such mutable fields should be considered carefully.

>>> So I would agree that we keep the current rfc6622bis draft as =
it is for the moment, and I'll have more discussions with other LOADng auth=
ors on this.

>>>

>>> best

>>>

>>> Jiazi

>>>

>>> On Apr 24, 2013, at 10:47 AM, "Dearlove, Christopher (UK)=
" <Chris.Dearlove@baesystems.com> wrote:

>>>

>>>> Jiazi

>>>>

>>>> Thanks for that, I'll just comment on the one point where =
I disagree.

>>>>

>>>> Putting some vague words in that protocols may indicate fi=
elds not to be covered is the sort of thing that I can predict will cause u=
s problems at the IESG. And it's not really a good plan for a generic mecha=
nism that can - at at present - be run independently
 of the routing protocol to acquire a protocol dependence. Rather I think t=
hat any routing protocols with a specific need to exclude data (which, all =
else being equal is a bad thing of course) should consider defining a new t=
ype extension - preferably one defined
 with some generic capability (could it, for example, list TLV types to be =
excluded?) But that's for the future. One thing I have learned is that desi=
gn in advance of what might hypothetically be needed generally gets it wron=
g, so it would be good to wait until
 exactly what's needed is clear, and then define a new case.

>>>>

>>>> Christopher

>>>>

>>>> --

>>>> Christopher Dearlove

>>>> Senior Principal Engineer, Communications Group

>>>> Communications, Networks and Image Analysis Capability

>>>> BAE Systems Advanced Technology Centre

>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,=
 UK

>>>> Tel: +44 1245 242194 |  Fax:
+44 1245 242124=


>>>> chris.dearlove@baesystems.com |
http://www.baesyste=
ms.com

>>>>

>>>> BAE Systems (Operations) Limited

>>>> Registered Office: Warwick House, PO Box 87, Farnborough A=
erospace Centre, Farnborough, Hants, GU14 6YU, UK

>>>> Registered in England & Wales No: 1996687

>>>>

>>>> -----Original Message-----

>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
ietf@jiaziyi.com<=
br>
>>>> Sent: 23 April 2013 15:37

>>>> To: ma=
net@ietf.org

>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-=
bis-02.txt

>>>>

>>>> ----------------------! WARNING ! ----------------------
>>>> This message originates from outside our organisation,

>>>> either from an external partner or from the internet.

>>>> Keep this in mind if you answer this message.

>>>> Follow the 'Report Suspicious Emails' link on IT matters
>>>> for instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>

>>>> (sorry if you receive duplicate of this message. Some of m=
y mails to

>>>> the mailing list are rejected, and I'm trying to figure ou=
t with our

>>>> secretary...)

>>>>

>>>> Hi,

>>>>

>>>> I had a review of the draft. I think it's in good shape, a=
nd ready for

>>>> WGLC.

>>>>

>>>> a few comments:

>>>>

>>>> In section 6 & 7, I didn't find the definition of nota=
tion

>>>>    <foo>+

>>>> Not in this draft, either rfc 5444.

>>>>

>>>> page 13,  source code address =3D=3D> source node =
address?

>>>>

>>>> section 9.1 bullet 1 states that the <msg-hop-limit>=
 and

>>>> <msg-hop-count> must be zeroed before calculating IC=
V. I'm thinking

>>>> about that we might need to mention that some protocol-spe=
cific mutable

>>>> fields must be zeroed here also. For example, in LOADng, a=
s a reactive

>>>> protocol, metric fields are defined as "mutable"=
 (in the meantime, I

>>>> still have some thoughts on those mutable fields that I ne=
ed to discuss

>>>> with other LOADng authors, but it's not that relevant here=
).

>>>>

>>>> best

>>>>

>>>> Jiazi

>>>>

>>>>

>>>> On Apr 15, 2013, at 5:59 PM, 
internet-drafts@ietf.org wrote:

>>>>

>>>>

>>>> A New Internet-Draft is available from the on-line Interne=
t-Drafts

>>>> directories.

>>>> This draft is a work item of the Mobile Ad-hoc Networks Wo=
rking Group

>>>> of the IETF.

>>>>

>>>>    Title           : In=
tegrity Check Value and Timestamp TLV Definitions

>>>> for Mobile Ad Hoc Networks (MANETs)

>>>>    Author(s)       : Ulrich Herbe=
rg

>>>>                 &n=
bsp;    Thomas Heide Clausen

>>>>                 &n=
bsp;    Christopher Dearlove

>>>>    Filename        : draft-i=
etf-manet-rfc6622-bis-02.txt

>>>>    Pages           : 24=


>>>>    Date            =
;: 2013-04-15

>>>>

>>>> Abstract:

>>>> This document revises, extends and replaces RFC 6622. &nbs=
p;It describes

>>>> general and flexible TLVs for representing cryptographic I=
ntegrity

>>>> Check Values (ICVs) and timestamps, using the generalized =
Mobile Ad

>>>> Hoc Network (MANET) packet/message format defined in RFC 5=
444.  It

>>>> defines two Packet TLVs, two Message TLVs, and two Address=
 Block TLVs

>>>> for affixing ICVs and timestamps to a packet, a message, a=
nd one or

>>>> more addresses, respectively.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> 
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis

>>>>

>>>> There's also a htmlized version available at:

>>>> 
http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-02

>>>>

>>>> A diff from the previous version is available at:

>>>> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-02

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@=
ietf.org

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

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@=
ietf.org

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

>>>>

>>>>

>>>> **********************************************************=
**********

>>>> This email and any attachments are confidential to the int=
ended

>>>> recipient and may also be privileged. If you are not the i=
ntended

>>>> recipient please delete it from your system and notify the=
 sender.

>>>> You should not copy it or use it for any purpose nor discl=
ose or

>>>> distribute its contents to any other person.

>>>> **********************************************************=
**********

>>>>

>>>

>>

>>

>

>



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet








 














 








--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25065145GLKXM0002VGREEN_--

From abdussalambaryun@gmail.com  Fri Apr 26 23:08:30 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7121F98D3 for ; Fri, 26 Apr 2013 23:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_102=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48K0DlRWVKQH for ; Fri, 26 Apr 2013 23:08:30 -0700 (PDT)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 300D421F98BD for ; Fri, 26 Apr 2013 23:08:30 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id u10so2798565pdi.25 for ; Fri, 26 Apr 2013 23:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TDC702JeFAt+7txF6ZuAtf98VgZcH+lkboPoFY6dxg0=; b=x3nvuByfzSzr2fXkpB+VlIEKBylSLCQ41KxAngYUBMpIXVGcNkANMmjyUpCWBu+SL2 3arCKTbEoPJylZ4oiwJyUIiOMhEktTcG++G8ZL6aQr265t9bCXnA26uNzdenDLUE0swk H+tn7p1xC5oulx677lP0iNvk/N4Md29djUu6eFV27pDPone6t2Px9VZwoCx/FXNUOSVo DOosmsRtfb6Tk4v4WjlcmgYklVCxEva/iA0giGJH4mt6bXTPGQ92yj53jx/uTMR8657e NwuL4DTb/NCPDMvp+a7HC5jdbBk0VWR59qM2n+dPdU4HsSmOJr8sSf0tcXq6iunx9U+5 MV5Q==
MIME-Version: 1.0
X-Received: by 10.68.13.135 with SMTP id h7mr62108639pbc.113.1367042909960; Fri, 26 Apr 2013 23:08:29 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Fri, 26 Apr 2013 23:08:29 -0700 (PDT)
In-Reply-To: 
References:   <2C47B8A7-B8DA-460F-9CE8-68D86659DCBF@gmail.com>         
Date: Sat, 27 Apr 2013 08:08:29 +0200
Message-ID: 
From: Abdussalam Baryun 
To: "Dearlove, Christopher (UK)" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "manet@ietf.org" 
Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Apr 2013 06:08:31 -0000

Hi Chris,

I am trying to understand the document and sorry if confused. IMO the
document assuming synchronised clocks of routers for integrity check,
my comments below,

On Fri, Apr 26, 2013 at 3:49 PM, Dearlove, Christopher (UK) <
Chris.Dearlove@baesystems.com> wrote:

>  You have read it, right? So you've read the section where it discusses
>  what happens in a non-synchronised network. 9.2 if you want a hint.****

I didnot do my final read but yes read through 6622-bis, sorry if
confused, but interested to discuss the issue mentioned by Jiazi,

Do you mean section 9.2 of the 6622-bis I-D or section 9.2 of
nhdp-olsrv2-sec-01 I-D, the second I-D is refering to the 6622-bis
that it uses sequence number, but not finding that in the subject I-D
or 6622-bis-02.

nhdp-olsrv2-sec> If no synchronized clocks are available in the MANET,
replay attacks cannot be countered by the framework provided by this
document.  An
   alternative version of the TIMESTAMP TLV defined in [RFC6622bis],
   with a monotonic sequence number, may have some partial value in this
   case, but will necessitate adding state to record observed message
   sequence number information.

AB> is there consideration of errors in time value among clocks in
seconds that may affect functions?

AB>does the document suggest integrity parameters/issues for
non-synchronised network = practical manet?

I dont find the parameter of *monotonic sequencing number* into
6622-bis for non-synchronised clocks for integrity, but refered by
another I-D, which not clear for me.

Best regards

AB

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If authors think that this message is not correct and I need more
reading you may ignore and I will understand, so I will put my review
comments after final review. This message is a discussion of reviewing
parts of the documents (trying to understand)or reply to other
participant discussion/comments on synchronisation issues.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From adrian@olddog.co.uk  Sun Apr 28 09:59:22 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9FB21F97AF for ; Sun, 28 Apr 2013 09:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qbtseVe-g+Y for ; Sun, 28 Apr 2013 09:59:21 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A474921F9777 for ; Sun, 28 Apr 2013 09:59:20 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SGxJoc003226;  Sun, 28 Apr 2013 17:59:19 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SGxHMg003212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Apr 2013 17:59:18 +0100
From: "Adrian Farrel" 
To: 
Date: Sun, 28 Apr 2013 17:59:18 +0100
Message-ID: <000801ce4431$b9640830$2c2c1890$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5EMarthaBQspzXT9uAuNdd0PRDOg==
Content-Language: en-gb
Cc: manet@ietf.org
Subject: [manet] AD review of draft-ietf-manet-smf-mib
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Apr 2013 16:59:22 -0000

Hi,

Thanks for this document. Here is my AD review, the purpose of which is
to iron out issues before the document goes to IETF last call and IESG
review.

I don't have any major issues with your document, but here is a list of
minor points for consideration. All issues are up for discussion, but I
think  new revision is needed.

Thanks,
Adrian

---

In a couple of places you say "MIBs" when you should say "MIB modules"
For example:
   6.3  Relationship to the Future RSSA-MIBs

This is hardly important, but could do with being cleaned up.

---

Please don't use direct citations (in square brackets) within the body
of the MIB module. This is because the text of the MIB module will be
extracted and used as a standalone file. You already have Section 6.2
to ensure that all the references are made correctly, so all you need
to do is remove the square brackets, from within Section 7, leaving the
contents in place.
E.g.
OLD
         FROM SNMPv2-SMI                          -- [RFC2578]
NEW
         FROM SNMPv2-SMI                          -- RFC 2578
END

E.g.
OLD
          [SMF] Macker, J.(ed.),
          Simplified Multicast Forwarding, RFC XXXX,
          July 2012.
NEW
          RFC XXXX, Macker, J.(ed.),
          Simplified Multicast Forwarding, July 2012.
END

---

Copyright in the MIB module itself is out of date.

---

Please resolve the different 'XXXX' and 'xxxx' so that they are unique.
Thus,
        DESCRIPTION
           "The first version of this MIB module,
            published as RFC xxxx.
           "
        -- RFC-Editor assigns xxxx
        ::= { experimental xxxx }   -- to be assigned by IANA
...contains two different meanings of xxxx.

---

SmfOpModeID has
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
                        -- future (4-255)
               }

I take from this that:
1. the range of SmfOpModeID is 1-255
2. You do not want to assign 4-255 at this time

I think that means that you should have either
       SYNTAX  INTEGER (1..255)
and put the interpretation in comments (which isn't so helpful); or
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
               }

How worried are you that new values will be defined, and what will you
do when they are? If this is going to happen relatively soon, then you
would need to respin the whole RFC and MIB module to add the value. That
is a pain!

In that case, you would be better to move the TC to a separate MIB
module so that it can be updated without revising the OID of the main
module.

It may be that the operational mode needs to follow the setting of a
specific protocol field. In that case, you may prefer to put this TC in
an IANA MIB module so that it can be updated automatically.

See also comment on SmfRssaID.

---

There is a similar problem with enumerations and ranges in SmfRssaID.
Here you have:
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4)
                           -- future(5-127)
                           -- noStdAction(128-239)
                           -- experimental(240-255)
                   }

Again, I think you should either have
       SYNTAX      INTEGER (1..255)
with the information in the comment; or
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4),
                           exp0(240),
                           exp1(241),
                           exp2(242),
                           exp3(243),
                           exp4(244),
                           exp5(245),
                           exp6(246),
                           exp7(247),
                           exp8(248),
                           exp9(249),
                           exp10(250),
                           exp11(251),
                           exp12(252),
                           exp13(253),
                           exp14(254),
                           exp15(255)
                   }
and move the TC into a separate MIB module (possibly operated by IANA)
so that it can be easily updated.

---

   smfOpModeCapabilitiesReference OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object contains a reference to the document
            that defines this operational mode."
       ::= { smfOpModeCapabilitiesEntry 3 }

I think you probably need a proper reference for the format of the
string here. Is the document referenced through a URI or what?

---

You have DEFVAL clauses for a number of objects that have MAX-ACCESS
of read-write.  I don't think this makes sense.  Defaults only apply to
creatable objects meaning "this is the value to apply if this object is
created automatically without being explicitly set."

Otherwise it is entirely up to the local implementation how it sets the
object. While there may be an approved default value for a protocol
implementation, that is not a DEFVAL, but a piece of information in a
protocol specification.

---

   smfIfIndex  OBJECT-TYPE
      SYNTAX      InterfaceIndexOrZero

If you use InterfaceIndexOrZero rather than InterfaceIndex, you must
state the meaning of zero for the object.

---

Are you sure you need smfIfName in addition to ifDescr?
Are you sure you need smfIfAdminStatus in addition to ifAdminStatus?

---

A number of references of the form...

       REFERENCE
          "Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

...should really include the RFC number (i.e. 6621) to read...

       REFERENCE
          "RFC 6621, Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

For example at SmfOpModeID, but search for them all.

---

I think that the SMF Performance Group needs some discussion of wrapping
and discontinuities.  I think wrapping is as simple as making a 
statement that the counters wrap to zero.  I don't really understand how
to describe discontinuities - you need a MIB expert for that.



From adrian@olddog.co.uk  Sun Apr 28 10:31:45 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CCB21F9A0A for ; Sun, 28 Apr 2013 10:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYsdjmJiLsjf for ; Sun, 28 Apr 2013 10:31:44 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 6528921F9A06 for ; Sun, 28 Apr 2013 10:31:44 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SHVgrK008933;  Sun, 28 Apr 2013 18:31:42 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SHVfDR008927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Apr 2013 18:31:41 +0100
From: "Adrian Farrel" 
To: "'Ulrich Herberg'" 
Date: Sun, 28 Apr 2013 18:31:41 +0100
Message-ID: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5ENc6YnmznzkH6SKCSyXprZ0fARg==
Content-Language: en-gb
Cc: manet@ietf.org, draft-ietf-manet-olsrv2-mib@tools.ietf.org
Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Apr 2013 17:31:45 -0000

Hi Ulrich,

Did you intend to post a new revision to make this change? 

Thanks,
Adrian

> -----Original Message-----
> From: Ulrich Herberg [mailto:ulrich@herberg.name]
> Sent: 15 April 2013 21:11
> To: Benoit Claise
> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;
pm-dir@ietf.org;
> manet@ietf.org
> Subject: Re: [manet] performance metrics directorate review of draft-ietf-
> manet-olsrv2-mib-06
> 
> Benoit,
> 
> thank you very much for this review. I agree that using the term
> "performance information" instead of "performance metrics" is a good
> idea. We will make the change.
> 
> Best regards
> Ulrich
> 
> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise  wrote:
> > Dear all,
> >
> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
> > performance metric directorate point of view.
> >
> > This draft doesn't contain any reference to RFC6390, but contains
> > "performance metric". Hence this review was triggered. For details about the
> > directorate, see
> > http://www.ietf.org/iesg/directorate/performance-metrics.html
> >
> >
> > Definition of Managed Objects for the  Optimized Link State Routing
> > Protocol version 2
> >
> > Abstract
> >
> >    This document defines the Management Information Base (MIB) module
> >    for configuring and managing the Optimized Link State Routing
> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
> >    into state information, performance metrics, and notifications.  This
> >    additional state and performance information is useful to
> >    troubleshoot problems and performance issues of the routing protocol.
> >    Different levels of compliance allow implementers to use smaller
> >    subsets of all defined objects, allowing for this MIB module to be
> >    deployed on more constrained routers.
> >
> >
> > Basically, all performance metrics come from this table:
> >
> >    o  olsrv2InterfacePerfTable - records performance counters for each
> >       active OLSRv2 interface on this device. selected path to each
> >       destination for which any such path is known.  This table has
> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
> >       nhdpIfIndex from the NHDP-MIB.
> >
> > NHDP-MIB is RFC 6779:
> >    NhdpInterfacePerfEntry ::=
> >       SEQUENCE {
> >          nhdpIfHelloMessageXmits
> >             Counter32,
> >          nhdpIfHelloMessageRecvd
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageRecvdAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageTriggeredXmits
> >             Counter32,
> >          nhdpIfHelloMessagePeriodicXmits
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
> >             Counter32
> >       }
> >
> >
> > This draft contains similar objects in olsrv2InterfacePerfTable :
> >
> >     Olsrv2InterfacePerfEntry ::=
> >        SEQUENCE {
> >           olsrv2IfTcMessageXmits
> >              Counter32,
> >           olsrv2IfTcMessageRecvd
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageRecvdAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageTriggeredXmits
> >              Counter32,
> >           olsrv2IfTcMessagePeriodicXmits
> >              Counter32,
> >           olsrv2IfTcMessageForwardedXmits
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
> >              Counter32
> >        }
> >
> >
> > Personally, I don't believe that those objects should be subject to the RFC
> > 6390 template definition. (Performance Metric Definition Template, section
> > 5.4.4, RFC 6390).
> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> > subject to it
> > Second reason: these objects are not really performance metrics, but mainly
> > basic monitoring objects.
> >
> > Since RFC 6779 uses the term performance information (in the abstract), I
> > would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
> > the "performance metric". That would avoid some confusion. However,
> keeping
> > the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
> > reason with RFC 6779.
> >
> > Regards, Benoit
> >
> >
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
> >


From internet-drafts@ietf.org  Mon Apr 29 12:15:41 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EAB21F9BA9; Mon, 29 Apr 2013 12:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tYNfDBtYopq; Mon, 29 Apr 2013 12:15:41 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5199321F9BB2; Mon, 29 Apr 2013 12:15:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p4
Message-ID: <20130429191540.6566.84892.idtracker@ietfa.amsl.com>
Date: Mon, 29 Apr 2013 12:15:40 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-07.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 19:15:41 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of t=
he IETF.

	Title           : Definition of Managed Objects for the	 Optimized Link St=
ate Routing Protocol version 2
	Author(s)       : Ulrich Herberg
                          Robert G. Cole
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-olsrv2-mib-07.txt
	Pages           : 76
	Date            : 2013-04-29

Abstract:
   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into state information, performance information, and notifications.
   This additional state and performance information is useful to
   troubleshoot problems and performance issues of the routing protocol.
   Different levels of compliance allow implementers to use smaller
   subsets of all defined objects, allowing for this MIB module to be
   deployed on more constrained routers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ulrich@herberg.name  Mon Apr 29 12:17:21 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A29021F9BA0 for ; Mon, 29 Apr 2013 12:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3hrktC2CDQk for ; Mon, 29 Apr 2013 12:17:20 -0700 (PDT)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 630ED21F9B7C for ; Mon, 29 Apr 2013 12:17:16 -0700 (PDT)
Received: by mail-vb0-f50.google.com with SMTP id w15so691962vbb.37 for ; Mon, 29 Apr 2013 12:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EOVoiDhLwOYHkE0PB6AR4GYtNx1Q/QbEvdKsAOZf4Kg=; b=1x7xuUN4WVCca/dFSLwGvqFaHYKD4a9Sp0L/5h97j1z8FYvS03qSGzpjXes/HKTkr4 SdXRvP2PY0XMlkgAS/acuVZI+w8SPANqk9OxoyZP610EXc/TlMyPe0Q7k8dqwke95xnI YzeWFAtHrhuH9ZhLR9++fPcwb/TUDoRTDALNk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EOVoiDhLwOYHkE0PB6AR4GYtNx1Q/QbEvdKsAOZf4Kg=; b=Jt6IkKy7gXAKmAmP5utBzVJvuMuglZffV0tRFWPv8g6s+Lh4qEsgxt4gJ5U11pi3k6 HLv27u6Sqph/LgyPcbrzZfmvACi/YpsbRyvPv3WeSL2kUzYorLBMkidxvJz0XQ25tVpL YpEOoT5QFhfBhjLIMS4eb4cEUIWHvdvjQuL026aqAAm5Bb29sMVdxcK/SVanLiPYO2kh 0lZzyd8soR/Q7qdPTdrUSu7pPWCwEuJUGjCyVjwTKhaVjOJK7oFLDAsXSVoPN/HIfVnZ bkm3XJxnO8PfVOc0phuKexZR9IvX2EpD+8ks4oXKjI/sQ+LfbHuTYA9bhO/HUzV0Y/gk Iusw==
MIME-Version: 1.0
X-Received: by 10.58.151.2 with SMTP id um2mr13858964veb.28.1367263035009; Mon, 29 Apr 2013 12:17:15 -0700 (PDT)
Received: by 10.220.13.195 with HTTP; Mon, 29 Apr 2013 12:17:14 -0700 (PDT)
In-Reply-To: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk>
References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk>
Date: Mon, 29 Apr 2013 12:17:14 -0700
Message-ID: 
From: Ulrich Herberg 
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmcrSfsmEnq61QbwYrd7Hi71aQHiR7h+cHWa7d36mYXpn2gRCHqERd2RA638UhMtKvlBSrN
Cc: manet@ietf.org, draft-ietf-manet-olsrv2-mib@tools.ietf.org
Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 19:17:21 -0000

Adrian,

yes, that was my intention...but sometimes, good intentions are not enough ;-)

I have submitted a new revision with the one-word change that Benoit requested.

Best regards
Ulrich

On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel  wrote:
> Hi Ulrich,
>
> Did you intend to post a new revision to make this change?
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: Ulrich Herberg [mailto:ulrich@herberg.name]
>> Sent: 15 April 2013 21:11
>> To: Benoit Claise
>> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;
> pm-dir@ietf.org;
>> manet@ietf.org
>> Subject: Re: [manet] performance metrics directorate review of draft-ietf-
>> manet-olsrv2-mib-06
>>
>> Benoit,
>>
>> thank you very much for this review. I agree that using the term
>> "performance information" instead of "performance metrics" is a good
>> idea. We will make the change.
>>
>> Best regards
>> Ulrich
>>
>> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise  wrote:
>> > Dear all,
>> >
>> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
>> > performance metric directorate point of view.
>> >
>> > This draft doesn't contain any reference to RFC6390, but contains
>> > "performance metric". Hence this review was triggered. For details about the
>> > directorate, see
>> > http://www.ietf.org/iesg/directorate/performance-metrics.html
>> >
>> >
>> > Definition of Managed Objects for the  Optimized Link State Routing
>> > Protocol version 2
>> >
>> > Abstract
>> >
>> >    This document defines the Management Information Base (MIB) module
>> >    for configuring and managing the Optimized Link State Routing
>> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
>> >    into state information, performance metrics, and notifications.  This
>> >    additional state and performance information is useful to
>> >    troubleshoot problems and performance issues of the routing protocol.
>> >    Different levels of compliance allow implementers to use smaller
>> >    subsets of all defined objects, allowing for this MIB module to be
>> >    deployed on more constrained routers.
>> >
>> >
>> > Basically, all performance metrics come from this table:
>> >
>> >    o  olsrv2InterfacePerfTable - records performance counters for each
>> >       active OLSRv2 interface on this device. selected path to each
>> >       destination for which any such path is known.  This table has
>> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
>> >       nhdpIfIndex from the NHDP-MIB.
>> >
>> > NHDP-MIB is RFC 6779:
>> >    NhdpInterfacePerfEntry ::=
>> >       SEQUENCE {
>> >          nhdpIfHelloMessageXmits
>> >             Counter32,
>> >          nhdpIfHelloMessageRecvd
>> >             Counter32,
>> >          nhdpIfHelloMessageXmitAccumulatedSize
>> >             Counter64,
>> >          nhdpIfHelloMessageRecvdAccumulatedSize
>> >             Counter64,
>> >          nhdpIfHelloMessageTriggeredXmits
>> >             Counter32,
>> >          nhdpIfHelloMessagePeriodicXmits
>> >             Counter32,
>> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>> >             Counter32,
>> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>> >             Counter32,
>> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>> >             Counter32
>> >       }
>> >
>> >
>> > This draft contains similar objects in olsrv2InterfacePerfTable :
>> >
>> >     Olsrv2InterfacePerfEntry ::=
>> >        SEQUENCE {
>> >           olsrv2IfTcMessageXmits
>> >              Counter32,
>> >           olsrv2IfTcMessageRecvd
>> >              Counter32,
>> >           olsrv2IfTcMessageXmitAccumulatedSize
>> >              Counter64,
>> >           olsrv2IfTcMessageRecvdAccumulatedSize
>> >              Counter64,
>> >           olsrv2IfTcMessageTriggeredXmits
>> >              Counter32,
>> >           olsrv2IfTcMessagePeriodicXmits
>> >              Counter32,
>> >           olsrv2IfTcMessageForwardedXmits
>> >              Counter32,
>> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>> >              Counter32
>> >        }
>> >
>> >
>> > Personally, I don't believe that those objects should be subject to the RFC
>> > 6390 template definition. (Performance Metric Definition Template, section
>> > 5.4.4, RFC 6390).
>> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
>> > subject to it
>> > Second reason: these objects are not really performance metrics, but mainly
>> > basic monitoring objects.
>> >
>> > Since RFC 6779 uses the term performance information (in the abstract), I
>> > would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
>> > the "performance metric". That would avoid some confusion. However,
>> keeping
>> > the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
>> > reason with RFC 6779.
>> >
>> > Regards, Benoit
>> >
>> >
>> >
>> > _______________________________________________
>> > manet mailing list
>> > manet@ietf.org
>> > https://www.ietf.org/mailman/listinfo/manet
>> >
>

From Martin.Duke@boeing.com  Mon Apr 29 14:36:27 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34621F9A9C for ; Mon, 29 Apr 2013 14:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+rFuwI9h0ru for ; Mon, 29 Apr 2013 14:36:20 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 85F9121F9487 for ; Mon, 29 Apr 2013 14:36:20 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r3TLaJTS019823 for ; Mon, 29 Apr 2013 16:36:19 -0500
Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r3TLaIF3019807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 29 Apr 2013 16:36:19 -0500
Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.36]) by XCH-PHX-212.sw.nos.boeing.com ([169.254.12.134]) with mapi id 14.02.0328.011; Mon, 29 Apr 2013 14:36:18 -0700
From: "Duke, Martin" 
To: "manet@ietf.org" 
Thread-Topic: DLEP Draft 4 Nits
Thread-Index: Ac5FIZJdjzOGpSc7Q3Kvhr41QILMFw==
Date: Mon, 29 Apr 2013 21:36:17 +0000
Message-ID: <5A8A5085482DA84995F4E70F5093AB5022D373@XCH-BLV-503.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_5A8A5085482DA84995F4E70F5093AB5022D373XCHBLV503nwnosboe_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Subject: [manet] DLEP Draft 4 Nits
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 21:36:27 -0000

--_000_5A8A5085482DA84995F4E70F5093AB5022D373XCHBLV503nwnosboe_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've articulated some difficulties I have with the data item TLVs in this a=
nd previous drafts, but here are a couple of minor questions about the Mess=
age formats in  Draft 04:

-          In 9.16: Shouldn't the draft describe the Status TLV termination=
 codes somewhere?

-          Section 23: Why are Heartbeat Interval/Threshold TLVs in Heartbe=
at messages, particularly as mandatory TLVs?

-          Section 25: Shouldn't there be a Status TLV in the Link Characte=
ristics ACK Message? I can imagine routers would want to know why their req=
uests were refused.



Nits about draft 04:



-          MAC address is missing from the TLV table at the beginning of se=
ction 9.

-          In that same list, "Transmit Latency" should be "Latency", "Rece=
ive Resources" should be "Resources (Receive)", and "Transmit Resources" sh=
ould be "Resources (Transmit)".

-          In 9.17: "indicates" -> "indicate"

-          Section 11: Heartbeat Interval/Threshold is a single TLV type, n=
ot two

-          So can LINK Characteristic ACK Timer TLVs be sent by routers? Se=
ction 9.18 suggests modems only, but Section 12 the opposite.  I vote "no."

-          Section 18: "Link Factor" -> "Link Quality"

-          Section 15 states there are no optional TLVs and then lists Stat=
us as optional.

-          Section 20 refers to "Other TLVs as listed are OPTIONAL," but th=
ere are no optional TLVs.

-          Section 22: I'm not a fan of Expected Forwarding Time but don't =
know why it would be excluded from Neighbor Update Messages

-          Section 24: should probably change "Current Data Rate" to "Curre=
nt Data Rate (Transmit)"

-          Section 24/25: The definitions of Current Data Rate in these two=
 sections are switched (i.e. the ACK message should take a certain form if =
the request is denied).



Martin


--_000_5A8A5085482DA84995F4E70F5093AB5022D373XCHBLV503nwnosboe_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I’ve articulated some difficulties I have with=
 the data item TLVs in this and previous drafts, but here are a couple of m=
inor questions about the Message formats in  Draft 04:


-     &=
nbsp;   
In 9.16: Shouldn’t the draft describe the Sta=
tus TLV termination codes somewhere?


-     &=
nbsp;   
Section 23: Why are Heartbeat Interval/Threshold TL=
Vs in Heartbeat messages, particularly as mandatory TLVs?


-     &=
nbsp;   
Section 25: Shouldn’t there be a Status TLV i=
n the Link Characteristics ACK Message? I can imagine routers would want to=
 know why their requests were refused.


 


Nits about draft 04:


 


-     &=
nbsp;   
MAC address is missing from the TLV table at the be=
ginning of section 9.


-     &=
nbsp;   
In that same list, “Transmit Latency” s=
hould be “Latency”, “Receive Resources” should be &=
#8220;Resources (Receive)”, and “Transmit Resources” shou=
ld be “Resources (Transmit)”.


-     &=
nbsp;   
In 9.17: “indicates” -> “indic=
ate”


-     &=
nbsp;   
Section 11: Heartbeat Interval/Threshold is a singl=
e TLV type, not two


-     &=
nbsp;   
So can LINK Characteristic ACK Timer TLVs be sent b=
y routers? Section 9.18 suggests modems only, but Section 12 the opposite. =
 I vote “no.”


-     &=
nbsp;   
Section 18: “Link Factor” -> “=
Link Quality”


-     &=
nbsp;   
Section 15 states there are no optional TLVs and th=
en lists Status as optional.


-     &=
nbsp;   
Section 20 refers to “Other TLVs as listed ar=
e OPTIONAL,” but there are no optional TLVs.


-     &=
nbsp;   
Section 22: I’m not a fan of Expected Forward=
ing Time but don’t know why it would be excluded from Neighbor Update=
 Messages


-     &=
nbsp;   
Section 24: should probably change “Current D=
ata Rate” to “Current Data Rate (Transmit)”

-     &=
nbsp;   
Section 24/25: The definitions of Current Data Rate=
 in these two sections are switched (i.e. the ACK message should take a cer=
tain form if the request is denied).


 


Martin






--_000_5A8A5085482DA84995F4E70F5093AB5022D373XCHBLV503nwnosboe_--


From abdussalambaryun@gmail.com  Tue Apr 30 10:58:57 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFB921F9C36 for ; Tue, 30 Apr 2013 10:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqkwz8gEvKwV for ; Tue, 30 Apr 2013 10:58:53 -0700 (PDT)
Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5F21F9C2F for ; Tue, 30 Apr 2013 10:58:53 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id w11so437067pde.9 for ; Tue, 30 Apr 2013 10:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YE6x7c98mnNCqjXKKWJriwBoM+5yVOyKjAxO3RROsuQ=; b=Ay1uAGhn0ftDnCON+wK7w3eMux0Liw3qBOJhZw5ZpepGWcdGa1NMTUJ1UigH/zK3mc xZvyQkNPsp9ncBDsKlwvtu6ulJl6nX4nibGy+LuIW3WkaxOMrn3Co6RaLBCN+rAkqPdx b5fUY2qj7HsEBB6yQWXgYXrOmq7xvF7ajXEtscFw1PN1g2o2il//P2C3Fi/m6uOfYTkJ IvwplAWiKOl6ddogXrSvltQ9+0/c9wVryHMGsKcWHn++LPQQ2nxVE4PcVpMQ+rAcsBb4 bKc3fWwDxOAM3tQSVxwUGsvCiTGHO9TZ1ZWmetGf5bHM+yQHZV1Lm+f1IHKgCP0CAgKV Xf+w==
MIME-Version: 1.0
X-Received: by 10.66.160.162 with SMTP id xl2mr46239231pab.215.1367344733155;  Tue, 30 Apr 2013 10:58:53 -0700 (PDT)
Received: by 10.68.230.35 with HTTP; Tue, 30 Apr 2013 10:58:53 -0700 (PDT)
In-Reply-To: 
References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> 
Date: Tue, 30 Apr 2013 18:58:53 +0100
Message-ID: 
From: Abdussalam Baryun 
To: draft-ietf-manet-olsrv2-mib@tools.ietf.org
Content-Type: multipart/alternative; boundary=047d7b6d81241af79204db97c1c5
Cc: manet 
Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 17:58:57 -0000

--047d7b6d81241af79204db97c1c5
Content-Type: text/plain; charset=ISO-8859-1

Not sure in new version -07 why deleted some words/statement in section 9.

AB



On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg  wrote:

> Adrian,
>
> yes, that was my intention...but sometimes, good intentions are not enough
> ;-)
>
> I have submitted a new revision with the one-word change that Benoit
> requested.
>
> Best regards
> Ulrich
>
> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel 
> wrote:
> > Hi Ulrich,
> >
> > Did you intend to post a new revision to make this change?
> >
> > Thanks,
> > Adrian
> >
> >> -----Original Message-----
> >> From: Ulrich Herberg [mailto:ulrich@herberg.name]
> >> Sent: 15 April 2013 21:11
> >> To: Benoit Claise
> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;
> > pm-dir@ietf.org;
> >> manet@ietf.org
> >> Subject: Re: [manet] performance metrics directorate review of
> draft-ietf-
> >> manet-olsrv2-mib-06
> >>
> >> Benoit,
> >>
> >> thank you very much for this review. I agree that using the term
> >> "performance information" instead of "performance metrics" is a good
> >> idea. We will make the change.
> >>
> >> Best regards
> >> Ulrich
> >>
> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise 
> wrote:
> >> > Dear all,
> >> >
> >> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06,
> from a
> >> > performance metric directorate point of view.
> >> >
> >> > This draft doesn't contain any reference to RFC6390, but contains
> >> > "performance metric". Hence this review was triggered. For details
> about the
> >> > directorate, see
> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html
> >> >
> >> >
> >> > Definition of Managed Objects for the  Optimized Link State Routing
> >> > Protocol version 2
> >> >
> >> > Abstract
> >> >
> >> >    This document defines the Management Information Base (MIB) module
> >> >    for configuring and managing the Optimized Link State Routing
> >> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
> >> >    into state information, performance metrics, and notifications.
>  This
> >> >    additional state and performance information is useful to
> >> >    troubleshoot problems and performance issues of the routing
> protocol.
> >> >    Different levels of compliance allow implementers to use smaller
> >> >    subsets of all defined objects, allowing for this MIB module to be
> >> >    deployed on more constrained routers.
> >> >
> >> >
> >> > Basically, all performance metrics come from this table:
> >> >
> >> >    o  olsrv2InterfacePerfTable - records performance counters for each
> >> >       active OLSRv2 interface on this device. selected path to each
> >> >       destination for which any such path is known.  This table has
> >> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
> via
> >> >       nhdpIfIndex from the NHDP-MIB.
> >> >
> >> > NHDP-MIB is RFC 6779:
> >> >    NhdpInterfacePerfEntry ::=
> >> >       SEQUENCE {
> >> >          nhdpIfHelloMessageXmits
> >> >             Counter32,
> >> >          nhdpIfHelloMessageRecvd
> >> >             Counter32,
> >> >          nhdpIfHelloMessageXmitAccumulatedSize
> >> >             Counter64,
> >> >          nhdpIfHelloMessageRecvdAccumulatedSize
> >> >             Counter64,
> >> >          nhdpIfHelloMessageTriggeredXmits
> >> >             Counter32,
> >> >          nhdpIfHelloMessagePeriodicXmits
> >> >             Counter32,
> >> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
> >> >             Counter32,
> >> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
> >> >             Counter32,
> >> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
> >> >             Counter32
> >> >       }
> >> >
> >> >
> >> > This draft contains similar objects in olsrv2InterfacePerfTable :
> >> >
> >> >     Olsrv2InterfacePerfEntry ::=
> >> >        SEQUENCE {
> >> >           olsrv2IfTcMessageXmits
> >> >              Counter32,
> >> >           olsrv2IfTcMessageRecvd
> >> >              Counter32,
> >> >           olsrv2IfTcMessageXmitAccumulatedSize
> >> >              Counter64,
> >> >           olsrv2IfTcMessageRecvdAccumulatedSize
> >> >              Counter64,
> >> >           olsrv2IfTcMessageTriggeredXmits
> >> >              Counter32,
> >> >           olsrv2IfTcMessagePeriodicXmits
> >> >              Counter32,
> >> >           olsrv2IfTcMessageForwardedXmits
> >> >              Counter32,
> >> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
> >> >              Counter32
> >> >        }
> >> >
> >> >
> >> > Personally, I don't believe that those objects should be subject to
> the RFC
> >> > 6390 template definition. (Performance Metric Definition Template,
> section
> >> > 5.4.4, RFC 6390).
> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> >> > subject to it
> >> > Second reason: these objects are not really performance metrics, but
> mainly
> >> > basic monitoring objects.
> >> >
> >> > Since RFC 6779 uses the term performance information (in the
> abstract), I
> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this term,
> and not
> >> > the "performance metric". That would avoid some confusion. However,
> >> keeping
> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for
> consistency
> >> > reason with RFC 6779.
> >> >
> >> > Regards, Benoit
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
>

--047d7b6d81241af79204db97c1c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Not sure in new version -07=A0why deleted some words/=
statement in section 9.
=A0
AB
=A0


On Mon, Apr =
29, 2013 at 8:17 PM, Ulrich Herberg <ulrich@herberg.name> =
wrote:


Adrian,



yes, that was my intention...but sometimes, good intentions are not enough =
;-)



I have submitted a new revision with the one-word change that Benoit reques=
ted.



Best regards

Ulrich




On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi Ulrich,

>

> Did you intend to post a new revision to make this change?

>

> Thanks,

> Adrian

>

>> -----Original Message-----

>> From: Ulrich Herberg [mailto:ulrich@herberg.name]

>> Sent: 15 April 2013 21:11

>> To: Benoit Claise

>> Cc: =
draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;

> pm-dir@ietf.org;

>> manet@ietf.org

>> Subject: Re: [manet] performance metrics directorate review of dra=
ft-ietf-

>> manet-olsrv2-mib-06

>>

>> Benoit,

>>

>> thank you very much for this review. I agree that using the term
>> "performance information" instead of "performance m=
etrics" is a good

>> idea. We will make the change.

>>

>> Best regards

>> Ulrich

>>

>> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com> wrote:

>> > Dear all,

>> >

>> > I reviewed http://tools.ietf.org/html/draft-ietf=
-manet-olsrv2-mib-06, from a

>> > performance metric directorate point of view.

>> >

>> > This draft doesn't contain any reference to RFC6390, but =
contains

>> > "performance metric". Hence this review was trigger=
ed. For details about the

>> > directorate, see

>> > http://www.ietf.org/iesg/directorate/perform=
ance-metrics.html

>> >

>> >

>> > Definition of Managed Objects for the =A0Optimized Link State=
 Routing

>> > Protocol version 2

>> >

>> > Abstract

>> >

>> > =A0 =A0This document defines the Management Information Base =
(MIB) module

>> > =A0 =A0for configuring and managing the Optimized Link State =
Routing

>> > =A0 =A0protocol version 2 (OLSRv2). =A0The OLSRv2-MIB module =
is structured

>> > =A0 =A0into state information, performance metrics, and notif=
ications. =A0This

>> > =A0 =A0additional state and performance information is useful=
 to

>> > =A0 =A0troubleshoot problems and performance issues of the ro=
uting protocol.

>> > =A0 =A0Different levels of compliance allow implementers to u=
se smaller

>> > =A0 =A0subsets of all defined objects, allowing for this MIB =
module to be

>> > =A0 =A0deployed on more constrained routers.

>> >

>> >

>> > Basically, all performance metrics come from this table:

>> >

>> > =A0 =A0o =A0olsrv2InterfacePerfTable - records performance co=
unters for each

>> > =A0 =A0 =A0 active OLSRv2 interface on this device. selected =
path to each

>> > =A0 =A0 =A0 destination for which any such path is known. =A0=
This table has

>> > =A0 =A0 =A0 AUGMENTS { nhdpInterfacePerfEntry } and as such i=
t is indexed via

>> > =A0 =A0 =A0 nhdpIfIndex from the NHDP-MIB.

>> >

>> > NHDP-MIB is RFC 6779:

>> > =A0 =A0NhdpInterfacePerfEntry ::=3D

>> > =A0 =A0 =A0 SEQUENCE {

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvd

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulatedSize

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvdAccumulatedSize

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageTriggeredXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessagePeriodicXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulatedSymmetric=
NeighborCount

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulatedHeardNeig=
hborCount

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,

>> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulatedLostNeigh=
borCount

>> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32

>> > =A0 =A0 =A0 }

>> >

>> >

>> > This draft contains similar objects in olsrv2InterfacePerfTab=
le :

>> >

>> > =A0 =A0 Olsrv2InterfacePerfEntry ::=3D

>> > =A0 =A0 =A0 =A0SEQUENCE {

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvd

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAccumulatedSize

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvdAccumulatedSize

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageTriggeredXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessagePeriodicXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageForwardedXmits

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,

>> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAccumulatedMPRSelect=
orCount

>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32

>> > =A0 =A0 =A0 =A0}

>> >

>> >

>> > Personally, I don't believe that those objects should be =
subject to the RFC

>> > 6390 template definition. (Performance Metric Definition Temp=
late, section

>> > 5.4.4, RFC 6390).

>> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779=
] was not

>> > subject to it

>> > Second reason: these objects are not really performance metri=
cs, but mainly

>> > basic monitoring objects.

>> >

>> > Since RFC 6779 uses the term performance information (in the =
abstract), I

>> > would propose that draft-ietf-manet-olsrv2-mib also uses this=
 term, and not

>> > the "performance metric". That would avoid some con=
fusion. However,

>> keeping

>> > the olsrv2InterfacePerfTable OID name is perfectly fine, for =
consistency

>> > reason with RFC 6779.

>> >

>> > Regards, Benoit

>> >

>> >

>> >

>> > _______________________________________________

>> > manet mailing list

>> > manet@ietf.org

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

>> >

>

_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--047d7b6d81241af79204db97c1c5--

From ulrich@herberg.name  Tue Apr 30 11:23:28 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7121F9AB3 for ; Tue, 30 Apr 2013 11:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-O0lBn4d3la for ; Tue, 30 Apr 2013 11:23:24 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1921F9AAB for ; Tue, 30 Apr 2013 11:23:23 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hv10so706195vcb.15 for ; Tue, 30 Apr 2013 11:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6NnK0bYMKgvjlbLci+z3mwP+IYr+UvAbtYzXPBMVDws=; b=g0eUM/A7cFPZCPy+FZCD44HLfm1+qaEVELxPWCZlKh0DnRITYieJWHhmNGMyqs2AFr NsmrLT8MyHTdjCpQCQT43u7qj9kXNj3V0pyC35NzCIM1EADcoeoVhLSqUw2M5MAfccrb KEw7kXNl/lUqX2Lsbh54CER2xULZxa8dyWChk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=6NnK0bYMKgvjlbLci+z3mwP+IYr+UvAbtYzXPBMVDws=; b=XK12rTCxOg25eISaofRgi5D/eNa+xiJH2nqSxm9ztxlbsaU7cT4QaOP43kFivqSg4a Gmtz+2JfE0Y1XUuSDIL6Z7bz9HJQeibuTdPDxK+uITcD+ozyRR8ufF3FRHgrVylip7Vj pcjxj14ZXo7/0gP9x/HsiOZHtrrKR2ZgMe8zQG8a7Cq46Ugg7I5zhejDXFLOSz1TJitr XPCgCTDjsANPZ1Zw0OU2dCDxaeef9WhkDgPHOunjajWSLCiAm1pTXi92J+ojhBrB2+Pb dBj8I00mO5O6q1ZBk+unxYw+UjasMh+Le+SomwHQah6h1W/c5brXBfoP2h/pIpIlgj8s G/Qg==
MIME-Version: 1.0
X-Received: by 10.58.168.208 with SMTP id zy16mr35445954veb.3.1367346203461; Tue, 30 Apr 2013 11:23:23 -0700 (PDT)
Received: by 10.220.13.195 with HTTP; Tue, 30 Apr 2013 11:23:23 -0700 (PDT)
In-Reply-To: 
References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk>  
Date: Tue, 30 Apr 2013 11:23:23 -0700
Message-ID: 
From: Ulrich Herberg 
To: Abdussalam Baryun 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkpizRLASdaqEUyCyMuurfzAm4M3ngC9oT9Hg5Xjd/ORpHOh1UuIZfpsjHKXLmuq5U6Sj7U
Cc: manet , draft-ietf-manet-olsrv2-mib@tools.ietf.org
Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 18:23:28 -0000

AB,

this sentence was out-of-place in section 9 and not related to
security considerations.

Best regards
Ulrich

On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
 wrote:
> Not sure in new version -07 why deleted some words/statement in section 9.
>
> AB
>
>
>
> On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg  wrote:
>>
>> Adrian,
>>
>> yes, that was my intention...but sometimes, good intentions are not enough
>> ;-)
>>
>> I have submitted a new revision with the one-word change that Benoit
>> requested.
>>
>> Best regards
>> Ulrich
>>
>> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel 
>> wrote:
>> > Hi Ulrich,
>> >
>> > Did you intend to post a new revision to make this change?
>> >
>> > Thanks,
>> > Adrian
>> >
>> >> -----Original Message-----
>> >> From: Ulrich Herberg [mailto:ulrich@herberg.name]
>> >> Sent: 15 April 2013 21:11
>> >> To: Benoit Claise
>> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;
>> > pm-dir@ietf.org;
>> >> manet@ietf.org
>> >> Subject: Re: [manet] performance metrics directorate review of
>> >> draft-ietf-
>> >> manet-olsrv2-mib-06
>> >>
>> >> Benoit,
>> >>
>> >> thank you very much for this review. I agree that using the term
>> >> "performance information" instead of "performance metrics" is a good
>> >> idea. We will make the change.
>> >>
>> >> Best regards
>> >> Ulrich
>> >>
>> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise 
>> >> wrote:
>> >> > Dear all,
>> >> >
>> >> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06,
>> >> > from a
>> >> > performance metric directorate point of view.
>> >> >
>> >> > This draft doesn't contain any reference to RFC6390, but contains
>> >> > "performance metric". Hence this review was triggered. For details
>> >> > about the
>> >> > directorate, see
>> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html
>> >> >
>> >> >
>> >> > Definition of Managed Objects for the  Optimized Link State Routing
>> >> > Protocol version 2
>> >> >
>> >> > Abstract
>> >> >
>> >> >    This document defines the Management Information Base (MIB) module
>> >> >    for configuring and managing the Optimized Link State Routing
>> >> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
>> >> >    into state information, performance metrics, and notifications.
>> >> > This
>> >> >    additional state and performance information is useful to
>> >> >    troubleshoot problems and performance issues of the routing
>> >> > protocol.
>> >> >    Different levels of compliance allow implementers to use smaller
>> >> >    subsets of all defined objects, allowing for this MIB module to be
>> >> >    deployed on more constrained routers.
>> >> >
>> >> >
>> >> > Basically, all performance metrics come from this table:
>> >> >
>> >> >    o  olsrv2InterfacePerfTable - records performance counters for
>> >> > each
>> >> >       active OLSRv2 interface on this device. selected path to each
>> >> >       destination for which any such path is known.  This table has
>> >> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
>> >> > via
>> >> >       nhdpIfIndex from the NHDP-MIB.
>> >> >
>> >> > NHDP-MIB is RFC 6779:
>> >> >    NhdpInterfacePerfEntry ::=
>> >> >       SEQUENCE {
>> >> >          nhdpIfHelloMessageXmits
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessageRecvd
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessageXmitAccumulatedSize
>> >> >             Counter64,
>> >> >          nhdpIfHelloMessageRecvdAccumulatedSize
>> >> >             Counter64,
>> >> >          nhdpIfHelloMessageTriggeredXmits
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessagePeriodicXmits
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>> >> >             Counter32,
>> >> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>> >> >             Counter32
>> >> >       }
>> >> >
>> >> >
>> >> > This draft contains similar objects in olsrv2InterfacePerfTable :
>> >> >
>> >> >     Olsrv2InterfacePerfEntry ::=
>> >> >        SEQUENCE {
>> >> >           olsrv2IfTcMessageXmits
>> >> >              Counter32,
>> >> >           olsrv2IfTcMessageRecvd
>> >> >              Counter32,
>> >> >           olsrv2IfTcMessageXmitAccumulatedSize
>> >> >              Counter64,
>> >> >           olsrv2IfTcMessageRecvdAccumulatedSize
>> >> >              Counter64,
>> >> >           olsrv2IfTcMessageTriggeredXmits
>> >> >              Counter32,
>> >> >           olsrv2IfTcMessagePeriodicXmits
>> >> >              Counter32,
>> >> >           olsrv2IfTcMessageForwardedXmits
>> >> >              Counter32,
>> >> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>> >> >              Counter32
>> >> >        }
>> >> >
>> >> >
>> >> > Personally, I don't believe that those objects should be subject to
>> >> > the RFC
>> >> > 6390 template definition. (Performance Metric Definition Template,
>> >> > section
>> >> > 5.4.4, RFC 6390).
>> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
>> >> > not
>> >> > subject to it
>> >> > Second reason: these objects are not really performance metrics, but
>> >> > mainly
>> >> > basic monitoring objects.
>> >> >
>> >> > Since RFC 6779 uses the term performance information (in the
>> >> > abstract), I
>> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this term,
>> >> > and not
>> >> > the "performance metric". That would avoid some confusion. However,
>> >> keeping
>> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for
>> >> > consistency
>> >> > reason with RFC 6779.
>> >> >
>> >> > Regards, Benoit
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>