From hannes.tschofenig@gmx.net Fri Jun 1 00:45:37 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 7C68621F85A8 for ; Fri, 1 Jun 2012 00:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 3DCx-8Y7ipQi for ; Fri, 1 Jun 2012 00:45:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8B6A621F85A4 for ; Fri, 1 Jun 2012 00:45:36 -0700 (PDT) Received: (qmail invoked by alias); 01 Jun 2012 07:45:34 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 01 Jun 2012 09:45:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/tPQ0qFZTteQr+yx4SEXxh4Q8hznLmp3crqROwG0 FemiQh2b9o5IFu From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 10:45:33 +0300 Message-Id: To: p2psip@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [P2PSIP] Themes in Communication Architectures 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, 01 Jun 2012 07:45:37 -0000 Hi all,=20 this week I spoke at an academic conference and provided the researchers = with my guidelines on how they can make their research work less = successful.=20 People liked it and they are already following some of my guidelines. = Great so far.=20 At the end I got a question that I couldn't provide an answer for and I = am sure you guys have thought about this already quite a bit.=20 The computer science industry seems to be following trends (or themes) = regarding communication architectures. A few years ago (maybe 5 - 7) = everyone wanted to design protocols that follow a peer-to-peer paradigm. = This working group and others in the IETF are a result of the excitement = at that time.=20 For some reason, however, the theme changed and we are now more in a = client-to-server thinking (which is what I would call most of the cloud = computing concepts). It may change again. So, the question for you who had worked such a long time on this p2p = paradigm: What are the reasons for the shift?=20 My guess is that it is a combination of technical difficulties to get = the p2p communication systems to work and the attractiveness of the = business model for collecting everything on the server-side, i.e. the = service provider is much more in control of what is going on (call this = a customer binding) and can track the user's service usage.=20 Ciao Hannes =20= From jaime.j.jimenez@ericsson.com Fri Jun 1 03:39: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 316EA21F862B for ; Fri, 1 Jun 2012 03:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 IZDI8T4miIIO for ; Fri, 1 Jun 2012 03:39:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E558721F8627 for ; Fri, 1 Jun 2012 03:39:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-9f-4fc89be2a7e5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D8.02.00702.2EB98CF4; Fri, 1 Jun 2012 12:39:31 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Fri, 1 Jun 2012 12:39:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4F380230B; Fri, 1 Jun 2012 13:39:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4FD2752F6C; Fri, 1 Jun 2012 13:39:29 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DC9F750A58; Fri, 1 Jun 2012 13:39:28 +0300 (EEST) MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_A44CEC68-4D14-437C-BB9A-FF4474426773"; protocol="application/pkcs7-signature"; micalg=sha1 From: Jaime Jimenez In-Reply-To: Date: Fri, 1 Jun 2012 13:39:28 +0300 Message-ID: <5C9A8137-A2BF-49E2-A596-8C6395DC60A8@ericsson.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Vvfx7BP+BudesFos3XmP1WLJzTOM DkweizftZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGtKXTWAtaoiv+7frN2sDYEtTFyMEhIWAi 8Xq7UBcjJ5ApJnHh3nq2LkYuDiGBU4wSG59chnLWM0rcXzCRDaRKSGA3o8TNg94Q9jpGiekt gRBF8xglPh9YxQ6SEBawlrh1fh4TiM0rYChx8+0uVhCbWWAKo0TXWSUQm03ASOL+0ttgcU6g +g1nd4LVswioSDxb8oYF5DpmAXWJY+8DIMbYS6yeupUJYq+VxM99x8HuEQEaf33mdFaID2Ql bh/czwRhq0lcPbeJGaJeU2L3lNNsExhFZiG5aBaSi2aBbUuS+PmHGSKsLbFs4WtmiLCOxOSF jKjCEPbH80eYIGxTiddHP0LVWEvM+HWQDcJWlJjS/ZB9ASPXKkbh3MTMnPRyc73Uoszk4uL8 PL3i1E2MwLg8uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cBY8Mdr0oTA1etsth+t2bqRm8Xd40PJ7bbpzYoaPV0sJlmHc9Z/sb7MxTV/yw0F5uNnPHL+ TV1e4vXkxqEZ3aszF983n7Du7Iynnw4Keoqt/WLu61cQpzjpdmVlW2D88s97F1lIhDXnzTdP e73jdHHshq2rtiaqnZxwqEdGrXveswsq9YFijdeXKrEUZyQaajEXFScCAPe7IAmZAgAA Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Themes in Communication Architectures 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, 01 Jun 2012 10:39:33 -0000 --Apple-Mail=_A44CEC68-4D14-437C-BB9A-FF4474426773 Content-Type: multipart/alternative; boundary="Apple-Mail=_84A35FF4-89CA-4E7B-B7D2-B4DD864287BF" --Apple-Mail=_84A35FF4-89CA-4E7B-B7D2-B4DD864287BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hannes, If you mean why some parts of the industry are moving from to CS than = P2P. Leaving technical difficulties aside, which I agree are one of the = reasons, IMO everything boils down to cheap bandwidth and cheap storage. = Those two things greatly favor client-server type of systems. It is also true that companies like to collect as much info as possible, = but they could do that while still leaving processing/storage on the = client side. At this rate my OS is going to exist just to support the = browser, we will be back to mainframe computing :D Ciao! -- Jaime On Jun 1, 2012, at 10:45 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > this week I spoke at an academic conference and provided the = researchers with my guidelines on how they can make their research work = less successful.=20 > People liked it and they are already following some of my guidelines. = Great so far.=20 >=20 > At the end I got a question that I couldn't provide an answer for and = I am sure you guys have thought about this already quite a bit.=20 >=20 > The computer science industry seems to be following trends (or themes) = regarding communication architectures. A few years ago (maybe 5 - 7) = everyone wanted to design protocols that follow a peer-to-peer paradigm. = This working group and others in the IETF are a result of the excitement = at that time.=20 >=20 > For some reason, however, the theme changed and we are now more in a = client-to-server thinking (which is what I would call most of the cloud = computing concepts). It may change again. >=20 > So, the question for you who had worked such a long time on this p2p = paradigm: What are the reasons for the shift?=20 >=20 > My guess is that it is a combination of technical difficulties to get = the p2p communication systems to work and the attractiveness of the = business model for collecting everything on the server-side, i.e. the = service provider is much more in control of what is going on (call this = a customer binding) and can track the user's service usage.=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_84A35FF4-89CA-4E7B-B7D2-B4DD864287BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Hannes,

If you mean why some parts of the industry = are moving from to CS than P2P. Leaving technical difficulties = aside, which I agree are one of the reasons, IMO everything boils down = to cheap bandwidth and cheap storage. Those two things greatly = favor client-server type of systems.

It is also = true that companies like to collect as much info as possible, but they = could do that while still leaving processing/storage on the client side. = At this rate my OS is going to exist just to support the browser, we = will be back to mainframe computing = :D

Ciao!
-- = Jaime

On Jun 1, 2012, at 10:45 AM, Hannes Tschofenig = wrote:

Hi all,

this week I spoke at an academic = conference and provided the researchers with my guidelines on how they = can make their research work less successful.
People liked it and = they are already following some of my guidelines. Great so far. =

At the end I got a question that I couldn't provide an answer = for and I am sure you guys have thought about this already quite a bit. =

The computer science industry seems to be following trends (or = themes) regarding communication architectures. A few years ago (maybe 5 = - 7) everyone wanted to design protocols that follow a peer-to-peer = paradigm. This working group and others in the IETF are a result of the = excitement at that time.

For some reason, however, the theme = changed and we are now more in a client-to-server thinking (which is = what I would call most of the cloud computing concepts). It may change = again.

