gmane.ietf.p2psip

UNSAF considerations and draft-ietf-p2psip-drr

Gonzalo Camarillo — 2013-06-17T12:02:12

Folks,

Appendix A of the following draft describes how a node can obtain IP
addresses on which it may be reached:

http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A

Have you taken into account the UNSAF considerations?

http://tools.ietf.org/html/rfc3424

Cheers,

Gonzalo

References to concepts draft in draft-ietf-p2psip-rpr anddraft-ietf-p2psip-drr

Gonzalo Camarillo — 2013-06-17T11:46:39

Hi,

both of these drafts (in the publication requested state) have
informative references to the concepts draft:

http://www.ietf.org/id/draft-ietf-p2psip-rpr-07.txt
http://www.ietf.org/id/draft-ietf-p2psip-drr-07.txt

Given that both draft state that they use the terminology defined in the
concepts draft "extensively", shouldn't those references be normative?
That is, downrefs.

Also, what is the status of the concepts draft?

http://tools.ietf.org/html/draft-ietf-p2psip-concepts-04

Thanks,

Gonzalo

Re: Certificates with multiple NodeIds

Marc Petit-Huguenin — 2013-06-16T15:29:01

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

Hi Polina,

On 06/15/2013 12:35 PM, Polina Goltsman wrote:

This is not a requirement for the management of the Connection Table, just a
compression algorithm to reference an entry in the Connection Table in the
destination_list.


Yes, but because the entity decoding the 16 bit opaque_id is the same that
encode it, it does not matter.  There is no interoperability problem that can
be created by following or not the SHOULD.  IMO, as this cannot create any
interoperability issue, the whole paragraph should have been moved to an
appendix, as this is more an implementation note, than normative stuff.


My understanding of this is that an Attach is required to do that, so the
special processing really applied only to bootstrap nodes.  You can Attach to
any node and never send an Update, relying on a stored Destination_list to be
reached and the via_list to receive responses, but the initial still have to
go through a bootstrap node.


My
understanding is that you cannot directly connect to a random node.  You
always have to do through a bootstrap node.

Note that this understanding seems to contradict 11.4.  IMO the whole 11.4
should have been removed, as there is no way to be sure 100% that an IP
address can be directly reached.  Caching peers to serve as future bootstrap
nodes would require to use a TURN server to contact them.  And as you said, it
increase the load on all node as they all can be bootstrap candidates.


Yes, the whole shared-secret/TLS-PSK/TLS-SRP/self-signed-certificate is
underspecified.  A good candidate for an Internet-Draft.


None that I can think of.  Again a good candidate for an Internet-Draft.


- -- 
Marc Petit-Huguenin
Email: marc-SHzPq5HBsP0vtAZ8OuFxWR2eb7JE58TQ< at >public.gmane.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)

iQIcBAEBCAAGBQJRvdm4AAoJECnERZXWan7E2t0P/3oMLqD3lWw6f4gLMN/vf2hI
qSTzKHnumRofBEgaYSeo7cqIH2RXEmDpI5b0wXnCPYsorLJp73nZD8esEAq2csom
kd0xkXYUVDV7V/xNVB82ZhWhD0PJylJhunnLUcwmOhmaDzP2IqXkunfz+y0dvCBT
zEGN53TfOF5sjJ/GdtMKZWoYpyfIEZ6aVDMVyuCmGvvn8Yaz15RjNFnpd8zgqC0P
xdP8KVSYUE5FZuPe5nTKnRIT12wjMbauuVw+awuSsBr9bfkwaLHvqGxDv/2TR2YI
2yunV253hmIzdeqQziHsvcoShYjKN0VQ3An2X69BIi3aF7w7DpkvSdEoYVrnP+G1
Dmy/9srdbhDagPAgJ4cTOgNde2jjODMTyL/VlnX+GGH8Ui48DHPK55My5XS7l3wf
H/1iO79JSB2XBDbicoXWUl51rdNqPX4v/cbl/A1bofAtUVXVLBSLSgnESBdpuSkI
myjGuf2gyFUnBuURlfHy7Ni1ELecscbKZSJz2yfDpwKyJEKHkmsnLBxJmZG4/Alx
PLRGUybgGoHguhxMQH886FOsGKQW5CivYKEjvOJEifm+yUuykfArJGc5pbfBBEFh
RL0L6huqUkhdvLLzXcYc7bmKyyEkucS0fkpbPcw6WVkrJHtY6b3xvH7jYG2JldTM
y1XU3AkmhfTNVQajv1wy
=lF1v
-----END PGP SIGNATURE-----

Re: Certificates with multiple NodeIds

Polina Goltsman — 2013-06-15T19:35:21

Dear Marc,

Thank you very much for your comments.

On 14.06.2013 18:38, Marc Petit-Huguenin wrote:
A have found this requirement in section 6.3.2.2. at the bottom of page 
53 (-26)

 >One possible encoding of the 16 bit integer version as an opaque
 >identifier is to encode an index into a Connection Table.
and so on.

I am not very good at this, but as I understood one must have very good 
reasons not to
implement "SHOULD".
 From -base: Section 3.2.1 Client Routing

    **Clients** may insert themselves in the overlay in two ways:

...

    (bullet 2)Establish a connection with an arbitrary peer in the overlay

...

    A **client** connected this way using a certificate with only
    a single Node-ID can proceed to use the connection without
    performing an Attach (Section 6.5.1  ).  A **client** wishing to connect
    using this mechanism with a certificate with multiple Node-IDs can
    use a Ping (Section 6.5.3 ) to probe the Node-ID of the node to
    which it is connected before doing the Attach.

Do I understand this wrong, or any client can connect to any peer it 
wants, so the issue
is not only with BP.

Moreover, did I miss a requirement that forbids me to for direct 
connection (without Attach) if
I know IP-Address of the Node I wish to connect to.
(This didn't make it to the -base, did it 
?https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html) 
<https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html%29**>
Exactly this. I mean endpoint as in the "endpoint of connection or link"

The point is that IMHO it(together with 3.2.1) should be specified somewhere
after section 5.
Thank you very much for the explanation. Do you think it should be 
specified, that this key
SHOULD be omitted?
1) This would increase load on the Bootstrap Peer, which IMHO is not 
desirable.
2) From your message:
*
*>Because there is no Attach, the peer has to spy on the first message 
sent by the

    client to extract the Node-ID from the SignerIdentity and "label"
    the newly
    created connection in the connection table.

Well, it was not that obvious to me. Was there a reason why it didn't 
make it to the -base?

I believe it is relatively hard to spy on the messages, that are routed 
through, since
they can be fragmented. So IMHO the first message should be destined to 
the connection
endpoint.
Thanks.
  Polina

Re: Certificates with multiple NodeIds

Marc Petit-Huguenin — 2013-06-14T16:38:11

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

Hi Polina,

Please find below my answers to some of your comments.  Note that I am not a
co-author of the spec, so that will be just my opinion.

On 04/22/2013 11:30 AM, Polina Goltsman wrote:

I am not sure where in the spec you found this requirement.


I agree that there is a layer violation here.

But this applies only to bootstrap nodes, which anyway require special
processing on their public address, as they accept connections without Attach.
So the special code that parses the message in addition to the header can be
isolated to that special kind of nodes.


Not sure what you mean by next endpoint.  The Ping will be answered by this
peer, returning a SecureBlock containing the Certificate of this peer.


My understanding is that the Attach creates a new connection and that the first
one is closed.  But this is underspecified so this will create an
interoperability problem.


I think it is clearly stated in 1.3 that certificate must be used with TLS-PSK
in the context of RELOAD:

"This feature is used together with certificate-based
 access control, not as a replacement for it."


The identity field is used to select a specific key, when there is a choice
between different keys.  In the case of RELOAD I suppose that having multiple
keys does not make sense so that field (and so the ServerKeyEchange record)
should be omitted.


AFAIK, this is how things are suppose to work in RELOAD.  Note that the
increased load is only when joining the overlay, so that seems like normal
workload to me.

https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html


Yes, I proposed something like this back in 2011:

https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html

That was not the solution selected by the authors.


I would suggest to write an I-D about this.

Thanks.

- -- 
Marc Petit-Huguenin
Email: marc-SHzPq5HBsP0vtAZ8OuFxWR2eb7JE58TQ< at >public.gmane.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)

iQIcBAEBCAAGBQJRu0bxAAoJECnERZXWan7ECRcP/jw5CphA7aO4vizign7o7Kdp
B9xNUuiDB1sV8Vxv/HftIRJmzbXecJLTOj8BuVwZnsTNeZqz7IGJCgRqkaH4Q2sF
HIsHls2OI49T7iIYUu7FNcY1h9PsMO/gtOd2195K4NY16GqluOMisCtwlcopTsBY
/fhNokoQ6SjSMtt02NjxZAxqFyrggZc9f02ig+TXEOHRKG1vxNA/7g6q/h3+mR7j
RNCw2J1kJSZu9fqWIcLWWUSV8GJQevSVHzja88jCxFMd7FrmvkCJ1HJGC7i+/8Q6
hxyNl/I4v8kBdN/Pn0wK2hBbSPPNIyYvLKGa76nwIeMmSkjmJbbfH4cWLQy2qDqf
OsJIibUyMurOyLf8zWpcorj4z4Y3E/pdXVrzlQ78zCxZ8hxh2Nem9q/xcaAeE9yh
HETN084rkEC0F/9Ro6T/TT2ZCXR8Xc+PYTPAk76dAS2wdQxwQ6wMXbLTIwtOH+Vf
BcbvMXI1qIwJ/Y4l5u7zZ/ype4lcjwZXXr+1iu2k9h2uAOg/REfL7dKRuEmSdOb7
yVEx6ZuxXDacgBn8uZVyrJvvUdgu8+/sMjAAcajXmW1lyA0ekIViTJPnRsWD7Ax4
FLQbFzxAdJ6cPUF3EUQ52JosqMM9hAQBXOSfVzXLLAA+XpqVlpMxvktALl8F3zvW
HwUMrudMecpks9f80p0q
=pzTn
-----END PGP SIGNATURE-----

Request to to progress I-D: draft-ietf-p2psip-rpr-07

Carlos Jesús Bernardos Cano — 2013-06-10T10:04:34

Dear Secretariat,

The P2PSIP WG has completed working group last call on the I-D:
draft-ietf-p2psip-rpr-07. The I-D is ready for IESG review and
publication. Please find attached the proto writeup for this P2PSIP WG
document.

Thanks,

Carlos

An extension to RELOAD to support Relay Peer Routing (draft-ietf-p2psip-rpr-07)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document has received significant community review, and appears to enjoy enough community interest to be considered valuable. It defines extensions to draft-ietf-p2psip-base, which also has an intended status of Proposed Standard.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

RELOAD recommends symmetric recursive routing for routing messages. An optional extesion that can be used to provide shorter routes for responses (reducing the overhead on intermediate nodes) consists in supporting a relay peer routing mode. This defines the required extension as well as describes potential use cases where it can be used.

Working Group Summary:

The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J. Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Gonzalo Camarillo

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd has personally done a thorough review of the document. Some changes (mainly editorial) were requested to the authors and included in the last revision of the draft. The Document Shepherd believes the document is ready for forwarding to IESG for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of these reviews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd has no such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There has been an IPR claim in full conformance with the provisions of BCP 78 and BCP 79. The Working Group was informed of this IPR claim befor version -02 of the draft was published. No WG discussion has happened.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits. The automatic nits detection tool detects 2 instances of lines with non-RFC5735-compliant IPv4 addresses, but I could
not find them, so I guess it is a detection mistake.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document meets the review criteria.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes, there is one (which is actually a downward normative reference) to draft-ietf-p2psip-concepts-04. This document has not been updated since October 2011. The plan is to contact authors to ensure the document is finalized or nominate a new editor to complete the work.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes. There is a normative reference to draft-ietf-p2psip-concepts-04, which intended status is Informational.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No formal language segments exist.
_______________________________________________
P2PSIP mailing list
P2PSIP-EgrivxUAwEY< at >public.gmane.org
https://www.ietf.org/mailman/listinfo/p2psip

Request to to progress I-D: draft-ietf-p2psip-drr-07

Carlos Jesús Bernardos Cano — 2013-06-10T10:03:11

Dear Secretariat,

The P2PSIP WG has completed working group last call on the I-D:
draft-ietf-p2psip-drr-07. The I-D is ready for IESG review and
publication. Please find attached the proto writeup for this P2PSIP WG
document.

Thanks,

Carlos
An extension to RELOAD to support Direct Response Routing (draft-ietf-p2psip-drr-07)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

Is this type of RFC indicated in the title page header?

Yes

Technical Summary:

RELOAD recommends symmetric recursive routing for routing messages. An optional extesion that can be used to provide shorter routes for responses (reducing the overhead on intermediate nodes) consists in supporting a direct response routing mode. This defines the required extension as well as describes potential use cases where it can be used.

Working Group Summary:

The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J. Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Gonzalo Camarillo

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of these reviews.

No.

The Document Shepherd has no such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

There is WG consensus behind this document.

No.

There are no nits. The automatic nits detection tool detects 2 instances of lines with non-RFC5735-compliant IPv4 addresses, but I could
not find them, so I guess it is a detection mistake.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document meets the review criteria.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

The document defines a new RELOAD Forwarding Option type. The IANA registry is defined in [I-D.ietf-p2psip-base], Forwarding Option Registry.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No formal language segments exist.
_______________________________________________
P2PSIP mailing list
P2PSIP-EgrivxUAwEY< at >public.gmane.org
https://www.ietf.org/mailman/listinfo/p2psip

Re: WGLC for draft-ietf-p2psip-sip-09

Michael Chen — 2013-06-09T15:36:38

Hi,
 
Has the issue of keep-alive been addressed?
 
  http://www.ietf.org/mail-archive/web/p2psip/current/msg06176.html
 
Thanks
 
--Michael
--------- Original Message --------- Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-09
From: "Marc Petit-Huguenin" <petithug-HInyCGIudOg< at >public.gmane.org>
Date: 5/20/13 8:19 am
To: cjbc-lKqjX1hQmNLe5aOfsHch1g< at >public.gmane.org
Cc: p2psip-chairs-nZLwadvX8BDR74oF6e/6QQ< at >public.gmane.org, p2psip-EgrivxUAwEY< at >public.gmane.org

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA256
 
 Sorry for the delay in responding to this.
 
 I read again the I-D, and I think that this document is ready to be submitted
 to the IESG.
 
 On 05/04/2013 10:33 AM, Carlos Jes&uacute;s Bernardos Cano wrote:
 > Hi,
 > 
 > Hereby we are issuing a WGLC for draft-ietf-p2psip-sip-09.
 > 
 > The WGLC will be open till the 20th of May. We kindly ask the WG to review
 > the document and provide comments.
 > 
 > If you have no comments and think the document is ready to be submitted to
 > IESG, please do send a note stating that to the WG ML.
 > 
 > Additional information about the document is below:
 > 
 > Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings 
 > Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas
 > C. Schmidt Filename : draft-ietf-p2psip-sip-09.txt Pages :
 > 19 Date : 2013-02-25
 > 
 > Abstract: This document defines a SIP Usage for REsource LOcation And
 > Discovery (RELOAD). The SIP Usage provides the functionality of a SIP
 > proxy or registrar in a fully-distributed system and includes a lookup
 > service for Address of Records (AORs) stored in the overlay. It also
 > defines Globally Routable User Agent Uris (GRUUs) that allow the 
 > registrations to map an AOR to a specific node reachable through the 
 > overlay. After such initial contact of a peer, the AppAttach method is
 > used to establish a direct connection between nodes through which SIP
 > messages are exchanged.
 > 
 > The IETF datatracker status page for this draft is: 
 > https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip
 > 
 > There's also a htmlized version available at: 
 > http://tools.ietf.org/html/draft-ietf-p2psip-sip-09
 > 
 
 - -- 
 Marc Petit-Huguenin
 Email: marc-SHzPq5HBsP0vtAZ8OuFxWR2eb7JE58TQ< at >public.gmane.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)
 
 iQIcBAEBCAAGBQJRmj8bAAoJECnERZXWan7EcJAQAMsY49O8XhTJOLcpbXmIeb0r
 g2qdOCq+c8/baC1sVG4QqEpoKwM6ELCgem6STh7kEJPMWos0VQGTtoERseN1wUZ0
 GA2WuyF0NjQrONcm3dnvzjJm39rcCfcjl/S8oU7rLBI3dfFInyQHJ+cv/O8aml/6
 0tDeNOACM6fQEsLKXITb2mCPFb+ybeNGWWq5QBA7t4SBhytkxkG/NVmlBQnDPryi
 1X/D/o/xOuvh+6JZNnxTQmNQLe6TwiFF6+FqliFcHAhRhYNB4qU3t+LkgMhZplJt
 85JKI+3/b4hN20JftQiyxD21Q8xEQte3i5X5tpnDLc9eUmwEbDJdmxJ0bQdFfCAb
 ZGYhWWsKpIlL1NoRRICcyG6e+ZmsR/fyzJMzGoEMhsw6fXUZheJTHhxVQrVCkEKr
 THCrdtKvqm/+1Y9CeEwk0k5UEfuVRTREo4b1Hk6GjIn/vyCOyt9R57LMn/9nGk2a
 dUyI68AfhmNbIFrSvQTvBKgim+DJ4OnJTDJBYGdHBupVFLuYxUuL8FLwO57YHJEe
 x3zFRxX1wrpkZB2I5wPgHVAvavYSJcYLBMNAqTDfn5DRzgZnS+cpwj1rYPYgNIFR
 WcCFdTruSOC36TLjNNDlNF7ClUjqOsZZIKQJAMAw6IEJ4FpXEahhLaOStzsSvx7K
 hPnzI9mLq9y1VRmZGABA
 =sdAy
 -----END PGP SIGNATURE-----
 _______________________________________________
 P2PSIP mailing list
 P2PSIP-EgrivxUAwEY< at >public.gmane.org
 https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP-EgrivxUAwEY< at >public.gmane.org
https://www.ietf.org/mailman/listinfo/p2psip

Re: Review of revised DRR and RPR documents

Carlos Jesús Bernardos Cano — 2013-06-09T08:53:19

Hi Ning,

Thanks for the updates.

Carlos

On Sun, 2013-06-09 at 07:10 +0000, Zongning wrote:


_______________________________________________
P2PSIP mailing list
P2PSIP< at >ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

Re: Review of revised DRR and RPR documents

Zongning — 2013-06-09T07:10:39

Hi, Carlos,

I have posted new revision of DRR and RPR drafts to solve the nits.
Thanks.

-Ning


_______________________________________________
P2PSIP mailing list
P2PSIP< at >ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

I-D Action: draft-ietf-p2psip-drr-07.txt

2013-06-09T07:07:42

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

Title           : An extension to RELOAD to support Direct Response Routing
Author(s)       : Ning Zong
                          Xingfeng Jiang
                          Roni Even
                          Yunfei Zhang
Filename        : draft-ietf-p2psip-drr-07.txt
Pages           : 16
Date            : 2013-06-09

Abstract:
   This document proposes an optional extension to RELOAD to support
   direct response routing mode.  RELOAD recommends symmetric recursive
   routing for routing messages.  The new optional extension provides a
   shorter route for responses reducing the overhead on intermediate
   peers and describes the potential cases where this extension can be
   used.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-drr-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-drr-07


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

Re: Review of revised DRR and RPR documents

Carlos Jesús Bernardos Cano — 2013-06-03T18:50:23

Hi,

One last comment. I've realized while writing the Document Shepherd
Write-Up, that current versions of the drafts have some nits (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Please, check and correct them:

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-drr-06.txt

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-rpr-06.txt

As soon as a new version is posted and I get all the authors' feedback
regarding full conformance with the provisions of BCP 78 and BCP 79 on
IPR disclosures, I'll request the IESG the review and approval for
publication of both documents.

Thanks,

Carlos

On Sat, 2013-05-04 at 19:23 +0200, Carlos Jesús Bernardos Cano wrote:


_______________________________________________
P2PSIP mailing list
P2PSIP< at >ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

Re: WGLC for draft-ietf-p2psip-sip-09

Marc Petit-Huguenin — 2013-05-20T15:19:57

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

Sorry for the delay in responding to this.

I read again the I-D, and I think that this document is ready to be submitted
to the IESG.

On 05/04/2013 10:33 AM, Carlos Jesús Bernardos Cano wrote:

- -- 
Marc Petit-Huguenin
Email: marc< at >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)

iQIcBAEBCAAGBQJRmj8bAAoJECnERZXWan7EcJAQAMsY49O8XhTJOLcpbXmIeb0r
g2qdOCq+c8/baC1sVG4QqEpoKwM6ELCgem6STh7kEJPMWos0VQGTtoERseN1wUZ0
GA2WuyF0NjQrONcm3dnvzjJm39rcCfcjl/S8oU7rLBI3dfFInyQHJ+cv/O8aml/6
0tDeNOACM6fQEsLKXITb2mCPFb+ybeNGWWq5QBA7t4SBhytkxkG/NVmlBQnDPryi
1X/D/o/xOuvh+6JZNnxTQmNQLe6TwiFF6+FqliFcHAhRhYNB4qU3t+LkgMhZplJt
85JKI+3/b4hN20JftQiyxD21Q8xEQte3i5X5tpnDLc9eUmwEbDJdmxJ0bQdFfCAb
ZGYhWWsKpIlL1NoRRICcyG6e+ZmsR/fyzJMzGoEMhsw6fXUZheJTHhxVQrVCkEKr
THCrdtKvqm/+1Y9CeEwk0k5UEfuVRTREo4b1Hk6GjIn/vyCOyt9R57LMn/9nGk2a
dUyI68AfhmNbIFrSvQTvBKgim+DJ4OnJTDJBYGdHBupVFLuYxUuL8FLwO57YHJEe
x3zFRxX1wrpkZB2I5wPgHVAvavYSJcYLBMNAqTDfn5DRzgZnS+cpwj1rYPYgNIFR
WcCFdTruSOC36TLjNNDlNF7ClUjqOsZZIKQJAMAw6IEJ4FpXEahhLaOStzsSvx7K
hPnzI9mLq9y1VRmZGABA
=sdAy
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
P2PSIP< at >ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

Implementation of -base::chapter 7 Data Storage Protocol

Polina Goltsman — 2013-05-20T07:24:04

Hi,

We have recently implemented chapter 7 and we have another list of 
questions.

The questions are sorted by the protocol message, being sent.

For the convenience, we also included the questions about chapter 7, 
that we have sent in our LastCall comments. These issues are marked with 
a star: '[issue ###]*'.

1. Store
======================================================================

Before describing the issues, we will cite the checklist from section 
7.4.1.1. It is the same list in exactly the same order, except that it 
is numbered. The 2 additional items - * and ** appear in section 
7.4.1.1. after describing StoreReq structure (it is last paragraph on 
page 101).

[*]  If the replica number is zero, then the peer MUST check that it is 
responsible for the resource and, if not, reject the request.
[**] If the replica number is nonzero, then the peer MUST check that it 
expects to be a replica for the resource and that the request sender is 
consistent with being the responsible node (i.e., that the receiving 
peer does not know of a better node) and, if not, reject the request.

1.  The Kind-ID is known and supported.
2.  The signatures over each individual data element (if any) are valid. 
If this check fails, the request MUST be rejected with an 
Error_Forbidden error.
3.  Each element is signed by a credential which is authorized to write 
this Kind at this Resource-ID. If this check fails, the request MUST be 
rejected with an Error_Forbidden error.
4.  For original (non-replica) stores, the StoreReq is signed by a 
credential which is authorized to write this Kind at this Resource-ID. 
If this check fails, the request MUST be rejected with an 
Error_Forbidden error.
5.  For replica stores, the StoreReq is signed by a Node-ID which is a 
plausible node to either have originally stored the value or in the 
replica set. What this means is overlay specific, but in the case of the 
Chord based DHT defined in this specification, replica StoreReqs MUST 
come from nodes which are either in the known replica set for a given 
resource or which are closer than some node in the replica set. If this 
check fails, the request MUST be rejected with an Error_Forbidden error.
6.  For original (non-replica) stores, the peer MUST check that if the 
generation counter is non-zero, it equals the current value of the 
generation counter for this Kind. This feature allows the generation 
counter to be used in a way similar to the HTTP Etag feature.
7.  For replica Stores, the peer MUST set the generation counter to 
match the generation counter in the message, and MUST NOT check the 
generation counter against the current value. Replica Stores MUST NOT 
use a generation counter of 0.
8.  The storage time values are greater than that of any value which 
would be replaced by this Store.
9.  The size and number of the stored values is consistent with the 
limits specified in the overlay configuration.
10. If the data is signed with identity_type set to "none" and/or 
SignatureAndHashAlgorithm values set to {0, 0} ("anonymous" and "none"), 
the StoreReq MUST be rejected with an Error_forbidden error. Only 
synthesized data returned by the storage can use these values (see 
Section 7.4.2.2)

Reload nodes send store requests in 4 situations:

Case 1.  Node wishes to store its data in the overlay.
Case 2.  Node, that has received the store request,  sends store 
requests to save replicas immediately after receiving the original request.
Case 3.  Resource's replica set has changed. Node has to save new 
replicas on new neighboring nodes.
Case 4.  Node is no longer responsible for this resource. It has to 
store data on new responsible node.

(We use the term Node, rather than peer because the address of peer is 
called NodeId).

[minor issue #1.0.1]
Is the order of checks important or can they be checked in any order?

[minor issue #1.0.2]
Is it an error to send StoreReq without StoreKindData's, or 
StoreKindData without any StoredDatas inside?


Case 1.1. Node A stores its data on Node B, which is responsible for 
ResourceId R.
--------------------------------------------------------------------

[issue #1.1.1]
Firstly, B has to perform check [*] - is B responsible for R - and 
reject the request if not.
It is unclear though what "reject" means exactly. From our point of view 
B should send Error_Forbidden to A, but this leads to [issue #1.5.1]

[minor issue #1.1.2]
What if A sends StoreKindData with generation_counter = 5 and B doesn't 
have any value for this kind already stored (e.g. A stores data for this 
kind for the first time)?
Would it be correct to accept the request, set 5 as initial 
generation_counter for this kind and increase it to 6?

[issue #1.1.3]*
We still don't understand the exact meaning of following texts in the 
beginning of section 7 under "storage_time"

 >data may be stored in a single transaction, rather than querying
 >for the value of a counter before the actual store.

Which counter is meant here?

 >If a node attempting to store new data in response to a user
 >request (rather than as an overlay maintenance operation such as
 >occurs when healing the overlay from a partition) is rejected with
 >an Error_Data_Too_Old error, the node MAY elect to perform its
 >store using a storage_time that increments the value used with the
 >previous store.

We don't understand what "using a storage_time that increments the
value used with the previous store" actually means. In this case it is 
assumed that the requesting node has already the storage_time
of the previous store available or must it send a StatReq first?
In the former case it could simply check if localtime > storage_time
before sending the request. By what amount should the value be
incremented?


Case 1.2. Node B, sends store requests to save replicas on nodes C and D 
immediately after receiving store request from Node A.
-----------------------------------------------------------------------

[issue #1.2.1]*
What is the exact time sequence of the following events?

  1.  A sends StoreReq to B.
  2.  B sends StoreAns to A, listing C and D as replicas (in 
StoreKindResponse).
  3.  B sends StoreReq to C; B sends StoreReq to D.
  4.  C sends StoreAns to B; C sends StoreAns to B.

and with reference to 7.4.1.2 def. of replicas.

  1.   A sends StatReq to C; A sends StatReq to D.

Does time sequence in section 10.4 apply to any topology plugin, or is 
it CHORD-RELOAD specific?  Section 7.4.1.2 defines replicas as "the list 
of peers at which the data was/will be replicated".

How should A react if storing replicas fails on C and/or D? Should it 
retry to store the data? Or should it inform usage and let it handle 
this case?

[issue #1.2.2]
In this case, replica number in StoreReq is not 0 and this replica store 
can fail due to check [**]. What does "reject the request" means in this 
case, and how should the node, that sent the StoreReq, react to this 
failure?

D can fail on such request, if some node D* has recently joined D, and B 
doesn't know about D*. If it is critical to save the required number of 
replicas, B should request the routing table of D, update its own 
routing table and store replica on D*. If it is not critical, than B can 
wait for the next update from its neighbors and send a store request as 
described in section 10.7.3.

[minor issue #1.2.3]
Is it possible to define different replication strategies for different 
kinds?
If not, why does a node have to send list of replicas for each kind, not 
for the entire request? (There is the "replicas" field in 
StoreKindResponse).

[minor issue #1.2.4]
What happens if B sends StoreReq with generation_counter of 0. Should C 
and D reject it? What error should they send?


Case 1.3. R's replica set changed, B has to save new replica on new node 
D* instead of D.
---------------------------------------------------------------------

[issue #1.3.1]
We still don't understand how CHORD-RELOAD should assign replica_numbers 
in this case. Should it be the next replica number 3 because it is the 
3rd replica store, that was sent, or should it be 2, because D had 
replica number 2?

We still believe that assigning replica_numbers sequentially will lead 
to many confusions and it is better to just use replica_number "1" (or 
"42") for all replicas in CHORD-RELOAD.


Case 1.4. Node A is no longer responsible for R. It has to migrate data 
to Node A*.
-----------------------------------------------------------------------

[issue #1.4.1]
What is the value of replica_number in this case? Is it "0", because A* 
is responsible for R, or is it some other replica number (check issue 
1.3.1)?

If we use replica_number of 0, then check [4] will fail, because A is 
not authorized to write at R.
If we use a replica_number that is non zero, then A' must copy 
generation_counter of A, and than the first paragraph on page 104 
doesn't make much sense.


1.5. Common issues
----------------------------------------------------------------------

[issue #1.5.1]
Error_Forbidden is sent by node B if checks [2],[3],[4],[5] or [10] 
fails, and checks [*] and [**] are also good candidates for sending this 
error. However there is no particular format for Error_Forbidden 
defined. This means, that the error message is human-readable, but not 
machine-readable. In turn the node, that receives this error cannot 
react to it, because it doesn't know why exactly his request was rejected.

As we understand:
Check [2] may fail if node A sends new replica store request and 
certificate of one of the datas has expired. Since nodes are not 
required to synchronize clocks, certificate may still be valid from A's 
point of view. In this case A needs some meaningful error message to 
react to this error.
The reaction to checks [3] and [4] must be usage-specific.
The reaction to check [5] should be topology-plugin specific.
And finally check [10] is a programming error at the sender, and it can 
only be logged and reported.

Checks [*] and [**] can fail due to nodes joined or left. They can be 
corrected, if notified properly.

[minor issue #1.5.2]
Section 7.
Any attempt to store a data value with a storage time before that of a 
value already stored at this location MUST generate a Error_Data_Too_Old 
error.

Section 7.4.1.1
The storage time values are greater than that of any value which would 
be replaced by this Store.

So is it before (accept if new_storage_time >= old_storage_time) or 
greater (new_storage_time > old_storage_time)?

[issue #1.5.3]
7.3.4.
In the NODE-MULTIPLE policy, a given value MUST be written (or 
overwritten) if and only if the signer’s certificate contains a Node-ID 
such that H(Node-ID || i).

Should it be obvious that this 'i' is represented as 32 bit unsigned 
integer in network byte order?

[minor issue #1.5.3]
7.3.2. and 7.3.3.
In the NODE-MATCH policy, a given value MUST be written (or
overwritten) if and only if the signer’s certificate has a specified
Node-ID which hashes (using the hash function for the overlay) to the
Resource-ID for the resource and that Node-ID is the one indicated in
the SignerIdentity value cert_hash.

We think it should be defined as "and that Node-ID is the one, that has 
signed the StoredValue (or StoreReq), as indicated by SignerIdentity".
First, we think cert_hash_node_id is also a valid choice. Second, 
SignerIdentity types can be extended.

[minor issue #1.5.4]
If the error is called Error_Generation_Counter_Too_Low,  what should 
and implementation do if it is opposite too high ?

[minor issue #1.5.5]*
What is the proper reaction for StoreReq, that contain two or more 
StoreKindDatas for the same KindId.

2. Fetch
======================================================================

[issue #2.1]
Does the node have to check, if it is responsible for this resource, or 
if it is in replica set for this resource?

[issue #2.2]
What is sent if there is no data stored for the requested resource? 
Empty FetchReq, FetchReq with FetchKindResponse for each kind and empty 
values in it, or Error_Not_Found?
What is sent if there is data for the requested resource, but no data 
for the requested kind?
What generation_counter should be sent in FetchKindResponse in this 
case? '0' seems to be a good choice. Can we just send FetchKindResponse 
with generation_counter of 0 and no values, or should we generate all 
requested values?

[minor issue #2.3]
Are storage time and  lifetime of synthesized values also set to 0 ?

3. Stat
=======================================================================

[issue #3.1]
Do all the considerations in Fetch also apply here? In particular:
1. Should the node check that it is responsible for resource or that it 
is in the replica set for it? (please consider [issue 1.2.1] here)
2. What to send, if current resource_id is not found? What happens if 
there is no data for this kind at this resource?
3. Does implementation have to process generation_counter as in FetchReq 
- do not send MetaDatas, if generation counter in request matches the 
one being stored.
4. Does store have to synthesize values for missing array indexes and 
nonexisting dictionary keys as in FetchReq?

4. Find
=======================================================================

[issue #4.1]
What does "closest to R" exactly mean and how  are 1+ R_n and 
nearest(1+R_n) defined? Does TopologyPlugin have to provide a valid 
order relation or metric for ResourceIds?

[issue #4.2]
Would it make sense to define wildcard resource_id to find any resource 
that has the requested kind on this node?

[issue #4.3]
It is unclear, what is the resource_id of '0'? Is it the resource with 
zero length on the wire, or is it the resource with some plausible for 
the current topology value of 0 (e.g. the same value as invalid NodeId).

[issue #4.4]
Should "kind_id is not known" be interpreted as "kind_id is not defined 
in overlay-config" or as "there is no resource which stores this kind on 
this node"? In the former case sending resource_id of '0' is overloaded 
- it is either unknown kind, or kind for which there is no entry on this 
node. Please consider also [issue 6.4].

5. Defining new Kinds
========================================================================
[issue #5.1]
Where exactly is textual form present?
In what units is max-size defined?

[issue #5.2]
Section 7.4.4. says, that some kinds cannot be used with find. Is there 
a config-entry for this?

6. Common issues
========================================================================

[issue #6.1]*
For each request in data storage protocol the receiving node should 
check if the requested kind is present in the configuration file. But 
the requirement is different in for each protocol message:
StoreReq: send back Error_Unknown_Kind. The error message must contain 
all kinds, the receiver didn't recognize and the sender MUST generate a 
config-update after receiving this message.
FetchReq: "Implementations SHOULD reject requests corresponding to 
unknown Kinds unless specifically configured otherwise. (as always, what 
"reject" mean)
StatReq: no hint given how to behave
FindReq: "If a Kind-ID is not known, then the corresponding Resource-ID 
MUST be 0."

[issue #6.2]
Would you consider moving the requirement about signature computation on 
arrays from 7.4.2.2, to 7.1, or at least referencing it in 7.1. In this 
place it is really easy to be overlooked.

[minor issue #6.3]* (this is in common issues because value is included 
in signature)
If some node wishes to delete its data, it should send StoredDataValue with
exists = False
value = {} (0 length)

What must a receiving node do if the value is given? Should it ignore 
the value, or reject it?

[issue #6.4]
ProbeReq/Ans defines one of the  ProbeInformationType - num_resources as:

 >indicates that the peer should Respond with the number of resources 
 >currently being stored by the peer.

It is unclear, what exactly "currently being stored" means with relation 
to non-existing values. In particular say Node A has stored some value 
at ResourceId R with lifetime 5hours, and in 1hour will remove it(as 
defined in 7.4.1.3). That means R will contain one StoredData with 
StoredDataVales::exist set to false and lifetime at least 4 hours. If 
this value is the only value R contains, does R count as "currently 
being stored"?
Should this resource be returned by Find ?

--- ---
Regards,
   Roland and Polina

WGLC for draft-ietf-p2psip-sip-09

Carlos Jesús Bernardos Cano — 2013-05-04T17:33:18

Hi,

Hereby we are issuing a WGLC for draft-ietf-p2psip-sip-09. 

The WGLC will be open till the 20th of May. We kindly ask the WG to
review the document and provide comments.

If you have no comments and think the document is ready to be submitted 
to IESG, please do send a note stating that to the WG ML.

Additional information about the document is below:

        Title           : A SIP Usage for RELOAD
        Author(s)       : Cullen Jennings
                          Bruce B. Lowekamp
                          Eric Rescorla
                          Salman A. Baset
                          Henning Schulzrinne
                          Thomas C. Schmidt
        Filename        : draft-ietf-p2psip-sip-09.txt
        Pages           : 19
        Date            : 2013-02-25

Abstract:
   This document defines a SIP Usage for REsource LOcation And Discovery
   (RELOAD).  The SIP Usage provides the functionality of a SIP proxy or
   registrar in a fully-distributed system and includes a lookup service
   for Address of Records (AORs) stored in the overlay.  It also defines
   Globally Routable User Agent Uris (GRUUs) that allow the
   registrations to map an AOR to a specific node reachable through the
   overlay.  After such initial contact of a peer, the AppAttach method
   is used to establish a direct connection between nodes through which
   SIP messages are exchanged.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-sip-09

Thanks

Review of revised DRR and RPR documents

Carlos Jesús Bernardos Cano — 2013-05-04T17:23:34

Hi,

I've just gone through the revised documents authors provided after my
first round of comments. I'm happy to see that most of the comments have
been now introduced. I have now only a few minor editorial ones, that
can be dealt with in parallel with the next steps. My reviews are
attached to this e-mail (I added comments to the PDF version of each
draft). Authors, please check the attachments!! :D

Thanks for the nice job.

Thanks,

Carlos
_______________________________________________
P2PSIP mailing list
P2PSIP-EgrivxUAwEY< at >public.gmane.org
https://www.ietf.org/mailman/listinfo/p2psip

RELOAD Interoperability Testing Event in Berlin

Marc Petit-Huguenin — 2013-05-02T14:40:12

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

This is the last call for participation for a RELOAD Interoperability Testing
event in Berlin, Germany on July 27 and 28.

On the Saturday, the event will be held at the Freie Universitaet Berlin.  On
the Sunday the event will be held at the venue of IETF 87.  Many thanks to the
Freie Universitaet Berlin and the IETF for providing the resources for this.

If you have a RELOAD implementation, complete or partial, and want to
participate, please send an email to reloadit-registration-V0vwV6LTwHHhIp2ksRZFZA< at >public.gmane.org,
with the following information:

- - Implementation name
- - Contact email
- - Number of persons attending.

Note that the event will be canceled if there is not at least 4 different
implementations registered by end of May, so please register as soon as
possible.  You do not need a complete implementation to participate and be
assured that the name of the participants will be kept confidential.

Remember that all participants can have one or more RELOAD configuration &
enrollment services provisioned for free to simplify the participation in
local or remote interoperability testing.  Please send me an email directly to
provision this service.

Thanks.

- -- 
Marc Petit-Huguenin
Email: marc-SHzPq5HBsP0vtAZ8OuFxWR2eb7JE58TQ< at >public.gmane.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)

iQIcBAEBCAAGBQJRgnq2AAoJECnERZXWan7EfRYP/jlSc6glgIynTdNyERtrbsQr
JAcO2E2V/oWpSbjM73U5uiiJdPAg4c/TCxLaEf0pDZBcftqB7lXnvou8nnyCZhqZ
TPCdu4B30nPYR7ZZ7v/0QDsG2+l8b17YHDiUM2yj605cUZL7r2jZqOazuX/zmpqz
Aoan7TI4k+7KDFQ3R0aGBVgW0LTq4QuXj1PJxAxwE4rwn9sAZCmq+3Zcdf+AE4kk
dX0sCI4GIOo89a5g4J72SGWMMinsLFWK60UDToiCloNU2Uyikrqin7c5jgHfOdcB
uFZDX4JjDrt6OhEttau0lyvYQCPtnfSbDzoHhgyQAzJnerQOb+nc/hV80/b5FSuJ
yVn61g77ozXDyl4KsKY8BGJQeDj4aGnSQdV8x0GcMKHmf3V+c84v8R5zF0uMrrgF
etE0Jqx3qbzyrCo9TbPGqwiB00h7ShQ/ZPxT+IT0QYCxHpRLehsUmCzD5KuKgGOU
U4gJSH7qwAF0avJrhqIgwGilteVFisBBcMidO+Q42EksLEu2pF5sv+GJHmOmkIUY
1pQ9vITgcSqre+5SEWfSccGGZ5tqBdUk3107qvKFusesTQjPDVzD0+fc77s1RxQG
EbicXgQegqfyw4CGtwR5UHxNkLmN+Rl0YjaKPPKWmhkAFyWw9T0TCMiGnNjEItp/
UjwrHTezvSr9noR1dJAo
=uksw
-----END PGP SIGNATURE-----

Fwd: I-D Action:draft-petithuguenin-p2psip-reload-eku-01.txt

Marc Petit-Huguenin — 2013-04-30T15:41:17

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

I just release a new version of this draft that was presented in Atlanta.  The
draft contains a new Implementation Status section, following the advices of
draft-sheffer-running-code.

Comments, questions and suggestions are welcome.

Thanks.

- -------- Original Message --------
Subject: I-D Action: draft-petithuguenin-p2psip-reload-eku-01.txt
Date: Mon, 29 Apr 2013 20:31:07 -0700
From: internet-drafts-EgrivxUAwEY< at >public.gmane.org
Reply-To: internet-drafts-EgrivxUAwEY< at >public.gmane.org
To: i-d-announce-EgrivxUAwEY< at >public.gmane.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title           : Using Extended Key Usage (EKU) for REsource LOcation And
Discovery (RELOAD) X.509 Certificates
Author(s)       : Marc Petit-Huguenin
Filename        : draft-petithuguenin-p2psip-reload-eku-01.txt
Pages           : 5
Date            : 2013-04-29

Abstract:
   This document describes an Extended Key Usage (EKU) X.509 certificate
   extension for restricting the usage of a certificate to a REsource
   LOcation And Discovery (RELOAD) overlay.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-eku

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-eku-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-petithuguenin-p2psip-reload-eku-01


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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRf+YcAAoJECnERZXWan7E3IcP/2OASAAQ8SpOaYvwPGNGaR8v
7/tS45rNfSjcd6mnXjZmiXYLkNJXxDWTTar1bALUkUA1jlBQjqg/seCbX2cIUoNr
L/osXDC8ZljmfBBvriDiWjEQhhH58yQFTiA3zWYJy8Y4ahZP8/gpSM7d2JE5pdtH
D2w2K2spzLGZykPoAOcczohimPtpCmPoIs09A+ZV/oq06UNVsD4V76g1VPUvBWxW
Cljm0M4mtlRJnSLLVj+trpHqrV3frJUjXhNgcZebkAWKPpR91Lrk7o86A5KcbjTc
T+5wygtwGZvao5sbxO4gswwXDptv/jh/ILVoFtXXDbRT28cUNdBe9Qv6XaZU/xJj
knv2v9yAM5u7wEfyQ+ukbgI01IfJg0s8SNOEMK8ENZh007BTk6p2xj+ZqMJnH0Mm
pmPYQCKcXbOfKvvjAc9iaGHlom9FsGYuRB1g8WRrTicfgBqGouYS+QPe6KsryCOC
5pDUtnZ523D9P4Selv+uofulLviH64njqnXkpG4/h9XmsKH3pHS8hDUgwq03qgcF
xcRVeB13XSX3zZrR/ed7KXdGFgHX3sjD/P9y1U1ShUVXyy7U2N/hxBYlBqQrXxMi
QpVQcY3rpYrG4HMFkFkSEKCioqqUkgazPtS09H7bTi4ylnxHlkK29pFI5fcheYf8
zhPfZFiM3Brq0usZk0Yk
=IFP9
-----END PGP SIGNATURE-----

Biggest Fake Conference in Computer Science

2013-04-27T17:31:20

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
P2PSIP mailing list
P2PSIP< at >ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

Certificates with multiple NodeIds

Polina Goltsman — 2013-04-22T18:30:39

Hi,

I have several questions regarding certificates with multiple NodeIDs.
It seems that different parts in the draft contradict each other.

First, section 6.6.1 defines requirements for future overlay link
protocols. I suppose, that current overlay link  protocol must meet
these requirements.

Certificates with multiple NodeIDs sometimes violate this requirement.
Unless a connection was formed as a result of exchanging Attach
messages, it is impossible to associate an endpoint and its NodeID,
which is the case when new node connects to BootstrapPeer.
As a consequence several reload requirements are hard or even impossible
to implement IMHO.

The first requirement is that ConnectionTable SHOULD use some indexes
instead of mapping NodeIds to (D)TLS Connections.

The second requirement is in section 6.1.2

The routing decisions must be made based on ForwardingHeader alone, and
a ForwardingHeader does not contain information about type of the
message, being sent. So this is practically NOT implementable.

Section 3.2.1 Bullet 2 - about Clients, that connect to peers

As far as I  understand, the procedure is as follows. The peer in the
overlay, that listens on some known port, receives a connection from a
client. This connection is in some unknown state because NodeId of at
least one endpoint is not known. Then, the client must send a PingReq to
the wildcard NodeId. It will be consumed by the peer as the next
endpoint. Once the client has learned the peer's NodeID, it may send
Attach, with, as I suppose, one static candidate. The peer must somehow
find out that this static candidate is the connection, that is already
formed and do not try to form it again.

(Moreover the Attach section doesn't state what to do if the connection
is already formed. This is also essential for the topology plugin, since
some node may already have an opened connection with its new neighbour
(consider peer-ready update), but in that case NodeIds are known and
connection table can be searched).

In my opinion, both client and peer could learn each other's NodeIDs
from the Ping. Both PingReq and PingAns are signed and thus uniquely
identify its senders. Since the connection to the client is in some
unknown state and the destination was wildcard NodeID, the peer can
assume that the sender of this message is another endpoint of this
connection. The peer can also compare the client's certificate with the
one, used to form TLS association.



Another question, that I have, is shared-secret admission schemes for TLS.
The TLS-PSK RFC states, that in case of TLS-PSK certificate exchange is
optional. It is unclear from the RFC, that PSK ciphers with certificate
exchange must be selected. It is also unclear, what should be sent in
TLS-PSK identity field - username, NodeID, both or nothing.
As of TLS-SRP RFC the client certificate cannot be requested.



I also can imagine two possible solutions to the first problem.

Solution 1(undesirable):
Have a specified way of finding out peer's identity. If one of the
certificates had multiple NodeIds, the first message, that is sent over
this connection must identified both peers. This can be Ping, Attach or
some dedicated "HelloReq" and it works as described above. After this
exchange both peers must update their connection tables with NodeIDs of
the endpoints.

This solution is undesirable, since it increases message load on
bootstrap nodes.

Solution 2:
Use TLS Extension to exchange not only the certificates, but also NodeID
(in some form, e.g. the cert_hash_node_id form) during the TLS connection.

The extension can use SupplementaryData [RFC 4680
<http://tools.ietf.org/html/rfc4680>] to exchange the actual NodeID. For
example:
struct {
      SupplementalDataType supp_data_type;
      uint16 supp_data_length;
      select(SupplementalDataType) {
          case reload_signer_identity: SignerIdentity
      }
} SupplementalDataEntry;

The 2 extensions, that look most suitable are:
1. user-mapping [RFC 4681<http://tools.ietf.org/html/rfc4681>]. The
information, that is sent, is exactly what is needed,but the RFC defines
only client's authentication, not the server's.
2. serverautz/clientauthz [RFC 5878
<http://tools.ietf.org/html/rfc5878>]. This RFC is not standard.

I also want to propose more precise way for configuring TLS connection,
by using a dedicated section and overlay-config for configuring underlay
link layer for reload. For example, for TLS this would be:
<tls:auth> normal/PSK/SRP</tls:auth>
<tls:multiple-node-id-cerificates-allowed> true/false <tls:...>
<tls:shared-secret-scheme>...</..>
<tls:allowed-cipher-suites>...</...>

Does it make sense?

Regards,
    Polina

I-D ACTION:draft-ietf-p2psip-rpr-05.txt

2013-04-16T16:11:38

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

    Title         : An extension to RELOAD to support Relay Peer Routing
    Author(s)     : N. Zong, et al
    Filename      : draft-ietf-p2psip-rpr
    Pages         : 15 
    Date          : April 16, 2013 
    
   This document proposes an optional extension to RELOAD to support
   relay peer routing mode.  RELOAD recommends symmetric recursive
   routing for routing messages.  The new optional extension provides a
   shorter route for responses reducing the overhead on intermediate
   peers and describes the potential use cases where this extension can
   be used.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-05.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
P2PSIP mailing list
P2PSIP-EgrivxUAwEY< at >public.gmane.org
https://www.ietf.org/mailman/listinfo/p2psip