From stefano.secci@lip6.fr Tue Dec 4 08:20:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5221F8C00 for ; Tue, 4 Dec 2012 08:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8vBioUOjQ0E for ; Tue, 4 Dec 2012 08:20:45 -0800 (PST) Received: from osiris.lip6.fr (osiris.lip6.fr [IPv6:2001:660:3302:283c::1e]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6F21F86D2 for ; Tue, 4 Dec 2012 08:20:44 -0800 (PST) Received: from tibre.lip6.fr (tibre.ipv6.lip6.fr [IPv6:2001:660:3302:282a:204:e2ff:fe09:d49f]) by osiris.lip6.fr (8.14.5/lip6) with ESMTP id qB4GKdfR011308 ; Tue, 4 Dec 2012 17:20:39 +0100 (CET) X-pt: osiris.lip6.fr Received: from portablesecci.rsr.lip6.fr (portablesecci.rsr.lip6.fr [132.227.85.209]) (authenticated bits=0) by tibre.lip6.fr (8.14.5/8.13.3) with ESMTP id qB4GKWFq020226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Dec 2012 17:20:32 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-391-521188171 From: Stefano Secci In-Reply-To: <74F2D872-EE52-4DC1-9027-5C3E7591F998@telecom-paristech.fr> Date: Tue, 4 Dec 2012 17:20:26 +0100 Message-Id: <14313E63-0CE8-4175-8235-2C6B0E525B2E@lip6.fr> References: <74F2D872-EE52-4DC1-9027-5C3E7591F998@telecom-paristech.fr> To: Luigi Iannone , lisp@ietf.org X-Mailer: Apple Mail (2.1084) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (osiris.lip6.fr [IPv6:2001:660:3302:283c::1e]); Tue, 04 Dec 2012 17:20:39 +0100 (CET) X-Scanned-By: MIMEDefang 2.73 Cc: Damien Saucez Subject: Re: [lisp] LISP Control Plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 16:20:46 -0000 --Apple-Mail-391-521188171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, thank you Luigi for pushing that on the list. We've just updated the = code. It now includes (as a single package, conceived to complement the = OpenLISP data-plane): - MS/MR interface (thanks to Dung, PhD student),=20 - DDT (thanks to Damien and Dung), with an optional root mode, - improved configuration interface and minor fixes with respect to the = last version. Of course, under testing and probably buggy. Feedback is welcome! Later we=92ll include new optional experimental control-plane messages = as plugins. A detailed technical report will follow shortly in the website.=20 Stefano Le 14 nov. 2012 =E0 11:15, Luigi Iannone a =E9crit : > Hi All, >=20 > as mentioned during the WG meeting, there is another LISP = control-plane implementation, based on the OpenLISP data-plane. >=20 > The page of the Stefano Secci's group developing the code is:=20 >=20 > http://www.lisp.ipv6.lip6.fr/a/Home/Home.html >=20 > and the code can be downloaded at: >=20 > https://github.com/lip6-lisp/control-plane >=20 >=20 > Ciao >=20 > Luigi --=20 Stefano Secci Associate Professor PHARE - LIP6 - Univ. Pierre and Marie Curie Bureau 25-26/318, Boite Courrier 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 Fax: +33 (0) 1 4427 8783 http://www-phare.lip6.fr/~secci/ =20 --Apple-Mail-391-521188171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi All,

as mentioned during the WG meeting, = there is another LISP control-plane implementation, based on the = OpenLISP data-plane.

The page of the Stefano Secci's group = developing the code is:

http://www.lisp.ipv= 6.lip6.fr/a/Home/Home.html

and the code can be downloaded = at:

= = https://github.com/lip= 6-lisp/control-plane


Ciao

Luigi

-- 
Stefano = Secci
Associate Professor
PHARE - LIP6 - Univ. Pierre and = Marie Curie
Bureau 25-26/318, Boite Courrier 169
4 place Jussieu, = 75005 Paris, France
Tel:  +33 (0) 1 4427 3678
Fax:  +33 = (0) 1 4427 8783
http://www-phare.lip6.fr/~secci/=   

= --Apple-Mail-391-521188171-- From terry.manderson@icann.org Wed Dec 12 16:29:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9592121F86D9 for ; Wed, 12 Dec 2012 16:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4PC9S46jrpQ for ; Wed, 12 Dec 2012 16:29:40 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDC21F850E for ; Wed, 12 Dec 2012 16:29:40 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 12 Dec 2012 16:29:39 -0800 From: Terry Manderson To: LISP mailing list list Date: Wed, 12 Dec 2012 16:29:38 -0800 Thread-Topic: WG Last Call for draft-ietf-lisp-threats & draft-ietf-lisp-deployment Thread-Index: Ac3YyO8YCbzPMsZbxUGVBVt0oNe7UQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3438239378_331071" MIME-Version: 1.0 Subject: [lisp] WG Last Call for draft-ietf-lisp-threats & draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:29:40 -0000 --B_3438239378_331071 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, In the WG Last Calls for draft-ietf-lisp-threats and draft-ietf-lisp-deployment I have not seen sufficient review to be able to consider that adequate review has been performed. Please LISP WG, review these documents. I am extending the last call until the 14th January 2013 (holiday season). Cheers Terry --B_3438239378_331071 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUMULkhbultX65hLNGLihxNc3oqZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjEzMDAyOTM4WjANBgkqhkiG 9w0BAQEFAASCAQAvfBJlM+NRvEZ7ZJ5V7f4Puw5e1OZiSBcksGF40kjZg7ZzwcyYuRIcOAMV IzCcR9VExyyajcA7/8YlOKlnUR8g7jJdfagYwxFsWxMRWU3RnyylWnT7gDwwIbL2VFzulVfz pWlYMhI3BfAG+QIC/1/G4dlhrNUfIyaSfSse2WE2u1OR/vYEOkcpkzF1bwZLzDun10Lq6Ui9 S8kB/pCJJgtG7bgdUTLj5dYN9c4kijdMaHbO1sba3J1zmSB6hLtItnvY6k2tRpGvSMP41Agy HJ1rHLnufE11H/Zl2D95jUnhuHrzBPLfAZ8CrBhdIieM4iNMn/a/HJkuW6k9pDBsbhvS --B_3438239378_331071-- From jmh@joelhalpern.com Wed Dec 12 17:24:48 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2421F8A94 for ; Wed, 12 Dec 2012 17:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJuVgUw-e2rZ for ; Wed, 12 Dec 2012 17:24:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B221F8A93 for ; Wed, 12 Dec 2012 17:24:48 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 17E36558D65 for ; Wed, 12 Dec 2012 17:24:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B78941C087D; Wed, 12 Dec 2012 17:24:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 911B31C0450; Wed, 12 Dec 2012 17:24:47 -0800 (PST) Message-ID: <50C92E5D.80708@joelhalpern.com> Date: Wed, 12 Dec 2012 20:24:45 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-lisp-threats@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 01:24:48 -0000 In conjunction with the WG last call on this document, I performed my own review. I am confused by the attack remediation in section 5.3. This seems t say that an ETR should reject any packet whose source RLOC is not valid for the source EID. This would seem to frequently doubling the packet drop for initial communication between two sites, which seems unfortunate. This recommendation is repeated in the first bullet of section 11. Is this really the WG recommendation? Also, I have some minor issues. Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can only be caused by control plane attacks, or by a device performing gleaning. This seems to ignore one other attack vector. It is not a vector which can inject fake entries, but it can disrupt operation. Namely, an insider sending packets to a broad range of EIDs. By assumption, the cache is not big enough to hold the whole mapping table (otherwise it would not be subject to overflow). It would therefore seem that this sort of attack could disrupt valid entries and interfere with proper ITR operation. Shouldn't this be mentioned? Could / should the caveat about rate limiting queries in section 5.4.1 be moved up in the section, so that the reader realizes early what is needed? I am wondering about the tradeoff of including DDT in this document. On the one hand, DDT is where we likely are going. On the other hand, including that material will mean that this document gets an RFC Editor hold until LISP DDT is published. Would it make more sense to defer the DDT specific section to the DDT document? Editorial: The title of section 5.3, "Attacks not leveraging on the LISP header" seems to have a grammatical error. I think the word "on" is extraneous. (And similarly for section 5.4) Yours, Joel M. Halpern From jmh@joelhalpern.com Wed Dec 12 18:02:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0421F8818 for ; Wed, 12 Dec 2012 18:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUjyurYblcsT for ; Wed, 12 Dec 2012 18:02:16 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A137821F87F2 for ; Wed, 12 Dec 2012 18:02:16 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id A16FAA3877 for ; Wed, 12 Dec 2012 18:02:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6D18F1C087D; Wed, 12 Dec 2012 18:02:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 486DA1C0450; Wed, 12 Dec 2012 18:02:15 -0800 (PST) Message-ID: <50C93725.5070100@joelhalpern.com> Date: Wed, 12 Dec 2012 21:02:13 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-lisp-deployment@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: [lisp] draft-ietf-lisp-deployment review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 02:02:17 -0000 In conjunction with the WG last call on this document, I performed my own review. It appears that the text in section 3.1 on Map Server deployment asserts that (for EIDs outside of an allocated IPv6 block) Map Servers will need to be run by the RIRs. I strongly hope this is not the case. The RIRs have not signed up to run this service. Given that there are already existing ways for sites to prove provenance for PI address blocks, some other mechanism would seem achievable. Minor issues: I find the characterization of site edge in section 2.1, "can be approximated as the the set of DFZ routers belonging to non-transit ASes" To be a weak approximation. It fails basically because the CE and PE routers for many sites are either non-BGP speakers, or use default routes. Also, the BGP properties of the site do not seem relevant to the LISP deployment issues, so I wonder why they are even mentioned here. Should section 2.3 on split ITR/ETR note that in placing the ITRs inside the site, the ITRs will still need global RLOCs, and this may add complexity to intra-site routing configuration, and further intra-site issues when there is a change of providers? In the last sentence of section 2.5.1 on ITR behind NAT, cold we add an "only"? The sentence would become "This setup supports only a single ITR behind the NAT device." Should sections 5.2 and 5.3 on P-ITR deployment note that there are likely to be additional costs involved, to be borne by some party, since the P-ITR devices under consideration are handling all non-LISP-originated traffic for the customer sites? Yours, Joel M. Halpern From luigi.iannone@telecom-paristech.fr Thu Dec 13 00:28:01 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13621F8A52 for ; Thu, 13 Dec 2012 00:28:01 -0800 (PST) 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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os37bA4xydux for ; Thu, 13 Dec 2012 00:28:00 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id 76AEE21F8A4D for ; Thu, 13 Dec 2012 00:27:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id A90AC22A77; Thu, 13 Dec 2012 09:27:58 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpXUfwXaeoTS; Thu, 13 Dec 2012 09:27:58 +0100 (CET) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr [137.194.165.4]) by zproxy120.enst.fr (Postfix) with ESMTPSA id EB88F22A75; Thu, 13 Dec 2012 09:27:57 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <50C92E5D.80708@joelhalpern.com> Date: Thu, 13 Dec 2012 09:27:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C92E5D.80708@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 08:28:01 -0000 Hi Joel, thank you very much for your review. Few comments inline. On 13 Dec. 2012, at 02:24 , Joel M. Halpern wrote: > In conjunction with the WG last call on this document, I performed my = own review. >=20 >=20 > I am confused by the attack remediation in section 5.3. This seems t = say that an ETR should reject any packet whose source RLOC is not valid = for the source EID. This would seem to frequently doubling the packet = drop for initial communication between two sites, which seems = unfortunate. This recommendation is repeated in the first bullet of = section 11. Is this really the WG recommendation? Yes and No. This has been discussed several times in between other = things. My suggestion is to change the following sentence of section 5.3 = from: "the LISP ETR should reject the packet and possibly query the mapping system to obtain a mapping for the encapsulated source EID (HA)." to: "the LISP ETR should reject the packet and query the=20 mapping system to obtain a mapping for the encapsulated source EID (HA). Note that this may increase communication=20 setup latency due to the delay in retrieving a mapping for the source EID on the ETR." I would not mention packet drops since LISP does not enforce any = specific action for packets with missing mappings (yes current = implementations drop the packets but is not part of the = specifications.) >=20 >=20 > Also, I have some minor issues. > Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can = only be caused by control plane attacks, or by a device performing = gleaning. This seems to ignore one other attack vector. It is not a = vector which can inject fake entries, but it can disrupt operation. = Namely, an insider sending packets to a broad range of EIDs. By = assumption, the cache is not big enough to hold the whole mapping table = (otherwise it would not be subject to overflow). It would therefore = seem that this sort of attack could disrupt valid entries and interfere = with proper ITR operation. Shouldn't this be mentioned? Good point. We can add a small paragraph mentioning it.=20 >=20 > Could / should the caveat about rate limiting queries in section 5.4.1 = be moved up in the section, so that the reader realizes early what is = needed? Could: Yes Should: IMO no. Rate Limitation is not the key point of the section. >=20 > I am wondering about the tradeoff of including DDT in this document. = On the one hand, DDT is where we likely are going. On the other hand, = including that material will mean that this document gets an RFC Editor = hold until LISP DDT is published. Would it make more sense to defer the = DDT specific section to the DDT document? Another good point but actually goes beyond DDT IMO. If we put ALT and = MS make sense to me to put DDT as well.=20 >=20 > Editorial: > The title of section 5.3, "Attacks not leveraging on the LISP = header" seems to have a grammatical error. I think the word "on" is = extraneous. (And similarly for section 5.4) >=20 Thanks, we'll fix. Luigi >=20 > Yours, > Joel M. Halpern From jnc@mercury.lcs.mit.edu Thu Dec 13 08:09:23 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E621F8B61 for ; Thu, 13 Dec 2012 08:09:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjLBekCTFNXE for ; Thu, 13 Dec 2012 08:09:22 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3646A21F8B5B for ; Thu, 13 Dec 2012 08:09:22 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 067C718C0E7; Thu, 13 Dec 2012 11:09:21 -0500 (EST) To: draft-ietf-lisp-threats@tools.ietf.org, lisp@ietf.org Message-Id: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> Date: Thu, 13 Dec 2012 11:09:21 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:09:23 -0000 > From: "Joel M. Halpern" > By assumption, the cache is not big enough to hold the whole mapping > table (otherwise it would not be subject to overflow). I'm not sure this is accurate (but I concede it will depend on the implementation). The chief reason (at least, in my mind) that LISP uses a pull-based control plane is not the sheer size of the mapping database (memory is, after all, cheap and plentiful these days), but rather the control traffic overhead implications - in particular, the issue of the overhead required to maintain (in particlar, updating, which is not a one-time-only cost) never-used entries. The local copy of mapping information in the ITRs is described as a cache because it is demand-loaded. Many (most?) caches that people come across are size-limited, so I think there is an _assumption_ on people's parts that the LISP cache is also size-limited, but I don't think there is any particular reason that this must always be so. If nothing else, size-limiting the cache means one has to code up a discard algorithm, etc. Now, it may be that the wise programmer will have some mechanism for running out of memory for the cache (and I wonder what, e.g., BGP implementations do for this circumstance), and perhaps forcing a box into that operating regime is an attack vector. Can people who maintain existing implementation tell us if they do in fact have a maximum cache size, and if so, something about what their retention/discard algorithm is? Also, how do they deal with running out of memory? Also, there was an extensive discussion on the mailing list about a year or so ago of cache designs, for size-limited caches, which would avoid knocking the 'real' entries out (in favour of the attacker's 'not-really-used' entries); if the document didn't pick up some of that (sorry, haven't had the time to read it yet), it could probably usefully do so. The other consideration is that even if the box does not hit a memory limit, an attack of the kind you describe will increase the load on the control plane (for loading all the extra mappings) above and beyond its normal load. this may be worth mentioning, and exploring (if it's not already discussed - again, sorry, haven't read the ID yet). I seem to recall that there are already rate limits on the control traffic from any given ITR? If so, one would expect that the primary 'victim' of such rate limiting would be the 'bad guy' (unless an attack of this sort happens as a box is starting), since most of the 'new' requests will be those of the attacker, so it will mostly be their mapping requests which are dropped. Yes, this may interfere with the operation of the ITR for real users who are going 'new' places - if that turns out _in practice_ to be a problem, perhaps there is some way to isolate such traffic? If we assume that only one (or a small number) of hosts inside the LISP region (served by that ITR) are the source of bogus traffic (intended to overflow/dilute the cache), then if an ITR keeps a 'request count' per source host (yes, more state, and more work to maintain it, but...), it could rate-limit requests per source. Since this does not require any _protocol_ changes, we can probably put off implementing such measures until it proves to be an actual problem in service - but its probably worth mentioning all this in the I-D. Noel From jmh@joelhalpern.com Thu Dec 13 08:32:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65C21F8A44 for ; Thu, 13 Dec 2012 08:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUcxVLLLe0i0 for ; Thu, 13 Dec 2012 08:32:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 796BC21F8A12 for ; Thu, 13 Dec 2012 08:32:48 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 29A88A680F for ; Thu, 13 Dec 2012 08:32:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5745F1C9EE4; Thu, 13 Dec 2012 08:32:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.17.141.180] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0B9A61C087D; Thu, 13 Dec 2012 08:32:44 -0800 (PST) Message-ID: <50CA0327.7010100@joelhalpern.com> Date: Thu, 13 Dec 2012 11:32:39 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Noel Chiappa References: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> In-Reply-To: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:32:49 -0000 I did consider whether it was relevant that the box might have enough room for the whole table. The section is "Cache Overflow", so I figure it was safe for discussion to assume that there was insufficient space. Yours, Joel On 12/13/2012 11:09 AM, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > By assumption, the cache is not big enough to hold the whole mapping > > table (otherwise it would not be subject to overflow). > > I'm not sure this is accurate (but I concede it will depend on the > implementation). > > The chief reason (at least, in my mind) that LISP uses a pull-based control > plane is not the sheer size of the mapping database (memory is, after all, > cheap and plentiful these days), but rather the control traffic overhead > implications - in particular, the issue of the overhead required to maintain > (in particlar, updating, which is not a one-time-only cost) never-used > entries. > > The local copy of mapping information in the ITRs is described as a cache > because it is demand-loaded. Many (most?) caches that people come across are > size-limited, so I think there is an _assumption_ on people's parts that the > LISP cache is also size-limited, but I don't think there is any particular > reason that this must always be so. > > If nothing else, size-limiting the cache means one has to code up a discard > algorithm, etc. Now, it may be that the wise programmer will have some > mechanism for running out of memory for the cache (and I wonder what, e.g., > BGP implementations do for this circumstance), and perhaps forcing a box into > that operating regime is an attack vector. > > Can people who maintain existing implementation tell us if they do in fact > have a maximum cache size, and if so, something about what their > retention/discard algorithm is? Also, how do they deal with running out of > memory? > > Also, there was an extensive discussion on the mailing list about a year or > so ago of cache designs, for size-limited caches, which would avoid knocking > the 'real' entries out (in favour of the attacker's 'not-really-used' > entries); if the document didn't pick up some of that (sorry, haven't had the > time to read it yet), it could probably usefully do so. > > > The other consideration is that even if the box does not hit a memory limit, > an attack of the kind you describe will increase the load on the control > plane (for loading all the extra mappings) above and beyond its normal load. > this may be worth mentioning, and exploring (if it's not already discussed > - again, sorry, haven't read the ID yet). > > I seem to recall that there are already rate limits on the control traffic > from any given ITR? If so, one would expect that the primary 'victim' of such > rate limiting would be the 'bad guy' (unless an attack of this sort happens > as a box is starting), since most of the 'new' requests will be those of the > attacker, so it will mostly be their mapping requests which are dropped. > > Yes, this may interfere with the operation of the ITR for real users who are > going 'new' places - if that turns out _in practice_ to be a problem, perhaps > there is some way to isolate such traffic? If we assume that only one (or a > small number) of hosts inside the LISP region (served by that ITR) are the > source of bogus traffic (intended to overflow/dilute the cache), then if an > ITR keeps a 'request count' per source host (yes, more state, and more work > to maintain it, but...), it could rate-limit requests per source. > > Since this does not require any _protocol_ changes, we can probably put off > implementing such measures until it proves to be an actual problem in service > - but its probably worth mentioning all this in the I-D. > > Noel > From jmh@joelhalpern.com Thu Dec 13 08:39:52 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0721F8B05 for ; Thu, 13 Dec 2012 08:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DblcrvnmSht1 for ; Thu, 13 Dec 2012 08:39:52 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39C21F8B03 for ; Thu, 13 Dec 2012 08:39:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7340BA3701 for ; Thu, 13 Dec 2012 08:39:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 311F61C9EDF; Thu, 13 Dec 2012 08:39:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.17.141.180] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 782F51C087D; Thu, 13 Dec 2012 08:39:51 -0800 (PST) Message-ID: <50CA04D2.4020001@joelhalpern.com> Date: Thu, 13 Dec 2012 11:39:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Iannone References: <50C92E5D.80708@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:39:53 -0000 Thank you for responding to my comments. With regard to the discussion of MS, ALT, and DDT, it seems to me that there are a couple of reasons for splitting DDT out: 1) MS and ALT are already documented, and need better security description. This seems the sensible place to fill that. IN contrast, the security information for DDT can be included in that document. 2) In theory there can be yet other mapping systems. This document can not deal with all future cases. I would like t be able to complete this short term deliverable without making it dependent upon a long term deliverable. Yours, Joel On 12/13/2012 3:27 AM, Luigi Iannone wrote: >>> I am wondering about the tradeoff of including DDT in this >>> document. On the one hand, DDT is where we likely are going. On >>> the other hand, including that material will mean that this >>> document gets an RFC Editor hold until LISP DDT is published. >>> Would it make more sense to defer the DDT specific section to the >>> DDT document? > Another good point but actually goes beyond DDT IMO. If we put ALT > and MS make sense to me to put DDT as well. > > From jnc@mercury.lcs.mit.edu Thu Dec 13 16:56:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF69E21F8A99 for ; Thu, 13 Dec 2012 16:56:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXfJucpHrypk for ; Thu, 13 Dec 2012 16:56:49 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4937421F8A11 for ; Thu, 13 Dec 2012 16:56:49 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 52FE018C0F6; Thu, 13 Dec 2012 19:56:48 -0500 (EST) To: draft-ietf-lisp-threats@tools.ietf.org, lisp@ietf.org Message-Id: <20121214005648.52FE018C0F6@mercury.lcs.mit.edu> Date: Thu, 13 Dec 2012 19:56:48 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:56:49 -0000 > From: "Joel M. Halpern" > The section is "Cache Overflow", so I figure it was safe for discussion > to assume that there was insufficient space. Ah, good point. Still, I think the discussion in my note is probably worth putting in the ID (if those points are not already there, my apologies if they are, I still haven't had a chance to read it, sigh): in particular, the observation that some of the issues (e.g. control plane load) which may not yet be handled do have potential solutions but they require neither i) protocol changes, nor ii) co-ordinated deployment of modified code, is probably very good to note. I think showing that those issues have been analyzed, and we do have a non-painful path for dealing with them, is something that would be useful to have there, lest people think we blew the issue off. > IN contrast, the security information for DDT can be included in that > document. Probably in a separate document paired with the DDT main spec and packet formats, actually. DDT security is going to be order of magnitude the same complexity as DNS security (not too surprising, they do similar things, and have similar securability requirements), and the complete description of all the operating modes, etc is going to be, like that for DNS, a fair amount of material. Noel From jmh@joelhalpern.com Thu Dec 13 17:30:06 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BC721F8C01 for ; Thu, 13 Dec 2012 17:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4AYR3G3iG7p for ; Thu, 13 Dec 2012 17:30:05 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9589F21F8BB0 for ; Thu, 13 Dec 2012 17:30:05 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 29F19A389A for ; Thu, 13 Dec 2012 17:30:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DABC31823D8; Thu, 13 Dec 2012 17:30:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.141.180] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B31DB1823D7; Thu, 13 Dec 2012 17:30:04 -0800 (PST) Message-ID: <50CA8119.6060408@joelhalpern.com> Date: Thu, 13 Dec 2012 20:30:01 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Noel Chiappa References: <20121214005648.52FE018C0F6@mercury.lcs.mit.edu> In-Reply-To: <20121214005648.52FE018C0F6@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 01:30:06 -0000 With regard to control plane load, I think most of what you wanted is already there, but take a read if you have a chance. Your comments on the need for a full DDT security document reinforce my feeling that we should remove the treatment from this document. Yours, Joel On 12/13/2012 7:56 PM, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > The section is "Cache Overflow", so I figure it was safe for discussion > > to assume that there was insufficient space. > > Ah, good point. > > Still, I think the discussion in my note is probably worth putting in the ID > (if those points are not already there, my apologies if they are, I still > haven't had a chance to read it, sigh): in particular, the observation that > some of the issues (e.g. control plane load) which may not yet be handled do > have potential solutions but they require neither i) protocol changes, nor ii) > co-ordinated deployment of modified code, is probably very good to note. > > I think showing that those issues have been analyzed, and we do have a > non-painful path for dealing with them, is something that would be useful to > have there, lest people think we blew the issue off. > > > > IN contrast, the security information for DDT can be included in that > > document. > > Probably in a separate document paired with the DDT main spec and packet > formats, actually. > > DDT security is going to be order of magnitude the same complexity as DNS > security (not too surprising, they do similar things, and have similar > securability requirements), and the complete description of all the operating > modes, etc is going to be, like that for DNS, a fair amount of material. > > Noel > From luigi.iannone@telecom-paristech.fr Fri Dec 14 02:56:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3721F86BC for ; Fri, 14 Dec 2012 02:56:17 -0800 (PST) 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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMPVoTeIv89Q for ; Fri, 14 Dec 2012 02:56:16 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id BE80621F86AA for ; Fri, 14 Dec 2012 02:56:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 7E65D22A1C; Fri, 14 Dec 2012 11:56:15 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX7UTzMOPW0v; Fri, 14 Dec 2012 11:56:14 +0100 (CET) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr [137.194.165.4]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 250D322A26; Fri, 14 Dec 2012 11:56:14 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> Date: Fri, 14 Dec 2012 11:56:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org, draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 10:56:17 -0000 Hi Noel, couple of comments inline. On 13 Dec. 2012, at 17:09 , Noel Chiappa = wrote: >> From: "Joel M. Halpern" >=20 >> By assumption, the cache is not big enough to hold the whole mapping >> table (otherwise it would not be subject to overflow). >=20 > I'm not sure this is accurate (but I concede it will depend on the > implementation). >=20 > The chief reason (at least, in my mind) that LISP uses a pull-based = control > plane is not the sheer size of the mapping database (memory is, after = all, > cheap and plentiful these days), but rather the control traffic = overhead > implications - in particular, the issue of the overhead required to = maintain > (in particlar, updating, which is not a one-time-only cost) never-used > entries. >=20 > The local copy of mapping information in the ITRs is described as a = cache > because it is demand-loaded. Many (most?) caches that people come = across are > size-limited, so I think there is an _assumption_ on people's parts = that the > LISP cache is also size-limited, but I don't think there is any = particular > reason that this must always be so. >=20 I understand your point and I agree with.=20 Yet, no matter how much memory you put in your device there is always a = hard limit, hence, the need to discuss it (at least in this document).=20= > If nothing else, size-limiting the cache means one has to code up a = discard > algorithm, etc. Now, it may be that the wise programmer will have some > mechanism for running out of memory for the cache (and I wonder what, = e.g., > BGP implementations do for this circumstance), and perhaps forcing a = box into > that operating regime is an attack vector. >=20 > Can people who maintain existing implementation tell us if they do in = fact > have a maximum cache size, and if so, something about what their > retention/discard algorithm is? Also, how do they deal with running = out of > memory? In OpenLISP there is no specific mechanism.=20 If memory is not available new mappings cannot be allocated and are = dropped (with an error sent to the control plane).=20 There is no specific design rationale behind this choice is just that it = comes for free in the BSD kernel. On the other points you raise I think that are covered in the document, = but if you manage to read the draft your review is always welcome. Luigi =20 From luigi.iannone@telecom-paristech.fr Fri Dec 14 03:01:37 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BEB21F871F for ; Fri, 14 Dec 2012 03:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CePhs+HWlJ46 for ; Fri, 14 Dec 2012 03:01:37 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63621F8711 for ; Fri, 14 Dec 2012 03:01:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 7FF0E22A2D; Fri, 14 Dec 2012 12:01:36 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paRhjnw6uhkT; Fri, 14 Dec 2012 12:01:36 +0100 (CET) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr [137.194.165.4]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 1F25C229FA; Fri, 14 Dec 2012 12:01:36 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <50CA04D2.4020001@joelhalpern.com> Date: Fri, 14 Dec 2012 12:01:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EE54367-D9AD-4D94-8A9F-859FD97C7CE0@telecom-paristech.fr> References: <50C92E5D.80708@joelhalpern.com> <50CA04D2.4020001@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 11:01:38 -0000 Hi Joel, I've got your point.=20 Your suggestion is to take out the DDT section and put it in the DDT = document (right?). For the first part (take it out from this doc) I have no problems. For = the second part (put it in the DDT doc) is up to the DDT authors, = according with their plans for the document.=20 (simplest solution is to cut & paste as it is ;-) ) ciao Luigi On 13 Dec. 2012, at 17:39 , Joel M. Halpern wrote: > Thank you for responding to my comments. > With regard to the discussion of MS, ALT, and DDT, it seems to me that = there are a couple of reasons for splitting DDT out: >=20 > 1) MS and ALT are already documented, and need better security = description. This seems the sensible place to fill that. IN contrast, = the security information for DDT can be included in that document. >=20 > 2) In theory there can be yet other mapping systems. This document = can not deal with all future cases. >=20 > I would like t be able to complete this short term deliverable without = making it dependent upon a long term deliverable. >=20 > Yours, > Joel >=20 > On 12/13/2012 3:27 AM, Luigi Iannone wrote: >>>> I am wondering about the tradeoff of including DDT in this >>>> document. On the one hand, DDT is where we likely are going. On >>>> the other hand, including that material will mean that this >>>> document gets an RFC Editor hold until LISP DDT is published. >>>> Would it make more sense to defer the DDT specific section to the >>>> DDT document? >> Another good point but actually goes beyond DDT IMO. If we put ALT >> and MS make sense to me to put DDT as well. >>=20 >>=20 From arnatal@ac.upc.edu Fri Dec 14 03:26:01 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B221F8541 for ; Fri, 14 Dec 2012 03:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoCg0JlZ9Qsk for ; Fri, 14 Dec 2012 03:25:55 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id A380721F853C for ; Fri, 14 Dec 2012 03:25:54 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qBEBPqGG031383 for ; Fri, 14 Dec 2012 12:25:52 +0100 Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by gw.ac.upc.edu (Postfix) with ESMTP id 11A2B6B0261 for ; Fri, 14 Dec 2012 12:25:51 +0100 (CET) Received: by mail-vc0-f172.google.com with SMTP id fw7so3724549vcb.31 for ; Fri, 14 Dec 2012 03:25:50 -0800 (PST) Received: by 10.52.88.14 with SMTP id bc14mr7296127vdb.110.1355484350815; Fri, 14 Dec 2012 03:25:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.209.135 with HTTP; Fri, 14 Dec 2012 03:25:30 -0800 (PST) In-Reply-To: References: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> From: =?ISO-8859-1?Q?Alberto_Rodr=EDguez_Natal?= Date: Fri, 14 Dec 2012 12:25:30 +0100 Message-ID: To: Luigi Iannone Content-Type: multipart/alternative; boundary=bcaec50166133a9ceb04d0ce4ba3 Cc: Noel Chiappa , draft-ietf-lisp-threats@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 11:26:02 -0000 --bcaec50166133a9ceb04d0ce4ba3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, A brief comment about cache implementation. LISPmob uses the following workaround. The maximum memory available for cache is the maximum the system can allocate. If no memory is available, the control plane is notified. Cache is maintained at a reasonable size due to that old cache entries are dropped after a time-out if they have no traffic for a while. Regards, Alberto On 14 December 2012 11:56, Luigi Iannone wrote: > Hi Noel, > > couple of comments inline. > > > On 13 Dec. 2012, at 17:09 , Noel Chiappa wrote: > > >> From: "Joel M. Halpern" > > > >> By assumption, the cache is not big enough to hold the whole mapping > >> table (otherwise it would not be subject to overflow). > > > > I'm not sure this is accurate (but I concede it will depend on the > > implementation). > > > > The chief reason (at least, in my mind) that LISP uses a pull-based > control > > plane is not the sheer size of the mapping database (memory is, after > all, > > cheap and plentiful these days), but rather the control traffic overhead > > implications - in particular, the issue of the overhead required to > maintain > > (in particlar, updating, which is not a one-time-only cost) never-used > > entries. > > > > The local copy of mapping information in the ITRs is described as a cache > > because it is demand-loaded. Many (most?) caches that people come across > are > > size-limited, so I think there is an _assumption_ on people's parts that > the > > LISP cache is also size-limited, but I don't think there is any > particular > > reason that this must always be so. > > > > I understand your point and I agree with. > Yet, no matter how much memory you put in your device there is always a > hard limit, hence, the need to discuss it (at least in this document). > > > > If nothing else, size-limiting the cache means one has to code up a > discard > > algorithm, etc. Now, it may be that the wise programmer will have some > > mechanism for running out of memory for the cache (and I wonder what, > e.g., > > BGP implementations do for this circumstance), and perhaps forcing a box > into > > that operating regime is an attack vector. > > > > Can people who maintain existing implementation tell us if they do in > fact > > have a maximum cache size, and if so, something about what their > > retention/discard algorithm is? Also, how do they deal with running out > of > > memory? > > In OpenLISP there is no specific mechanism. > If memory is not available new mappings cannot be allocated and are > dropped (with an error sent to the control plane). > There is no specific design rationale behind this choice is just that it > comes for free in the BSD kernel. > > On the other points you raise I think that are covered in the document, > but if you manage to read the draft your review is always welcome. > > Luigi > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --bcaec50166133a9ceb04d0ce4ba3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

A brief comment about cache implementation. LISPmob uses the= following workaround. The maximum memory available for=20 cache is the maximum the system can allocate. If no memory is available, the control plane is notified. Cache is maintained at a reasonable size due to that old cache entries are dropped after a time-out if they have no traffic for a while.

Regards,
Alberto

On 14 December 2012 11:56, Luigi Iannone <<= a href=3D"mailto:luigi.iannone@telecom-paristech.fr" target=3D"_blank">luig= i.iannone@telecom-paristech.fr> wrote:
Hi Noel,

couple of comments inline.


On 13 Dec. 2012, at 17:09 , Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>> From: "Joel M. Halpern" <jmh@joelhalpern.com>
>
>> By assumption, the cache is not big enough to hold the whole mappi= ng
>> table (otherwise it would not be subject to overflow).
>
> I'm not sure this is accurate (but I concede it will depend on the=
> implementation).
>
> The chief reason (at least, in my mind) that LISP uses a pull-based co= ntrol
> plane is not the sheer size of the mapping database (memory is, after = all,
> cheap and plentiful these days), but rather the control traffic overhe= ad
> implications - in particular, the issue of the overhead required to ma= intain
> (in particlar, updating, which is not a one-time-only cost) never-used=
> entries.
>
> The local copy of mapping information in the ITRs is described as a ca= che
> because it is demand-loaded. Many (most?) caches that people come acro= ss are
> size-limited, so I think there is an _assumption_ on people's part= s that the
> LISP cache is also size-limited, but I don't think there is any pa= rticular
> reason that this must always be so.
>

I understand your point and I agree with.
Yet, no matter how much memory you put in your device there is always a har= d limit, hence, the need to discuss it (at least in this document).


> If nothing else, size-limiting the cache means one has to code up a di= scard
> algorithm, etc. Now, it may be that the wise programmer will have some=
> mechanism for running out of memory for the cache (and I wonder what, = e.g.,
> BGP implementations do for this circumstance), and perhaps forcing a b= ox into
> that operating regime is an attack vector.
>
> Can people who maintain existing implementation tell us if they do in = fact
> have a maximum cache size, and if so, something about what their
> retention/discard algorithm is? Also, how do they deal with running ou= t of
> memory?

In OpenLISP there is no specific mechanism.
If memory is not available new mappings cannot be allocated and are dropped= (with an error sent to the control plane).
There is no specific design rationale behind this choice is just that it co= mes for free in the BSD kernel.

On the other points you raise I think that are covered in the document, but= if you manage to read the draft your review is always welcome.

Luigi


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

--bcaec50166133a9ceb04d0ce4ba3-- From fcoras@ac.upc.edu Fri Dec 14 05:00:00 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5321F8566 for ; Fri, 14 Dec 2012 05:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfK-ngf-IkXE for ; Fri, 14 Dec 2012 04:59:59 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3521F84DA for ; Fri, 14 Dec 2012 04:59:59 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qBECxu0h003536; Fri, 14 Dec 2012 13:59:56 +0100 Received: from [192.168.1.11] (233.pool85-58-142.dynamic.orange.es [85.58.142.233]) by gw.ac.upc.edu (Postfix) with ESMTP id 92F916B008E; Fri, 14 Dec 2012 13:59:55 +0100 (CET) Message-ID: <50CB22CB.5010206@ac.upc.edu> Date: Fri, 14 Dec 2012 13:59:55 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: lisp@ietf.org References: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> In-Reply-To: <20121213160921.067C718C0E7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:00:00 -0000 Hello Noel, On 12/13/2012 05:09 PM, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > By assumption, the cache is not big enough to hold the whole mapping > > table (otherwise it would not be subject to overflow). > > I'm not sure this is accurate (but I concede it will depend on the > implementation). > > The chief reason (at least, in my mind) that LISP uses a pull-based control > plane is not the sheer size of the mapping database (memory is, after all, > cheap and plentiful these days), but rather the control traffic overhead > implications - in particular, the issue of the overhead required to maintain > (in particlar, updating, which is not a one-time-only cost) never-used > entries. Well, it depends, one of the practical reasons that led to LISP was the DFZ routing table growth. Many wondered then if both TCAM cache size and lookup speed would scale fast enough. Fast forwarding with LISP may require the use of some fast (and maybe large - but more on this lower) caches. > The local copy of mapping information in the ITRs is described as a cache > because it is demand-loaded. Many (most?) caches that people come across are > size-limited, so I think there is an _assumption_ on people's parts that the > LISP cache is also size-limited, but I don't think there is any particular > reason that this must always be so. > > If nothing else, size-limiting the cache means one has to code up a discard > algorithm, etc. Now, it may be that the wise programmer will have some > mechanism for running out of memory for the cache (and I wonder what, e.g., > BGP implementations do for this circumstance), and perhaps forcing a box into > that operating regime is an attack vector. Both Luigi's [2,3] works and ours [1] show that for today's traffic loads/patterns one does not need large caches (relative to those maintained in BGP routers). In fact, with some relatively small caches and a simple eviction algorithm, performance is acceptable. [1] http://personals.ac.upc.edu/fcoras/publications/2012-fcoras-networking-lisp-cache.pdf [2] https://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf [3] https://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf > Also, there was an extensive discussion on the mailing list about a year or > so ago of cache designs, for size-limited caches, which would avoid knocking > the 'real' entries out (in favour of the attacker's 'not-really-used' > entries); if the document didn't pick up some of that (sorry, haven't had the > time to read it yet), it could probably usefully do so. We're currently investigating this and here is where size matters but not necessarily in obvious ways. One or multiple coordinated users could trash an ITRs cache quite fast. Of course, user rate limiting and control plane rate limiting will help but, as you mentioned lower, they would also limit the ability of the ITR to learn new, legitimate destinations. So we think that an elaborate eviction policy should help here a lot. Florin > The other consideration is that even if the box does not hit a memory limit, > an attack of the kind you describe will increase the load on the control > plane (for loading all the extra mappings) above and beyond its normal load. > this may be worth mentioning, and exploring (if it's not already discussed > - again, sorry, haven't read the ID yet). > > I seem to recall that there are already rate limits on the control traffic > from any given ITR? If so, one would expect that the primary 'victim' of such > rate limiting would be the 'bad guy' (unless an attack of this sort happens > as a box is starting), since most of the 'new' requests will be those of the > attacker, so it will mostly be their mapping requests which are dropped. > > Yes, this may interfere with the operation of the ITR for real users who are > going 'new' places - if that turns out _in practice_ to be a problem, perhaps > there is some way to isolate such traffic? If we assume that only one (or a > small number) of hosts inside the LISP region (served by that ITR) are the > source of bogus traffic (intended to overflow/dilute the cache), then if an > ITR keeps a 'request count' per source host (yes, more state, and more work > to maintain it, but...), it could rate-limit requests per source. > > Since this does not require any _protocol_ changes, we can probably put off > implementing such measures until it proves to be an actual problem in service > - but its probably worth mentioning all this in the I-D. > > Noel From jmh@joelhalpern.com Fri Dec 14 08:27:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F28321F8959 for ; Fri, 14 Dec 2012 08:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjBqN1nSQVdl for ; Fri, 14 Dec 2012 08:27:20 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1358021F87CC for ; Fri, 14 Dec 2012 08:27:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id AFC67559ADB for ; Fri, 14 Dec 2012 08:27:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8AADF1BD7869; Fri, 14 Dec 2012 08:27:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0D0FD1BD7863; Fri, 14 Dec 2012 08:27:19 -0800 (PST) Message-ID: <50CB5363.5080306@joelhalpern.com> Date: Fri, 14 Dec 2012 11:27:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Iannone References: <50C92E5D.80708@joelhalpern.com> <50CA04D2.4020001@joelhalpern.com> <3EE54367-D9AD-4D94-8A9F-859FD97C7CE0@telecom-paristech.fr> In-Reply-To: <3EE54367-D9AD-4D94-8A9F-859FD97C7CE0@telecom-paristech.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 16:27:20 -0000 Agreed, your action would be to remove the DDT material from this document. The question of how the DDT spec handles having sufficient security discussion is a separate matter. Yours, Joel On 12/14/2012 6:01 AM, Luigi Iannone wrote: > Hi Joel, > > I've got your point. > > Your suggestion is to take out the DDT section and put it in the DDT document (right?). > > For the first part (take it out from this doc) I have no problems. For the second part (put it in the DDT doc) is up to the DDT authors, according with their plans for the document. > (simplest solution is to cut & paste as it is ;-) ) > > ciao > > Luigi > > > On 13 Dec. 2012, at 17:39 , Joel M. Halpern wrote: > >> Thank you for responding to my comments. >> With regard to the discussion of MS, ALT, and DDT, it seems to me that there are a couple of reasons for splitting DDT out: >> >> 1) MS and ALT are already documented, and need better security description. This seems the sensible place to fill that. IN contrast, the security information for DDT can be included in that document. >> >> 2) In theory there can be yet other mapping systems. This document can not deal with all future cases. >> >> I would like t be able to complete this short term deliverable without making it dependent upon a long term deliverable. >> >> Yours, >> Joel >> >> On 12/13/2012 3:27 AM, Luigi Iannone wrote: >>>>> I am wondering about the tradeoff of including DDT in this >>>>> document. On the one hand, DDT is where we likely are going. On >>>>> the other hand, including that material will mean that this >>>>> document gets an RFC Editor hold until LISP DDT is published. >>>>> Would it make more sense to defer the DDT specific section to the >>>>> DDT document? >>> Another good point but actually goes beyond DDT IMO. If we put ALT >>> and MS make sense to me to put DDT as well. >>> >>> > From luigi.iannone@telecom-paristech.fr Mon Dec 17 00:34:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C321F8A4B for ; Mon, 17 Dec 2012 00:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJJ9LvJqeyPs for ; Mon, 17 Dec 2012 00:34:36 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 167AA21F8A49 for ; Mon, 17 Dec 2012 00:34:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id DAE8522D4B; Mon, 17 Dec 2012 09:34:33 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZpIX+UG0kQM; Mon, 17 Dec 2012 09:34:32 +0100 (CET) Received: from dhcp164-03.enst.fr (dhcp164-03.enst.fr [137.194.165.3]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 9248822D3C; Mon, 17 Dec 2012 09:34:32 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <50CB5363.5080306@joelhalpern.com> Date: Mon, 17 Dec 2012 09:34:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <199FBF5B-9F71-4B7E-B8FC-2D047D2323A6@telecom-paristech.fr> References: <50C92E5D.80708@joelhalpern.com> <50CA04D2.4020001@joelhalpern.com> <3EE54367-D9AD-4D94-8A9F-859FD97C7CE0@telecom-paristech.fr> <50CB5363.5080306@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:34:36 -0000 Hi, Ack. Should we issue a new version of the document now or wait after the = closure of the LC? L. On 14 Dec. 2012, at 17:27 , Joel M. Halpern wrote: > Agreed, your action would be to remove the DDT material from this = document. > The question of how the DDT spec handles having sufficient security = discussion is a separate matter. >=20 > Yours, > Joel >=20 > On 12/14/2012 6:01 AM, Luigi Iannone wrote: >> Hi Joel, >>=20 >> I've got your point. >>=20 >> Your suggestion is to take out the DDT section and put it in the DDT = document (right?). >>=20 >> For the first part (take it out from this doc) I have no problems. = For the second part (put it in the DDT doc) is up to the DDT authors, = according with their plans for the document. >> (simplest solution is to cut & paste as it is ;-) ) >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> On 13 Dec. 2012, at 17:39 , Joel M. Halpern = wrote: >>=20 >>> Thank you for responding to my comments. >>> With regard to the discussion of MS, ALT, and DDT, it seems to me = that there are a couple of reasons for splitting DDT out: >>>=20 >>> 1) MS and ALT are already documented, and need better security = description. This seems the sensible place to fill that. IN contrast, = the security information for DDT can be included in that document. >>>=20 >>> 2) In theory there can be yet other mapping systems. This document = can not deal with all future cases. >>>=20 >>> I would like t be able to complete this short term deliverable = without making it dependent upon a long term deliverable. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/13/2012 3:27 AM, Luigi Iannone wrote: >>>>>> I am wondering about the tradeoff of including DDT in this >>>>>> document. On the one hand, DDT is where we likely are going. On >>>>>> the other hand, including that material will mean that this >>>>>> document gets an RFC Editor hold until LISP DDT is published. >>>>>> Would it make more sense to defer the DDT specific section to the >>>>>> DDT document? >>>> Another good point but actually goes beyond DDT IMO. If we put ALT >>>> and MS make sense to me to put DDT as well. >>>>=20 >>>>=20 >>=20 From jmh@joelhalpern.com Mon Dec 17 08:29:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50121F8B7F for ; Mon, 17 Dec 2012 08:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umAypJGTHt2N for ; Mon, 17 Dec 2012 08:29:19 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BDA4A21F8B7E for ; Mon, 17 Dec 2012 08:29:19 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 99690A63B9 for ; Mon, 17 Dec 2012 08:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4C0011C0760; Mon, 17 Dec 2012 08:29:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-81.clppva.east.verizon.net [70.106.135.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id ADEE91CA0E2; Mon, 17 Dec 2012 08:29:02 -0800 (PST) Message-ID: <50CF4840.8060303@joelhalpern.com> Date: Mon, 17 Dec 2012 11:28:48 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Iannone References: <50C92E5D.80708@joelhalpern.com> <50CA04D2.4020001@joelhalpern.com> <3EE54367-D9AD-4D94-8A9F-859FD97C7CE0@telecom-paristech.fr> <50CB5363.5080306@joelhalpern.com> <199FBF5B-9F71-4B7E-B8FC-2D047D2323A6@telecom-paristech.fr> In-Reply-To: <199FBF5B-9F71-4B7E-B8FC-2D047D2323A6@telecom-paristech.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , draft-ietf-lisp-threats@tools.ietf.org Subject: Re: [lisp] LISP Threats Document Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:29:20 -0000 I hope that there will be more comments from the working group. So let's wait to issue the revision. Thank you, Joel On 12/17/2012 3:34 AM, Luigi Iannone wrote: > Hi, > > Ack. > > Should we issue a new version of the document now or wait after the closure of the LC? > > L. > > > On 14 Dec. 2012, at 17:27 , Joel M. Halpern wrote: > >> Agreed, your action would be to remove the DDT material from this document. >> The question of how the DDT spec handles having sufficient security discussion is a separate matter. >> >> Yours, >> Joel >> >> On 12/14/2012 6:01 AM, Luigi Iannone wrote: >>> Hi Joel, >>> >>> I've got your point. >>> >>> Your suggestion is to take out the DDT section and put it in the DDT document (right?). >>> >>> For the first part (take it out from this doc) I have no problems. For the second part (put it in the DDT doc) is up to the DDT authors, according with their plans for the document. >>> (simplest solution is to cut & paste as it is ;-) ) >>> >>> ciao >>> >>> Luigi >>> >>> >>> On 13 Dec. 2012, at 17:39 , Joel M. Halpern wrote: >>> >>>> Thank you for responding to my comments. >>>> With regard to the discussion of MS, ALT, and DDT, it seems to me that there are a couple of reasons for splitting DDT out: >>>> >>>> 1) MS and ALT are already documented, and need better security description. This seems the sensible place to fill that. IN contrast, the security information for DDT can be included in that document. >>>> >>>> 2) In theory there can be yet other mapping systems. This document can not deal with all future cases. >>>> >>>> I would like t be able to complete this short term deliverable without making it dependent upon a long term deliverable. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/13/2012 3:27 AM, Luigi Iannone wrote: >>>>>>> I am wondering about the tradeoff of including DDT in this >>>>>>> document. On the one hand, DDT is where we likely are going. On >>>>>>> the other hand, including that material will mean that this >>>>>>> document gets an RFC Editor hold until LISP DDT is published. >>>>>>> Would it make more sense to defer the DDT specific section to the >>>>>>> DDT document? >>>>> Another good point but actually goes beyond DDT IMO. If we put ALT >>>>> and MS make sense to me to put DDT as well. >>>>> >>>>> >>> > From jmh.direct@joelhalpern.com Mon Dec 17 08:31:47 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212AE21F8795 for ; Mon, 17 Dec 2012 08:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if1Fg7txK9gm for ; Mon, 17 Dec 2012 08:31:46 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 508F721F8799 for ; Mon, 17 Dec 2012 08:31:45 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 57E66A6A31 for ; Mon, 17 Dec 2012 08:31:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 116A31CA83E; Mon, 17 Dec 2012 08:31:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-81.clppva.east.verizon.net [70.106.135.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 65B4B1CA848; Mon, 17 Dec 2012 08:31:25 -0800 (PST) Message-ID: <50CF48BD.6020602@joelhalpern.com> Date: Mon, 17 Dec 2012 11:30:53 -0500 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lori Jakab References: <50C93725.5070100@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] draft-ietf-lisp-deployment review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:31:47 -0000 Thank you. These resolutions look effective to me. Yours, Joel PS: As mentioned for the security document, I would leave the DDT work out of this. We can deal with DDT deployment impact either in the DDT document, or in a companion doc when we get that far. On 12/17/2012 8:11 AM, Lori Jakab wrote: > Hi Joel, > > Thank you for reviewing. See inline for answers. > > On Dec 13, 2012, at 4:02 AM, Joel M. Halpern wrote: > >> In conjunction with the WG last call on this document, I performed my own review. >> >> >> It appears that the text in section 3.1 on Map Server deployment asserts that (for EIDs outside of an allocated IPv6 block) Map Servers will need to be run by the RIRs. I strongly hope this is not the case. The RIRs have not signed up to run this service. Given that there are already existing ways for sites to prove provenance for PI address blocks, some other mechanism would seem achievable. > > How about this simplified text for the second paragraph of Section 3.1 (removing the bullets)? > > "The Map-Server is provided by a Mapping Service Provider (MSP). The MSP participates in the global distributed mapping database infrastructure, by setting up connections to other participants, according to the specific mapping system that is employed (e.g., ALT, DDT). Participation in the mapping database, and the storing of EID-to-RLOC mapping data is subject to the policies of the "root" operators, who SHOULD check ownership rights for the EID prefixes stored in the database by participants. These policies are out of the scope of this document." > > I didn't enter too much into specifics, because I think mapping system specific deployment description should go into separate documents, and EID allocation was mentioned as candidate for a separate document too. However, since we seem to move forward on DDT for the global mapping system, should we have a bit more detail about joining the DDT? What does the WG think? > >> >> >> Minor issues: >> I find the characterization of site edge in section 2.1, "can be approximated as the the set of DFZ routers belonging to non-transit ASes" To be a weak approximation. It fails basically because the CE and PE routers for many sites are either non-BGP speakers, or use default routes. Also, the BGP properties of the site do not seem relevant to the LISP deployment issues, so I wonder why they are even mentioned here. > > Well, the document was written with the goals of RFC4984 in mind, to reduce the size of the DFZ, so we focused on stub ASes that are BGP speakers. Would it address your concern if we replaced > > LISP was designed with deployment at the core-edge boundary in mind, > which can be approximated as the set of DFZ routers belonging to non- > transit ASes. For the purposes of this document, we will consider > this boundary to be consisting of the routers connecting LISP sites > to their upstreams. > > with > > The first scenario we discuss is customer edge, when xTR functionality > is placed on the router(s) that connect the LISP site to its upstream(s), > but are under its control. > >> >> Should section 2.3 on split ITR/ETR note that in placing the ITRs inside the site, the ITRs will still need global RLOCs, and this may add complexity to intra-site routing configuration, and further intra-site issues when there is a change of providers? > > Thanks for this suggestion, I think it's valuable information to the reader. Will include in the next revision. > >> >> In the last sentence of section 2.5.1 on ITR behind NAT, cold we add an "only"? The sentence would become "This setup supports only a single ITR behind the NAT device." > > Sure. Will do. > >> >> Should sections 5.2 and 5.3 on P-ITR deployment note that there are likely to be additional costs involved, to be borne by some party, since the P-ITR devices under consideration are handling all non-LISP-originated traffic for the customer sites? > > Here's suggested text for 5.2: > > Routing all non-LISP ingress traffic through a third party which is > not one of its ISPs is only feasible for sites with modest amounts of > traffic (like those using the IPv6 tunnel broker services today), > especially in the first stage of the transition to LISP, with a > significant number of legacy sites. > This is because the handling of > said traffic is likely to result in additional costs, which would be > passed down to the client. > When the LISP/non-LISP site > ratio becomes high enough, this approach can prove increasingly > attractive. > > And 5.3: > > The PSP manages a set of distributed P-ITR(s) that will advertise the > corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) > will then encapsulate the traffic they receive for those EIDs towards > the RLOCs of the LISP site, ensuring their reachability from non-LISP > sites. > Note that handling non-LISP-originated traffic may incur > additional costs for the PSP, which may be passed down to the client. > > Thanks, > -Lori > >> >> Yours, >> Joel M. Halpern > From lori@lispmob.org Mon Dec 17 05:17:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3E21F8AB7 for ; Mon, 17 Dec 2012 05:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf4RWTfE4OkD for ; Mon, 17 Dec 2012 05:17:38 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id D006921F89D3 for ; Mon, 17 Dec 2012 05:17:37 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qBHDBrAv032236; Mon, 17 Dec 2012 14:11:53 +0100 Received: from sjc-vpn4-1112.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by gw.ac.upc.edu (Postfix) with ESMTP id 78BDC6B01A4; Mon, 17 Dec 2012 14:11:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Lori Jakab In-Reply-To: <50C93725.5070100@joelhalpern.com> Date: Mon, 17 Dec 2012 15:11:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C93725.5070100@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 17 Dec 2012 12:10:02 -0800 Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] draft-ietf-lisp-deployment review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 13:31:32 -0000 Hi Joel, Thank you for reviewing. See inline for answers. On Dec 13, 2012, at 4:02 AM, Joel M. Halpern wrote: > In conjunction with the WG last call on this document, I performed my = own review. >=20 >=20 > It appears that the text in section 3.1 on Map Server deployment = asserts that (for EIDs outside of an allocated IPv6 block) Map Servers = will need to be run by the RIRs. I strongly hope this is not the case. = The RIRs have not signed up to run this service. Given that there are = already existing ways for sites to prove provenance for PI address = blocks, some other mechanism would seem achievable. How about this simplified text for the second paragraph of Section 3.1 = (removing the bullets)? "The Map-Server is provided by a Mapping Service Provider (MSP). The = MSP participates in the global distributed mapping database = infrastructure, by setting up connections to other participants, = according to the specific mapping system that is employed (e.g., ALT, = DDT). Participation in the mapping database, and the storing of = EID-to-RLOC mapping data is subject to the policies of the "root" = operators, who SHOULD check ownership rights for the EID prefixes stored = in the database by participants. These policies are out of the scope of = this document." I didn't enter too much into specifics, because I think mapping system = specific deployment description should go into separate documents, and = EID allocation was mentioned as candidate for a separate document too. = However, since we seem to move forward on DDT for the global mapping = system, should we have a bit more detail about joining the DDT? What = does the WG think? >=20 >=20 > Minor issues: > I find the characterization of site edge in section 2.1, "can be = approximated as the the set of DFZ routers belonging to non-transit = ASes" To be a weak approximation. It fails basically because the CE and = PE routers for many sites are either non-BGP speakers, or use default = routes. Also, the BGP properties of the site do not seem relevant to = the LISP deployment issues, so I wonder why they are even mentioned = here. Well, the document was written with the goals of RFC4984 in mind, to = reduce the size of the DFZ, so we focused on stub ASes that are BGP = speakers. Would it address your concern if we replaced LISP was designed with deployment at the core-edge boundary in mind, which can be approximated as the set of DFZ routers belonging to non- transit ASes. For the purposes of this document, we will consider this boundary to be consisting of the routers connecting LISP sites to their upstreams. with The first scenario we discuss is customer edge, when xTR = functionality is placed on the router(s) that connect the LISP site to its = upstream(s), but are under its control. >=20 > Should section 2.3 on split ITR/ETR note that in placing the ITRs = inside the site, the ITRs will still need global RLOCs, and this may add = complexity to intra-site routing configuration, and further intra-site = issues when there is a change of providers? Thanks for this suggestion, I think it's valuable information to the = reader. Will include in the next revision. >=20 > In the last sentence of section 2.5.1 on ITR behind NAT, cold we = add an "only"? The sentence would become "This setup supports only a = single ITR behind the NAT device." Sure. Will do. >=20 > Should sections 5.2 and 5.3 on P-ITR deployment note that there are = likely to be additional costs involved, to be borne by some party, since = the P-ITR devices under consideration are handling all = non-LISP-originated traffic for the customer sites? Here's suggested text for 5.2: Routing all non-LISP ingress traffic through a third party which is not one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today), especially in the first stage of the transition to LISP, with a significant number of legacy sites. This is because the handling of said traffic is likely to result in additional costs, which would be passed down to the client. When the LISP/non-LISP site ratio becomes high enough, this approach can prove increasingly attractive. And 5.3: The PSP manages a set of distributed P-ITR(s) that will advertise the corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) will then encapsulate the traffic they receive for those EIDs towards the RLOCs of the LISP site, ensuring their reachability from non-LISP sites. Note that handling non-LISP-originated traffic may incur additional costs for the PSP, which may be passed down to the client. Thanks, -Lori >=20 > Yours, > Joel M. Halpern From jmh@joelhalpern.com Wed Dec 26 07:33:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3821F8CC8 for ; Wed, 26 Dec 2012 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tLQjjmBSCCX for ; Wed, 26 Dec 2012 07:33:43 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 794E521F8CC7 for ; Wed, 26 Dec 2012 07:33:43 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 32B86A3734 for ; Wed, 26 Dec 2012 07:33:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 11E881BCC7BF for ; Wed, 26 Dec 2012 07:33:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-81.clppva.east.verizon.net [70.106.135.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 807F21BCC7BE for ; Wed, 26 Dec 2012 07:33:42 -0800 (PST) Message-ID: <50DB18CF.60205@joelhalpern.com> Date: Wed, 26 Dec 2012 10:33:35 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "lisp@ietf.org" References: <20121226135531.24862.99414.idtracker@ietfa.amsl.com> In-Reply-To: <20121226135531.24862.99414.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] I-D Action: draft-saucez-lisp-itr-graceful-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:33:44 -0000 Tis is an interesting piece of work. Once we clear the current blocking documents, I look forward to discussion on the list of the pros and cons of the ideas presented herein. Yours, Joel PS: As a minor item, when you respin this document, please shorten the abstract. A lot. On 12/26/2012 8:55 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LISP ITR Graceful Restart > Author(s) : Damien Saucez > Olivier Bonaventure > Luigi Iannone > Clarence Filsfils > Filename : draft-saucez-lisp-itr-graceful-01.txt > Pages : 12 > Date : 2012-12-26 > > Abstract: > The Locator/ID Separation Protocol (LISP) is a map-and-encap > mechanism to enable the communication between hosts identified with > their Endpoint IDentifier (EID) over the Internet where EIDs are not > routable. To do so, packets toward EIDs are encapsulated in packets > with routing locators (RLOCs) to form dynamic tunnels. An Ingress > Tunnel Router (ITR) that encapsulates EID packets determines tunnel > endpoints via mappings that associate EIDs to RLOCs. Before > encapsulating a packet, the ITR queries the mapping system to obtain > the mapping associated to the EID of the packet it must encapsulate. > Such mapping is cached by the ITR in its local EID-to-RLOC cache for > any subsequent encapsulation for the same EID. LISP is scalable > because the EID-to-RLOC cache of an ITR, which is initially empty, is > populated progressively according to the traffic going through the > ITR. However, after an ITR is restarted, e.g., for maintenance > reason, its cache is empty which means that all packets that are re- > routed to the freshly restarted ITR will cause cache misses and a > potentially high loss rate. In this draft, we present mechanisms to > reduce the negative impact on traffic caused by the restart of an ITR > in a LISP network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-saucez-lisp-itr-graceful > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-saucez-lisp-itr-graceful-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-saucez-lisp-itr-graceful-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From rbonica@juniper.net Fri Dec 28 13:12:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACAB21F8E16 for ; Fri, 28 Dec 2012 13:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.324 X-Spam-Level: X-Spam-Status: No, score=-103.324 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQVT6sh4x0w4 for ; Fri, 28 Dec 2012 13:12:42 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id B5FAA21F8E09 for ; Fri, 28 Dec 2012 13:12:42 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUN4LSmfsKwIE7pfJs1nO1nmjBvw3vFt3@postini.com; Fri, 28 Dec 2012 13:12:42 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Dec 2012 13:10:56 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Dec 2012 13:10:56 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Dec 2012 13:19:16 -0800 Received: from mail249-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Dec 2012 21:10:54 +0000 Received: from mail249-ch1 (localhost [127.0.0.1]) by mail249-ch1-R.bigfish.com (Postfix) with ESMTP id 68696160005E for ; Fri, 28 Dec 2012 21:10:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1de0h1202h1e76h1d1ah1d2ahzz8275dh18602ehz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail249-ch1 (localhost.localdomain [127.0.0.1]) by mail249-ch1 (MessageSwitch) id 1356729051648042_10701; Fri, 28 Dec 2012 21:10:51 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail249-ch1.bigfish.com (Postfix) with ESMTP id 9BC8310C004E for ; Fri, 28 Dec 2012 21:10:51 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Dec 2012 21:10:43 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.183]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0245.002; Fri, 28 Dec 2012 21:10:42 +0000 From: Ronald Bonica To: "lisp@ietf.org" Thread-Topic: draft-ietf-lisp-architecture-00 Thread-Index: Ac3lP8m0fK4ZarxSQiKVQcRLg1sT1w== Date: Fri, 28 Dec 2012 21:10:42 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E01612@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [lisp] draft-ietf-lisp-architecture-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 21:12:43 -0000 Noel, Thanks for this well-written document. The following are questions regardin= g Sections 2.2 and 2.3. 2.2. Deployment of New Namespaces =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D When you say a "new namespace", which of the following do you mean: 1) something that is visible within the LISP site, but not within the ISP n= etwork 2) something that is visible within the ISP network, but not the LISP site= =20 3) something that may be visible both within the LISP site and the ISP netw= ork Your example suggests #2. Do I have that right? If so, could you make that = clear? 2.3. Future Development of LISP =3D=3D=3D=3D=3D=3D=3D=3D=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 section is confusing. Because it is included in Section 2 (Goals), one= would think that it document one of LISP's goals. However, section begins = by stating that its contents are beyond the scope of the document. It then = continues to normatively reference another document that captures "one pers= on's thoughts". Does this section really document LISP goal? If so, what is that goal? -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From rbonica@juniper.net Sat Dec 29 07:12:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37A21F8610 for ; Sat, 29 Dec 2012 07:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOJs3NN3N0M7 for ; Sat, 29 Dec 2012 07:12:43 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB021F8600 for ; Sat, 29 Dec 2012 07:12:43 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUN8Ia4gzhlAduOwNUdd2BIhaWST203y/@postini.com; Sat, 29 Dec 2012 07:12:43 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 29 Dec 2012 07:11:04 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 29 Dec 2012 07:11:03 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 29 Dec 2012 07:19:24 -0800 Received: from mail11-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Sat, 29 Dec 2012 15:11:03 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id 08306A03A5 for ; Sat, 29 Dec 2012 15:11:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz111aIzz1de0h1202h1e76h1d1ah1d2ahzz8275dh18602ehz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1356793860847150_26369; Sat, 29 Dec 2012 15:11:00 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id CCD983C0062 for ; Sat, 29 Dec 2012 15:11:00 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 29 Dec 2012 15:11:00 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.183]) by BY2PRD0512HT001.namprd05.prod.outlook.com ([10.255.243.34]) with mapi id 14.16.0245.002; Sat, 29 Dec 2012 15:10:59 +0000 From: Ronald Bonica To: "lisp@ietf.org" Thread-Topic: draft-ietf-lisp-introduction: Self-deployment Thread-Index: Ac3l1rQqr3rWtnouT4qy64zLRt/xJA== Date: Sat, 29 Dec 2012 15:10:58 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E01865@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [lisp] draft-ietf-lisp-introduction: Self-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 15:12:44 -0000 Hi Noel, Thanks again for another well-written document. However, in Section 2.3, the term "self-deployment" may not be entirely acc= urate. If a technology were truly "self-deploying", nobody would have to do= anything to deploy it. It would just deploy itself in your network, whethe= r you want it or not ;-) I think you are trying to say that the economic benefits of LISP are so com= pelling that operators will deploy it of their own accord. Hence, there is = no need for anybody (e.g., the IETF, network operator groups) to encourage = individual operators to deploy. Am I reading this section correctly? If so, is such a statement required, or even appropriate in an IETF documen= t? -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From jnc@mercury.lcs.mit.edu Sat Dec 29 08:08:08 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769DA21F869A for ; Sat, 29 Dec 2012 08:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PooV5Dbgjd+k for ; Sat, 29 Dec 2012 08:08:08 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id C753021F8621 for ; Sat, 29 Dec 2012 08:08:07 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8E97518C07E; Sat, 29 Dec 2012 11:08:06 -0500 (EST) To: lisp@ietf.org Message-Id: <20121229160806.8E97518C07E@mercury.lcs.mit.edu> Date: Sat, 29 Dec 2012 11:08:06 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] draft-ietf-lisp-introduction: Self-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 16:08:08 -0000 > From: Ronald Bonica > Thanks again for another well-written document. Thank you so much for those very kind words.. I do hope to improve it a little more, once I get back to work on them, once things quiet down in the new year. > in Section 2.3, the term "self-deployment" may not be entirely > accurate. ... I think you are trying to say that the economic benefits > of LISP are so compelling that operators will deploy it of their own > accord. Hence, there is no need for anybody (e.g., the IETF, network > operator groups) to encourage individual operators to deploy. Am I > reading this section correctly? Yes, pretty much; it means omething very close to that, yes. What I had in the back of my mind was the early days of the Web, when it was so useful, and so easy to add, that it just seemed to deploy itself (and at a high rate of knots, too). Of course, when you actually look at what is happening, it is (as you say) that the benefits are large compared to the costs (as was true of the Web deployment). I cheerfully admit that the term 'self-deployment' is perhapsa not the best, and if you (or anyone) has a superior alternative I will happily substitute it. > If so, is such a statement required, or even appropriate in an IETF > document? Well, the reason I mention it, and think it worth mentioning, is that that concept/goal had a great impact on the design. I think we've all come to realize that anyone (well, almost anyone reasonably sharp :-) can do a good design, but designing something that will actually succeed in making it out into large-scale deployment in today's enormous network is a far steeper challenge. Having that in mind is not just a major goal, but also impacts the design in a myriad ways (e.g. the encapsulation, to name one off the top of my head). So to really understand many of the design choices (e.g. the whole basic architecture, with its orientation around site edge devices [at least, in the early stages], as opposed to the approach used in some other identity/location separation schemes, where individual hosts are the focus), one has to keep in mind that that was a main goal. So, yes, I do think we need to say something about this. And even if _broad_ economic considerations haven't been prominent in the IETF before, perhaps they should have been? Now, perhaps the text could use some tweaking, to make sure that it stays within appropriate bounds (without consulting it, I don't recall exactly what it says)? And now I have to go lie down - I forgot to turn on the bedroom humidifier last night, and as a result I have a sinus headache! :-) Noel From damien.saucez@gmail.com Sun Dec 30 12:45:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8B721F855A; Sun, 30 Dec 2012 12:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TBhXF6UEbJw; Sun, 30 Dec 2012 12:45:16 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D921F8558; Sun, 30 Dec 2012 12:45:12 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id z2so5641569wey.32 for ; Sun, 30 Dec 2012 12:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=MwLjU9i7XROJzrbNZNYiIHjd7YvbOW8WMcXyE/ze4sk=; b=npmdov2LZ5hXELEQZGMN2yVZuCkkQT9DdFuDHaONiB1jx6e3CNn544dsQuMDg+6WJK NIWFSnvj2wbTAsj8KNBGCScGH4ExX6BSDkJ+j4+3DZmpaq5gaZYumO2x+UwKEutBXDQq fl3Uwh/elaAxZq/RZmQO8DbJjDagQ68KYU9/a7T3eCPitpJhwsQrUR2AHgyPilsYlU6C lyzcj52YuKcbBcKbim28MrpnEVWAV18/Ir/ytTU29xUZ0kLFrFo5tskeO2hHbcXTBGA8 W1Img+QyKrDeEqmtGJRnZJCPTP/VG7RI86nECQgAcrwH2BOCpiGhbzDR98GzTUzes1YI BPNg== X-Received: by 10.180.109.195 with SMTP id hu3mr52180372wib.31.1356900312248; Sun, 30 Dec 2012 12:45:12 -0800 (PST) Received: from [172.16.139.253] (44.189.101.84.rev.sfr.net. [84.101.189.44]) by mx.google.com with ESMTPS id hg17sm72626675wib.1.2012.12.30.12.45.10 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 12:45:11 -0800 (PST) From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Dec 2012 21:45:09 +0100 Message-Id: <0A534525-59E1-418E-826B-177655767B17@gmail.com> To: draft-xu-softwire-ip-in-udp@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Softwires@ietf.org, LISP mailing list list Subject: [lisp] draft-xu-softwire-ip-in-udp X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 20:45:17 -0000 Hello, Interesting document, have you ever though of LISP to do that? Regards, Damien Saucez