So, the question for you who had worked such a long time = on this p2p paradigm: What are the reasons for the shift?

My = guess is that it is a combination of technical difficulties to get the = p2p communication systems to work and the attractiveness of the business = model for collecting everything on the server-side, i.e. the service = provider is much more in control of what is going on (call this a = customer binding) and can track the user's service usage. =

Ciao
Hannes

____________________________________________= ___
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail=_84A35FF4-89CA-4E7B-B7D2-B4DD864287BF-- --Apple-Mail=_A44CEC68-4D14-437C-BB9A-FF4474426773 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MDExMDM5MjlaMCMGCSqG SIb3DQEJBDEWBBSNAijQD/KQK77WusvaTb1n9s9JazBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNV BAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCaObzO R9uy6LZk9ciUsJXTMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zANBgkq hkiG9w0BAQEFAASBgArnS3vXTMk7Wu/H/nIiE6FLqnC0clrQ6HaWwcrHspf3ZJTXXtYwkW+sHM+z AdNzKZKJ1OB0gLeTEzHmW1d9lpsvqMDmwrJUS2M34VlIMiUbRd+9P2Wtnlapsf9D4opKvou/ZAfb W2yJmyUxxUvqX1Wj9tdgl7diOPbau8De+eMXAAAAAAAA --Apple-Mail=_A44CEC68-4D14-437C-BB9A-FF4474426773-- From petithug@acm.org Wed Jun 6 07:09:02 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 1584921F8852 for ; Wed, 6 Jun 2012 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5STYDQyHksB for ; Wed, 6 Jun 2012 07:09:01 -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 E91A321F8842 for ; Wed, 6 Jun 2012 07:08:57 -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 "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 012C920945 for ; Wed, 6 Jun 2012 14:08:55 +0000 (UTC) Message-ID: <4FCF6476.9050201@acm.org> Date: Wed, 06 Jun 2012 07:08:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: p2psip@ietf.org References: <20111029194051.8068.56577.idtracker@ietfa.amsl.com> <4EAC713E.4080606@acm.org> In-Reply-To: <4EAC713E.4080606@acm.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Reissuing certificate [was I-D Action: draft-ietf-p2psip-base-19.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, 06 Jun 2012 14:09:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am currently reimplementing my RELOAD enrollment server and unfortunately the questions below were never answered. It would be great also if the open issue in section 11.3 could be decided (password errors SHOULD be returned as 401 Unauthorized). And as I am at it, here a nit in section 11.3: s/with the parameter encode as described/with the parameters encoded as described/ and two more in section 11.1: s/Inside each overlay element, the required-kinds elements can/Inside each configuration element, the required-kinds element can/ s/Multiple required-kinds elements MAY be present./Multiple kind-block elements MAY be present./ On 10/29/2011 02:33 PM, Marc Petit-Huguenin wrote: > Not a full review yet, but I saw this new text in section 10.3: > > "The enrollment server SHOULD maintain a mapping of users to node-ids and > if the same user returns (e.g., to have their certificate re-issued) > return the same Node-ID, thus avoiding the need for implementations to > re-store all their data when their certificates expire." > > Even after the sentence is fixed there would still be two issues: > > - How does this work if the user requested multiple certificates from the > same login? - How does this work if the number of Node-Ids requested > changes? > > Also I would like to point out that I proposed a different solution to > this problem in this draft: > > http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-bis-00#section-6 > > My solution does not permit to change the private key without assigning > new Node-Ids, but in addition of not having the two problems listed above, > it does not require server-side storage. > - -- 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) iQIcBAEBCAAGBQJPz2RwAAoJECnERZXWan7EndYP/j/uvdvV75NgeLu7nzyx25DP UrnpB12MQyZjzkT/5FluR862dIYTaBIYXVsKyLxslEfEp1FVs59O9q0gtEeCETay TBRj7g5Ag+KZ2ibvzTk2aYjRhO7sZFdTzmGpHM027kLLAlcDalRd6RGb3IsRpmGd nOnKwb2t+++AHQ2b/zmLpOS+ESwITHlcw3dISfyLBM4BphBQ31OWUCZGdGVgtWED P0+BC31c093V2MwcbN30o4aDEsttpp8eUKS0DaeObHpSmcszFD8VwkzuglLOsHfd gzQNZcNIWXSCKvc8+zWEU+6hqcCYHKB4quuSZLi+028sQ/95RZ30ZY0YBtK8A/I8 5zUsPNH07fGWOhIs6CoXOLmDAd7exR23Fg2HL8TvqoeIId4XONYL1zmeZ9VUOtHT NH2BRLV4VkpDzpjKlMLKgwdMO0pnIqA91sWSGZlzzGyE12iXUXJLfSk03oQ//Op0 LwMzb+SY79rSTmIt2T9yexjG1g/XGT6HL0oLO1R7777/gRB7AiIb0aGOd+ekJFY1 HbFehJ9QJ2k1nvgx1f3SNG5sHlo0/zylkVYzoKVoNA73s1+SR0S78HGqMr2iTwkl ZlfnQ3IBXEQuBsWvc7YW8D/q4UQCqC0hENJpkn4A9Ghj300bmgYUoIyfIjdvULDd 1TodgYyudu4mnLye3eUF =jXKJ -----END PGP SIGNATURE----- From fluffy@iii.ca Fri Jun 15 16:18:18 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 DC05211E80D3 for ; Fri, 15 Jun 2012 16:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00SiRxmhZfJL for ; Fri, 15 Jun 2012 16:18:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C211E80CE for ; Fri, 15 Jun 2012 16:18:17 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D4B3922DD6D; Fri, 15 Jun 2012 19:18:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 15 Jun 2012 17:18:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <86A01DD0-830F-4E02-8046-F8CDF063177C@iii.ca> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Themes in Communication Architectures 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, 15 Jun 2012 23:18:19 -0000 It's more about the business models that will fly at a given time.=20 But on the technology front, note that as lots of traffic moved from = really fast notebook computers to sort of slow mobile phones, the = relative ratio of client to server power has shifted from where it was 5 = years ago. No doubt it will shift again. That said, there is still far = more going on with P2P today than there was 5 years ago - it's just less = interesting to talk about than say SDN.=20 On Jun 1, 2012, at 1:45 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > this week I spoke at an academic conference and provided the = researchers with my guidelines on how they can make their research work = less successful.=20 > People liked it and they are already following some of my guidelines. = Great so far.=20 >=20 > At the end I got a question that I couldn't provide an answer for and = I am sure you guys have thought about this already quite a bit.=20 >=20 > The computer science industry seems to be following trends (or themes) = regarding communication architectures. A few years ago (maybe 5 - 7) = everyone wanted to design protocols that follow a peer-to-peer paradigm. = This working group and others in the IETF are a result of the excitement = at that time.=20 >=20 > For some reason, however, the theme changed and we are now more in a = client-to-server thinking (which is what I would call most of the cloud = computing concepts). It may change again. >=20 > So, the question for you who had worked such a long time on this p2p = paradigm: What are the reasons for the shift?=20 >=20 > My guess is that it is a combination of technical difficulties to get = the p2p communication systems to work and the attractiveness of the = business model for collecting everything on the server-side, i.e. the = service provider is much more in control of what is going on (call this = a customer binding) and can track the user's service usage.=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@iii.ca Fri Jun 15 16:21:25 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 9E34511E80ED for ; Fri, 15 Jun 2012 16:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAmmiEClI9iv for ; Fri, 15 Jun 2012 16:21:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 246A111E80CE for ; Fri, 15 Jun 2012 16:21:25 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5B91B22E257; Fri, 15 Jun 2012 19:21:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4FCF6476.9050201@acm.org> Date: Fri, 15 Jun 2012 17:21:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111029194051.8068.56577.idtracker@ietfa.amsl.com> <4EAC713E.4080606@acm.org> <4FCF6476.9050201@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Reissuing certificate [was I-D Action: draft-ietf-p2psip-base-19.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: Fri, 15 Jun 2012 23:21:25 -0000 On Jun 6, 2012, at 8:08 AM, Marc Petit-Huguenin wrote: > It would be great also if the open issue in section 11.3 could be = decided > (password errors SHOULD be returned as 401 Unauthorized). that was on slide 6 of the preso at last meeting - I need to go find all = the notes but I seem to recall the decision was 401 would not be used.=20= From petithug@acm.org Fri Jun 15 17:15:02 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 DB42F11E8108 for ; Fri, 15 Jun 2012 17:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNXj4eyEDxOD for ; Fri, 15 Jun 2012 17:15:00 -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 D4B3511E80CE for ; Fri, 15 Jun 2012 17:15:00 -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 "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E96AE20145; Sat, 16 Jun 2012 00:14:58 +0000 (UTC) Message-ID: <4FDBD000.6020906@acm.org> Date: Fri, 15 Jun 2012 17:14:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Cullen Jennings References: <20111029194051.8068.56577.idtracker@ietfa.amsl.com> <4EAC713E.4080606@acm.org> <4FCF6476.9050201@acm.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Reissuing certificate [was I-D Action: draft-ietf-p2psip-base-19.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: Sat, 16 Jun 2012 00:15:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/15/2012 04:21 PM, Cullen Jennings wrote: > > On Jun 6, 2012, at 8:08 AM, Marc Petit-Huguenin wrote: > >> It would be great also if the open issue in section 11.3 could be >> decided (password errors SHOULD be returned as 401 Unauthorized). > > that was on slide 6 of the preso at last meeting - I need to go find all > the notes but I seem to recall the decision was 401 would not be used. > OK, so for until it is fixed, I'll return "512 Specification broken" in my implementation. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP28//AAoJECnERZXWan7ECEsQAKJACLCL64TDMEG6fzcofp2u f4KNwxpo4eV+N1u7dV1NbAViW3NWcl33VACExrllIMPHUpTdVh3vN7sBA4ysP3iK WfasfGdPQUSJTSv266K89u6O0HOaMYcqUFOnsx/eXQs+U7b3WsHmdYsgoU4yNG2Z w+HIfUIKl39z6n0uf8NZaAzvzDtzIqkeo7HkFK85UrQh36P882aU98PR+0kRB4uU tq1tI9XDbJ55Z3STMWyRRZOMel8qhrwPuaprRVDJ91cRClxnbWngbniiwBTVHx7M +eYv+kaTKy1MOs1aBYCPhqxSjg6f5U2WvBDjhbtYDzhin2XJ7NszROgJddoleFIf ViVgrI9Lw6U7Jh8LlVVreDCRCHgXLU5xuEVSKjLO6VXs747YmU0za0fDpsvQuoqr QeF+rYn7m2XMIGPlZkeLK3aRmHJRXw3uvaNJZP+g9e8GCja4LUNQKjIf0AMoppWE 8UYkzG/rEGjBhSoOA3gZYbW3Ufvi3P7EJMfoe9Eqg+Ul3vuaAEaTVc15r3Fz6AIr KynVEls8C7ay4HWCFyWJxGkJw/pjWF1JX8RPsSmqH2v/9dOlUt9rKOn8SX86qLOl axs424UXlTAjFsNCKOJ2YFr8anbWWjOt4oSUXCGvtAcu/dcBXLvIdEVm163FC09t L8niItFNFes8rMBN3vQy =wXr3 -----END PGP SIGNATURE----- From petithug@acm.org Sat Jun 16 08:37:51 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 AECC221F8504 for ; Sat, 16 Jun 2012 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrW+697nLUdm for ; Sat, 16 Jun 2012 08:37:49 -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 C48FA21F84FB for ; Sat, 16 Jun 2012 08:37:48 -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 "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 479BC20415; Sat, 16 Jun 2012 15:37:46 +0000 (UTC) Message-ID: <4FDCA848.9000509@acm.org> Date: Sat, 16 Jun 2012 08:37:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: fangh01 References: <1f2afd1f.9a81.137e4e6f27d.Coremail.fangh01@163.com> In-Reply-To: <1f2afd1f.9a81.137e4e6f27d.Coremail.fangh01@163.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org, p2psip@ietf.org Subject: Re: [P2PSIP] [reload-implementers] Is there any protype or simple implementation about the RELOAD? 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, 16 Jun 2012 15:37:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/13/2012 01:12 AM, fangh01 wrote: > Hello, I'm interested in the RELOAD protocol, and I plan to implement a > live streaming system based on p2psip which use the RELOAD protocol. > However, after search the internet, I couldn't find any RELOAD related > implementation to reference, is there any protype or simple implementation > on RELOAD protocol offered on the internet? Look in the archives for the "Implementation listing" thread: http://implementers.org/archives/reload/2011-October/date.html > Another question is that can anyone show the standard RELOAD packets with > the ".pcap" format? I uploaded a pcap file and its associated RSA key here: http://ietf.implementers.org/reload/storage.pcap.gz http://ietf.implementers.org/reload/bootstrap.p12 You need to install the p12 in Wireshark first (password: password). Note that for some reason Wireshark 1.6.8 does not decrypt the packets. It works fine with Wireshark 1.7 (I always use the HEAD of the git tree, so YMMV). Note that this is not an endorsement of the practice of implementing protocols based on examples. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP3KhFAAoJECnERZXWan7Eb3UQALAUb4TaUpkraw9NciCw70V7 yqgmE88SF+7LOG/8fXDsEdae4brVr30r2zL/4oAdr3iAzqY9oxbwpqhteMknAMl4 EG7Wr7yshX6mN3Z+fnMmjUzOhHY0f2GFvAVkLicGeJc2ly4x57aHROeKxVugaMP5 8InD59NAfC6MzQgXGTCv/dUKaFVnUoM7pt+5cGtn9YR0Dkt+gvB4P3wt/1RDoJpo x1vp4OozC7M6dFWHrDSriIZEEysLHM+wV6fqlqFRDxskqrFGgfsjPnQW8UuhO8cJ TBLXGRuAhwinQGklUe6xISiNqkp9mXH8wgjWxgapBVYdIV8sTeLhhf51So56QoaG iKyO/AldLCDL22+iM6z1u8sqVobSOtaB+Oo9ZTKIHjmHyVNfLa107RR61tVPKqNo 3a4nYMzZNtV0EI6s3y5genuMR0DBnHJtjzls7Ibvvc8amzmjsdemjp1Xm6jEwoaK jIXw1vA4TIakCk0vYiqR1bQSUntkKPpX1G9dDzbRUT9MMsp17+bQc7S0oxgMLWNL IBoon+MSZvUxmy0YdosbNmi0FZ5GKJwHOBNHBoBlpd7Yuw/I1mH5aZFHkvuA01ll 4ym4rX81AzhafqnsEE55OwJw7i3TPUhgZ+TUFQ8PYpEuMu0GwWFZzc2xvV5gf63x XzK5Ad3yQ74X4NDCFmv4 =JOFl -----END PGP SIGNATURE----- From ekr@rtfm.com Mon Jun 18 12:55:04 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 C6DD521F870B for ; Mon, 18 Jun 2012 12:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_63=0.6, 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 L2AL+-UWTErG for ; Mon, 18 Jun 2012 12:55:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7EB621F870A for ; Mon, 18 Jun 2012 12:55:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3338545vbb.31 for ; Mon, 18 Jun 2012 12:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=3+5RiPa3AJQRF/esRbUhFB7yP0RWeBic4hHPZPBbRsE=; b=be1vXHf/oya1DM8UPwz0s3f0OzOfPYONQNTAlYY7tnTIWNk4fi7syX+zBI3j4SrvfT Sm30fmrAnusnTDxTtseUTOD0mbEPpM9FeWDaHaFyPSORSqZPg9PQLsCoXzXuSJOdYfRk /OJoCZ1zNor3emCj5evVu0i1iB3SazJ474Y1PrhcIDPCbwFrlm0NC752AHKWsXxgtM6z 2baJ0zUIiLuB6u8sFKG97fnfmu8f+SYZvN3TxB4c297FCxU+UppNJl6oPRlQQZv1mwx4 1aBG8+PNxUrxDvNz72w39GkFDDl2VulcK1gS/3mF2uaubVLdAo2UdxQhgMSTim+8h3GH Z18Q== Received: by 10.220.154.2 with SMTP id m2mr8340834vcw.2.1340049302966; Mon, 18 Jun 2012 12:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 18 Jun 2012 12:54:22 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 18 Jun 2012 12:54:22 -0700 Message-ID: To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmLSIHl86PvuTFbmZLb+jXMb6JKp5dRW+YYeitawUcn9Ok/J5SB0u9P0PFRZoe780P8jWpB Subject: [P2PSIP] Certificates in SecurityBlock 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, 18 Jun 2012 19:55:04 -0000 In principle the SecurityBlock structure is designed to work with certificates which are stored in the overlay and then retrieved at verification time. In practice, however, the certificates are indexed into the security block by Hash(cert) but stored in the overlay under subject, so you can't retrieve them from the overlay. There seem to be two fixes for this: (1) Modify(add to?) the certificate store usage to store certs under the fingerprint so they can be retrieved. (2) Stop claiming that you can fetch the certs and just say that for this version you must send the certs with the message. Is anyone interested in not sending all the certs with the message? If so, we should do (1). Otherwise, we should do (2). -Ekr From fluffy@cisco.com Mon Jun 18 14:37:12 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 0F53D11E80C1 for ; Mon, 18 Jun 2012 14:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.887 X-Spam-Level: X-Spam-Status: No, score=-105.887 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, 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 Ij06FgXAFy4K for ; Mon, 18 Jun 2012 14:37:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8474911E808F for ; Mon, 18 Jun 2012 14:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5949; q=dns/txt; s=iport; t=1340055430; x=1341265030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VCd2POXWofYRnt4LiqtMKkqo/wxjobjO4EJIn8RchZY=; b=DoPFxoFUC/mEOJPBOm67nIuVAFsWBcWtchGeF5pXEqqiky9cRSFHqidF I1fz754Tgk8e9XTZXXhjvW5U/5DpI4sSTqDCQT/TqWOlwt1Qey5t51j0I 7e5jfAPxweEnpZfZu6M9q0IlWB7G/ERwC3PmkRC1W5Jduusz14z3nXXXn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAHme30+tJV2c/2dsb2JhbABFDrIHg1yBB4IYAQEBAwESASc/BQsCAQgYHhAyJQIEDieHZAWYcJ9wizeFW2ADlSSOF4Fmgic5gV8 X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="93541260" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jun 2012 21:37:10 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5ILb9oE029473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jun 2012 21:37:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 18 Jun 2012 16:37:09 -0500 From: "Cullen Jennings (fluffy)" To: Roland Bless Thread-Topic: [P2PSIP] Review RELOAD Chord Spec chapter Thread-Index: AQHNTZqDFg9QG4BjD0+qpkffZUKn/g== Date: Mon, 18 Jun 2012 21:37:08 +0000 Message-ID: <4EADF78D-9D44-40A6-B61B-EF352C2CEE20@cisco.com> References: <4F886174.6080105@kit.edu> <4F88AC42.7000807@kit.edu> In-Reply-To: <4F88AC42.7000807@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18978.001 x-tm-as-result: No--53.790300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: P2PSIP WG Subject: Re: [P2PSIP] Review RELOAD Chord Spec chapter 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, 18 Jun 2012 21:37:12 -0000 switched to your suggested text in next version - thanks On Apr 13, 2012, at 4:44 PM, Roland Bless wrote: > Hi Cullen, >=20 > On 13.04.2012 22:49, Cullen Jennings wrote: >> There is one comment inline in the email that I'd really appreciate >> it if you could look at the change I made and see if it looks right >> to you. >=20 > See comments below and inline. >=20 >> The places N was being used for a specific peer, I moved the N to X >> to help clarify this. >=20 > looks ok. >=20 >>> p. 108: " o RELOAD uses a 128 bit hash instead of a 160 bit >>> hash, as RELOAD is not designed to be used in networks with close >>> to or more than 2^128 nodes (and it is hard to see how one would >>> assemble such a network)." >>>=20 >>> The reasoning here is a little bit odd since the address space size >>> is more related to how many objects one can store and the number of >>> objects can very much larger than the number of actually existing >>> nodes. >>=20 >> clarified. this is a bit complicated in Reload as the size the >> Node-ID does not need to the be the same size as Resource-ID. >=20 > Change is ok, but for section 10 they actually have the same size (as pro= bably for all structured KBR schemes). > "For this Chord based topology plugin, the size of the Resource-ID is > 128 bits." >=20 >>> sec. 9.1: >>>=20 >>> minor: It would be helpful to describe that neighbor table and >>> finger table only contain Node-IDs and that the mapping to locators >>> is done by using the Attach procedure via the overlay (such entries >>> will be kept in the Connection Table then?!). >> added >=20 > "The neighbor and finger tables have a logical Node-ID but the > actually mapping of a IP level addressing information to reach that > Node-ID is kept in the connection table." > I'm not a native speaker, but I'd rather propose: > "The neighbor and finger table entries contain logical Node-IDs as > values but the actual mapping of an IP level addressing information > to reach that Node-ID is kept in the connection table." >=20 >>> " Fundamentally, the chord data structure ": this is somewhat >>> confusing since it is not clear what you mean by "the chord data >>> structure", because it was not defined. In this context it seems to >>> mean the logical data structure across all nodes and not a >>> particular data structure inside a single node. This may confuse >>> readers since "the chord data structure" is nothing that actually >>> needs to be implemented. >>=20 >> fixed >=20 > ok. >=20 >>> May 9.1 is also the section where you could state that N=3D2^128? >> fixed >=20 > ok. >=20 >>> It should be clarified that this is only meant conceptually (one >>> shouldn't implement it that way). "The routing table is >>> conceptually the union of the neighbor table and the finger >>> table." >>=20 >> fixed >=20 > ok. >=20 >>> sec. 9.4: typo old: " success response. It MUST then sends a >>> Store request to its" new: " success response. It MUST then send >>> a Store request to its" >>>=20 >>=20 >> fixed >=20 > ok. >=20 >>> 9.5: (p.110) " 4. JP MUST enter all the peers it has contacted >>> into its routing table." presumably only successfully contacted >>> peers should be entered into the routing table, so maybe better: " >>> 4. JP MUST enter all the peers it has successfully contacted into >>> its routing table." >>=20 >> fixed >=20 > ok. >=20 >>> p.111: " 7. ... AP can now forget any data which is assigned to JP >>> and not AP." I think that this should be kept as long as AP is in >>> the replica set (cf. 9.7.3) >>=20 >> fixed >=20 > ok. >=20 >=20 >>> Major: "In order to set up its finger table entry for peer i, JP >>> simply sends an Attach to peer (n+2^(128-i)." should be changed >>> to: "In order to set up its finger table entry for peer at finger >>> index i (i.e., finger[i]), JP simply sends an Attach to peer >>> n+2^(127-i)." as finger[0] should point to node n+2^127, i.e. >>> halfway round the ring, otherwise n+2^128-0 would point to n >>> itself. >>=20 >> This is ( and related stuff in 9.7.4.2) is the change I really want >> you to check. >=20 > New formulation with i'th finger is much better (though still a bit > confusing since the finger[i] notation is mentioned in the overview and > also the original Chord paper), but the particular sentence is not > quite correct. > "In order to set up its i'th finger table entry for peer i, JP simply > sends an Attach to peer (n+2^(128-i)." > The i'th finger this is usually not for peer i and there is a > superfluous "(". > So better correct to: > "In order to set up its i'th finger table entry, JP simply > sends an Attach to peer n+2^(128-i)." >=20 >> Look at how I clarified this and check you think I got it right. The >> arrays start at 0 or 1 and been a point of confusion several times in >> the past on this and it does not matter as long as it is clear. Check >> with respect to section 9.7.4.2 too. >=20 > Yep. Clearer now. >=20 >>> sec. 9.7.1: p. 113, typo? old: " If the neighbor failure effects >>> the peer's range of responsible IDs," new: " If the neighbor >>> failure affects the peer's range of responsible IDs," >>=20 >> fixed >=20 > ok. >=20 >>> sec. 9.7.3: change throughout the section N to n >>=20 >> Look at how I clarified this too. >=20 > looks good. >=20 >>> Major: sec. 9.7.4.2: " entries in the finger table. A finger >>> table entry i is valid if it is in the range [ n+2^( 128-i ) , >>> n+2^( 128-(i-1) )-1 ]. Invalid" new: " entries in the finger >>> table. A finger table entry at index i (finger[i]) is valid if it >>> is in the range [ n+2^( 127-i ) , n+2^( 127-(i-1) )-1 ]. Invalid" >>>=20 >>> So finger[127] will be the successor. >>=20 >> check fix here too >=20 > That's ok now. >=20 > Regards, > Roland >=20 From fluffy@cisco.com Mon Jun 18 14:41:53 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 CB5F711E80CC for ; Mon, 18 Jun 2012 14:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 Bn+pQWpi8Pjp for ; Mon, 18 Jun 2012 14:41:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF111E808F for ; Mon, 18 Jun 2012 14:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=927; q=dns/txt; s=iport; t=1340055713; x=1341265313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AHM7NpAWCwRI8TLONbGwzZXlUX0q/Iw0x0heRBF529I=; b=J8s8SoVPEvdZuKBeHV96RZ4CiFN9kMXXAzhU5KwKz1kx2AXtOs2g8a+5 9rrJ7rzD5MUpfrx8OfbYoWPTGYyNmWJuGm0n4TJQk5R9hNteuBri1jPTf aEj9VK0eYBfchRz9EPaDPvoDciElX+v+D2/IVmjDcl3Sr06DPfuyWllRf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKuf30+tJV2c/2dsb2JhbABFtXGBB4IYAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dkBZh2n3CLN4VbYAOVJI4XgWaCYA X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="93542304" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jun 2012 21:41:52 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5ILfq9P000424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jun 2012 21:41:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Mon, 18 Jun 2012 16:41:52 -0500 From: "Cullen Jennings (fluffy)" To: Michael Chen Thread-Topic: [P2PSIP] Update of reload base draft Thread-Index: AQHNTZssdzg8k1/hsUaIJXGSUF3OJw== Date: Mon, 18 Jun 2012 21:41:52 +0000 Message-ID: <5F4E110A-1D64-4940-B32C-64C68FC715FC@cisco.com> References: <20120123220447.61e8c06078a3b23a733c71e914c0b9df.cbaffa24c6.wbe@email03.secureserver.net> In-Reply-To: <20120123220447.61e8c06078a3b23a733c71e914c0b9df.cbaffa24c6.wbe@email03.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18978.001 x-tm-as-result: No--36.226600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9656231CC25A284E9F188C8DE2422A17@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 18 Jun 2012 21:41:53 -0000 Do you feel theses have been resolved at this point? On Jan 23, 2012, at 10:04 PM, Michael Chen wrote: > Cullen, >=20 > Back in September and October of last year, I posted 6 questions and > suggested corrections to base-19, but all of them went on unanswered. I > also don't see them being addressed by base-20. These are their subject > lines: >=20 > [P2PSIP] Base draft section 6.4.3.2 Stat Response Definition > clarification, Michael Chen > [P2PSIP] Question about base draft section 9.7.4.2, Michael Chen > [P2PSIP] Base section 10.4 clarification, Michael Chen >=20 > [P2PSIP] Base draft 9.5 bullet 2 needs to be revised, Michael Chen > [P2PSIP] Question about base draft 9.7.4.4 Detecting partitioning, > Michael Chen > [P2PSIP] Base draft 9.7.4.1 title does not match its content, Michael > Chen >=20 > Would any of the key members revisit and reply them? >=20 > Thanks >=20 > --Michael From ekr@rtfm.com Mon Jun 18 15:36: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 3DA1811E80BB for ; Mon, 18 Jun 2012 15:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 gJcjv69gfphY for ; Mon, 18 Jun 2012 15:36:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 174B221F85A4 for ; Mon, 18 Jun 2012 15:36:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3415385vbb.31 for ; Mon, 18 Jun 2012 15:36:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=kF7PrBJ5JGiwBDL6CN72gbPZF9KfntkHN6qZdFcXtBA=; b=oD4sbB7j8x5AYGJSpW6QYTqIoX3PNlB2G5+QSxuH8WMPXIursIvcfJVWogL2TFjJ8G lxV8zW4j/ICD9ndPTkFrccNfD8K0H3FEF2KePh8F0eui0YrQhltQybupZzjo6HoVViio wCJLa3m1KRALa0Xc0zLz4NodYbruF9GJmb8kVlSY53mgn66FzIoZXd6WwKjPjAKWNqnP xiayd/OWeAVdrzUbjBd/93ukgCufGByqpnw+4xd2ESvgGY5pqR0wTuG+FUMb+9E5gqHx 8+aj/Ui+vveB7zEW1UurX60LV0taTvjd1NRraPsZdDvtHdAWuNqqNGz8XZEbIAhpCNck IggA== Received: by 10.52.36.33 with SMTP id n1mr5016685vdj.53.1340058987402; Mon, 18 Jun 2012 15:36:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 18 Jun 2012 15:35:47 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F60A655.20509@student.kit.edu> References: <4F5FB5F4.3090208@student.kit.edu> <4F5FD422.1050401@acm.org> <4F60737C.6010908@student.kit.edu> <4F6099D5.1080602@acm.org> <4F60A655.20509@student.kit.edu> From: Eric Rescorla Date: Mon, 18 Jun 2012 15:35:47 -0700 Message-ID: To: =?ISO-8859-1?Q?Andr=E9_Becker?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm9lmblCRvkS12uqopzl519gUzX4ouJpTISjEeXE3AzUiujJCvS+Wv6AfrBFwcyXr+Am9RJ 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: Mon, 18 Jun 2012 22:36:29 -0000 This does seem kind of unattractive, though I would observe that (a) it's not blind (b) you actually have to have valid RELOAD credentials to mount it. I'm not sure it's enough to check the sequence on each peer, since the attacker could just connect to a bunch of peers. Maybe if you checked the sequence, the rule could be that you sent an update to where you got it from since he is obviously wrong. Thoughts? -Ekr On Wed, Mar 14, 2012 at 7:08 AM, Andr=E9 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=E9 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=E9 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. =A0Whenever a node detects that another node has = old >>>>> =A0configuration 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 sequen= ce >>>>> number. =A0If 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 use= d >>>>> 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 checke= d >>>>> by EACH peer, including intermediate nodes. If only the last node >>>>> checked the configuration_sequence number, it would take significantl= y >>>>> 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 MUS= T >>>>> generate a ConfigUpdate message to update the last node that forwarde= d >>>>> 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 inclu= de >>> 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 attac= k: >>> >>> 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 v= ia >>> list). The ConfigUpdateReq, however, cannot be sent by reversing the vi= a >>> 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 targ= et >>> node. This means: >>> >>> If correctly timed, the adversary can cause a huge number of messages o= f >>> 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 onl= y >>> 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 signatur= e. > > I thought about that too, but I think that does not solve the problem. Th= is > would mean that, before a ConfigUpdateReq is generated, the receiving nod= e > had to validate the signature of the request. But: Can or should a node b= e > 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 latt= er > would cause more work, but I can't speak for other implementations. > > Regards, > =A0Andr=E9 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From roland.bless@kit.edu Tue Jun 19 03:56: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 650BC21F85A8 for ; Tue, 19 Jun 2012 03:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 CIOLdkxsdCzF for ; Tue, 19 Jun 2012 03:56:54 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id C0BE721F8559 for ; Tue, 19 Jun 2012 03:56:52 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Sgw73-0007oQ-BA; Tue, 19 Jun 2012 12:56:51 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1Sgw73-0000eq-74; Tue, 19 Jun 2012 12:56:45 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id D2869A8062E; Tue, 19 Jun 2012 12:56:44 +0200 (CEST) Message-ID: <4FE05AEC.2010206@kit.edu> Date: Tue, 19 Jun 2012 12:56:44 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <4F886174.6080105@kit.edu> <4F88AC42.7000807@kit.edu> <4EADF78D-9D44-40A6-B61B-EF352C2CEE20@cisco.com> In-Reply-To: <4EADF78D-9D44-40A6-B61B-EF352C2CEE20@cisco.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1340103411.570054000 Cc: P2PSIP WG Subject: Re: [P2PSIP] Review RELOAD Chord Spec chapter 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, 19 Jun 2012 10:56:55 -0000 Hi Cullen, On 18.06.2012 23:37, Cullen Jennings (fluffy) wrote: > switched to your suggested text in next version - thanks Ok, meanwhile I have some more comments, mostly clarification questions. Two major comments though: - The Connection Table is somewhat unclear. * Is it correct that it contains all nodes that are directly connected to a node, including those from the routing table? * Does it belong more to the topology plugin or to the forwarding & link management? * In case one has to route a message towards a destination, should the connection table be searched first (for an exact match), then the neighbor set and then the finger table? - It is unclear to me why (sec. 10.7.1, p.) the spec states: "peer MUST remove the entry from its neighbor table and replace it with the best match it has from the other peers in its routing table. If using reactive recovery, it then sends an immediate Update to all nodes in its Neighbor Table." so the peer replaces the failed entry with one of its fingers, which is maybe a poor choice, and sends this information to its neighbors. IMHO it makes much more sense to request routing information from the neighbors in order to get a better replacement for the lost peer, instead of "confusing" the neighbors with more inaccurate routing information. Then some more clarifications/nits: =3D=3D=3D=3D=3D Sec. 10.5 (p.110): "The join process for a joining party (JP) with Node-ID n" why joining _party_ if the terminology section mentions Joining Peer and AP is the Admitting Peer? =3D=3D=3D=3D=3D "1. JP MUST connect to its chosen bootstrap node." it is unclear what "connect" exactly means. This is actually described in Sec. 11.5: "When contacting a bootstrap node, the joining node MUST first form the DTLS or TLS connection to the bootstrap node and then sends an Attach request over this connection with the destination Node-ID set to the joining node's Node-ID." So my suggestion is to explain it a little but more or to put a forward reference to section 11.5. =3D=3D=3D=3D=3D "2. JP SHOULD send an Attach request to the admitting peer (AP) for Node-ID n. The "send_update" flag should be used to acquire the routing table for AP." Here, it is not clear how the JP finds the AP. This is explained in Section 12: "JP then sends an Attach through that peer to a resource ID of itself (JP). It gets routed to the admitting peer (AP) because JP is not yet part of the overlay." I suggest to change it to: "2. JP SHOULD send an Attach request to Node-ID n in order to contact the admitting peer (AP). The "send_update" flag should be used to acquire the routing table for AP, i.e., it gets an UpdateReq message after connecting (via TLS) to AP." Question: should it be "acquire the routing table of AP" or "acquire the routing table from AP"? =3D=3D=3D=3D=3D "3. JP SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table as well as to the desired finger table entries. Note that this does not populate their routing tables, but only their connection tables, so JP will not get messages that it is expected to route to other nodes." here it is unclear that the Attach requests are sent via the AP and what "desired" finger table entries means, e.g., in contrast to all? =3D=3D=3D=3D=3D Sec. 10.7.: " A peer MUST maintain an association (via Attach) to every member of its neighbor set. " why only to the neighbor set and not the whole routing table? =3D=3D=3D=3D=3D Sec. 10.7.1: " Every time a connection to a peer in the neighbor table is lost (as determined by connectivity pings or the failure of some request)," I think that "connectivity pings" means periodically sent Pings to all members of the Connection Table by the Link Management Layer as mentioned in sec. 6.5. A reference may help here. However, I couldn't find out how often such "connectivity pings" should be sent (the chord-ping-interval is only related to pinging finger table entries). =3D=3D=3D=3D=3D "If the neighbor failure effects the peer's range of responsible IDs, then the Update MUST be sent to all nodes in its Connection Table." Why Connection Table? I think this must be Neighbor Table! =3D=3D=3D=3D=3D Sec. 10.7.2.: "If a finger table entry is found to have failed," how is it determined to have "failed"? 10.7.1 is only related to neighbor failures...does the same definition apply here? =3D=3D=3D=3D=3D Sec. 10.7.3.: "When a peer discovers that its range of responsible IDs have changed, it MUST send an Update to all entries in its connection table." Why connection table? Why not neighbor or routing table? =3D=3D=3D=3D=3D Sec. 10.7.4.1.: "A peer MUST periodically send an Update request to every peer in its Connection Table." Why connection table? Why not neighbor table? =3D=3D=3D=3D=3D "A peer SHOULD randomly offset these Update requests so they do not occur all at once." This is a little bit too imprecise. How should this be done? A typical mechanism is using a randomly chosen offset from an interval [0.5*Tp,1.5*Tp] where Tp is the target period, cf. S. Floyd, V. Jacobson, =84The Synchronization of Periodic Routing Messages=93, IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994, http://portal.acm.org/citation.cfm?id=3D187045 =3D=3D=3D=3D=3D Sec: 10.7.4.2.: "A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element "chord-ping- interval", which defaults to 3600 seconds (one per hour)." This paragraph should probably moved some paragraphs down as it has been stated yet that a peer should actually send Ping requests at all (this is explained in the subsequent paragraphs). =3D=3D=3D=3D=3D Sec 12: - throughout the figures: "Update" should be "UpdateReq" and Attach should be AttachReq? =3D=3D=3D=3D=3D Neighor Table and Connection Table are written sometimes in lower case and sometimes in upper case style. I'm sure that the RFC editor will ask for consistency in writing... Regards, Roland From michaelc@idssoftware.com Tue Jun 19 07:17: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 0921821F8462 for ; Tue, 19 Jun 2012 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6sCTcu0GRvT for ; Tue, 19 Jun 2012 07:17:05 -0700 (PDT) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by ietfa.amsl.com (Postfix) with SMTP id 84E3A21F8460 for ; Tue, 19 Jun 2012 07:17:05 -0700 (PDT) Received: (qmail 16301 invoked from network); 19 Jun 2012 14:16:56 -0000 Received: from unknown (HELO p3plwbeout03-04.prod.phx3.secureserver.net) (72.167.218.216) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 19 Jun 2012 14:16:56 -0000 Received: from localhost ([72.167.218.245]) by p3plwbeout03-04.prod.phx3.secureserver.net with bizsmtp id QEGw1j0025JG3DC01EGwun; Tue, 19 Jun 2012 07:16:56 -0700 x-cmae-analysis: v=2.0 cv=btDO9Tmi c=1 sm=1 a=xXSidrheL/Sf2WtqiMNNiQ==:17 a=p0rljX0vrmMA:10 a=KB2BwbusDjUA:10 a=ZX_OrFjfoeAA:10 a=712Koz02r44A:10 a=IkcTkHD0fZMA:10 a=3oy0TPriAAAA:8 a=TZb1taSUAAAA:8 a=5IsXbjgYAAAA:8 a=48vgC7mUAAAA:8 a=q3CaFLEswoxIlt6qW-cA:9 a=QEXdDO2ut3YA:10 a=Dd_Pfn986HIA:10 a=lZB815dzVvQA:10 a=xXSidrheL/Sf2WtqiMNNiQ==:117 Received: (qmail 17866 invoked by uid 99); 19 Jun 2012 14:16:56 -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.19 Message-Id: <20120619071654.61e8c06078a3b23a733c71e914c0b9df.19483d33bb.wbe@email03.secureserver.net> From: "Michael Chen" To: "Eric Rescorla" , p2psip@ietf.org Date: Tue, 19 Jun 2012 07:16:54 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] Certificates in SecurityBlock 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, 19 Jun 2012 14:17:06 -0000 Hi Eric,=0A=0A> -------- Original Message --------=0A> Subject: [P2PSIP] Ce= rtificates in SecurityBlock=0A> From: Eric Rescorla =0A> Date= : Mon, June 18, 2012 12:54 pm=0A> To: p2psip@ietf.org=0A> =0A> =0A> In prin= ciple the SecurityBlock structure is designed to work with=0A> certificates= which are stored in the overlay and then retrieved=0A> at verification tim= e. In practice, however, the certificates are=0A> indexed into the security= block by Hash(cert) but stored in=0A> the overlay under subject, so you ca= n't retrieve them from=0A> the overlay.=0A> =0A> There seem to be two fixes= for this:=0A> (1) Modify(add to?) the certificate store usage to store cer= ts=0A> under the fingerprint so they can be retrieved.=0A> (2) Stop claimin= g that you can fetch the certs and just say that=0A> for this version you m= ust send the certs with the message.=0A> =0A> Is anyone interested in not s= ending all the certs with the message?=0A> If so, we should do (1). Otherwi= se, we should do (2).=0A =0AWe should do (2), since doing a cert fetch in t= he middle of a request=0Aprocessing adds complexity.=0A=0AIf future version= do (1), it will also be a good opportunity to add=0Athe single-hop optimiz= ation I proposed long ago, in which messages=0Ameant for directly connected= peers send an empty security block,=0Abecause everything is already being = done by TLS and DTLS.=0A=0AThanks=0A=0A--Michael=0A=0A From michaelc@idssoftware.com Tue Jun 19 07:35: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 69EEE21F8608 for ; Tue, 19 Jun 2012 07:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWU83L2nQBrS for ; Tue, 19 Jun 2012 07:35:27 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 4AF8721F85F7 for ; Tue, 19 Jun 2012 07:35:27 -0700 (PDT) Received: (qmail 23570 invoked from network); 19 Jun 2012 14:35:26 -0000 Received: from unknown (HELO p3plwbeout03-05.prod.phx3.secureserver.net) (72.167.218.217) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 19 Jun 2012 14:35:26 -0000 Received: from localhost ([72.167.218.245]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id QEbR1j0015JG3DC01EbRG4; Tue, 19 Jun 2012 07:35:25 -0700 x-cmae-analysis: v=2.0 cv=OMylLFmB c=1 sm=1 a=xXSidrheL/Sf2WtqiMNNiQ==:17 a=p0rljX0vrmMA:10 a=KB2BwbusDjUA:10 a=vgGKBIj0N-sA:10 a=712Koz02r44A:10 a=IkcTkHD0fZMA:10 a=3oy0TPriAAAA:8 a=TZb1taSUAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=p6QfRxR_hdDKMjAD3hIA:9 a=QEXdDO2ut3YA:10 a=X8Pu_JJacGEA:10 a=eUH0tZlfHQcA:10 a=9H2INRmCif8A:10 a=4nHr7OOBJt4A:10 a=AYokrTKsi_YA:10 a=SnVgptjxCBYA:10 a=2YTu50nXm0AA:10 a=JfD0Fch1gWkA:10 a=cq3inAW2T1YA:10 a=lZB815dzVvQA:10 a=xXSidrheL/Sf2WtqiMNNiQ==:117 Received: (qmail 3923 invoked by uid 99); 19 Jun 2012 14:35:25 -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.19 Message-Id: <20120619073524.61e8c06078a3b23a733c71e914c0b9df.7bd07af37a.wbe@email03.secureserver.net> From: "Michael Chen" To: "Cullen Jennings \(fluffy\)" Date: Tue, 19 Jun 2012 07:35:24 -0700 Mime-Version: 1.0 Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 19 Jun 2012 14:35:28 -0000 Cullen,=0A=0ANo, none of these were addressed in base-20. Here are the topi= cs again=0Awith hyper-links plus 1 more:=0A=0A Base draft section 6.4.3.2 = Stat Response Definition clarification=0A http://www.ietf.org/mail-archi= ve/web/p2psip/current/msg06088.html=0A Question about base draft section 9= .7.4.2=0A http://www.ietf.org/mail-archive/web/p2psip/current/msg06087.h= tml=0A Base section 10.4 clarification=0A http://www.ietf.org/mail-arch= ive/web/p2psip/current/msg06084.html=0A Base draft 9.5 bullet 2 needs to b= e revised=0A http://www.ietf.org/mail-archive/web/p2psip/current/msg0606= 5.html=0A Question about base draft 9.7.4.4 Detecting partitioning=0A h= ttp://www.ietf.org/mail-archive/web/p2psip/current/msg06064.html=0A Base d= raft 9.7.4.1 title does not match its content=0A http://www.ietf.org/mai= l-archive/web/p2psip/current/msg06062.html=0A=0A STUN keep-alive in AppAtt= ach(ed) connection=0A http://www.ietf.org/mail-archive/web/p2psip/curren= t/msg06176.html=0A=0AThe last one should be addressed in the sip usage draf= t.=0A=0AThanks=0A=0A--Michael=0A=0A> -------- Original Message --------=0A>= Subject: Re: [P2PSIP] Update of reload base draft=0A> From: "Cullen Jennin= gs (fluffy)" =0A> Date: Mon, June 18, 2012 2:41 pm=0A> To= : Michael Chen =0A> Cc: P2PSIP Mailing List =0A> =0A> =0A> Do you feel theses have been resolved at this po= int?=0A> =0A> On Jan 23, 2012, at 10:04 PM, Michael Chen wrote:=0A> =0A> > = Cullen,=0A> > =0A> > Back in September and October of last year, I posted 6= questions and=0A> > suggested corrections to base-19, but all of them went= on unanswered. I=0A> > also don't see them being addressed by base-20. The= se are their subject=0A> > lines:=0A> > =0A> > [P2PSIP] Base draft section = 6.4.3.2 Stat Response Definition=0A> > clarification, Michael Chen=0A> > [P= 2PSIP] Question about base draft section 9.7.4.2, Michael Chen=0A> > [P2PSI= P] Base section 10.4 clarification, Michael Chen=0A> > =0A> > [P2PSIP] Base= draft 9.5 bullet 2 needs to be revised, Michael Chen=0A> > [P2PSIP] Questi= on about base draft 9.7.4.4 Detecting partitioning,=0A> > Michael Chen=0A> = > [P2PSIP] Base draft 9.7.4.1 title does not match its content, Michael=0A>= > Chen=0A> > =0A> > Would any of the key members revisit and reply them?= =0A> > =0A> > Thanks=0A> > =0A> > --Michael=0A From cjbc@it.uc3m.es Thu Jun 21 06:06: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 032F221F8534 for ; Thu, 21 Jun 2012 06:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 JOjrDiYS3Unz for ; Thu, 21 Jun 2012 06:06:52 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id A7FFA21F8522 for ; Thu, 21 Jun 2012 06:06:52 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id AEEBA76C077; Thu, 21 Jun 2012 15:06:49 +0200 (CEST) Message-ID: <1340284009.11077.148.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Thu, 21 Jun 2012 15:06:49 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rbq/LStpxTkxn8rvXHeJ" X-Mailer: Evolution 3.2.2-1+b1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18986.005 X-TM-AS-Result: No--4.665-7.0-31-1 X-imss-scan-details: No--4.665-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] WG Call for adoption: draft-peng-p2psip-snmp-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 21 Jun 2012 13:06:54 -0000 --=-rbq/LStpxTkxn8rvXHeJ Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, In Paris, there was a hum asking the group for consensus to move towards adopting the RELOAD SNMP draft as a working group item. This email starts a 2-week consensus call on adopting Title : An SNMP Usage for RELOAD Author(s) : YongLin Peng Wei Wang ZhenWu Hao Yu Meng Filename : draft-peng-p2psip-snmp-04.txt Pages : 24 Date : 2012-03-06 =20 as a P2PSIP WG document. Please, read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 5th July 2012. Brian & Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Video over Mobile Networks http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-rbq/LStpxTkxn8rvXHeJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk/jHGkACgkQNdy6TdFwT2dWNQCg3qLw/688PJ8hb79Lwk+YT1Y3 gAsAn2xsQRprpiwV11JXByCmmrGsfoJ2 =3+In -----END PGP SIGNATURE----- --=-rbq/LStpxTkxn8rvXHeJ-- From petithug@acm.org Thu Jun 28 09: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 AC4DC21F854D for ; Thu, 28 Jun 2012 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 xhy3-4Gh3WsZ for ; Thu, 28 Jun 2012 09: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 7E7A221F85A4 for ; Thu, 28 Jun 2012 09: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 "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6D00A204C6; Thu, 28 Jun 2012 16:15:02 +0000 (UTC) Message-ID: <4FEC8304.5050800@acm.org> Date: Thu, 28 Jun 2012 09:15:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: fangh01 References: <1f2afd1f.9a81.137e4e6f27d.Coremail.fangh01@163.com> <4FDCA848.9000509@acm.org> In-Reply-To: <4FDCA848.9000509@acm.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org, p2psip@ietf.org Subject: Re: [P2PSIP] [reload-implementers] Is there any protype or simple implementation about the RELOAD? 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, 28 Jun 2012 16:15:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/16/2012 08:37 AM, Marc Petit-Huguenin wrote: > On 06/13/2012 01:12 AM, fangh01 wrote: >> Hello, I'm interested in the RELOAD protocol, and I plan to implement a >> live streaming system based on p2psip which use the RELOAD protocol. >> However, after search the internet, I couldn't find any RELOAD related >> implementation to reference, is there any protype or simple >> implementation on RELOAD protocol offered on the internet? > > Look in the archives for the "Implementation listing" thread: > > http://implementers.org/archives/reload/2011-October/date.html > >> Another question is that can anyone show the standard RELOAD packets >> with the ".pcap" format? > > I uploaded a pcap file and its associated RSA key here: > > http://ietf.implementers.org/reload/storage.pcap.gz > http://ietf.implementers.org/reload/bootstrap.p12 > > You need to install the p12 in Wireshark first (password: password). Note > that for some reason Wireshark 1.6.8 does not decrypt the packets. It > works fine with Wireshark 1.7 (I always use the HEAD of the git tree, so > YMMV). I just verified that the new stable release of Wireshark (1.8.0) decrypts correctly the RELOAD packets. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP7IMCAAoJECnERZXWan7EirAQANflE+hfXolCAXKdGUWZ82U/ qKPCpxiS1rKYNYvDJZwNcjsMMp5//8kFDfoezN6Wfy29ItJvuurDE2t0ogJTKrPT uVka7tesAo91a7kELaK2KdA+yd9FPeFOZ1SA9JQ9GFC7wPiS5OkZcqXESepZ50hO gZyjACe0ODLZKfGTPO1tv2fs2W3r2SX+K/ocfJMrUbWy/g0YnnAlZ0k+JAdU6tcn ZFQawBLweKYCGvvXHQ03Xmdsm4LQ4bPspZVItjmi3CdNviHsFoM4aCqE1lviZWBU +LE6HunB0VfBsIP8PT4/YOUvrEp1LTD1MLKO7scQYf9ApI9q+e9/NXOV3tQZvOvN xodgWGpiVkfq5ju0nl1Z0taD6GEL2t/U5DJUGQtROLcHL1G+HASFSM/n+uMBeQMv mcnBIXSEjJDk8fJcj89vygOrUBU0CskOu/Opoc6g1cWoK/Z0wODxtS9q00nK01ui c1s34nG/ucUvbxz5I5hsNcGMEAiaqjGi5qyFoOY6GyNtMWmmRAocFIFYGhSaA73M RS8uwqaeLpipbPlX4fO+YH2V312ILFoEu/2ootTinupnl+Km7gGDLDsKvC9iZ8PT tKmdQYZ8742+xmHQf/mWUAQrTIM9LZEU6wBVG/lnNhosBf2Tp2QkYJuPP922CAN2 p4/NxR5Kn2PGWYcC3T2c =eg5/ -----END PGP SIGNATURE----- From fluffy@iii.ca Fri Jun 29 09:49: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 72B8821F87EC for ; Fri, 29 Jun 2012 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaG9YGAaPGW7 for ; Fri, 29 Jun 2012 09:49:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45721F87F7 for ; Fri, 29 Jun 2012 09:49:53 -0700 (PDT) Received: from sjc-vpn5-823.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AF75A22E253; Fri, 29 Jun 2012 12:49:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <1340284009.11077.148.camel@acorde.it.uc3m.es> Date: Fri, 29 Jun 2012 09:48:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FDBFF95-4CB2-45FB-B2D6-DE21D3BE4BEF@iii.ca> References: <1340284009.11077.148.camel@acorde.it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.1278) Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WG Call for adoption: draft-peng-p2psip-snmp-04 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, 29 Jun 2012 16:49:55 -0000 I've read this and it seems like it is ready for WG adoption. We don't = plan to implement so I don't have a strong feeling one way or the other = if the WG should adopt it but I certainly have no objections to it being = adopted.=20 Cullen =20 On Jun 21, 2012, at 6:06 , Carlos Jes=FAs Bernardos Cano wrote: > Hi, >=20 > In Paris, there was a hum asking the group for consensus to move = towards > adopting the RELOAD SNMP draft as a working group item. >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : An SNMP Usage for RELOAD > Author(s) : YongLin Peng > Wei Wang > ZhenWu Hao > Yu Meng > Filename : draft-peng-p2psip-snmp-04.txt > Pages : 24 > Date : 2012-03-06 >=20 > as a P2PSIP WG document. Please, read the current revision and state = you > opinion either for or against adoption (and with reasoning why) in the > mailing list. The call for adoption ends 5th July 2012. >=20 > Brian & Carlos >=20 > --=20 > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > IEEE Network Special Issue on > Video over Mobile Networks > http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip