From jaime.j.jimenez@ericsson.com Thu Mar 1 03:12:16 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2D21F8749 for ; Thu, 1 Mar 2012 03:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ85LnxpWw1u for ; Thu, 1 Mar 2012 03:12:14 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2305521F8732 for ; Thu, 1 Mar 2012 03:12:13 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-66-4f4f598c07bf Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 34.4A.27041.C895F4F4; Thu, 1 Mar 2012 12:12:12 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.143]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 1 Mar 2012 12:12:12 +0100 From: =?iso-8859-1?Q?Jaime_Jim=E9nez_J?= To: Marc Petit-Huguenin Date: Thu, 1 Mar 2012 12:12:10 +0100 Thread-Topic: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 Thread-Index: Acz3nCYxRync/vMMSHOlB9kpzaNqiw== Message-ID: <44DCE3A5-BB06-4915-982C-85A843B879F3@ericsson.com> References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> <4F43704C.3040701@kit.edu> <4F4E4881.6000807@acm.org> In-Reply-To: <4F4E4881.6000807@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_AA8D6880-3C19-455E-9849-7AF9DFB095CF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:12:17 -0000 --Apple-Mail=_AA8D6880-3C19-455E-9849-7AF9DFB095CF Content-Type: multipart/alternative; boundary="Apple-Mail=_B0106171-B3D5-406E-8AC7-D1EA8FACA3EA" --Apple-Mail=_B0106171-B3D5-406E-8AC7-D1EA8FACA3EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sure, I'll try to pass by there :) -- Jaime On Feb 29, 2012, at 5:47 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi Roland, >=20 > On 02/21/2012 02:22 AM, Roland Bless wrote: >> Hi, >>=20 >> On 20.02.2012 19:18, Marc Petit-Huguenin wrote: >>> I did not see much interest in the RELOAD interop in Paris so far. = If >>> you think that you will maybe attend, please send me a direct email, = you >>> will be able to cancel without problem. I really need to have an = idea of >>> the number of people attending for planning purpose. >>=20 >> Basically, we are interested, but our implementation isn't probably = mature >> enough for an interop at this IETF (amy at the next one). = Furthermore, I'll >> arrive on Sunday and can't make it on Saturday. >>=20 >=20 > If you arrive before 1:00pm the Sunday, please stop by anyway. = Knowing other > implementers can only help to organize future interop events. >=20 > Thanks. >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPTkiAAAoJECnERZXWan7Ef9IP/0JoeEasvNpNYBmNhiAl21Ga > dnJEK/HaXZONeqPU2EDQKv8/qktj3ulezDoJm6Tx4ym2itmdIrcKeKFBf5DB/8jQ > XWry4FAhd3m/y9ItWu/6CN9N9DwaEw1NMqCcBDg+UgeTM4GbjVSvc9N74p7Y1qQY > Xqavmh3YNEbHMkh7+C7fXDiziPOBBUU0Q+6twFIWgBb4ctFpSiuQLrdcwBp7LX95 > DHPviuD2HJgbOmPXA6I9fy9HufJ9+HXKpklgtoeywkdaRHR69wHDNwYlRuNepLLE > oct5waapkoyXQjkQosBBeS4t/VkY7OcYEyQe+qwH1EVrDH//pEQ2Gy+/yh6Utqjn > u5ZWwkpNzZ9dDv6aDEP1TFbxdjSST8u8+WjkMHalYFQ6NOsvCFsFHC07scpbtMNC > G60/voeiaD7mzWoWcnPZ7b7uXtnDeg0El0b+/tixZkTM/71dLWL6RLtfbgaDcZE1 > Ku13rPvzk9TBnZZIOBiD6ryPALArpmjIaXL5Z0GCDp8Lqz9Rw/JMuTKL+Ux7JlQ/ > 6JPKtHpNtybgtF5GCIliWovQdaykLT9Mo7AmKTCqoqHL+dI0Y0F1znlXhgZPOZ/w > E3ED+QGXRt2MtbWzof/ExxeKRwuRTJimTdiV/TL0jok3JJuZI/QV722JE/xJ40iO > /U6ZmxA6d3W0+ySdEws5 > =3Daf2d > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_B0106171-B3D5-406E-8AC7-D1EA8FACA3EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sure, = I'll try to pass by there :)

-- = Jaime

On Feb 29, 2012, at 5:47 PM, Marc Petit-Huguenin = wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA256

Hi Roland,

On 02/21/2012 02:22 AM, Roland Bless = wrote:
Hi,

On 20.02.2012 = 19:18, Marc Petit-Huguenin wrote:
I did not see much interest in = the RELOAD interop in Paris so far. =  If
you think that you will maybe = attend, please send me a direct email, = you
will be able to cancel without problem.  I really = need to have an idea of
the number of people attending = for planning purpose.

Basically, we = are interested, but our implementation isn't probably = mature
enough for an interop = at this IETF (amy at the next one). Furthermore, = I'll
arrive on Sunday and = can't make it on Saturday.


If you arrive before 1:00pm the = Sunday, please stop by anyway.  Knowing other
implementers can = only help to organize future interop events.

Thanks.

- -- =
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iQIcBAEBCAAGBQJPTkiAAAoJECnERZXWan7Ef9IP/0JoeEasvNpNYBm= NhiAl21Ga
dnJEK/HaXZONeqPU2EDQKv8/qktj3ulezDoJm6Tx4ym2itmdIrcKeKFBf5DB/= 8jQ
XWry4FAhd3m/y9ItWu/6CN9N9DwaEw1NMqCcBDg+UgeTM4GbjVSvc9N74p7Y1qQYXqavmh3YNEbHMkh7+C7fXDiziPOBBUU0Q+6twFIWgBb4ctFpSiuQLrdcwBp7LX95
DHPvi= uD2HJgbOmPXA6I9fy9HufJ9+HXKpklgtoeywkdaRHR69wHDNwYlRuNepLLE
oct5waapkoy= XQjkQosBBeS4t/VkY7OcYEyQe+qwH1EVrDH//pEQ2Gy+/yh6Utqjn
u5ZWwkpNzZ9dDv6aD= EP1TFbxdjSST8u8+WjkMHalYFQ6NOsvCFsFHC07scpbtMNC
G60/voeiaD7mzWoWcnPZ7b7= uXtnDeg0El0b+/tixZkTM/71dLWL6RLtfbgaDcZE1
Ku13rPvzk9TBnZZIOBiD6ryPALArp= mjIaXL5Z0GCDp8Lqz9Rw/JMuTKL+Ux7JlQ/
6JPKtHpNtybgtF5GCIliWovQdaykLT9Mo7A= mKTCqoqHL+dI0Y0F1znlXhgZPOZ/w
E3ED+QGXRt2MtbWzof/ExxeKRwuRTJimTdiV/TL0j= ok3JJuZI/QV722JE/xJ40iO
/U6ZmxA6d3W0+ySdEws5
=3Daf2d
-----END = PGP = SIGNATURE-----
_______________________________________________
P2PSI= P mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail=_B0106171-B3D5-406E-8AC7-D1EA8FACA3EA-- --Apple-Mail=_AA8D6880-3C19-455E-9849-7AF9DFB095CF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICEQCaObzOR9uy6LZk9ciUsJXTMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMTExMDA3MDgy NDA3WhcNMTQxMDA3MDgyNDA1WjBqMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNSmFpbWUg SmltZW5lejEQMA4GA1UEBRMHZWphamltbjErMCkGCSqGSIb3DQEJARYcamFpbWUuai5qaW1lbmV6 QGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzS0HqaJg8DzcIQIMn3U7 MMfhgUlP8eETQflo8p6+CtB6QePChaU+7igtsK28NwE3keNwGXAWulJlg4ScqvTHuhQkaCHpq1eZ X18exYkpzI2dw6LIVcJwVauWSIR7TEeuIHzD71ekDDdQGSFYMnhbKc+mTfWCpZ3zT9NH2IGok4kC AwEAAaOCAYgwggGEMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVs aWEuY29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRl bGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9j ZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHGphaW1lLmou amltZW5lekBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFLs/X1d9fU7fNptr Jf+FMGSwhLB8MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAlAPQI4BnKBEx2hYo3J+WU0+ZB38sRl9P39BEZXv6pFeLP1kB 0b/oe20EQshlRuzttkwMoQ2ibW70LM6+dALQ+LzYNXVxH8RUnj7ZsyLHj3kmRiT9oFi0ytayn1+O quoC1njz5q2ULAInUIw5mfKZ0Rldm0TjtmhzMTjTNGyKSHU9fi8Ra+zu6CeXg/wEVSVy6XX9Chqc sL3WkTRea2juYj+xOVnz75nybxfAp9VRdGi7OGc8dOt2rVaf18LnPbgyzNUMUJfKvETHJrT6IG7P zH0lY3o7svmyr01evx/7tFq4pBoq9vYtYCzQ2Jf31WzbJu0HEzgNZAHnAK8AMNqbjDCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICFTCCAhECAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zAJBgUrDgMCGgUAoIIBHTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMDExMTEyMTFaMCMGCSqG SIb3DQEJBDEWBBQ7km5RZ/Rvzhn2Jm6UhUWE5BrIcTBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNV BAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCaObzO R9uy6LZk9ciUsJXTMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zANBgkq hkiG9w0BAQEFAASBgGZyVdAp2dLtRZvD1ivjXk65F54LoaIwRsvVuQXBHt9xHb3vOKZKI8nm3Bzx rRoZhF0SxuH9s5MkBU6/QTRK5qxl0jAlJLXcs3euYTPyUvLA6yyELsq2ZwfCXXkLxVCrbLMzU9A/ DtqJS+u1Bz1hGb5aC5wcQfWxz78nbwrH7iWBAAAAAAAA --Apple-Mail=_AA8D6880-3C19-455E-9849-7AF9DFB095CF-- From brian.rosen@neustar.biz Thu Mar 1 06:38:13 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0321E82E3 for ; Thu, 1 Mar 2012 06:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbbHlZwAS9GE for ; Thu, 1 Mar 2012 06:38:13 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id BF8CF21E8093 for ; Thu, 1 Mar 2012 06:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330612709; x=1645963641; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Bv8wQwMawhBn1L1T6jZ/k uBKUx+MhcPWnj9y9QAOW7s=; b=pORbph59UDR2dRwUbIM+UtNo1Z51YtY4Wr2y7 mWXP3Nk5v2tuhmMOM8RxUUH/zgfi7MLV25wXnSVfaXBp/PHsw== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.3884854; Thu, 01 Mar 2012 09:38:28 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 1 Mar 2012 09:38:09 -0500 From: "Rosen, Brian" To: P2PSIP WG Date: Thu, 1 Mar 2012 09:38:08 -0500 Thread-Topic: p2psip meeting at IETF 83 Thread-Index: Acz3uOuxVkvAp0SqSmSwwqq+ScygXQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4dBQCkDIVyoo/Jesk6N42Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] p2psip meeting at IETF 83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:38:13 -0000 We have been scheduled for a meeting slot at IETF 83: p2psip Session 1 (1 hour) Wednesday, Afternoon Session II 1510-1610 Room Name: 241 This is the preliminary agenda, and it may change. Please do not assume th= is slot is definite. We are accepting requests for agenda time. We will schedule time for new w= ork which has received some interest from the WG as evidenced by list discu= ssion. Brian= From ietf-ipr@ietf.org Fri Mar 2 14:29:58 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED421E802D; Fri, 2 Mar 2012 14:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEgh3aNEQYnk; Fri, 2 Mar 2012 14:29:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E921F8496; Fri, 2 Mar 2012 14:29:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: zongning@huawei.com, even.roni@huawei.com, zhangyunfei@chinamobile.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302222957.4098.68487.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 14:29:57 -0800 Cc: p2psip@ietf.org, ipr-announce@ietf.org, bryan@ethernot.org Subject: [P2PSIP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-p2psip-rpr-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 22:29:58 -0000 Dear Ning Zong, Roni Even, Yunfei Zhang: An IPR disclosure that pertains to your Internet-Draft entitled "An extens= ion to RELOAD to support Relay Peer Routing" (draft-ietf-p2psip-rpr) was submit= ted to the IETF Secretariat on 2012-02-24 and has been posted on the "IETF Page= of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1685/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-p2= psip- rpr-01.""); The IETF Secretariat From michaelc@IDSSOFTWARE.COM Sat Mar 3 10:28:26 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653421F86AA for ; Sat, 3 Mar 2012 10:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+7ovQaQQkN9 for ; Sat, 3 Mar 2012 10:28:25 -0800 (PST) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id C757B21F867B for ; Sat, 3 Mar 2012 10:28:25 -0800 (PST) Received: (qmail 16616 invoked from network); 3 Mar 2012 18:28:24 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 3 Mar 2012 18:28:23 -0000 Received: (qmail 9477 invoked by uid 99); 3 Mar 2012 18:28:23 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Workspace Webmail 5.6.13 Message-Id: <20120303112822.61e8c06078a3b23a733c71e914c0b9df.1367639faa.wbe@email03.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 03 Mar 2012 11:28:22 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Wrong hyperlinks to ICE RFC5245 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 18:28:26 -0000 Hi,=0A=0AIn the current HTML version of base-20 draft, from section 5.5.1.5= to=0A5.5.1.14,=0A=0A http://tools.ietf.org/html/draft-ietf-p2psip-base-20= =0A=0Athere are many references of "Section X.Y of ICE" where "Section X.Y"= is=0Aa hyperlink to the draft itself instead of the actual ICE RFC5245.=0A= Please remove or correct the links.=0A=0AThanks=0A=0A--Michael=0A From petithug@acm.org Mon Mar 5 08:20:54 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7902A21F8806 for ; Mon, 5 Mar 2012 08:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe9vtlOCPGay for ; Mon, 5 Mar 2012 08:20:53 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7A421F8802 for ; Mon, 5 Mar 2012 08:20:53 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B135920474; Mon, 5 Mar 2012 16:04:06 +0000 (UTC) Message-ID: <4F54E7E2.6040503@acm.org> Date: Mon, 05 Mar 2012 08:20:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: p2psip@ietf.org References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> In-Reply-To: <4F428E6A.1020901@acm.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:20:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is the last call for participation for the RELOAD interoperability testing at IETF 83 in Paris. If you plan to attend, please send me an email as soon as possible, as the test environment capacity will be limited to the people who have registered so far. Thanks. On 02/20/2012 10:18 AM, Marc Petit-Huguenin wrote: > I did not see much interest in the RELOAD interop in Paris so far. If you > think that you will maybe attend, please send me a direct email, you will > be able to cancel without problem. I really need to have an idea of the > number of people attending for planning purpose. > > Thanks. > > On 02/10/2012 10:34 AM, Marc Petit-Huguenin wrote: >> Please let me know if you may be attending the RELOAD interop event in >> Paris. This is for planning purpose, so please send me an email even if >> you are not 100% sure about your plans - I need to have an idea of what >> kind of hardware I need to bring. I will create a private mailing-list >> for the discussion between the people who will announce their intention >> of attending. > >> Also please note that you do not need a complete implementation to >> attend. The list of attendees and the bugs found in individual >> implementations will be kept confidential. You do not need to attend the >> IETF meeting to attend the interop event. > >> Thanks. > >> On 02/07/2012 08:18 AM, Robert Sparks wrote: >>> Folks - > >>> We have made space available for RELOAD interop testing the weekend >>> before IETF83. (Two half day sessions 0900-1300 Saturday and Sunday). >>> Marc Petit-Huguenin will be coordinating the tests. Please let him >>> know if you will be bringing an implementation. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPVOfYAAoJECnERZXWan7Eq28QALyCXMVzImNWA5ZWO/+4BjKz EsLXaCQMbHChj7hNlVauU2WDiGjZ6lSQN3xUj4/OOy6gHPWl0KhY9pgmdmAMNxeV mYpUd6ghkm+DVcB2IgTmA2TZqC0oPK+jNV4lv/PyrF62qRECcjLADXuJFMkBVk7k SL3FwFFniuwsCroY7f013aNsm5oodVw/OuU6mfLwXJJXF747HlOuQJhYx8enMf2l AGsqb0R5l1sggqXubs44Nvyc1V0/SBPSH0/2ta7E6gw5QV6JZ8QiAVoMuei6me/e 41PzhTSsBA9sj53bPuG9pinqOhG4w0Ol5DC9Mcc1aJTZ4FC7xIV4ChkhJ6Kvhmz/ FYrWnwQ1LA/MxfeSO18/xbEsS5xaPmrbt1d8+sXWcPxfiJtr/T57uVaCAvu3v64n qWA2WKDz47tg9XXg/0+aA6SoLPC0n5F8V4VwsncPE5TfSM/eLcoRjOWe3yLhUF/+ E3CqU0RmQLBn8N9x1xJA2ZT1lz4dnrHah4mAIHGb5rrQYmmlsIAPnqdz12z7p4bL Flb8BnPcOtiojz5MXkDdWpQXkDqXmvwxDPWOE5aN3IdOgDRtuk8pkujFXTWiKWhP c4tvl7Q0pG7K9OTNVuyms6na1QkxQbBJqrDQ48S+xD+BXjQkvoby+d8wyoasJ772 BAyDOrdl3vDpuDLtUx9Z =vy23 -----END PGP SIGNATURE----- From davidbryan@gmail.com Mon Mar 5 09:49:00 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1A21F88A1 for ; Mon, 5 Mar 2012 09:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH99dGAwPaLu for ; Mon, 5 Mar 2012 09:48:59 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4AE521F88A0 for ; Mon, 5 Mar 2012 09:48:59 -0800 (PST) Received: by qcsq13 with SMTP id q13so2300663qcs.31 for ; Mon, 05 Mar 2012 09:48:59 -0800 (PST) Received-SPF: pass (google.com: domain of davidbryan@gmail.com designates 10.229.69.70 as permitted sender) client-ip=10.229.69.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of davidbryan@gmail.com designates 10.229.69.70 as permitted sender) smtp.mail=davidbryan@gmail.com; dkim=pass header.i=davidbryan@gmail.com Received: from mr.google.com ([10.229.69.70]) by 10.229.69.70 with SMTP id y6mr2587339qci.48.1330969739038 (num_hops = 1); Mon, 05 Mar 2012 09:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=ff9idfq5ctfVewiNQeC8N28Thvd9VBb1AR7f/+XgnnI=; b=saILOv2N2Hwx459uunM9EaKHVLp5A1ixGv+S/nJ8VKmnu0hwlKxn1Rvnh2IHqMixo1 rI9tQaNsOomIXGJcUJPy2gwodJi1ATO+3Ajq2KZgxq6KvTS1wbHjLjwZ/qlz24HFu3tb a2LXaUFZmC+gzKHocvVNX+MbOwb7+YZldOs3GSpcSlARC7zWTke7hX4Zd19M2XzN3zV8 dvmFXv4v2mxQYNoiZ5KF5PKqQp47N8eCLCLzG2uGmzLG21YxfSoRACcdLHR2N382DDVc WcFh0toChMNIy8Q4+XLYhP5Iuuve6qsD8qIkclQ36nxcTZBTai7aYpkx7WCFZpSrVtVU 4Z9w== MIME-Version: 1.0 Received: by 10.229.69.70 with SMTP id y6mr2227497qci.48.1330969738832; Mon, 05 Mar 2012 09:48:58 -0800 (PST) Sender: davidbryan@gmail.com Received: by 10.229.227.194 with HTTP; Mon, 5 Mar 2012 09:48:58 -0800 (PST) Date: Mon, 5 Mar 2012 09:48:58 -0800 X-Google-Sender-Auth: WFxlQ3iwGJ-GJPIlUQ4FCZGDA1Y Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Call for agenda items X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:49:00 -0000 If you have interest in an agenda slot for IETF-83, please send to Brian and myself. We will have enough space on the agenda this time to consider non-WG item presentations if they have had some mailing list discussion. Thanks, David (as chair) From andre.becker@student.kit.edu Tue Mar 13 14:02:55 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7121E8028 for ; Tue, 13 Mar 2012 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUFWW+GzpXqt for ; Tue, 13 Mar 2012 14:02:54 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF2921E8020 for ; Tue, 13 Mar 2012 14:02:51 -0700 (PDT) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1S7Yrp-0004W4-Ic; Tue, 13 Mar 2012 22:02:49 +0100 Received: from [192.168.0.103] (172.21.117.6) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 13 Mar 2012 22:02:49 +0100 Message-ID: <4F5FB5F4.3090208@student.kit.edu> Date: Tue, 13 Mar 2012 22:02:44 +0100 From: =?ISO-8859-15?Q?Andr=E9_Becker?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 8bit Subject: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 21:02:55 -0000 Hi, there's an ambiguity in the current draft concerning the ConfigUpdate mechanism. It remains unclear which node is responsible for checking the configuration_sequence number (and, additionally, to generate the appropriate error and the ConfigUpdateReq). Section 5.5.4 states: The ConfigUpdate method is used to push updated configuration data across the overlay. Whenever a node detects that another node has old configuration data, it MUST generate a ConfigUpdate request. A ConfigUpdate request must be generated if an old configuration_sequence number is detected, but when does a node check it? In section 5.3.2.1 it says: When a destination node receives a request, it MUST check that the configuration_sequence field is equal to its own configuration sequence number. If they do not match, it MUST generate an error, either Error_Config_Too_Old or Error_Config_Too_New. In addition, if the configuration file in the request is too old, it MUST generate a ConfigUpdate message to update the requesting node. The critical term now is "destination node". If you search the document, you'll find this term also in section 5.3.4. Here it is used for the node that reassembles the fragments and checks the signature, meaning the last node on the message's route. There are several reasons why this node cannot or should not be meant by section 5.3.2.1. I'm pretty sure that the configuration_sequence number must be checked by EACH peer, including intermediate nodes. If only the last node checked the configuration_sequence number, it would take significantly longer time for new configuration data to spread in the overlay. Additionally, security problems would arise, which is even more important. So my suggestion would be to change the text of section 5.3.2.1 cited above to something equivalent to the following: Whenever a destination node or intermediate node receives a message, it MUST check that the configuration_sequence field is equal to its own configuration sequence number. If they do not match, it MUST generate an error, either Error_Config_Too_Old or Error_Config_Too_New. In addition, if the configuration file in the request is too old, it MUST generate a ConfigUpdate message to update the last node that forwarded the message. I'd be glad to read your comments, André From petithug@acm.org Tue Mar 13 16:11:35 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C1821E8060 for ; Tue, 13 Mar 2012 16:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QptM6hxdYMg for ; Tue, 13 Mar 2012 16:11:34 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2579A21E804F for ; Tue, 13 Mar 2012 16:11:34 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 22A1C2041A; Tue, 13 Mar 2012 22:54:14 +0000 (UTC) Message-ID: <4F5FD422.1050401@acm.org> Date: Tue, 13 Mar 2012 16:11:30 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= References: <4F5FB5F4.3090208@student.kit.edu> In-Reply-To: <4F5FB5F4.3090208@student.kit.edu> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 23:11:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/13/2012 02:02 PM, AndrĂ© Becker wrote: > Hi, > > there's an ambiguity in the current draft concerning the ConfigUpdate > mechanism. It remains unclear which node is responsible for checking the > configuration_sequence number (and, additionally, to generate the > appropriate error and the ConfigUpdateReq). Section 5.5.4 states: > > The ConfigUpdate method is used to push updated configuration data across > the overlay. Whenever a node detects that another node has old > configuration data, it MUST generate a ConfigUpdate request. > > A ConfigUpdate request must be generated if an old configuration_sequence > number is detected, but when does a node check it? In section 5.3.2.1 it > says: > > When a destination node receives a request, it MUST check that the > configuration_sequence field is equal to its own configuration sequence > number. If they do not match, it MUST generate an error, either > Error_Config_Too_Old or Error_Config_Too_New. In addition, if the > configuration file in the request is too old, it MUST generate a > ConfigUpdate message to update the requesting node. > > The critical term now is "destination node". If you search the document, > you'll find this term also in section 5.3.4. Here it is used for the node > that reassembles the fragments and checks the signature, meaning the last > node on the message's route. There are several reasons why this node cannot > or should not be meant by section 5.3.2.1. I'm pretty sure that the > configuration_sequence number must be checked by EACH peer, including > intermediate nodes. If only the last node checked the > configuration_sequence number, it would take significantly longer time for > new configuration data to spread in the overlay. Additionally, security > problems would arise, which is even more important. So my suggestion would > be to change the text of section 5.3.2.1 cited above to something > equivalent to the following: > > Whenever a destination node or intermediate node receives a message, it > MUST check that the configuration_sequence field is equal to its own > configuration sequence number. If they do not match, it MUST generate an > error, either Error_Config_Too_Old or Error_Config_Too_New. In addition, if > the configuration file in the request is too old, it MUST generate a > ConfigUpdate message to update the last node that forwarded the message. > There was a similar discussion last year: https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPX9QdAAoJECnERZXWan7Elu0QAJj2mAhH3SHuMcwkHk+2pd0K LKdwC2stROdXeEcDkw5pmI3OR2t7StjZTgSgOPNzYsCv6O6qH3ZGtPFAbL6K6gqp IZjj1EvuRd4508B/Ju5gkexKAw2ZpCBsiMtJ0D7xE3b4ZI8PMiPY3mP3CtY5b7pG DLtmkZGzKqXepiUehNUUaxsgaPntRgYvDKmw6hX2pN30KkdWZVaJVNKiOce5iwuz 5VE3TUV6JDJ5BiEFr9EtDCyYjAdnA/CzlULtrUhPxdrzUl5852WjCYXz2J6RrKcy UW4Ag6dk8tVsI8d7kuYeBJIVMPQCJlXaeHpYxYFGIrXTwM7hj0s5zCbnjDn+kCS8 SsLhcnsVcsr9ykYaqdMdOR1FliGQppJcxwbw5FNdzcL2paeLX3tEMDodZAIYFCkH D4mK3SQI1SWqhLu0u3qaC4UOF8c6gSQGMj2YC3BTFnGCTYpzonMszIFpCbDSfgQk FDUdpslw+1nytYdtNggN0aF8OwqW4sIh+k+J3W3l73Ac7ja5UBKmsKLZE21lGbmZ 73JV1O3I8xtV/cVMO1cE9dS4oTlcZuxDc6mHzcNYz5TJnoO9bDB6uhFRR2JY82PP ZEplULT8gNCnGEwLsBScTM0zmP5fGhQNxm//gJXKzswqCJ+9nBkACPGHA8BYcfG3 I7cSxAFpgVkmvf5KJjuI =lhlC -----END PGP SIGNATURE----- From andre.becker@student.kit.edu Wed Mar 14 03:31:28 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54D521F8680 for ; Wed, 14 Mar 2012 03:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTNhUzkjgtFI for ; Wed, 14 Mar 2012 03:31:28 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id B69AE21F8678 for ; Wed, 14 Mar 2012 03:31:27 -0700 (PDT) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1S7lUL-0008FR-UR; Wed, 14 Mar 2012 11:31:25 +0100 Received: from [192.168.0.103] (172.21.117.6) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 14 Mar 2012 11:31:25 +0100 Message-ID: <4F60737C.6010908@student.kit.edu> Date: Wed, 14 Mar 2012 11:31:24 +0100 From: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4F5FB5F4.3090208@student.kit.edu> <4F5FD422.1050401@acm.org> In-Reply-To: <4F5FD422.1050401@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Cc: "P2PSIP@ietf.org" Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:31:28 -0000 Hi, Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/13/2012 02:02 PM, AndrĂ© Becker wrote: >> Hi, >> >> there's an ambiguity in the current draft concerning the ConfigUpdate >> mechanism. It remains unclear which node is responsible for checking the >> configuration_sequence number (and, additionally, to generate the >> appropriate error and the ConfigUpdateReq). Section 5.5.4 states: >> >> The ConfigUpdate method is used to push updated configuration data across >> the overlay. Whenever a node detects that another node has old >> configuration data, it MUST generate a ConfigUpdate request. >> >> A ConfigUpdate request must be generated if an old configuration_sequence >> number is detected, but when does a node check it? In section 5.3.2.1 it >> says: >> >> When a destination node receives a request, it MUST check that the >> configuration_sequence field is equal to its own configuration sequence >> number. If they do not match, it MUST generate an error, either >> Error_Config_Too_Old or Error_Config_Too_New. In addition, if the >> configuration file in the request is too old, it MUST generate a >> ConfigUpdate message to update the requesting node. >> >> The critical term now is "destination node". If you search the document, >> you'll find this term also in section 5.3.4. Here it is used for the node >> that reassembles the fragments and checks the signature, meaning the last >> node on the message's route. There are several reasons why this node cannot >> or should not be meant by section 5.3.2.1. I'm pretty sure that the >> configuration_sequence number must be checked by EACH peer, including >> intermediate nodes. If only the last node checked the >> configuration_sequence number, it would take significantly longer time for >> new configuration data to spread in the overlay. Additionally, security >> problems would arise, which is even more important. So my suggestion would >> be to change the text of section 5.3.2.1 cited above to something >> equivalent to the following: >> >> Whenever a destination node or intermediate node receives a message, it >> MUST check that the configuration_sequence field is equal to its own >> configuration sequence number. If they do not match, it MUST generate an >> error, either Error_Config_Too_Old or Error_Config_Too_New. In addition, if >> the configuration file in the request is too old, it MUST generate a >> ConfigUpdate message to update the last node that forwarded the message. >> > There was a similar discussion last year: > > https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html Thanks for the pointer. However, the discussion back then did not include the security aspects. I outlined a possible attack on RELOAD using the current ConfigUpdate mechanism in my bachelor thesis which is, unfortunately, written in german. But here a short summary of the attack: An adversary who is part of the overlay can store an old message of a node he wants to attack (called the target node). He now changes the configuration_sequence number (which is not included in the signature) to an old value and sends this message to an arbitrary destination node in the overlay. What does this node do? It first generates an Error_Config_Too_Old which is sent to the adversary (by reversing the via list). The ConfigUpdateReq, however, cannot be sent by reversing the via list, it is a totally new request with new transaction_id. This request is sent to the creator of the message, which is not the adversary, but the the target node. This means the adversary can cause an arbitrary node to send a message of big size, probably RELOADs biggest message to a target node he wants to attack. This node MUST check the message's signature, which is the potentially most expensive operation in RELOAD. Now the adversary can send it's, let's say "forged messages" (old messages with altered configuration_sequence) to a huge number of nodes over routes of different lengths (arranged with appropriate destination lists). These nodes that generate the ConfigUpdateReqs also have different distances to the target node. This means: If correctly timed, the adversary can cause a huge number of messages of big size to arrive at the target node at approximately the same time, which definitely could result in a denial of service. The adversary needs only one single node to form the attack AND he cannot be detected by the attacked peer. I hope this revives the discussion. Regards, AndrĂ© From petithug@acm.org Wed Mar 14 06:15:06 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761B421F84EB for ; Wed, 14 Mar 2012 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81y+LGZuzyFo for ; Wed, 14 Mar 2012 06:15:05 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0619C21F84FC for ; Wed, 14 Mar 2012 06:15:05 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9FAC720199; Wed, 14 Mar 2012 12:57:43 +0000 (UTC) Message-ID: <4F6099D5.1080602@acm.org> Date: Wed, 14 Mar 2012 06:15:01 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= References: <4F5FB5F4.3090208@student.kit.edu> <4F5FD422.1050401@acm.org> <4F60737C.6010908@student.kit.edu> In-Reply-To: <4F60737C.6010908@student.kit.edu> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "P2PSIP@ietf.org" Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:15:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/14/2012 03:31 AM, AndrĂ© Becker wrote: > Hi, > > Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 03/13/2012 02:02 PM, AndrĂ© Becker wrote: >>> Hi, >>> >>> there's an ambiguity in the current draft concerning the ConfigUpdate >>> mechanism. It remains unclear which node is responsible for checking >>> the configuration_sequence number (and, additionally, to generate the >>> appropriate error and the ConfigUpdateReq). Section 5.5.4 states: >>> >>> The ConfigUpdate method is used to push updated configuration data >>> across the overlay. Whenever a node detects that another node has old >>> configuration data, it MUST generate a ConfigUpdate request. >>> >>> A ConfigUpdate request must be generated if an old >>> configuration_sequence number is detected, but when does a node check >>> it? In section 5.3.2.1 it says: >>> >>> When a destination node receives a request, it MUST check that the >>> configuration_sequence field is equal to its own configuration sequence >>> number. If they do not match, it MUST generate an error, either >>> Error_Config_Too_Old or Error_Config_Too_New. In addition, if the >>> configuration file in the request is too old, it MUST generate a >>> ConfigUpdate message to update the requesting node. >>> >>> The critical term now is "destination node". If you search the >>> document, you'll find this term also in section 5.3.4. Here it is used >>> for the node that reassembles the fragments and checks the signature, >>> meaning the last node on the message's route. There are several >>> reasons why this node cannot or should not be meant by section 5.3.2.1. >>> I'm pretty sure that the configuration_sequence number must be checked >>> by EACH peer, including intermediate nodes. If only the last node >>> checked the configuration_sequence number, it would take significantly >>> longer time for new configuration data to spread in the overlay. >>> Additionally, security problems would arise, which is even more >>> important. So my suggestion would be to change the text of section >>> 5.3.2.1 cited above to something equivalent to the following: >>> >>> Whenever a destination node or intermediate node receives a message, it >>> MUST check that the configuration_sequence field is equal to its own >>> configuration sequence number. If they do not match, it MUST generate >>> an error, either Error_Config_Too_Old or Error_Config_Too_New. In >>> addition, if the configuration file in the request is too old, it MUST >>> generate a ConfigUpdate message to update the last node that forwarded >>> the message. >>> >> There was a similar discussion last year: >> >> https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html > Thanks for the pointer. However, the discussion back then did not include > the security aspects. I outlined a possible attack on RELOAD using the > current ConfigUpdate mechanism in my bachelor thesis which is, > unfortunately, written in german. But here a short summary of the attack: > > An adversary who is part of the overlay can store an old message of a node > he wants to attack (called the target node). He now changes the > configuration_sequence number (which is not included in the signature) to > an old value and sends this message to an arbitrary destination node in > the overlay. What does this node do? It first generates an > Error_Config_Too_Old which is sent to the adversary (by reversing the via > list). The ConfigUpdateReq, however, cannot be sent by reversing the via > list, it is a totally new request with new transaction_id. This request is > sent to the creator of the message, which is not the adversary, but the the > target node. > > This means the adversary can cause an arbitrary node to send a message of > big size, probably RELOADs biggest message to a target node he wants to > attack. This node MUST check the message's signature, which is the > potentially most expensive operation in RELOAD. Now the adversary can send > it's, let's say "forged messages" (old messages with altered > configuration_sequence) to a huge number of nodes over routes of different > lengths (arranged with appropriate destination lists). These nodes that > generate the ConfigUpdateReqs also have different distances to the target > node. This means: > > If correctly timed, the adversary can cause a huge number of messages of > big size to arrive at the target node at approximately the same time, which > definitely could result in a denial of service. The adversary needs only > one single node to form the attack AND he cannot be detected by the > attacked peer. The configuration_sequence field should probably be part of the signature. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPYJnRAAoJECnERZXWan7ERloP/0VCYNjSvs14w6JgxC/QkmS4 8cr9tdj6Ozi/tR1tQqRsd7/JCet+sMlBYj45+owPFj7ahZuI8X7K5jlM3ZQWWlo7 7rItWnR3qzEoTNETHXkKMY7ifLRkkFrg345S/pUY8aTaeYNwLkvCPZiLPynjB8Nr 84AsIUv/4iVd0+Qe6U9cJqtIoPrykg+J32MolLgEYFVAEaicnJG0DPcBDj7vMN3U CeBWOD776JqMswzqa7czrHQ8DR3qdbcyyAIG2Ntri3OWAqXL5rxb7V9RtKxNvFLy ti5KZPwEpm+AoPZH2gQbPkuGJU0u+w0TgBhQITGc/Grn9Yy+0TBEqq5vfJtpqBRM gCOJ36Y4MxeWsRqeTiYzaKposRc3g7rjPvRnZetat3CPxwMHr0Qn5aMwFZeqCwSe NpSSKmeCaeTE5+4CHkg6ywiY6xJYRUQhKtUoO2ESownUwei59axorL8Tjr20enqg zwJ5Z9O/MGu5C9M1YBjVbEdC2znLxyGGu6tGTLwl4VoFVqkwL66fQaORM4vU7XhI dJesg+tJoeqrWbdOXskD0wx3X4PL6fKYJNWzLCXX/xP49JN++GCZdXfQjlJ4SYqj K+AH9d0++2TIHRCsW3xDIYJJFb1GVsG07mGKU9lbQYfGLif+F9vXu7Os1dWfA3Tu HNbvxpTx2/O7OLByhp68 =pAkb -----END PGP SIGNATURE----- From andre.becker@student.kit.edu Wed Mar 14 07:08:28 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F221F8821 for ; Wed, 14 Mar 2012 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSISTOpV3srf for ; Wed, 14 Mar 2012 07:08:27 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id AB32021F881C for ; Wed, 14 Mar 2012 07:08:24 -0700 (PDT) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1S7osJ-00073c-8v; Wed, 14 Mar 2012 15:08:23 +0100 Received: from [192.168.0.103] (172.21.117.6) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 14 Mar 2012 15:08:23 +0100 Message-ID: <4F60A655.20509@student.kit.edu> Date: Wed, 14 Mar 2012 15:08:21 +0100 From: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4F5FB5F4.3090208@student.kit.edu> <4F5FD422.1050401@acm.org> <4F60737C.6010908@student.kit.edu> <4F6099D5.1080602@acm.org> In-Reply-To: <4F6099D5.1080602@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Cc: "P2PSIP@ietf.org" Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:08:28 -0000 Hi, Am 14.03.2012 14:15, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/14/2012 03:31 AM, AndrĂ© Becker wrote: >> Hi, >> >> Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 03/13/2012 02:02 PM, AndrĂ© Becker wrote: >>>> Hi, >>>> >>>> there's an ambiguity in the current draft concerning the ConfigUpdate >>>> mechanism. It remains unclear which node is responsible for checking >>>> the configuration_sequence number (and, additionally, to generate the >>>> appropriate error and the ConfigUpdateReq). Section 5.5.4 states: >>>> >>>> The ConfigUpdate method is used to push updated configuration data >>>> across the overlay. Whenever a node detects that another node has old >>>> configuration data, it MUST generate a ConfigUpdate request. >>>> >>>> A ConfigUpdate request must be generated if an old >>>> configuration_sequence number is detected, but when does a node check >>>> it? In section 5.3.2.1 it says: >>>> >>>> When a destination node receives a request, it MUST check that the >>>> configuration_sequence field is equal to its own configuration sequence >>>> number. If they do not match, it MUST generate an error, either >>>> Error_Config_Too_Old or Error_Config_Too_New. In addition, if the >>>> configuration file in the request is too old, it MUST generate a >>>> ConfigUpdate message to update the requesting node. >>>> >>>> The critical term now is "destination node". If you search the >>>> document, you'll find this term also in section 5.3.4. Here it is used >>>> for the node that reassembles the fragments and checks the signature, >>>> meaning the last node on the message's route. There are several >>>> reasons why this node cannot or should not be meant by section 5.3.2.1. >>>> I'm pretty sure that the configuration_sequence number must be checked >>>> by EACH peer, including intermediate nodes. If only the last node >>>> checked the configuration_sequence number, it would take significantly >>>> longer time for new configuration data to spread in the overlay. >>>> Additionally, security problems would arise, which is even more >>>> important. So my suggestion would be to change the text of section >>>> 5.3.2.1 cited above to something equivalent to the following: >>>> >>>> Whenever a destination node or intermediate node receives a message, it >>>> MUST check that the configuration_sequence field is equal to its own >>>> configuration sequence number. If they do not match, it MUST generate >>>> an error, either Error_Config_Too_Old or Error_Config_Too_New. In >>>> addition, if the configuration file in the request is too old, it MUST >>>> generate a ConfigUpdate message to update the last node that forwarded >>>> the message. >>>> >>> There was a similar discussion last year: >>> >>> https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html >> Thanks for the pointer. However, the discussion back then did not include >> the security aspects. I outlined a possible attack on RELOAD using the >> current ConfigUpdate mechanism in my bachelor thesis which is, >> unfortunately, written in german. But here a short summary of the attack: >> >> An adversary who is part of the overlay can store an old message of a node >> he wants to attack (called the target node). He now changes the >> configuration_sequence number (which is not included in the signature) to >> an old value and sends this message to an arbitrary destination node in >> the overlay. What does this node do? It first generates an >> Error_Config_Too_Old which is sent to the adversary (by reversing the via >> list). The ConfigUpdateReq, however, cannot be sent by reversing the via >> list, it is a totally new request with new transaction_id. This request is >> sent to the creator of the message, which is not the adversary, but the the >> target node. >> >> This means the adversary can cause an arbitrary node to send a message of >> big size, probably RELOADs biggest message to a target node he wants to >> attack. This node MUST check the message's signature, which is the >> potentially most expensive operation in RELOAD. Now the adversary can send >> it's, let's say "forged messages" (old messages with altered >> configuration_sequence) to a huge number of nodes over routes of different >> lengths (arranged with appropriate destination lists). These nodes that >> generate the ConfigUpdateReqs also have different distances to the target >> node. This means: >> >> If correctly timed, the adversary can cause a huge number of messages of >> big size to arrive at the target node at approximately the same time, which >> definitely could result in a denial of service. The adversary needs only >> one single node to form the attack AND he cannot be detected by the >> attacked peer. > The configuration_sequence field should probably be part of the signature. I thought about that too, but I think that does not solve the problem. This would mean that, before a ConfigUpdateReq is generated, the receiving node had to validate the signature of the request. But: Can or should a node be able to validate a signature computed with an old configuration document? I don't think so, as the root certificates are part of the document. Also, a possible extension to RELOAD could be to include allowed (or required) algorithms for signature computation in the configuration document. This would stress this problem even more. This is why I would prefer to keep the configuartion_sequence out of the signature. If the attack I presented is a serious issue (which I think it is), the questions is which change would cut deeper: Checking of configuration_sequence by each peer on the route, or taking configuration_sequence into the signature. In my implementation, the latter would cause more work, but I can't speak for other implementations. Regards, AndrĂ© From petithug@acm.org Wed Mar 14 08:22:44 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91DB21E8073 for ; Wed, 14 Mar 2012 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGEKPo5-iLr8 for ; Wed, 14 Mar 2012 08:22:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8E87C21E8054 for ; Wed, 14 Mar 2012 08:22:43 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 95DC020199; Wed, 14 Mar 2012 15:05:22 +0000 (UTC) Message-ID: <4F60B7C0.2020200@acm.org> Date: Wed, 14 Mar 2012 08:22:40 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= References: <4F5FB5F4.3090208@student.kit.edu> <4F5FD422.1050401@acm.org> <4F60737C.6010908@student.kit.edu> <4F6099D5.1080602@acm.org> <4F60A655.20509@student.kit.edu> In-Reply-To: <4F60A655.20509@student.kit.edu> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "P2PSIP@ietf.org" Subject: [P2PSIP] Attack on ConfigUpdate [was Re: draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:22:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/14/2012 07:08 AM, AndrĂ© Becker wrote: > Hi, > > Am 14.03.2012 14:15, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 03/14/2012 03:31 AM, AndrĂ© Becker wrote: >>> Hi, >>> >>> Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> On 03/13/2012 02:02 PM, AndrĂ© Becker wrote: [...] >>> Thanks for the pointer. However, the discussion back then did not >>> include the security aspects. I outlined a possible attack on RELOAD >>> using the current ConfigUpdate mechanism in my bachelor thesis which >>> is, unfortunately, written in german. But here a short summary of the >>> attack: >>> >>> An adversary who is part of the overlay can store an old message of a >>> node he wants to attack (called the target node). He now changes the >>> configuration_sequence number (which is not included in the signature) >>> to an old value and sends this message to an arbitrary destination node >>> in the overlay. What does this node do? It first generates an >>> Error_Config_Too_Old which is sent to the adversary (by reversing the >>> via list). The ConfigUpdateReq, however, cannot be sent by reversing >>> the via list, it is a totally new request with new transaction_id. This >>> request is sent to the creator of the message, which is not the >>> adversary, but the the target node. >>> >>> This means the adversary can cause an arbitrary node to send a message >>> of big size, probably RELOADs biggest message to a target node he wants >>> to attack. This node MUST check the message's signature, which is the >>> potentially most expensive operation in RELOAD. Now the adversary can >>> send it's, let's say "forged messages" (old messages with altered >>> configuration_sequence) to a huge number of nodes over routes of >>> different lengths (arranged with appropriate destination lists). These >>> nodes that generate the ConfigUpdateReqs also have different distances >>> to the target node. This means: >>> >>> If correctly timed, the adversary can cause a huge number of messages >>> of big size to arrive at the target node at approximately the same >>> time, which definitely could result in a denial of service. The >>> adversary needs only one single node to form the attack AND he cannot >>> be detected by the attacked peer. >> The configuration_sequence field should probably be part of the >> signature. > I thought about that too, but I think that does not solve the problem. > This would mean that, before a ConfigUpdateReq is generated, the receiving > node had to validate the signature of the request. But: Can or should a > node be able to validate a signature computed with an old configuration > document? I don't think so, as the root certificates are part of the > document. Well, this is not explicitly said in the I-D, but a reasonable way to implement RELOAD is to be sure that any new version of the configuration document always also contains the old root certificate when a new one is distributed. > Also, a possible extension to RELOAD could be to include allowed (or > required) algorithms for signature computation in the configuration > document. This would stress this problem even more. > > This is why I would prefer to keep the configuartion_sequence out of the > signature. If the attack I presented is a serious issue (which I think it > is), the questions is which change would cut deeper: Checking of > configuration_sequence by each peer on the route, or taking > configuration_sequence into the signature. In my implementation, the > latter would cause more work, but I can't speak for other implementations. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPYLe+AAoJECnERZXWan7E1XUP/jqq+58xGEVTUXOt5T5Hh4VR U2xZ2m/pFPlk8Sv5mEWLkbSITohMkn8gL+3aViCtSrRqZdAkD65cGLrbd1vGQojL AATT5QM3WCeUtSsC/gXquqJcej5nRweVICs2A0WguzKY7YMKCJz9V17W0TVfRi/P 0+FTZKPy3os1FGGIWweKbWluHzRsvCSM83SXiCk8y0uCZ9ChK0iVECl1OBIy2xIK OSlT8SjKEJZMHdF9EGRGLNrcavkungp6XhwV6/ji5SaBDqHSiM2AJtVtFBrnBQkM V81LoQ4C144c5s82c+ClSKh5sW0CEKu73K28Y8IrUBfISs11oaLO687HbIu1F7S9 SngSeuOvtpi3SLInGPOBhDMwh1mcHIBp2QdbGQb9SZbd+ULNxX+SLpWXWk+Hngw3 i3ZamKiu1/DVn1uJlX2ZvR4ylPDZojGsY63WaCpyH7qAsKsvkuytGweDe0Yzj3U6 qARLW+21/hPmiU/VwcP48R4MprzVqJ+e+OhLFcalwbL0kAK8hPBhqLNOW408tfKP O7HaawKrWaAWvTHjqp/FMdNMG5MZbCJ9dDPvl5jr0ojr8bU6uaGIGMrfjKen1R+/ TZCAuTAnnNrhPcXuECO99WHFj6QCMkxOCBoNcfHE7DWko86Z6t+S70JmbN6A6mGr N3AnsnAAy98IrXPkR9pk =MaE2 -----END PGP SIGNATURE----- From davidbryan@gmail.com Thu Mar 15 08:42:24 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBFD21F874F for ; Thu, 15 Mar 2012 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGTxtudwAY7i for ; Thu, 15 Mar 2012 08:42:23 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5D21F875A for ; Thu, 15 Mar 2012 08:42:22 -0700 (PDT) Received: by faaa25 with SMTP id a25so662011faa.31 for ; Thu, 15 Mar 2012 08:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=FEzZwGjUWPYDsd4bwvDe8x5Zqt6HL56RDLyneumPTmo=; b=tLKQGj66ylxfrWQu9NjsPLKetXinChGFwYv6qGmCWa3JS3ymhM0ffjGJHRYwuWdyRe xb0veKMRBKW6Tw09LcCLHX3ur09duiZGP972DUT6949Wqpv/ckrCg7UbsW8w6K+mKHTp Oqx9ki7WMo2ClnXIsps/oQ1f7rgcfsDsTN1NzLVU++QFb1H5Vur9rUr/Zrfojrif7LIN MCu8GwHt8eJahafNdYcgBtiNCd4OcLBugWCsv8ofM6rgRlQBEwcU9MAXHetF3pkiZxac mPppoP3FyKLbYLbIfgQElGvVwChgE9HUQojnGW39p44tAqR2LcSrkUFUmCEE4YE4xFDp 9O7A== MIME-Version: 1.0 Received: by 10.224.1.9 with SMTP id 9mr8354491qad.30.1331826140347; Thu, 15 Mar 2012 08:42:20 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.227.194 with HTTP; Thu, 15 Mar 2012 08:42:20 -0700 (PDT) Date: Thu, 15 Mar 2012 08:42:20 -0700 X-Google-Sender-Auth: Xbx3FxedEx8jsHeYRlljoTXWEfs Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Draft agenda for Paris X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:42:25 -0000 Hello all, here is the draft agenda for Paris. The first two items (DRR/RPR and Service Discovery) will be going to WGLC right after Paris, so they are first on our agenda. We also have a few new (non-WG) items on the agenda this time. David (as chair) --- P2PSIP Agenda, IETF-83, Paris DRR/RPR Update, :10, draft-ietf-p2psip-drr-01/draft-ietf-rpr-01, (speaker TBD) Service Discover Draft Update, :10, draft-ietf-p2psip-service-discovery-04, (speaker TBD) RELOAD Update, :10, draft-ietf-p2psip-base-20, Cullen Jennings ShaRe/DisCo Update, :10, draft-knauf-p2psip-disco-04 and draft-knauf-p2psip-share-02, Thomas Schmidt SNMP Usage for RELOAD, :10, draft-peng-p2psip-snmp-04, Peng Yonglin COAP, :10, draft-jimenze-p2psip-coap-reload-01, Jamie Jimenez From petithug@acm.org Thu Mar 15 08:58:34 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB6B21F8729 for ; Thu, 15 Mar 2012 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-Yv0Ipx4U+U for ; Thu, 15 Mar 2012 08:58:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CF93921F8722 for ; Thu, 15 Mar 2012 08:58:32 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E9DF2201BE; Thu, 15 Mar 2012 15:41:07 +0000 (UTC) Message-ID: <4F6211A5.9040308@acm.org> Date: Thu, 15 Mar 2012 08:58:29 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: "David A. Bryan" References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Draft agenda for Paris X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:58:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/15/2012 08:42 AM, David A. Bryan wrote: > Hello all, here is the draft agenda for Paris. The first two items (DRR/RPR > and Service Discovery) will be going to WGLC right after Paris, so they are > first on our agenda. We also have a few new (non-WG) items on the agenda > this time. > > David (as chair) > > --- > > P2PSIP Agenda, IETF-83, Paris > > DRR/RPR Update, :10, draft-ietf-p2psip-drr-01/draft-ietf-rpr-01, (speaker > TBD) Service Discover Draft Update, :10, > draft-ietf-p2psip-service-discovery-04, (speaker TBD) RELOAD Update, :10, > draft-ietf-p2psip-base-20, Cullen Jennings The slides from the presentation in Taipei are still not available on the web site, and the minutes for this presentation still do not reflect the discussion. Shouldn't this been fixed before having a new presentation about RELOAD? > ShaRe/DisCo Update, :10, draft-knauf-p2psip-disco-04 and > draft-knauf-p2psip-share-02, Thomas Schmidt SNMP Usage for RELOAD, :10, > draft-peng-p2psip-snmp-04, Peng Yonglin COAP, :10, > draft-jimenze-p2psip-coap-reload-01, Jamie Jimenez - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPYhGkAAoJECnERZXWan7EXZEP/iMWuAU8bRGvGETNBfuaDyKJ l/qqdcefLMPfi6RZ+1BmzEEHBTWEK39djJ4sdzOtT4JPU+ctmF9U0l9bbdcYHdfN BU68xkeAOMOBnHOEw+m3buFFrNRvGWRoiLqEg04o6dyhIUXdxSS26kS3d0M63tTl T41GmFoVL6DSq4aZ91Fv/6HewURm5+NcLlCUzOUHGDi0xXh2ZgcTYL6feE4s7MIQ sEdiF62TcacjWck8FeRSJzRNN/+rkiNwqAscoIa2f2wtYEFa/DnRaXh6px9lZ1d+ h8qZHyYLPxPBjoz0FByW2m0y59AGQGCLC/I53XaVGu7txe9e3UPtgFgQeTVQLdMc 5TZOgT2OQjYqHFc7xT/qYorf946E5z53KBZKnwAa/Hu2nyjmN3E6B5W7uDANNnZI GeVse6BPNQ5NhLXdy0vf0+NAvkIYj7cgXmnh/kAk6a09Ii5nHUUg2K5BJCT8K1ou TOACcx0vB8oUxqjaTOjBBEeCNO+XVYoiebhclLZ8Fg3Dagzcb2vJ7Ei2dnToah6l zfHfrs8FgKIZNrMXTbxoJkRneXzTdoLHgSmB+9TFIRcyQLPRy8j/zlkQ0s6UnFsN L/VFE4xgPnu0bbSI7NQbERvV0eENfM42lRuCUMmA78buKPU0Kdmb+d/8IYXyqaai CNcQG0tNfPqJPaX9Dv1g =A8Tl -----END PGP SIGNATURE----- From davidbryan@gmail.com Sat Mar 17 08:42:54 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF721F861A for ; Sat, 17 Mar 2012 08:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJZO9HH8kzf0 for ; Sat, 17 Mar 2012 08:42:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8067921F8619 for ; Sat, 17 Mar 2012 08:42:53 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2524982yhk.31 for ; Sat, 17 Mar 2012 08:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=8sDJevmEYh2YgKSrnhMyxOl9t3O4A8RVK+QJa2jiGnc=; b=YTY2C7ZyZbbF91s/nIlhI81kJ3tnO73nrqe5BWJm3CtuhAZuht0yZzSIVVlnT/1q1L 8EPIIR2PcTsJrYIFM0JtwB6hkydRxoWeIinOTx0+wQOTJEtAWOhgR0E7Hpaxq/pWOR47 r4+vE4wQs291y0Haq8tfzlIHUmJpEEBqhynYHA1XcFHLSDuDTvsuWa8dm3cmPnZ9HPnA SU2H6Mf1c3skBxxnBSiVbW/fKw/py+MQIrxfhBsi8BWWbYuQojo/Kq3Olg7MM8TgOE9n WuyQBhI5t7ueosoeP9NZch4LOMRcCRNKUxCcIr72geZXL/mmprDtJmKdwDe8QqWouxUB WVGw== MIME-Version: 1.0 Received: by 10.224.138.84 with SMTP id z20mr8441280qat.43.1331998973116; Sat, 17 Mar 2012 08:42:53 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.227.194 with HTTP; Sat, 17 Mar 2012 08:42:53 -0700 (PDT) Date: Sat, 17 Mar 2012 08:42:53 -0700 X-Google-Sender-Auth: ovQL9Yeigv6lWYBWF6W9-9oSt1Y Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Stepping down as chair X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 15:42:54 -0000 Hi all, I just wanted to drop a note to the list to let everyone know I am stepping down as chair. As you know, I haven't been able to make it to the last several meetings due to job constraints, and unfortunately, I won't be in Paris either. I felt it was best to step down and open the slot for someone who can devote more time to the role and is able to regularly attend the meetings. Thank you everyone for all the great ideas and hard work. I've enjoyed working on P2PSIP, and look forward to working with everyone again in the future! David From gonzalo.camarillo@ericsson.com Mon Mar 19 00:06:33 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB221F84F6 for ; Mon, 19 Mar 2012 00:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.354 X-Spam-Level: X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBGfONcXqBLK for ; Mon, 19 Mar 2012 00:06:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 761D421F84F5 for ; Mon, 19 Mar 2012 00:06:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-f6-4f66daf66425 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 20.F5.17856.6FAD66F4; Mon, 19 Mar 2012 08:06:31 +0100 (CET) Received: from [131.160.126.145] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Mon, 19 Mar 2012 08:06:30 +0100 Message-ID: <4F66DAF5.6080400@ericsson.com> Date: Mon, 19 Mar 2012 09:06:29 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "David A. Bryan" References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: P2PSIP WG Subject: Re: [P2PSIP] Stepping down as chair X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:06:33 -0000 Hi, I would like to thank David for all this work during all this years. He has been one of the main drivers for P2P technologies in the RAI area from the beginning. Spencer Dawkins will be helping Brian Rosen chair the P2PSIP session in Paris. Cheers, Gonzalo On 17/03/2012 5:42 PM, David A. Bryan wrote: > Hi all, > > I just wanted to drop a note to the list to let everyone know I am > stepping down as chair. As you know, I haven't been able to make it to > the last several meetings due to job constraints, and unfortunately, I > won't be in Paris either. I felt it was best to step down and open the > slot for someone who can devote more time to the role and is able to > regularly attend the meetings. > > Thank you everyone for all the great ideas and hard work. I've enjoyed > working on P2PSIP, and look forward to working with everyone again in > the future! > > David > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From jouni.maenpaa@ericsson.com Mon Mar 19 00:06:58 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0393321E800C for ; Mon, 19 Mar 2012 00:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnc+0cbEbs5x for ; Mon, 19 Mar 2012 00:06:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C766321E800F for ; Mon, 19 Mar 2012 00:06:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-71-4f66db0f48a0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.06.17856.F0BD66F4; Mon, 19 Mar 2012 08:06:56 +0100 (CET) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.1.66]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 19 Mar 2012 08:06:55 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Marc Petit-Huguenin , "p2psip@ietf.org" Date: Mon, 19 Mar 2012 08:06:54 +0100 Thread-Topic: [P2PSIP] Destination list [was Re: I-D Action: draft-ietf-p2psip-service-discovery-04.txt] Thread-Index: AczilikteiHuescKT5iN7aV2UJzAegjCF1fg Message-ID: <2B0A8F5B80F8BA4A90AB906FF34A2EE7355E1074E8@ESESSCMS0364.eemea.ericsson.se> References: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> <4F2C1407.9050104@acm.org> In-Reply-To: <4F2C1407.9050104@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] Destination list [was Re: I-D Action: draft-ietf-p2psip-service-discovery-04.txt] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:06:58 -0000 Hi Marc, Thanks for the comment. We will add the change you propose to the next revi= sion of the draft that we will submit when the I-D submission tool opens ag= ain. Regards, Jouni=20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Marc Petit-Huguenin Sent: 3. helmikuuta 2012 19:06 To: p2psip@ietf.org Subject: [P2PSIP] Destination list [was Re: I-D Action: draft-ietf-p2psip-s= ervice-discovery-04.txt] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 One more comment on this draft: The RedirServiceProvider resource record has a field to store the Node-ID o= f the service provider, but I think that it would be better to use a Destin= ation list instead. One of the reasons is that the provider can be a RELOA= D client without direct routability (see -base section 3.2.1, second bullet= ). There is also future extensions that could require a Destination list. = So I propose to change the definition to this: struct { RedirServiceProviderExtType type; Destination destination_list<0..2^16-1>; opaque namespace<0..2^16-1>; uint16 level; uint16 node; uint16 length; select (type) { /* This type may be extended */ } extension; } RedirServiceProvider; On 01/06/2012 02:23 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the Peer-to-Peer Session=20 > Initiation Protocol Working Group of the IETF. >=20 > Title : Service Discovery Usage for REsource LOcation And=20 > Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo=20 > Filename : draft-ietf-p2psip-service-discovery-04.txt Pages : 14 > Date : 2012-01-06 >=20 > REsource LOcation and Discovery (RELOAD) does not define a generic=20 > service discovery mechanism as part of the base protocol. This=20 > document defines how the Recursive Distributed Rendezvous (ReDiR)=20 > service discovery mechanism used in OpenDHT can be applied to RELOAD=20 > overlays to provide a generic service discovery mechanism. >=20 >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discover > y-04.txt > > >=20 Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at:=20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery > -04.txt > > >=20 - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPLBQFAAoJECnERZXWan7Ew54P/RaqTzxzwEe3OOJw3u7/BwWb zDu7g6ViTDjuZMYl6hMW0lPYaDyceAAlltEd+n6lBkmLPVydxaOSi4lF5GbCgHYz R4YPLj7/39fWQtmMtquY4AdsaJd1Skp4JlbtvTqiV9X7VJ+XLdgQRAKeHGMB6QfP pmNAq0K2udUDw8V7JsSW1whdVASBYhywvjzkEX5RRk2xs2ZwLxI649J7SmhWdCGd +MEaOtrI7uOZFJnCEoOlN/WFjqVBexWHmxzAKUHkWeNkiYmkhL3ifYvSCVO1rHeZ f071vvF+wsS6VYhGoDfo8PDm02gRSI3iIczlSFEEsE3VFIBIZMA5D00VOIhF5+7D /o8YNCeCDWLin68QrQhHRnwt7bS8hFtHDVlIjTAY5/42jWVe0VW8267ls/fnEHtl bG/+tmuceQL9RsdVO/R37GJs1LcphPbw12VFBBUVZQWe9FbjxRtl38m3cPNRjHHO yQechYu5mk2Ug/JMprLpWlLgLrV1UVPXsdl+Bbsnnie8qzr4kWfn2/NiXpgtmfiS vgRAysm1l9BpGTz5srMSkHCCftDbG6CoFceHGypiqOWi1lhVrzTHURoX4ohWV+LT XOKWImUEm40Ef4B/nVqtPpmhMDid88xBe7aUqse1nKnOCmOfHXjJDrrhmWGtmjZF mkW3okCjJtU2x1BcfwFb =3DHN7N -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Wed Mar 28 07:29:29 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A91321F8896; Wed, 28 Mar 2012 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ncNXPOcvZp; Wed, 28 Mar 2012 07:29:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F4821F888C; Wed, 28 Mar 2012 07:29:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120328142929.15500.73639.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 07:29:29 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-21.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:29:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-21.txt Pages : 166 Date : 2012-03-28 This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-21.txt