From nobody Fri Mar 4 11:43:03 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F671A88C2 for ; Fri, 4 Mar 2016 11:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT6vs1aJL4XZ for ; Fri, 4 Mar 2016 11:42:59 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1F81A88BD for ; Fri, 4 Mar 2016 11:42:59 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DEC9720A89 for ; Fri, 4 Mar 2016 14:36:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 04 Mar 2016 14:36:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=BX+Ef VfgIRiE5ARYnclDDDQXGn4=; b=298vE/lOhynlKIOeoloQ7hAR4aTc4Mdp0ZiqM HoSOVi8WJsf+OAYSGeu6HvDCTd4Y2kOh63+wL3gM0douiCS6RSlrDI3JXUA4Bkt5 G1hUWd0iA8CplcobRY87j3yd47jn7JPufeHIAxr3jGpb4U7ApXqLtXQ91nL3OjSm /7brac= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=BX+EfVfgIRiE5ARYnclDDDQXGn4=; b=qSJFx tpIAZIzVB0ZVK/L7t2mzzbjXYUjYumihgn5lb0BcMrC4wMXLpoRmwQQRVJg5fPJw e/WdFDDCCYzrBKmw5nizQWTJfLoBmUeoF8M9WdE5xqIGZ3F2jq+RunB/md/peIse N1uP8v0IWi0o+j9yhm9jKd1RaOgG/UQmpXlcvU= X-Sasl-enc: 3XP2uBhUWlYynL8K1cUsGQY8ylOTUmp0cFaEAoOJOSG6 1457120205 Received: from dhcp-171-68-20-44.cisco.com (dhcp-171-68-20-44.cisco.com [171.68.20.44]) by mail.messagingengine.com (Postfix) with ESMTPA id B1784C00018; Fri, 4 Mar 2016 14:36:44 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6605EAB1-BFCE-49F0-9F18-59DF81BD3FF6" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Fri, 4 Mar 2016 11:36:43 -0800 Message-Id: References: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 19:43:02 -0000 --Apple-Mail=_6605EAB1-BFCE-49F0-9F18-59DF81BD3FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alvaro, Are you able to clear based on the latest version? = https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21 = Thanks, Alissa > On Jan 7, 2016, at 12:27 PM, Alvaro Retana (aretana) = wrote: >=20 > On 1/6/16, 4:44 AM, "Songhaibin (A)" wrote: >=20 > Haibin: >=20 > Hi! >=20 > ... >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I am balloting a DISCUSS because I am concerned that this document >>> doesn't >>> actually do what it set out to achieve. I would love it if during = the >>> discussion I >>> was pointed to the places where RELOAD already solves the issues, = but >>> for now >>> I wasn't able to find them. >>>=20 >>> According to the text, both extensions are intended to collect >>> information >>> "along the path", and the Figures clearly depict what is intended to >>> happen. >>> However, I don't think that as specified (or at least as explained) = the >>> behavior is >>> guaranteed. Specific points: >>>=20 >>> 1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that = an >>> "overlay MAY be configured to use alternative routing >>> algorithms=8A[or]=8AMAY be >>> selected on a per-message basis". How is the symmetry enforced if = other >>> routing algorithms are used? Enforcing that the ping/trace messages = use >>> symmetric routing when other algorithms are in use won't necessarily >>> help >>> because the paths may be different. >>=20 >> I think one important thing is that, the draft does not guarantee = what it >> conveys must be the information that caused the previous failures, = but >> with the retrieved information from the previous traversed nodes = (with >> high probability, as it cannot guarantee the exact same path), a user = or >> machine can analyze and infer what is the problem. Symmetric routing = is >> achieved by the via list (whatever DHT routing algorithms are used), = but >> response message could go through not exactly the same path as there >> still can be failures during that short period. >>=20 >>>=20 >>> 2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the = response >>> traverses the same peers as the request traversed, except in reverse >>> order >>> (symmetric routing) and possibly with extra nodes (loose routing)." >>> In other words, even if symmetric routing is used, there is no >>> guarantee that >>> the same path will be followed by the response, unless the = originator >>> builds the >>> Via List with strict details of all the nodes in the path -- maybe = this >>> is what is >>> intended, but no explicit mention occurs in the document. >>=20 >> I agree this should be mentioned in the document. >=20 > Clarifying the caveats (like what we're discussing above, for example) = is > one of the ways to move forward with resolving my DISCUSS. >=20 > However, I have to say that the clarifications, which basically point = at > no guarantees about the path (or its relevance), leave me very > dissatisfied with a technical solution that is unreliable. :-( >=20 >>=20 >>>=20 >>> 3. In 4.3, what does "directly or via symmetric routing" mean? Is it >>> directly >>> connected? If so, then (for the text in 4.3) that would mean that C = is >>> adjacent >>> to A, and even though it is the next hop after B, the path taken to >>> reach C with >>> the PathTrack request doesn't include B =8B the result is that the >>> diagnostic >>> information received from C may not be relevant relative to = destination >>> D. >>=20 >> As each PathTrack request will contain the destination ID, which was = the >> same destination ID as the previously failed message. So no matter = how >> the PathTrack request arrives to C, C will have a look at that >> destination ID for the next step. >=20 > My point above was the the path *to* C (from A) may not actually even = go > through B. In other words, even if the rest of the path (all the way = to > D) is congruent, the overall information is still not completely = relevant. >=20 >>=20 >>=20 >>>=20 >>> Are there implementations available? What has been the experience? = The >>> Shepherd's write-up didn't mention any, and the TBD codes make me = think >>> that >>> maybe Experimental might be a better status for this document. >>=20 >> In my memory, there was one several years ago, but not based on = RELOAD. >=20 > Given the clear inconsistency and the lack of experience, I want to > suggest that Experimental status be considered. >=20 >>=20 >>=20 >>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> In general, as others have mentioned, I think the text could be a = lot >>> clearer and >>> not leave some concepts to interpretation. >>>=20 >>> 1. In 4.2.1, the MessageExtension is defined with a Boolean of >>> "critical", but >>> the text (a paragraph later) says that this "extension is not >>> critical". I may be >>> missing some of the semantics, or there's an error somewhere. >>=20 >> My understanding with RELOAD, if value of "critical" can be true or >> false, if it is critical, then every node must support the extension, = if >> it is not critical, then it is optional to support it. As it explains = in >> that section, "If a peer does not support the extension, they will = simply >> ignore the diagnostic portion of the message..." >=20 > I looked at the text again -- it is still confusing to me, but I = noticed > that Section 6.1. (Message Creation and Transmission) does say that = "the > sender MUST...[set] the value of critical to FALSE". Maybe using > "Critical" (capital C) to describe the state (vs the use of the word = as an > adjective) would help. >=20 >>=20 >>>=20 >>> 2. In 4.3..the last paragraph reads: if "...succesive calls to >>> PathTrack return >>> different paths, the results should be discarded and the request = resent, >>> ensuring that the second request traverses the appropriate path". >>> Path changes are a fact of life =8B the second request may just be >>> reflecting the >>> new path, so resending it in an attempt to find the "appropriate = path" >>> may be >>> futile. >>=20 >> At least in the previous two attempts, the path was "stable". >>=20 >>> 3. What is a "routing mode"? Section 4.3.1. (New RELOAD Request: >>> PathTrack) talks about it when saying that the "PathTrack request = can be >>> routed directly or through the overlay based on the routing mode". >>> Later >>> Section 6.2. (Message Processing: Intermediate Peers) says that >>> "processing >>> this request according to the overlay specified routing mode from = RELOAD >>> protocol" -- I looked in RFC6940 for "routing mode", but didn't find >>> anything. >>> Note that it also looks to me like there's no place in the >>> DiagnosticsRequest to >>> indicate a mode.. >>=20 >> This draft should add a reference to RFC 7263 for the routing mode. >=20 > Ok. >=20 >>=20 >>> 4. Section 5.3. (dMFlags and Diagnostic Kind ID Types) defines an >>> "UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the >>> intermediate >>> peer which receives the diagnostics message to the next hop peer for >>> this >>> message." How is that information derived? >>=20 >> It can use the traceroute tool. >>=20 >>> 5. I think that the Reference to RFC5226 should be Normative. >>>=20 >>=20 >> Accepted. >>=20 >>>=20 >>> I also agree with others that the title should probably be something >>> around >>> RELOAD Diagnostics, and that this work doesn't really update = RFC6940, it >>> extends it in independent ways. >>=20 >> It seems we can achieve a consensus here that it extends RELOAD. What >> about the title "RELOAD Extension for P2P Overlay Diagnostics"? >=20 > I am not opposed to that. >=20 > Thanks! >=20 > Alvaro. >=20 --Apple-Mail=_6605EAB1-BFCE-49F0-9F18-59DF81BD3FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Alvaro,

Are you able to clear based on the = latest version? https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21

Thanks,
Alissa


On Jan 7, 2016, at 12:27 PM, Alvaro Retana = (aretana) <aretana@cisco.com> wrote:

On = 1/6/16, 4:44 AM, "Songhaibin (A)" <haibin.song@huawei.com> wrote:

Haibin:

Hi!

...



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I am balloting a DISCUSS because I = am concerned that this document
doesn't
actually do what it set out to achieve.  I would love it = if during the
discussion I
was pointed to = the places where RELOAD already solves the issues, but
for = now
I wasn't able to find them.

According to the text, both extensions are intended to = collect
information
"along the path", and = the Figures clearly depict what is intended to
happen.
However, I don't think that as specified (or at least as = explained) the
behavior is
guaranteed. =  Specific points:

1. RFC6940 says (in = Section 6.2. (Symmetric Recursive Routing)) that an
"overlay= MAY be configured to use alternative routing
algorithms=8A[or]=8AMAY be
selected on a = per-message basis". How is the symmetry enforced if other
routing algorithms are used?  Enforcing that the = ping/trace messages use
symmetric routing when other = algorithms are in use won't necessarily
help
because the paths may be different.

I think one important thing is = that, the draft does not guarantee what it
conveys must be = the information that caused the previous failures, but
with = the retrieved information from the previous traversed nodes (with
high probability, as it cannot guarantee the exact same = path), a user or
machine can analyze and infer what is the = problem. Symmetric routing is
achieved by the via list = (whatever DHT routing algorithms are used), but
response = message could go through not exactly the same path as there
still can be failures during that short period.


2. RFC6940 also (in 6.2.2. (Response Origination)) reads: = "the response
traverses the same peers as the request = traversed, except in reverse
order
(symmetric = routing) and possibly with extra nodes (loose routing)."
In = other words, even if symmetric routing is used, there is no
guarantee that
the same path will be followed = by the response, unless the originator
builds the
Via List with strict details of all the nodes in the path -- = maybe this
is what is
intended, but no = explicit mention occurs in the document.

I agree this should be mentioned in the document.

Clarifying the caveats (like what = we're discussing above, for example) is
one of the ways to = move forward with resolving my DISCUSS.

However, I have to say that the clarifications, which = basically point at
no guarantees about the path (or its = relevance), leave me very
dissatisfied with a technical = solution that is unreliable. :-(



3. In 4.3, what does "directly or via = symmetric routing" mean? Is it
directly
connected? If so, then (for the text in 4.3) that would mean = that C is
adjacent
to A, and even though it = is the next hop after B, the path taken to
reach C with
the PathTrack request doesn't include B =8B the result is = that the
diagnostic
information received = from C may not be relevant relative to destination
D.

As each PathTrack request will = contain the destination ID, which was the
same destination = ID as the previously failed message. So no matter how
the = PathTrack request arrives to C, C will have a look at that
destination ID for the next step.

My point above was the the path = *to* C (from A) may not actually even go
through B. =  In other words, even if the rest of the path (all the way to
D) is congruent, the overall information is still not = completely relevant.




Are there implementations = available?  What has been the experience? The
Shepherd's write-up didn't mention any, and the TBD codes = make me think
that
maybe Experimental might = be a better status for this document.

In my memory, there was one several years ago, but not based = on RELOAD.

Given the clear = inconsistency and the lack of experience, I want to
suggest = that Experimental status be considered.





---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

In general, as others have = mentioned, I think the text could be a lot
clearer and
not leave some concepts to interpretation.

1. In 4.2.1, the MessageExtension is defined with a Boolean = of
"critical", but
the text (a paragraph = later) says that this "extension is not
critical". I may = be
missing some of the semantics, or there's an error = somewhere.

My understanding = with RELOAD, if value of "critical" can be true or
false, = if it is critical, then every node must support the extension, if
it is not critical, then it is optional to support it. As it = explains in
that section, "If a peer does not support the = extension, they will simply
ignore the diagnostic portion = of the message..."

I looked at = the text again -- it is still confusing to me, but I noticed
that Section 6.1. (Message Creation and Transmission) does = say that "the
sender MUST...[set] the value of critical to = FALSE".  Maybe using
"Critical" (capital C) to = describe the state (vs the use of the word as an
adjective) = would help.



2. In 4.3..the last paragraph reads: if "...succesive calls = to
PathTrack return
different paths, the = results should be discarded and the request resent,
ensuring= that the second request traverses the appropriate path".
Path changes are a fact of life =8B the second request may = just be
reflecting the
new path, so = resending it in an attempt to find the "appropriate path"
may be
futile.

At least in the previous two attempts, the path was = "stable".

3. What is a "routing mode"?  Section 4.3.1. (New RELOAD = Request:
PathTrack) talks about it when saying that the = "PathTrack request can be
routed directly or through the = overlay based on the routing mode".
Later
Section 6.2. (Message Processing: Intermediate Peers) says = that
"processing
this request according to = the overlay specified routing mode from RELOAD
protocol" = -- I looked in RFC6940 for "routing mode", but didn't find
anything.
Note that it also looks to me like = there's no place in the
DiagnosticsRequest to
indicate a mode..

This draft should add a reference to RFC 7263 for the routing = mode.

Ok.


4. Section 5.3. (dMFlags and Diagnostic Kind = ID Types) defines an
"UNDERLAY_HOP (8 bits): Indicates the = IP layer hops from the
intermediate
peer = which receives the diagnostics message to the next hop peer for
this
message."  How is that information = derived?

It can use the = traceroute tool.

5. I think that the Reference to RFC5226 should be = Normative.


Accepted.


I also agree with others that = the title should probably be something
around
RELOAD Diagnostics, and that this work doesn't really update = RFC6940, it
extends it in independent ways.

It seems we can achieve a = consensus here that it extends RELOAD. What
about the = title "RELOAD Extension for P2P Overlay Diagnostics"?

I am not opposed to that.

Thanks!

Alvaro.


= --Apple-Mail=_6605EAB1-BFCE-49F0-9F18-59DF81BD3FF6-- From nobody Fri Mar 4 11:53:03 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5941A8909 for ; Fri, 4 Mar 2016 11:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfuwGzzbF2Oi for ; Fri, 4 Mar 2016 11:53:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E49D1A8901 for ; Fri, 4 Mar 2016 11:53:00 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 47C6620418 for ; Fri, 4 Mar 2016 14:43:39 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 04 Mar 2016 14:43:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=i47kbFIPVEA11FyBoBTHM2nGGdc=; b=I0kCVX 6OB+e9J5bhOVgmjFpGtCBpp3nXUAFcXYypAvpgMeO4bsLIL5Z2ud2h/0syHnNLXM A4PKT4U8vGa5SGIdfq1oUTKAObntnAo/Wv0XRx6ECa+ejAtpRoBbGKBWskRMe4Of 6oQqgSbSJ7BSHrpdtsYqrQ6Ya9SR16UaVMFgw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=i47kbFIPVEA11Fy BoBTHM2nGGdc=; b=ZDfSi0EdHrApkwYACDqXXgxPRU/Ykj+3eolEGxaxUdBAnwH amNYIFLkMT2sebV2QGoc/LFuXV3kjY0amtHCEBnRtXcoK1wWF7JNEGv7VQHkolsr 9yUoQclGoRKIU7hBejHaLFqSbDI+N8HrhKe6sQi7McnCLa4S8FhDpZmArr+Y= X-Sasl-enc: bcc6b6aR+ECA3SVFp7YTZALHdiwI3tgQXn47EYPTOhbt 1457120618 Received: from dhcp-171-68-20-44.cisco.com (dhcp-171-68-20-44.cisco.com [171.68.20.44]) by mail.messagingengine.com (Postfix) with ESMTPA id B7A94C00020; Fri, 4 Mar 2016 14:43:38 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Fri, 4 Mar 2016 11:43:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <412972789d024091baeda005b8500e47@HUB02.mailcluster.haw-hamburg.de> <56B91C25.2020308@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: p2psip@ietf.org Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 19:53:02 -0000 Hi Thomas, Any update? Thanks, Alissa > On Feb 18, 2016, at 3:40 PM, Alissa Cooper wrote: >=20 > Hi Thomas, >=20 > Checking in on this and the -share doc. When do you expect to respond? >=20 > Thanks, > Alissa >=20 >> On Feb 8, 2016, at 2:52 PM, Thomas C. Schmidt = wrote: >>=20 >> Yes, I'll catch up on this asap. >>=20 >> Cheers, >> Thomas >>=20 >> On 08.02.2016 23:34, Alissa Cooper wrote: >>> Is anyone in the WG able to respond to these comments and questions? >>>=20 >>> Thanks, >>> Alissa >>>=20 >>>> On Jan 15, 2016, at 1:58 PM, Alissa Cooper = wrote: >>>>=20 >>>> I have reviewed this document in preparation for IETF last call. I = have a number of comments and questions that need to be resolved before = last call can be initiated. In particular, I have some security concerns = about using this in an overlay that allows registrations for any domain. >>>>=20 >>>> I=92ve also included some nits below that should be resolved = together with last call comments. >>>>=20 >>>>=20 >>>> =3D=3D Substantive comments and questions =3D=3D >>>>=20 >>>> =3D Section 3.2 =3D >>>>=20 >>>> This section is underspecified and I=92m not sure the references to = RFC 2533 and RFC 2738 are the appropriate ones. I think what you need to = specify here is that the contact_prefs will encode a media feature set = comprised of SIP User Agent capabilities, as defined in RFC 3840 and = registered in the SIP media feature tag registration tree (assuming that = is what is intended). >>>>=20 >>>> It=92s also confusing that you only mention whether sip.schemes is = required or not without mentioning whether specifying any other = capabilities is required or optional. >>>>=20 >>>> =3D Section 3.3 =3D >>>>=20 >>>> "Before issuing a Store request to the overlay, any peer SHOULD = verify that the AOR of the request is a valid Resource Name with respect = to its domain name and the namespaces defined in the overlay = configuration document (see Section 3.4)." >>>>=20 >>>> Why is this SHOULD rather than MUST? >>>>=20 >>>> =3D Section 3.4 =3D >>>>=20 >>>> (1) I note that this documents refers to a different version of the = IEEE Posix spec than draft-ietf-p2psip-share. What=92s the reason for = the difference? >>>>=20 >>>> (2) >>>> I find the explanation of the expected behavior here hard to = follow. I've suggested a re-write below. There also seems to be one case = that is not specified, which is when the "enable" attribute is set to = false. Text describing what should happen in that case needs to be = added. >>>>=20 >>>> OLD >>>> A RELOAD overlay can be configured to accept store requests for any = AOR, or to apply domain name restrictions. For the latter, an = enumeration of admissible domain names including wildcarded name = patterns of the following form MAY be configured. >>>>=20 >>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name >>>>=20 >>>> In this example, any AOR will be accepted that is either of the = form @dht.example.com, or ends with the domain "my.name". When = restrictions apply and in the absence of domain patterns, the default = behavior is to accept only AORs that exactly match the domain name of = the overlay. Otherwise, i.e., when restrictions are not configured = (attribute enable not set), the default behavior is to accept any AOR. = In the absence of a element, implementors SHOULD = assume this default value. Encoding of the domain name complies to the = restricted ASCII character set without character escaping as defined in = Section 19.1 of [RFC3261]. >>>>=20 >>>> The element serves as a container for zero to = multiple sub-elements. A element MAY be present if = the "enable" attribute of its parent element is set to true. Each = element defines a pattern for constructing admissible resource = names. It is of type xsd:string and interpreted as a regular expression = according to "POSIX Extended Regular Expression" (see the specifications = in [IEEE-Posix]). >>>>=20 >>>> NEW >>>> A RELOAD overlay can be configured to accept store requests for any = AOR, or to apply domain name restrictions. To apply restrictions, the = overlay configuration document needs to contain a = element. The element serves as a container for = zero to multiple sub-elements. A element MAY be = present if the "enable" attribute of its parent element is set to true. = Each element defines a pattern for constructing admissible = resource names. It is of type xsd:string and interpreted as a regular = expression according to "POSIX Extended Regular Expression" (see the = specifications in [IEEE-Posix]). Encoding of the domain name complies to = the restricted ASCII character set without character escaping as defined = in Section 19.1 of [RFC3261]. >>>>=20 >>>> Inclusion of a element in an overlay = configuration document is OPTIONAL. If the element is not included, the = default behavior is to accept any AOR. If the element is included and = the =93enable=94 attribute is not set, the overlay MUST only accept AORs = that match the domain name of the overlay. If the element is included = and the =93enable=94 attribute is set to true, the overlay MUST only = accept AORs that match patterns specified in the = element. >>>>=20 >>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name >>>>=20 >>>> In this example, any AOR will be accepted that is either of the = form @dht.example.com, or ends with the domain "my.name". >>>>=20 >>>> =3D Section 8.2.3 =3D >>>>=20 >>>> The attack described here seems trivial, and therefore it seems to = me that the way SIP usage of RELOAD has been specified here has a gaping = hole in it. Basically in any overlay that wants to allow registrations = from any domain, the only defense against calls being directed to the = wrong recipient is for users to bypass the overlay and do what they = would normally do when making a SIP call. Thus in this use case the only = thing achieved by using RELOAD is to create a giant vulnerability. >>>>=20 >>>> Did the WG consider this? What is the value of standardizing this = in this way, given this security issue? If the way that SIP usage was = specified was limited to overlays with domain restrictions, at least = this attack would be limited to bogus registrations of users within the = overlay domain(s). >>>>=20 >>>> =3D Section 8.2.4 =3D >>>>=20 >>>> (1) >>>> By "public" you mean "visible to all nodes in the overlay," = correct? >>>>=20 >>>> (2) >>>> "Methods of providing >>>> location and identity privacy are still being studied." >>>>=20 >>>> Is this true, specifically for P2PSIP? >>>>=20 >>>>=20 >>>> =3D=3D Nits =3D=3D >>>>=20 >>>> =3D Section 1 =3D >>>>=20 >>>> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation = And Discovery (RELOAD)/ >>>>=20 >>>> OLD >>>> Two opposite scenarios of deploying P2P SIP services are in the = focus of this document: A highly regulated environment of a "single = provider" that admits parties using AORs with domains from controlled = namespace(s), only, and an open, multi-party infrastructure that = liberally allows a registration and rendezvous for various or any domain = namespace. >>>>=20 >>>> NEW >>>> This RELOAD usage may be relevant in a variety of environments, = including a highly regulated environment of a "single provider" that = admits parties using AORs with domains from controlled namespace(s) = only, or an open, multi-party infrastructure that liberally allows a = registration and rendezvous for various or any domain namespace. >>>>=20 >>>> =3D Section 3.1 =3D >>>>=20 >>>> "RELOAD peers MAY store two kinds of SIP mappings=94 >>>>=20 >>>> I don=92t think you need the normative MAY there, =93can=94 would = work. >>>>=20 >>>> =3D Section 3.4 =3D >>>>=20 >>>> The second line of the example here needs to use .example as the = TLD, not .name. Please make the corresponding changes in the text. >>>>=20 >>>> =3D Section 5.1 =3D >>>>=20 >>>> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ >>>>=20 >>>> =3D Section 6 =3D >>>>=20 >>>> I don't think you need the normative MAY here. >>>>=20 >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>>=20 >>=20 >> --=20 >>=20 >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Tue Mar 8 19:04:12 2016 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 B545512D81C; Tue, 8 Mar 2016 19:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAaDjxfLNtJ7; Tue, 8 Mar 2016 19:04:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1194712DDAB; Tue, 8 Mar 2016 19:04:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFO80831; Wed, 09 Mar 2016 03:04:02 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Mar 2016 03:04:01 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Wed, 9 Mar 2016 11:03:57 +0800 From: "Songhaibin (A)" To: Alissa Cooper , "Alvaro Retana (aretana)" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHROE3xg1hbhCRGu0GftwreM9LEL57uSeMggAJp5wCAWO/agIAHTBxw Date: Wed, 9 Mar 2016 03:03:56 +0000 Message-ID: References: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F65DC7CEBnkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56DF92A3.0063, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b57b51ea44527d2a47ed345b83233b60 Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 03:04:10 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F65DC7CEBnkgeml513mbschi_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable And would Jari clear his DISCUSS based on the version 21? Best Regards! -Haibin From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Saturday, March 05, 2016 3:37 AM To: Alvaro Retana (aretana) Cc: Songhaibin (A); IESG; Roni Even; p2psip-chairs@ietf.org; draft-ietf-p2p= sip-diagnostics@ietf.org; p2psip@ietf.org; cjbc@it.uc3m.es Subject: Re: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (= with DISCUSS and COMMENT) Hi Alvaro, Are you able to clear based on the latest version? https://tools.ietf.org/h= tml/draft-ietf-p2psip-diagnostics-21 Thanks, Alissa On Jan 7, 2016, at 12:27 PM, Alvaro Retana (aretana) > wrote: On 1/6/16, 4:44 AM, "Songhaibin (A)" > wrote: Haibin: Hi! ... ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am balloting a DISCUSS because I am concerned that this document doesn't actually do what it set out to achieve. I would love it if during the discussion I was pointed to the places where RELOAD already solves the issues, but for now I wasn't able to find them. According to the text, both extensions are intended to collect information "along the path", and the Figures clearly depict what is intended to happen. However, I don't think that as specified (or at least as explained) the behavior is guaranteed. Specific points: 1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that an "overlay MAY be configured to use alternative routing algorithms=A9[or]=A9MAY be selected on a per-message basis". How is the symmetry enforced if other routing algorithms are used? Enforcing that the ping/trace messages use symmetric routing when other algorithms are in use won't necessarily help because the paths may be different. I think one important thing is that, the draft does not guarantee what it conveys must be the information that caused the previous failures, but with the retrieved information from the previous traversed nodes (with high probability, as it cannot guarantee the exact same path), a user or machine can analyze and infer what is the problem. Symmetric routing is achieved by the via list (whatever DHT routing algorithms are used), but response message could go through not exactly the same path as there still can be failures during that short period. 2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the response traverses the same peers as the request traversed, except in reverse order (symmetric routing) and possibly with extra nodes (loose routing)." In other words, even if symmetric routing is used, there is no guarantee that the same path will be followed by the response, unless the originator builds the Via List with strict details of all the nodes in the path -- maybe this is what is intended, but no explicit mention occurs in the document. I agree this should be mentioned in the document. Clarifying the caveats (like what we're discussing above, for example) is one of the ways to move forward with resolving my DISCUSS. However, I have to say that the clarifications, which basically point at no guarantees about the path (or its relevance), leave me very dissatisfied with a technical solution that is unreliable. :-( 3. In 4.3, what does "directly or via symmetric routing" mean? Is it directly connected? If so, then (for the text in 4.3) that would mean that C is adjacent to A, and even though it is the next hop after B, the path taken to reach C with the PathTrack request doesn't include B < the result is that the diagnostic information received from C may not be relevant relative to destination D. As each PathTrack request will contain the destination ID, which was the same destination ID as the previously failed message. So no matter how the PathTrack request arrives to C, C will have a look at that destination ID for the next step. My point above was the the path *to* C (from A) may not actually even go through B. In other words, even if the rest of the path (all the way to D) is congruent, the overall information is still not completely relevant. Are there implementations available? What has been the experience? The Shepherd's write-up didn't mention any, and the TBD codes make me think that maybe Experimental might be a better status for this document. In my memory, there was one several years ago, but not based on RELOAD. Given the clear inconsistency and the lack of experience, I want to suggest that Experimental status be considered. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In general, as others have mentioned, I think the text could be a lot clearer and not leave some concepts to interpretation. 1. In 4.2.1, the MessageExtension is defined with a Boolean of "critical", but the text (a paragraph later) says that this "extension is not critical". I may be missing some of the semantics, or there's an error somewhere. My understanding with RELOAD, if value of "critical" can be true or false, if it is critical, then every node must support the extension, if it is not critical, then it is optional to support it. As it explains in that section, "If a peer does not support the extension, they will simply ignore the diagnostic portion of the message..." I looked at the text again -- it is still confusing to me, but I noticed that Section 6.1. (Message Creation and Transmission) does say that "the sender MUST...[set] the value of critical to FALSE". Maybe using "Critical" (capital C) to describe the state (vs the use of the word as an adjective) would help. 2. In 4.3..the last paragraph reads: if "...succesive calls to PathTrack return different paths, the results should be discarded and the request resent, ensuring that the second request traverses the appropriate path". Path changes are a fact of life < the second request may just be reflecting the new path, so resending it in an attempt to find the "appropriate path" may be futile. At least in the previous two attempts, the path was "stable". 3. What is a "routing mode"? Section 4.3.1. (New RELOAD Request: PathTrack) talks about it when saying that the "PathTrack request can be routed directly or through the overlay based on the routing mode". Later Section 6.2. (Message Processing: Intermediate Peers) says that "processing this request according to the overlay specified routing mode from RELOAD protocol" -- I looked in RFC6940 for "routing mode", but didn't find anything. Note that it also looks to me like there's no place in the DiagnosticsRequest to indicate a mode.. This draft should add a reference to RFC 7263 for the routing mode. Ok. 4. Section 5.3. (dMFlags and Diagnostic Kind ID Types) defines an "UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the intermediate peer which receives the diagnostics message to the next hop peer for this message." How is that information derived? It can use the traceroute tool. 5. I think that the Reference to RFC5226 should be Normative. Accepted. I also agree with others that the title should probably be something around RELOAD Diagnostics, and that this work doesn't really update RFC6940, it extends it in independent ways. It seems we can achieve a consensus here that it extends RELOAD. What about the title "RELOAD Extension for P2P Overlay Diagnostics"? I am not opposed to that. Thanks! Alvaro. --_000_E33E01DFD5BEA24B9F3F18671078951F65DC7CEBnkgeml513mbschi_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

 = ;

And would = Jari clear his DISCUSS based on the version 21?

 = ;

Best Regards!

-Haibin

 = ;

From: Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Saturday, March 05, 2016 3:37 AM
To: Alvaro Retana (aretana)
Cc: Songhaibin (A); IESG; Roni Even; p2psip-chairs@ietf.org; draft-i= etf-p2psip-diagnostics@ietf.org; p2psip@ietf.org; cjbc@it.uc3m.es
Subject: Re: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostic= s-19: (with DISCUSS and COMMENT)

 

Hi Alvaro,

 

Are you able to clear based on = the latest version? https://tools.ietf.org/html/draft-ietf-p2psip-diagno= stics-21

 

Thanks,

Alissa

 

 

On Jan 7, 2016, at 12:27 PM, Al= varo Retana (aretana) <aretana@cisc= o.com> wrote:

 

On 1/6/16, 4:44 AM, "Songh= aibin (A)" <haibin.song@h= uawei.com> wrote:

Haibin:

Hi!

...




----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting a DISCUSS because I am concerned that this document
doesn't
actually do what it set out to achieve.  I would love it if during the=
discussion I
was pointed to the places where RELOAD already solves the issues, but
for now
I wasn't able to find them.

According to the text, both extensions are intended to collect
information
"along the path", and the Figures clearly depict what is intended= to
happen.
However, I don't think that as specified (or at least as explained) the
behavior is
guaranteed.  Specific points:

1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that an
"overlay MAY be configured to use alternative routing
algorithms=A9[or]=A9MAY be
selected on a per-message basis". How is the symmetry enforced if othe= r
routing algorithms are used?  Enforcing that the ping/trace messages u= se
symmetric routing when other algorithms are in use won't necessarily
help
because the paths may be different.


I think one important thing is that, the draft does not guarantee what it conveys must be the information that caused the previous failures, but
with the retrieved information from the previous traversed nodes (with
high probability, as it cannot guarantee the exact same path), a user or machine can analyze and infer what is the problem. Symmetric routing is
achieved by the via list (whatever DHT routing algorithms are used), but response message could go through not exactly the same path as there
still can be failures during that short period.



2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the respons= e
traverses the same peers as the request traversed, except in reverse
order
(symmetric routing) and possibly with extra nodes (loose routing)." In other words, even if symmetric routing is used, there is no
guarantee that
the same path will be followed by the response, unless the originator
builds the
Via List with strict details of all the nodes in the path -- maybe this
is what is
intended, but no explicit mention occurs in the document.=


I agree this should be mentioned in the document.


Clarifying the caveats (like what we're discussing above, for example) is one of the ways to move forward with resolving my DISCUSS.

However, I have to say that the clarifications, which basically point at no guarantees about the path (or its relevance), leave me very
dissatisfied with a technical solution that is unreliable. :-(





3. In 4.3, what does "directly or via symmetric routing" mean? Is= it
directly
connected? If so, then (for the text in 4.3) that would mean that C is
adjacent
to A, and even though it is the next hop after B, the path taken to
reach C with
the PathTrack request doesn't include B ‹ the result is that the
diagnostic
information received from C may not be relevant relative to destination
D.


As each PathTrack request will contain the destination ID, which was the same destination ID as the previously failed message. So no matter how
the PathTrack request arrives to C, C will have a look at that
destination ID for the next step.


My point above was the the path *to* C (from A) may not actually even go through B.  In other words, even if the rest of the path (all the way = to
D) is congruent, the overall information is still not completely relevant.<= br>





Are there implementations available?  What has been the experience? Th= e
Shepherd's write-up didn't mention any, and the TBD codes make me think
that
maybe Experimental might be a better status for this document.


In my memory, there was one several years ago, but not based on RELOAD.


Given the clear inconsistency and the lack of experience, I want to
suggest that Experimental status be considered.







----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general, as others have mentioned, I think the text could be a lot
clearer and
not leave some concepts to interpretation.

1. In 4.2.1, the MessageExtension is defined with a Boolean of
"critical", but
the text (a paragraph later) says that this "extension is not
critical". I may be
missing some of the semantics, or there's an error somewhere.


My understanding with RELOAD, if value of "critical" can be true = or
false, if it is critical, then every node must support the extension, if it is not critical, then it is optional to support it. As it explains in that section, "If a peer does not support the extension, they will sim= ply
ignore the diagnostic portion of the message..."


I looked at the text again -- it is still confusing to me, but I noticed that Section 6.1. (Message Creation and Transmission) does say that "t= he
sender MUST...[set] the value of critical to FALSE".  Maybe using=
"Critical" (capital C) to describe the state (vs the use of the w= ord as an
adjective) would help.





2. In 4.3..the last paragraph reads: if "...succesive calls to
PathTrack return
different paths, the results should be discarded and the request resent, ensuring that the second request traverses the appropriate path".
Path changes are a fact of life ‹ the second request may just be
reflecting the
new path, so resending it in an attempt to find the "appropriate path&= quot;
may be
futile.


At least in the previous two attempts, the path was "stable".


3. What is a "routing mode= "?  Section 4.3.1. (New RELOAD Request:
PathTrack) talks about it when saying that the "PathTrack request can = be
routed directly or through the overlay based on the routing mode".
Later
Section 6.2. (Message Processing: Intermediate Peers) says that
"processing
this request according to the overlay specified routing mode from RELOAD protocol" -- I looked in RFC6940 for "routing mode", but did= n't find
anything.
Note that it also looks to me like there's no place in the
DiagnosticsRequest to
indicate a mode..


This draft should add a reference to RFC 7263 for the routing mode.


Ok.




4. Section 5.3. (dMFlags and Di= agnostic Kind ID Types) defines an
"UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the
intermediate
peer which receives the diagnostics message to the next hop peer for
this
message."  How is that information derived?


It can use the traceroute tool.


= 5. I think that the Reference to RFC5226 should be Normative.


Accepted.



I also agree with others that the title should probably be something
around
RELOAD Diagnostics, and that this work doesn't really update RFC6940, it extends it in independent ways.


It seems we can achieve a consensus here that it extends RELOAD. What
about the title "RELOAD Extension for P2P Overlay Diagnostics"?

=
I am not opposed to that.

Thanks!

Alvaro.

 

--_000_E33E01DFD5BEA24B9F3F18671078951F65DC7CEBnkgeml513mbschi_-- From nobody Wed Mar 9 03:10:04 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41B12D6EC; Wed, 9 Mar 2016 03:10:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309111001.2167.40133.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 03:10:01 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-17.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 11:10:01 -0000 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 of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-17.txt Pages : 20 Date : 2016-03-09 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: https://tools.ietf.org/html/draft-ietf-p2psip-sip-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 9 03:51:56 2016 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 8DF0412DE0C for ; Wed, 9 Mar 2016 03:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOiMUHUYHd7S for ; Wed, 9 Mar 2016 03:51:48 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E019E12D642 for ; Wed, 9 Mar 2016 03:51:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.24,311,1454972400"; d="scan'208";a="37952843" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 09 Mar 2016 12:51:38 +0100 Received: from CAS03.mailcluster.haw-hamburg.de (2002:8d16:183e::8d16:183e) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 9 Mar 2016 12:51:38 +0100 Received: from [192.168.178.90] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.62) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 9 Mar 2016 12:51:37 +0100 To: References: <6b5b72685626449295d80c4f0f926412@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <56E00E45.3040103@haw-hamburg.de> Date: Wed, 9 Mar 2016 12:51:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <6b5b72685626449295d80c4f0f926412@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 11:51:51 -0000 Hi Alissa, all, many thanks for the review and sorry for my late reply. Please see inline On 15.01.2016 22:58, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. I have a number of comments and questions that need to be resolved before last call can be initiated. In particular, I have some security concerns about using this in an overlay that allows registrations for any domain. > Regarding the security concerns, please see below. > I’ve also included some nits below that should be resolved together with last call comments. > > > == Substantive comments and questions == > > = Section 3.2 = > > This section is underspecified and I’m not sure the references to RFC 2533 and RFC 2738 are the appropriate ones. I think what you need to specify here is that the contact_prefs will encode a media feature set comprised of SIP User Agent capabilities, as defined in RFC 3840 and registered in the SIP media feature tag registration tree (assuming that is what is intended). > Previous version had been the state of discussion from a long time ago. We've updated to follow RFC 3840, which was indeed intended. > It’s also confusing that you only mention whether sip.schemes is required or not without mentioning whether specifying any other capabilities is required or optional. > This is only a highlighting following a previous discussion on the list, where clarity was requested on how to distinguish SIP/SIPs. We've made this more explicit by the following text: In particular, a callee can indicate that it prefers contact via a particular SIP scheme - SIP or SIPS - by using one of the following contact_prefs attribute: (sip.schemes=SIP) (sip.schemes=SIPS) > = Section 3.3 = > > "Before issuing a Store request to the overlay, any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4)." > > Why is this SHOULD rather than MUST? > This only concerns the issuer of a request and the rationale behind being liberal is that there might be reasons why an issuer cannot validate the Resource Name (e.g., does not have resources, or no access to a current/consistent overlay configuration etc.). The storing node does have the obligation ("MUST") to verify the AOR. This could be changed, though, but from the perspective of consistency, the storing node is the one to take the final responsibility. > = Section 3.4 = > > (1) I note that this documents refers to a different version of the IEEE Posix spec than draft-ietf-p2psip-share. What’s the reason for the difference? > This I could not figure. I had several colleagues looking at the case, but all see identical Posix refs??? > (2) > I find the explanation of the expected behavior here hard to follow. I've suggested a re-write below. There also seems to be one case that is not specified, which is when the "enable" attribute is set to false. Text describing what should happen in that case needs to be added. > Thanks for the improvement, we replaced the text. Also, there is now a definition for the "enable" attribute is set to false: If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. > = Section 8.2.3 = > > The attack described here seems trivial, and therefore it seems to me that the way SIP usage of RELOAD has been specified here has a gaping hole in it. Basically in any overlay that wants to allow registrations from any domain, the only defense against calls being directed to the wrong recipient is for users to bypass the overlay and do what they would normally do when making a SIP call. Thus in this use case the only thing achieved by using RELOAD is to create a giant vulnerability. > > Did the WG consider this? What is the value of standardizing this in this way, given this security issue? If the way that SIP usage was specified was limited to overlays with domain restrictions, at least this attack would be limited to bogus registrations of users within the overlay domain(s). > This security issue only arises, if the overlay *and* the enrollment service both do not impose restrictions. Normally, at least the enrollment server does not issue certificates for any username/AOR. We have clarified by referring to authorization at this point. Actually, this issue comes at no surprise: If we allow anybody to store any name, then the system is open to name hijacking. The concept of name restrictions and implications was discussed at a WG meeting and was considered deployment-dependent. There may be use cases that provide protection by other means. However, the default case of this spec is to restrict AORs to the current domain name *and* have the enrollment server authorize individual names. Still it is IMO good to be clear to the reader: If you open up the name registration, then you may face name hijacking. > = Section 8.2.4 = > > (1) > By "public" you mean "visible to all nodes in the overlay," correct? > Yes - reworded now. > (2) > "Methods of providing > location and identity privacy are still being studied." > > Is this true, specifically for P2PSIP? > For P2P overlays, I guess privacy is an active field. This would apply to P2PSIP, even if work is not explicitly dedicated to it. > > == Nits == > > = Section 1 = > > s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/ > Thanks, corrected. > OLD > Two opposite scenarios of deploying P2P SIP services are in the focus of this document: A highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s), only, and an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace. > > NEW > This RELOAD usage may be relevant in a variety of environments, including a highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s) only, or an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace. > Thanks, replaced. > = Section 3.1 = > > "RELOAD peers MAY store two kinds of SIP mappings” > > I don’t think you need the normative MAY there, “can” would work. > Thanks, fixed. > = Section 3.4 = > > The second line of the example here needs to use .example as the TLD, not .name. Please make the corresponding changes in the text. > Thanks, fixed. > = Section 5.1 = > > s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ > Fixed, thanks. > = Section 6 = > > I don't think you need the normative MAY here. > Also cleared. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Mar 17 05:48:14 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 615BF12D8EE; Thu, 17 Mar 2016 05:48:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317124811.12476.96497.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 05:48:11 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-concepts@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-concepts-08: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 12:48:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-p2psip-concepts-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for sticking with it! A document such as this could be useful, given the complexity of RELOAD. From nobody Thu Mar 17 06:55:57 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B812DE71; Tue, 15 Mar 2016 20:32:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316033214.7274.27398.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 20:32:14 -0700 Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 06:55:55 -0700 Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-concepts@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Ben Campbell's Yes on draft-ietf-p2psip-concepts-08: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 16 Mar 2016 03:32:14 -0000 Ben Campbell has entered the following ballot position for draft-ietf-p2psip-concepts-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for doing this. I wish more of our protocols had high-level concept descriptions like this. - 1, first paragraph: I was slightly surprised not to see the word "rendezvous" turn up here. It's not critical, but it's a term that has meaning to a lot of "conventional SIP " people. - 2.2, last paragraph: While I assume the client in the first sentence is the conventional SIP client mentioned further down the paragraph, the initial paragraph structure led me to expect you to call the special peer offering the SIP registrar service a "client". - 2.5, first paragraph: consider expanding "zeroconf" to "zero configuration" -6: I’m not going to push the matter this late in the process, but there might have been an opportunity to describe the security concepts of p2psip at a similar level of detail. From nobody Sat Mar 19 04:31:15 2016 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 A93CB12D739 for ; Sat, 19 Mar 2016 04:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=U1+o1/vY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JErrW3oK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiM0xMUK2NpN for ; Sat, 19 Mar 2016 04:31:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E698612D539 for ; Sat, 19 Mar 2016 04:31:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 585B720285 for ; Sat, 19 Mar 2016 07:31:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 19 Mar 2016 07:31:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=IjC2J5U0+aEOrJ8NvFhlI0f9Euc=; b=U1+o1/ vYbEbCcLLak8Y+Joh4zhPUq74UW5oc8PT8rfK/aLzmZur3VyXVljWzNPHCaE115u PnQwOZ1qDCv5jyeZZ9HtlpUAdZq++SMgNKvO6DnvJHmHANtvsTBbxuO9SitBjMIn Vi4XWGICdYe147lDQj+W1EV5eGUw1fnk1DrFY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=IjC2J5U0+aEOrJ8 NvFhlI0f9Euc=; b=JErrW3oKp9O3KWLBWpzfqGyZl4S/teGcRKM0X5PWnaoL+81 qil7aCixuXnLRJxDd1mjiXF0symwwy87LGt7SqYmSzSSg/qmgKKVdybnPGEG1VT2 Yo3OsY8+40RMHWMKKcCG/rnA/mGMOlMLLSRLoWM6DV6GZX+HnZHqUKWSWpr0= X-Sasl-enc: NI0pkVaaG8bsUfSYzV2gicHReoCDpKt3YP0X/QNs8Hkv 1458387070 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 3FFE8C00014; Sat, 19 Mar 2016 07:31:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Sat, 19 Mar 2016 04:31:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2AABBDFD-EC74-4999-A337-3439F663BF8C@cooperw.in> References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> <11E81FFA-7187-43B4-BA99-40859D835FDD@piuha.net> <78ECC973-EF0E-40F1-8C26-F060F033563E@isode.com> To: Jari Arkko X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , Alexey Melnikov , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Mar 2016 11:31:13 -0000 Jari, Are you able to clear now that these changes have been made? Thanks, Alissa > On Jan 29, 2016, at 10:46 PM, Songhaibin (A) = wrote: >=20 > Dear Alexey and Jari, >=20 > Accept the text what Jari suggested. And now it is clear. >=20 > BR, > -Haibin Song >=20 >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Thursday, January 07, 2016 6:36 PM >> To: Jari Arkko; Songhaibin (A) >> Cc: The IESG; p2psip-chairs@ietf.org; = draft-ietf-p2psip-diagnostics@ietf.org; >> p2psip@ietf.org >> Subject: Re: [P2PSIP] Jari Arkko's Discuss on = draft-ietf-p2psip-diagnostics-19: >> (with DISCUSS) >>=20 >> Hi, >>=20 >>> On 7 Jan 2016, at 00:34, Jari Arkko wrote: >>>=20 >>>=20 >>>> In Section 5.3, it says "The dMFlags field described above is a 64 = bit field >> that allows initiator nodes to identify up to 62 items of base = information to >> request in a request message (the first and last flags being = reserved)." 62 bits >> can be used to indicate up to 62 diagnostic Kinds, but dMFlags = reserves all "0"s >> that means nothing is requested, and all "1"s that means everything = is >> requested. But at the same time, the first and last bits cannot be = used for >> other purposes. >>>=20 >>> Right. Can that be explained somewhere, and can Section 9.1 show the >>> two aspects? That is, the all 0s/1s *and* first and last bits being >>> reserved? The current text does not reserve the first and last bits. >>> It only reserves the all 0s and all 1s... >>=20 >> I thought the same. >>>=20 >>> = +-------------------------+------------------------------+----------+ >>> | diagnostic information |diagnostic flag in dMFlags | RFC = | >>> = |-------------------------+------------------------------+----------| >>> |Reserved | 0x 0000 0000 0000 0000 >> |RFC-[TBDX]| >>> |STATUS_INFO | 0x 0000 0000 0000 0001 >> |RFC-[TBDX]| >>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 >> |RFC-[TBDX]| >>> |PROCESS_POWER | 0x 0000 0000 0000 0004 >> |RFC-[TBDX]| >>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 >> |RFC-[TBDX]| >>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 >> |RFC-[TBDX]| >>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 >> |RFC-[TBDX]| >>> |MACHINE_UPTIME | 0x 0000 0000 0000 0040 >> |RFC-[TBDX]| >>> |APP_UPTIME | 0x 0000 0000 0000 0080 >> |RFC-[TBDX]| >>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 >> |RFC-[TBDX]| >>> |DATASIZE_STORED | 0x 0000 0000 0000 0200 >> |RFC-[TBDX]| >>> |INSTANCES_STORED | 0x 0000 0000 0000 0400 >> |RFC-[TBDX]| >>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 >> |RFC-[TBDX]| >>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 >> |RFC-[TBDX]| >>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 >> |RFC-[TBDX]| >>> |UNDERLAY_HOP | 0x 0000 0000 0000 4000 >> |RFC-[TBDX]| >>> |BATTERY_STATUS | 0x 0000 0000 0000 8000 >> |RFC-[TBDX]| >>> |Reserved | 0x FFFF FFFF FFFF FFFF >> |RFC-[TBDX]| >>> +-------------------------+------------------------------+----+ >>>=20 >>> But maybe I'm missing something. >>>=20 >>> I thought the text above should be something like this instead: >>=20 >> Exactly my point. If what Jari suggests is not true, then the text = needs even >> more work. >>>=20 >>> = +-------------------------+------------------------------+----------+ >>> | diagnostic information |diagnostic flag in dMFlags | RFC = | >>> = |-------------------------+------------------------------+----------| >>> |Reserved All 0s value | 0x 0000 0000 0000 0000 >> |RFC-[TBDX]| >>> |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| >>> |STATUS_INFO | 0x 0000 0000 0000 0002 >> |RFC-[TBDX]| >>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 >> |RFC-[TBDX]| >>> |PROCESS_POWER | 0x 0000 0000 0000 0008 >> |RFC-[TBDX]| >>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 >> |RFC-[TBDX]| >>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 >> |RFC-[TBDX]| >>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 >> |RFC-[TBDX]| >>> |MACHINE_UPTIME | 0x 0000 0000 0000 0080 >> |RFC-[TBDX]| >>> |APP_UPTIME | 0x 0000 0000 0000 0100 >> |RFC-[TBDX]| >>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 >> |RFC-[TBDX]| >>> |DATASIZE_STORED | 0x 0000 0000 0000 0400 >> |RFC-[TBDX]| >>> |INSTANCES_STORED | 0x 0000 0000 0000 0800 >> |RFC-[TBDX]| >>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 >> |RFC-[TBDX]| >>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 >> |RFC-[TBDX]| >>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 >> |RFC-[TBDX]| >>> |UNDERLAY_HOP | 0x 0000 0000 0000 8000 >> |RFC-[TBDX]| >>> |BATTERY_STATUS | 0x 0000 0000 0001 0000 >> |RFC-[TBDX]| >>> |Reserved Last Bit | 0x 8000 0000 0000 0000 >> |RFC-[TBDX]| >>> |Reserved All 1s Value | 0x FFFF FFFF FFFF FFFF >> |RFC-[TBDX]| >>> +-------------------------+------------------------------+----+ >>>=20 >>>>=20 >>>>>=20 >>>>> Also, Section 5.3 uses "delimited" when it probably should have = said >>>>> "terminated", unless there's more substructure in the >>>>> SOFTWARE_VERSION string than is identified by the text. >>>>=20 >>>> It is the language problem and accepted. >>>=20 >>> Thanks! >>>=20 >>> Jari >>>=20 >=20 From nobody Sat Mar 19 15:25:41 2016 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 09C2112D586; Sat, 19 Mar 2016 15:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi0C_d4Vs5ZE; Sat, 19 Mar 2016 15:25:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C512D52A; Sat, 19 Mar 2016 15:25:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CB162CCBF; Sun, 20 Mar 2016 00:25:33 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rGI2hwXuzUL; Sun, 20 Mar 2016 00:25:32 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 556872CC9A; Sun, 20 Mar 2016 00:25:32 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D41F1FA7-FD3E-4642-9425-C820DC0D254E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: <9CE619D9-1996-42CB-A8E4-78A86BC3A234@fastmail.fm> Date: Sun, 20 Mar 2016 00:25:30 +0200 Message-Id: <6874FFA6-1829-4302-81EB-ADA235DE4FD4@piuha.net> References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> <11E81FFA-7187-43B4-BA99-40859D835FDD@piuha.net> <78ECC973-EF0E-40F1-8C26-F060F033563E@isode.com> <2AABBDFD-EC74-4999-A337-3439F663BF8C@cooperw.in> <9CE619D9-1996-42CB-A8E4-78A86BC3A234@fastmail.fm> To: Alexey Melnikov X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , Alexey Melnikov , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Mar 2016 22:25:38 -0000 --Apple-Mail=_D41F1FA7-FD3E-4642-9425-C820DC0D254E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alexey is correct. That=92s still a bug, and one that has to be fixed. I=92ll leave it to you Alissa to shepherd this however, I have cleared. Jari On 19 Mar 2016, at 21:36, Alexey Melnikov = wrote: > Alissa, >=20 >> On 19 Mar 2016, at 11:31, Alissa Cooper wrote: >>=20 >> Jari, >>=20 >> Are you able to clear now that these changes have been made? >=20 > The draft has improved, however Section 9.1 still seems incorrect: if = the first bit is reserved, then the first allocated value must be 2, so = all other allocated values should be shifted by 1 bit. >=20 >>=20 >> Thanks, >> Alissa >>=20 >>> On Jan 29, 2016, at 10:46 PM, Songhaibin (A) = wrote: >>>=20 >>> Dear Alexey and Jari, >>>=20 >>> Accept the text what Jari suggested. And now it is clear. >>>=20 >>> BR, >>> -Haibin Song >>>=20 >>>> -----Original Message----- >>>> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >>>> Sent: Thursday, January 07, 2016 6:36 PM >>>> To: Jari Arkko; Songhaibin (A) >>>> Cc: The IESG; p2psip-chairs@ietf.org; = draft-ietf-p2psip-diagnostics@ietf.org; >>>> p2psip@ietf.org >>>> Subject: Re: [P2PSIP] Jari Arkko's Discuss on = draft-ietf-p2psip-diagnostics-19: >>>> (with DISCUSS) >>>>=20 >>>> Hi, >>>>=20 >>>>> On 7 Jan 2016, at 00:34, Jari Arkko wrote: >>>>>=20 >>>>>=20 >>>>>> In Section 5.3, it says "The dMFlags field described above is a = 64 bit field >>>> that allows initiator nodes to identify up to 62 items of base = information to >>>> request in a request message (the first and last flags being = reserved)." 62 bits >>>> can be used to indicate up to 62 diagnostic Kinds, but dMFlags = reserves all "0"s >>>> that means nothing is requested, and all "1"s that means everything = is >>>> requested. But at the same time, the first and last bits cannot be = used for >>>> other purposes. >>>>>=20 >>>>> Right. Can that be explained somewhere, and can Section 9.1 show = the >>>>> two aspects? That is, the all 0s/1s *and* first and last bits = being >>>>> reserved? The current text does not reserve the first and last = bits. >>>>> It only reserves the all 0s and all 1s... >>>>=20 >>>> I thought the same. >>>>>=20 >>>>> = +-------------------------+------------------------------+----------+ >>>>> | diagnostic information |diagnostic flag in dMFlags | RFC = | >>>>> = |-------------------------+------------------------------+----------| >>>>> |Reserved | 0x 0000 0000 0000 0000 >>>> |RFC-[TBDX]| >>>>> |STATUS_INFO | 0x 0000 0000 0000 0001 >>>> |RFC-[TBDX]| >>>>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 >>>> |RFC-[TBDX]| >>>>> |PROCESS_POWER | 0x 0000 0000 0000 0004 >>>> |RFC-[TBDX]| >>>>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 >>>> |RFC-[TBDX]| >>>>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 >>>> |RFC-[TBDX]| >>>>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 >>>> |RFC-[TBDX]| >>>>> |MACHINE_UPTIME | 0x 0000 0000 0000 0040 >>>> |RFC-[TBDX]| >>>>> |APP_UPTIME | 0x 0000 0000 0000 0080 >>>> |RFC-[TBDX]| >>>>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 >>>> |RFC-[TBDX]| >>>>> |DATASIZE_STORED | 0x 0000 0000 0000 0200 >>>> |RFC-[TBDX]| >>>>> |INSTANCES_STORED | 0x 0000 0000 0000 0400 >>>> |RFC-[TBDX]| >>>>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 >>>> |RFC-[TBDX]| >>>>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 >>>> |RFC-[TBDX]| >>>>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 >>>> |RFC-[TBDX]| >>>>> |UNDERLAY_HOP | 0x 0000 0000 0000 4000 >>>> |RFC-[TBDX]| >>>>> |BATTERY_STATUS | 0x 0000 0000 0000 8000 >>>> |RFC-[TBDX]| >>>>> |Reserved | 0x FFFF FFFF FFFF FFFF >>>> |RFC-[TBDX]| >>>>> +-------------------------+------------------------------+----+ >>>>>=20 >>>>> But maybe I'm missing something. >>>>>=20 >>>>> I thought the text above should be something like this instead: >>>>=20 >>>> Exactly my point. If what Jari suggests is not true, then the text = needs even >>>> more work. >>>>>=20 >>>>> = +-------------------------+------------------------------+----------+ >>>>> | diagnostic information |diagnostic flag in dMFlags | RFC = | >>>>> = |-------------------------+------------------------------+----------| >>>>> |Reserved All 0s value | 0x 0000 0000 0000 0000 >>>> |RFC-[TBDX]| >>>>> |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| >>>>> |STATUS_INFO | 0x 0000 0000 0000 0002 >>>> |RFC-[TBDX]| >>>>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 >>>> |RFC-[TBDX]| >>>>> |PROCESS_POWER | 0x 0000 0000 0000 0008 >>>> |RFC-[TBDX]| >>>>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 >>>> |RFC-[TBDX]| >>>>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 >>>> |RFC-[TBDX]| >>>>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 >>>> |RFC-[TBDX]| >>>>> |MACHINE_UPTIME | 0x 0000 0000 0000 0080 >>>> |RFC-[TBDX]| >>>>> |APP_UPTIME | 0x 0000 0000 0000 0100 >>>> |RFC-[TBDX]| >>>>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 >>>> |RFC-[TBDX]| >>>>> |DATASIZE_STORED | 0x 0000 0000 0000 0400 >>>> |RFC-[TBDX]| >>>>> |INSTANCES_STORED | 0x 0000 0000 0000 0800 >>>> |RFC-[TBDX]| >>>>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 >>>> |RFC-[TBDX]| >>>>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 >>>> |RFC-[TBDX]| >>>>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 >>>> |RFC-[TBDX]| >>>>> |UNDERLAY_HOP | 0x 0000 0000 0000 8000 >>>> |RFC-[TBDX]| >>>>> |BATTERY_STATUS | 0x 0000 0000 0001 0000 >>>> |RFC-[TBDX]| >>>>> |Reserved Last Bit | 0x 8000 0000 0000 0000 >>>> |RFC-[TBDX]| >>>>> |Reserved All 1s Value | 0x FFFF FFFF FFFF FFFF >>>> |RFC-[TBDX]| >>>>> +-------------------------+------------------------------+----+ >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Also, Section 5.3 uses "delimited" when it probably should have = said >>>>>>> "terminated", unless there's more substructure in the >>>>>>> SOFTWARE_VERSION string than is identified by the text. >>>>>>=20 >>>>>> It is the language problem and accepted. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Jari >>=20 --Apple-Mail=_D41F1FA7-FD3E-4642-9425-C820DC0D254E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW7dHaAAoJEM80gCTQU46qomYP/3+qQIj7/UP8tkSLXu1iey9J fsqTwcxPrPvJHVq4/Zp1BqVKQuZnJyt2T4LXIk4pwzc2XlZMxa9BxguQiWj1ls4/ 5uhbP4hRtCJXwBFGWrC5t3CCj1YvvLuAi+OH+FCl8qBNxzV4q3F4yfvhRlhMsa7W J9LX3Jw6ZHR6597Z3G+ORngIeviAF1twIa64EqyuT6fiJ4W1eHpFCoy+X6gX8e0x oQ+tdJiIjehO5XmbNSOCJ5xy5wWrSW7XEUSeBWT6htB/Okph+qFL03TvkxOV6VoY TtWYSIqrnidGxQTeMyV9EMikBCFxtA6Bq1Rj9B/sx1mtXxR06uTA7XuwXu7qOqas 5PpIoEyYELTR1JZvEl3oCErY7KZmLSHleZvRFty50+kU9ubKvXOpUbWGcTl1iG8S arNFoLWvajfsZc7GDwFP9xNKdt1wBeQ4D9O8v1NZfcsFM/ksVaUl1016oHnPJQAk HWPQqprpvjBDf92eYIwGeOzGhexvhF38ensj9taRkz5Ms/PrYM5NL1JRLlbA3KQB b840EFvtJFU6mGGLLmT5RL5/Yt3+lJ5amxcg8gumjlv5W6ErGXbMgku4LBUQokmE 093t6NGk6CsdwXd/owO9TunHonSBg9w1GEAzMwPUhtQa2o0zuc5tKgvebI50uXHI iULmCSouphvP0ar3m97D =V/Ai -----END PGP SIGNATURE----- --Apple-Mail=_D41F1FA7-FD3E-4642-9425-C820DC0D254E-- From nobody Sat Mar 19 15:28:06 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B036912D586; Sat, 19 Mar 2016 15:28:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160319222805.15018.68420.idtracker@ietfa.amsl.com> Date: Sat, 19 Mar 2016 15:28:05 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-diagnostics@ietf.org, p2psip@ietf.org, alexey.melnikov@isode.com Subject: [P2PSIP] Jari Arkko's No Objection on draft-ietf-p2psip-diagnostics-21: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Mar 2016 22:28:05 -0000 Jari Arkko has entered the following ballot position for draft-ietf-p2psip-diagnostics-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for improving the IANA considerations section! However, Section 9.1 still has a bug that IMHO needs to be corrected. The reserved values need to be shifted in value by one, because now you have two with the value 1. As Alexey said: "The draft has improved, however Section 9.1 still seems incorrect: if the first bit is reserved, then the first allocated value must be 2, so all other allocated values should be shifted by 1 bit." However, I have cleared so that the shepherding AD and the WG can take care of this. Please make sure you fix this though, as my understanding is that if you didn't make the change, the protocol would not work as you intended it to work. From nobody Sun Mar 20 16:38:49 2016 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 9C8D812D58A for ; Sun, 20 Mar 2016 16:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uj7KWzjhXmc for ; Sun, 20 Mar 2016 16:38:45 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F46312D555 for ; Sun, 20 Mar 2016 16:38:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,368,1454972400"; d="scan'208";a="38237767" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 21 Mar 2016 00:38:42 +0100 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 21 Mar 2016 00:38:42 +0100 Received: from [192.168.178.90] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 21 Mar 2016 00:38:41 +0100 To: Alissa Cooper , P2PSIP WG References: From: "Thomas C. Schmidt" Message-ID: <56EF3475.2040009@haw-hamburg.de> Date: Mon, 21 Mar 2016 00:38:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Mar 2016 23:38:47 -0000 Hi Alissa, many thanks for the careful review. We have revised and resubmitted the document accordingly. For the details, please see our comments inline. On 15.01.2016 00:03, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. I have > a number of comments and questions that need to be resolved before last > call can be initiated. I’ve also included some nits below that should be > resolved together with last call comments. > > Given the nature of this document, I’d like for the shepherd to request > an early SECDIR review after the comments below have been resolved so > that the authors and WG can receive security feedback before the > document progresses to IESG evaluation. > I assume this needs to be initiated by Marc (Petit-Huguenin) right away? > > == Substantive comments and questions == > > = Section 3.1 = > > I think this section requires clarification. > > How is the index value supposed to be initialized? Is it supposed to be > chosen at random or set to 0 (or 1, as in the figure)? > It is now clarified that the (8 bit individual) index is under sole control of the writing peer. The peer is free to use these bits according to application needs. No interoperability issue, as the key only requires uniqueness, no further semantic attached to it. > I don’t understand how this mechanism relates to how SSRCs are chosen. > In fact RFC 3550 doesn’t specify a particular algorithm to use, but > merely provides one example. The mechanism to build the keys is now more explicitly stated. The pointer to RFC 3550 refers only to a method for calculating the collision probability, no reference to assignment algorithms. >Furthermore, I don’t see how the collision > probably for the array index value, which selects the least significant > three bytes from a cryptographically random Node-Id that must be 16 > bytes or longer, would be the same as for a randomly chosen 32-bit > integer. Could you explain? > The formula presented in RFC 3550 has a length parameter (L) and we added that L=24 must be chosen in the present case. Otherwise, the argument is that the selected 24 bits from a (cryptographically random) Node-Id also form uniform pseudo-random numbers, since the selection mechanism does not produce a bias. > = Section 5 = > > Are variable resource names expected to be UTF-8 strings? I think > somewhere in this section the internationalization expectations for > these strings need to be specified. > Resource names correspond to regular Reload resource names, thus opaque (ASCII-encoded) strings of variable length up to 254 bytes. We are not touching this here. > = Section 5.3 = > > (1) > I think this section needs to specify normative requirements on the > pattern construction to avoid duplicative or substring names as > described in 5.1 > Yes, we've included "variable parts in elements defined in the overlay configuration document MUST remain syntactically separated from the user name part (e.g., by a dedicated delimiter) to prevent collisions with other names of other users." > (2) > "Configurations in this overlay document MUST adhere in syntax and > semantic of names as defined by the context of use. For example, syntax > restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a more > general naming is feasible in plain RELOAD." > > I don’t understand what the normative requirement is here or why it is > needed. How is “the context of use” defined? Shouldn’t it be up to the > specific protocol documents to define the required syntax and semantics > for specific usages (e.g., the way draft-ietf-p2psip-sip does)? > Right, this was misleading. We changed to "It is noteworthy that additional constraints on the syntax and semantic of names can apply according to specific Usages." > (3) > "In the absence of a element for a Kind using > the USER-CHAIN-ACL access policy (see Section 6.6 > ), > implementors SHOULD assume this default value." > > Why is this SHOULD and not MUST? Shouldn’t implementations > conservatively assume that variable names are not allowed unless > explicitly specified? > We agree - changed to MUST. > (4) > "If no pattern is defined for a Kind or the "enable" attribute is false, > allowable Resource Names are restricted to the username of the signer > for Shared Resource.” > > I think this needs to account for an error condition where the pattern > does not meet the pattern construction requirements, e.g.: > > ""If no pattern is defined for a Kind, if the "enable" attribute is > false, or if the regular expression does not meet the requirements > specified in this section, the allowable Resource Names are restricted > to the username of the signer for Shared Resource.” > Thanks, we forgot this - changed now. > = Section 6.2 = > > For privacy reasons, wouldn’t it be better to overwrite every entry in a > subtree when the root of the subtree gets overwritten? Otherwise the > list of users who were given write access may remain long after their > access has been revoked. > Yes in general, but there are two constraints. (a) Only the Resource Owner can overwrite all entries of a subtree (entries of which may have different owners). Periodic checks of the Owner may produce an unwanted extra load. (b) There may be use cases, where a subtree shall be temporarily invalidated, but reactivated later (e.g., some behavioral monitoring puts some peer under suspect, but later releases this). For these reasons, we argue for a "SHOULD" here: "To protect the privacy of the users, the Resource Owner SHOULD overwrite all subtrees that have been invalidated." > = Section 6.3 = > > How strings are to be compared (e.g., as binary objects or whatever it > is) needs to be normatively specified. > Yes, comparing binary objects is added, now. > It is confusing to use normative language only in step 5 here. I would > suggest either normatively defining each action or not using SHALL here. > Yes, agreed and changed to: "This final ACL item is expected to be the root item of this ACL which MUST be further validated by verifying that the root item was signed by the owner of the ACL Resource." > = Section 6.6 = > > "Otherwise, the value MUST be written if the certificate of the signer > contains a username that matches to one of the variable resource name > pattern (c.f. Section 5 > ) > specified in the configuration document" > > It seems to me that matching the pattern is not sufficient — isn’t it > the case that both the user and domain portions of the user name in the > certificate need to match the user and domain name portions present in > the resource name? Yes, this is made clearer now: "contains a username that matches to the user and domain portion in one of the variable resource name patterns" >In general, the document seems to be missing > discussion of the implications of having the user name and the resource > name diverge. I think this affects every operation that involves > comparing the two (or the Resource-Id, right?). > The logic is as follows: Store if (a) a regular USER-MATCH or USER-NODE-MATCH works (we are regular owner), or if (b) a variable resource name is successfully authenticated (we are owner using variable naming - this includes matching of username *and* resource name), or if (c) ACL authorization is in effect (we harvest trust delegation) for this resource. Otherwise, the store request must be denied, which we added explicitly, now. > I’m also unclear about why policy for allowing access to shared > resources is being strictly coupled with policy for allowing variable > resource names. Might there be cases where it makes sense to authorize > one but not the other? > I don't see the strict coupling, here: First the check is done to store based on USER-MATCH or USER-NODE-MATCH, which do not work with variable resource names, then ... It is rather that USER-CHAIN-ACL grants storing rights in both cases, variable naming and trust delegation. This makes IMO sense, as it abstracts from the strict naming authorities of USER-MATCH or USER-NODE-MATCH. > = Section 8.2 = > > This section misses the threat of a misbehaving peer who is delegated > write access — that seems like an important case to cover. > O.K., we added a subsection on that. > = Section 8.3 = > > By “publicly readable” do you mean “readable by any node in the > overlay”? Admission to the overlay would still be access controlled, > correct? > Yes, of course. We clarified. > = Section 9.2 = > > What is the significance of 17, other than that it is in the unassigned > range? > None, I guess it was just free. We changed to 'TBD'. > > == Nits == > > = Section 1 = > > The reference to I-D.ietf-p2psip-disco should be removed given that the > document is several years old and not expected to advance as far as I know. > Yup, this document died with the working group. > s/from one authorized to another (previously unauthorized) user/from one > authorized user to another (previously unauthorized) user/ > Thanks, fixed. > = Section 2 = > > s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts > ]/[I-D.ietf-p2psip-concepts > ]/ > Thanks, fixed. > = Section 3.1 = > > s/Append an 8 bit long short individual index value/Append an 8-bit > individual index value/ > O.K., done. > = Section 4.1 = > > s/an Access Control including/an Access Control List including/ > Thanks, done. > = Section 5.1 = > > Same comment about I-D.ietf-p2psip-disco > as > in Section 1. > Done. Thanks, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Sun Mar 20 16:47:25 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D812D63A; Sun, 20 Mar 2016 16:47:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320234721.8950.79271.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 16:47:21 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:47:22 -0000 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 of the IETF. Title : A Usage for Shared Resources in RELOAD (ShaRe) Authors : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-08.txt Pages : 20 Date : 2016-03-20 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-share-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 20 18:03:47 2016 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 04E2412D7FB; Sun, 20 Mar 2016 18:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjV5lff7DiBu; Sun, 20 Mar 2016 18:03:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D6612D522; Sun, 20 Mar 2016 18:03:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLA63528; Mon, 21 Mar 2016 01:03:33 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Mar 2016 01:03:32 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Mon, 21 Mar 2016 09:03:26 +0800 From: "Songhaibin (A)" To: Jari Arkko , The IESG Thread-Topic: Jari Arkko's No Objection on draft-ietf-p2psip-diagnostics-21: (with COMMENT) Thread-Index: AQHRgi6hJ4wRO2ehzE+4M89sweQo559jFkiw Date: Mon, 21 Mar 2016 01:03:26 +0000 Message-ID: References: <20160319222805.15018.68420.idtracker@ietfa.amsl.com> In-Reply-To: <20160319222805.15018.68420.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56EF4866.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c3fb951a6b64c5f919522befa4483482 Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" , "alexey.melnikov@isode.com" Subject: Re: [P2PSIP] Jari Arkko's No Objection on draft-ietf-p2psip-diagnostics-21: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 01:03:39 -0000 WWVzLiBUaGF0J3MgYSBidWcuIEkgd2lsbCBmaXggaXQgYXMgQWxleGV5IHN1Z2dlc3RlZC4NCg0K QmVzdCBSZWdhcmRzIQ0KLUhhaWJpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEphcmkgQXJra28gW21haWx0bzpqYXJpLmFya2tvQHBpdWhhLm5ldF0NCj4gU2VudDog U3VuZGF5LCBNYXJjaCAyMCwgMjAxNiA2OjI4IEFNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZHJh ZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3NAaWV0Zi5vcmc7IHAycHNpcC1jaGFpcnNAaWV0Zi5v cmc7DQo+IGNqYmNAaXQudWMzbS5lczsgcDJwc2lwQGlldGYub3JnOyBhbGV4ZXkubWVsbmlrb3ZA aXNvZGUuY29tDQo+IFN1YmplY3Q6IEphcmkgQXJra28ncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMjE6ICh3aXRoDQo+IENPTU1FTlQpDQo+IA0KPiBKYXJp IEFya2tvIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBk cmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0yMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1w MnBzaXAtZGlhZ25vc3RpY3MvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmtzIGZvciBpbXByb3ZpbmcgdGhlIElBTkEg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiEgSG93ZXZlciwgU2VjdGlvbg0KPiA5LjEgc3RpbGwgaGFz IGEgYnVnIHRoYXQgSU1ITyBuZWVkcyB0byBiZSBjb3JyZWN0ZWQuIFRoZSByZXNlcnZlZCB2YWx1 ZXMgbmVlZA0KPiB0byBiZSBzaGlmdGVkIGluIHZhbHVlIGJ5IG9uZSwgYmVjYXVzZSBub3cgeW91 IGhhdmUgdHdvIHdpdGggdGhlIHZhbHVlIDEuDQo+IA0KPiBBcyBBbGV4ZXkgc2FpZDogIlRoZSBk cmFmdCBoYXMgaW1wcm92ZWQsIGhvd2V2ZXIgU2VjdGlvbiA5LjEgc3RpbGwgc2VlbXMNCj4gaW5j b3JyZWN0OiBpZiB0aGUgZmlyc3QgYml0IGlzIHJlc2VydmVkLCB0aGVuIHRoZSBmaXJzdCBhbGxv Y2F0ZWQgdmFsdWUgbXVzdCBiZSAyLCBzbw0KPiBhbGwgb3RoZXIgYWxsb2NhdGVkIHZhbHVlcyBz aG91bGQgYmUgc2hpZnRlZCBieSAxIGJpdC4iDQo+IA0KPiBIb3dldmVyLCBJIGhhdmUgY2xlYXJl ZCBzbyB0aGF0IHRoZSBzaGVwaGVyZGluZyBBRCBhbmQgdGhlIFdHIGNhbiB0YWtlIGNhcmUNCj4g b2YgdGhpcy4gUGxlYXNlIG1ha2Ugc3VyZSB5b3UgZml4IHRoaXMgdGhvdWdoLCBhcyBteSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgaWYgeW91DQo+IGRpZG4ndCBtYWtlIHRoZSBjaGFuZ2UsIHRoZSBw cm90b2NvbCB3b3VsZCBub3Qgd29yayBhcyB5b3UgaW50ZW5kZWQgaXQgdG8NCj4gd29yay4NCj4g DQoNCg== From nobody Tue Mar 22 09:06:16 2016 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 908F612D5EE for ; Sat, 19 Mar 2016 12:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Rhg0xSVN; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=q2Ohjouu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6XcGEZMtNXO for ; Sat, 19 Mar 2016 12:34:14 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B2612D5B9 for ; Sat, 19 Mar 2016 12:34:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B5C5220844 for ; Sat, 19 Mar 2016 15:34:13 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 19 Mar 2016 15:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=DHhb0jZFIq4sH6LBRZn6zTu2zWw=; b=Rhg0xS VNswFelKAciJD0upeVhuDSoUH3Ki1Rvld0/e3owtqzviqdPPIPvsLEXRwvdzx7H9 zAOHY36fMOtCqAGMt4LlKLIW6KyE3V5HK3N7/g0bNWuSH+vN/6GCN4XP3C51sHv6 9T7+657BPhIgMpaKU9XhQI02ahCOR4QV6HnQ4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=DHhb0jZFIq4sH6L BRZn6zTu2zWw=; b=q2OhjouuH3ybCYBRQ7b7WTa/32yfoBSlMO9ncrNX9ITyOtc st7shfTjuAQTXw6Ox7vml/gi9WVbgvhKuVWZ8Lxc4neeoU9PCB4R9uDqR+HulEDU 8/j+1v8jGiLLBmuaC88Hn4R8ThyigKvNsqpQWHUimuWGhWLtV8LTqyJs2DjY= X-Sasl-enc: wHSaO29ehsrhVQoXPt2nNx3HVKFOkeRqDHpPt7AewQEt 1458416053 Received: from [10.2.215.180] (unknown [212.183.128.226]) by mail.messagingengine.com (Postfix) with ESMTPA id 33C00C00013; Sat, 19 Mar 2016 15:34:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13D15) In-Reply-To: <2AABBDFD-EC74-4999-A337-3439F663BF8C@cooperw.in> Date: Sat, 19 Mar 2016 19:36:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9CE619D9-1996-42CB-A8E4-78A86BC3A234@fastmail.fm> References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> <11E81FFA-7187-43B4-BA99-40859D835FDD@piuha.net> <78ECC973-EF0E-40F1-8C26-F060F033563E@isode.com> <2AABBDFD-EC74-4999-A337-3439F663BF8C@cooperw.in> To: Alissa Cooper Archived-At: X-Mailman-Approved-At: Tue, 22 Mar 2016 09:06:14 -0700 Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , Jari Arkko , IESG , Alexey Melnikov , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Mar 2016 19:34:16 -0000 Alissa, > On 19 Mar 2016, at 11:31, Alissa Cooper wrote: >=20 > Jari, >=20 > Are you able to clear now that these changes have been made? The draft has improved, however Section 9.1 still seems incorrect: if the fi= rst bit is reserved, then the first allocated value must be 2, so all other a= llocated values should be shifted by 1 bit. >=20 > Thanks, > Alissa >=20 >> On Jan 29, 2016, at 10:46 PM, Songhaibin (A) wro= te: >>=20 >> Dear Alexey and Jari, >>=20 >> Accept the text what Jari suggested. And now it is clear. >>=20 >> BR, >> -Haibin Song >>=20 >>> -----Original Message----- >>> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >>> Sent: Thursday, January 07, 2016 6:36 PM >>> To: Jari Arkko; Songhaibin (A) >>> Cc: The IESG; p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf= .org; >>> p2psip@ietf.org >>> Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnost= ics-19: >>> (with DISCUSS) >>>=20 >>> Hi, >>>=20 >>>> On 7 Jan 2016, at 00:34, Jari Arkko wrote: >>>>=20 >>>>=20 >>>>> In Section 5.3, it says "The dMFlags field described above is a 64 bit= field >>> that allows initiator nodes to identify up to 62 items of base informati= on to >>> request in a request message (the first and last flags being reserved)."= 62 bits >>> can be used to indicate up to 62 diagnostic Kinds, but dMFlags reserves a= ll "0"s >>> that means nothing is requested, and all "1"s that means everything is >>> requested. But at the same time, the first and last bits cannot be used f= or >>> other purposes. >>>>=20 >>>> Right. Can that be explained somewhere, and can Section 9.1 show the >>>> two aspects? That is, the all 0s/1s *and* first and last bits being >>>> reserved? The current text does not reserve the first and last bits. >>>> It only reserves the all 0s and all 1s... >>>=20 >>> I thought the same. >>>>=20 >>>> +-------------------------+------------------------------+----------+ >>>> | diagnostic information |diagnostic flag in dMFlags | RFC | >>>> |-------------------------+------------------------------+----------| >>>> |Reserved | 0x 0000 0000 0000 0000 >>> |RFC-[TBDX]| >>>> |STATUS_INFO | 0x 0000 0000 0000 0001 >>> |RFC-[TBDX]| >>>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 >>> |RFC-[TBDX]| >>>> |PROCESS_POWER | 0x 0000 0000 0000 0004 >>> |RFC-[TBDX]| >>>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 >>> |RFC-[TBDX]| >>>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 >>> |RFC-[TBDX]| >>>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 >>> |RFC-[TBDX]| >>>> |MACHINE_UPTIME | 0x 0000 0000 0000 0040 >>> |RFC-[TBDX]| >>>> |APP_UPTIME | 0x 0000 0000 0000 0080 >>> |RFC-[TBDX]| >>>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 >>> |RFC-[TBDX]| >>>> |DATASIZE_STORED | 0x 0000 0000 0000 0200 >>> |RFC-[TBDX]| >>>> |INSTANCES_STORED | 0x 0000 0000 0000 0400 >>> |RFC-[TBDX]| >>>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 >>> |RFC-[TBDX]| >>>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 >>> |RFC-[TBDX]| >>>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 >>> |RFC-[TBDX]| >>>> |UNDERLAY_HOP | 0x 0000 0000 0000 4000 >>> |RFC-[TBDX]| >>>> |BATTERY_STATUS | 0x 0000 0000 0000 8000 >>> |RFC-[TBDX]| >>>> |Reserved | 0x FFFF FFFF FFFF FFFF >>> |RFC-[TBDX]| >>>> +-------------------------+------------------------------+----+ >>>>=20 >>>> But maybe I'm missing something. >>>>=20 >>>> I thought the text above should be something like this instead: >>>=20 >>> Exactly my point. If what Jari suggests is not true, then the text needs= even >>> more work. >>>>=20 >>>> +-------------------------+------------------------------+----------+ >>>> | diagnostic information |diagnostic flag in dMFlags | RFC | >>>> |-------------------------+------------------------------+----------| >>>> |Reserved All 0s value | 0x 0000 0000 0000 0000 >>> |RFC-[TBDX]| >>>> |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| >>>> |STATUS_INFO | 0x 0000 0000 0000 0002 >>> |RFC-[TBDX]| >>>> |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 >>> |RFC-[TBDX]| >>>> |PROCESS_POWER | 0x 0000 0000 0000 0008 >>> |RFC-[TBDX]| >>>> |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 >>> |RFC-[TBDX]| >>>> |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 >>> |RFC-[TBDX]| >>>> |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 >>> |RFC-[TBDX]| >>>> |MACHINE_UPTIME | 0x 0000 0000 0000 0080 >>> |RFC-[TBDX]| >>>> |APP_UPTIME | 0x 0000 0000 0000 0100 >>> |RFC-[TBDX]| >>>> |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 >>> |RFC-[TBDX]| >>>> |DATASIZE_STORED | 0x 0000 0000 0000 0400 >>> |RFC-[TBDX]| >>>> |INSTANCES_STORED | 0x 0000 0000 0000 0800 >>> |RFC-[TBDX]| >>>> |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 >>> |RFC-[TBDX]| >>>> |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 >>> |RFC-[TBDX]| >>>> |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 >>> |RFC-[TBDX]| >>>> |UNDERLAY_HOP | 0x 0000 0000 0000 8000 >>> |RFC-[TBDX]| >>>> |BATTERY_STATUS | 0x 0000 0000 0001 0000 >>> |RFC-[TBDX]| >>>> |Reserved Last Bit | 0x 8000 0000 0000 0000 >>> |RFC-[TBDX]| >>>> |Reserved All 1s Value | 0x FFFF FFFF FFFF FFFF >>> |RFC-[TBDX]| >>>> +-------------------------+------------------------------+----+ >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Also, Section 5.3 uses "delimited" when it probably should have said >>>>>> "terminated", unless there's more substructure in the >>>>>> SOFTWARE_VERSION string than is identified by the text. >>>>>=20 >>>>> It is the language problem and accepted. >>>>=20 >>>> Thanks! >>>>=20 >>>> Jari >=20 From nobody Wed Mar 23 13:21:22 2016 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 09F0112D80E for ; Wed, 23 Mar 2016 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=QkQVDWbS; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=NwPnKCVt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gm4p7ITOYx2 for ; Wed, 23 Mar 2016 13:21:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDED712D1B4 for ; Wed, 23 Mar 2016 13:21:16 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3759F20906 for ; Wed, 23 Mar 2016 16:21:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 23 Mar 2016 16:21:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=EbaX25nHV/hzu16kAXKHP0gvMtM=; b=QkQVDW bSP+aQohvNln5ggcfNJSoixf+ESYt5xgCI/DFdAKHkI514N5092tedMObbiUE0Ht SF2zD79J1wv/XJzqBKnP7dsL4HAMubNPid+k21k5531y9M4G2Q5Zhb5stRBLafHk BrAprJHbCm9m+78IX1BBXzfv3Aa7BRQ+FjxvE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=EbaX25nHV/hzu16 kAXKHP0gvMtM=; b=NwPnKCVtNVXsm/qI7gPafQaZdiMJt5ROC3IKuQExev+t7+d /nXkWuDJjfmjCEj9H3/IzCtTwnxeoyFW6sAvDpqby3HLO8RbEA4uaUALEjjJC5bx jkUgQZBaYOXgYacK21nB2XbUX5NMg3XaqQovlRuSYyF5kPJneTbD8csi/rkQ= X-Sasl-enc: qpS/xKwBx9+nhWMRqrlNAH4V2qUNSrNfgqexNSRm+7Yv 1458764475 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B073680230; Wed, 23 Mar 2016 16:21:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <56EF3475.2040009@haw-hamburg.de> Date: Wed, 23 Mar 2016 13:21:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <488F2FA5-D434-49F5-8A83-7B4C33423971@cooperw.in> References: <56EF3475.2040009@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 23 Mar 2016 20:21:20 -0000 Thanks, the changes look good and the explanations make sense. Marc = should go ahead and request the early secdir review by sending mail to = sector@ietf.org. Alissa > On Mar 20, 2016, at 4:38 PM, Thomas C. Schmidt = wrote: >=20 > Hi Alissa, >=20 > many thanks for the careful review. We have revised and resubmitted = the document accordingly. >=20 > For the details, please see our comments inline. >=20 > On 15.01.2016 00:03, Alissa Cooper wrote: >> I have reviewed this document in preparation for IETF last call. I = have >> a number of comments and questions that need to be resolved before = last >> call can be initiated. I=92ve also included some nits below that = should be >> resolved together with last call comments. >>=20 >> Given the nature of this document, I=92d like for the shepherd to = request >> an early SECDIR review after the comments below have been resolved so >> that the authors and WG can receive security feedback before the >> document progresses to IESG evaluation. >>=20 >=20 > I assume this needs to be initiated by Marc (Petit-Huguenin) right = away? >=20 >>=20 >> =3D=3D Substantive comments and questions =3D=3D >>=20 >> =3D Section 3.1 =3D >>=20 >> I think this section requires clarification. >>=20 >> How is the index value supposed to be initialized? Is it supposed to = be >> chosen at random or set to 0 (or 1, as in the figure)? >>=20 >=20 > It is now clarified that the (8 bit individual) index is under sole = control of the writing peer. The peer is free to use these bits = according to application needs. No interoperability issue, as the key = only requires uniqueness, no further semantic attached to it. >=20 >> I don=92t understand how this mechanism relates to how SSRCs are = chosen. >> In fact RFC 3550 doesn=92t specify a particular algorithm to use, but >> merely provides one example. >=20 > The mechanism to build the keys is now more explicitly stated. The = pointer to RFC 3550 refers only to a method for calculating the = collision probability, no reference to assignment algorithms. >=20 >> Furthermore, I don=92t see how the collision >> probably for the array index value, which selects the least = significant >> three bytes from a cryptographically random Node-Id that must be 16 >> bytes or longer, would be the same as for a randomly chosen 32-bit >> integer. Could you explain? >>=20 >=20 > The formula presented in RFC 3550 has a length parameter (L) and we = added that L=3D24 must be chosen in the present case. Otherwise, the = argument is that the selected 24 bits from a (cryptographically random) = Node-Id also form uniform pseudo-random numbers, since the selection = mechanism does not produce a bias. >=20 >> =3D Section 5 =3D >>=20 >> Are variable resource names expected to be UTF-8 strings? I think >> somewhere in this section the internationalization expectations for >> these strings need to be specified. >>=20 >=20 > Resource names correspond to regular Reload resource names, thus = opaque (ASCII-encoded) strings of variable length up to 254 bytes. We = are not touching this here. >=20 >> =3D Section 5.3 =3D >>=20 >> (1) >> I think this section needs to specify normative requirements on the >> pattern construction to avoid duplicative or substring names as >> described in 5.1 >>=20 >=20 > Yes, we've included >=20 > "variable parts in elements defined in the overlay = configuration document MUST remain syntactically separated from the user = name part (e.g., by a dedicated delimiter) to prevent collisions with = other names of other users." >=20 >> (2) >> "Configurations in this overlay document MUST adhere in syntax and >> semantic of names as defined by the context of use. For example, = syntax >> restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a = more >> general naming is feasible in plain RELOAD." >>=20 >> I don=92t understand what the normative requirement is here or why it = is >> needed. How is =93the context of use=94 defined? Shouldn=92t it be up = to the >> specific protocol documents to define the required syntax and = semantics >> for specific usages (e.g., the way draft-ietf-p2psip-sip does)? >>=20 >=20 > Right, this was misleading. We changed to >=20 > "It is noteworthy that additional constraints on the syntax and = semantic of names can apply according to specific Usages." >=20 >=20 >> (3) >> "In the absence of a element for a Kind = using >> the USER-CHAIN-ACL access policy (see Section 6.6 >> = ), >> implementors SHOULD assume this default value." >>=20 >> Why is this SHOULD and not MUST? Shouldn=92t implementations >> conservatively assume that variable names are not allowed unless >> explicitly specified? >>=20 >=20 > We agree - changed to MUST. >=20 >> (4) >> "If no pattern is defined for a Kind or the "enable" attribute is = false, >> allowable Resource Names are restricted to the username of the signer >> for Shared Resource.=94 >>=20 >> I think this needs to account for an error condition where the = pattern >> does not meet the pattern construction requirements, e.g.: >>=20 >> ""If no pattern is defined for a Kind, if the "enable" attribute is >> false, or if the regular expression does not meet the requirements >> specified in this section, the allowable Resource Names are = restricted >> to the username of the signer for Shared Resource.=94 >>=20 >=20 > Thanks, we forgot this - changed now. >=20 >> =3D Section 6.2 =3D >>=20 >> For privacy reasons, wouldn=92t it be better to overwrite every entry = in a >> subtree when the root of the subtree gets overwritten? Otherwise the >> list of users who were given write access may remain long after their >> access has been revoked. >>=20 >=20 > Yes in general, but there are two constraints. >=20 > (a) Only the Resource Owner can overwrite all entries of a subtree = (entries of which may have different owners). Periodic checks of the = Owner may produce an unwanted extra load. > (b) There may be use cases, where a subtree shall be temporarily = invalidated, but reactivated later (e.g., some behavioral monitoring = puts some peer under suspect, but later releases this). >=20 > For these reasons, we argue for a "SHOULD" here: >=20 > "To protect the privacy of the users, the Resource Owner SHOULD = overwrite all subtrees that have been invalidated." >=20 >> =3D Section 6.3 =3D >>=20 >> How strings are to be compared (e.g., as binary objects or whatever = it >> is) needs to be normatively specified. >>=20 >=20 > Yes, comparing binary objects is added, now. >=20 >> It is confusing to use normative language only in step 5 here. I = would >> suggest either normatively defining each action or not using SHALL = here. >>=20 >=20 > Yes, agreed and changed to: >=20 > "This final ACL item is expected to be the root item of this ACL which = MUST be further validated by verifying that the root item was signed by = the owner of the ACL Resource." >=20 >> =3D Section 6.6 =3D >>=20 >> "Otherwise, the value MUST be written if the certificate of the = signer >> contains a username that matches to one of the variable resource name >> pattern (c.f. Section 5 >> ) >> specified in the configuration document" >>=20 >> It seems to me that matching the pattern is not sufficient =97 isn=92t = it >> the case that both the user and domain portions of the user name in = the >> certificate need to match the user and domain name portions present = in >> the resource name? >=20 > Yes, this is made clearer now: >=20 > "contains a username that matches to the user and domain portion in = one of the variable resource name patterns" >=20 >> In general, the document seems to be missing >> discussion of the implications of having the user name and the = resource >> name diverge. I think this affects every operation that involves >> comparing the two (or the Resource-Id, right?). >>=20 >=20 > The logic is as follows: Store if (a) a regular USER-MATCH or = USER-NODE-MATCH works (we are regular owner), or if (b) a variable = resource name is successfully authenticated (we are owner using variable = naming - this includes matching of username *and* resource name), or if = (c) ACL authorization is in effect (we harvest trust delegation) for = this resource. >=20 > Otherwise, the store request must be denied, which we added = explicitly, now. >=20 >> I=92m also unclear about why policy for allowing access to shared >> resources is being strictly coupled with policy for allowing variable >> resource names. Might there be cases where it makes sense to = authorize >> one but not the other? >>=20 >=20 > I don't see the strict coupling, here: First the check is done to = store based on USER-MATCH or USER-NODE-MATCH, which do not work with = variable resource names, then ... It is rather that USER-CHAIN-ACL = grants storing rights in both cases, variable naming and trust = delegation. This makes IMO sense, as it abstracts from the strict naming = authorities of USER-MATCH or USER-NODE-MATCH. >=20 >> =3D Section 8.2 =3D >>=20 >> This section misses the threat of a misbehaving peer who is delegated >> write access =97 that seems like an important case to cover. >>=20 >=20 > O.K., we added a subsection on that. >=20 >> =3D Section 8.3 =3D >>=20 >> By =93publicly readable=94 do you mean =93readable by any node in the >> overlay=94? Admission to the overlay would still be access = controlled, >> correct? >>=20 >=20 > Yes, of course. We clarified. >=20 >> =3D Section 9.2 =3D >>=20 >> What is the significance of 17, other than that it is in the = unassigned >> range? >>=20 > None, I guess it was just free. We changed to 'TBD'. >=20 >>=20 >> =3D=3D Nits =3D=3D >>=20 >> =3D Section 1 =3D >>=20 >> The reference to I-D.ietf-p2psip-disco should be removed given that = the >> document is several years old and not expected to advance as far as I = know. >>=20 >=20 > Yup, this document died with the working group. >=20 >> s/from one authorized to another (previously unauthorized) user/from = one >> authorized user to another (previously unauthorized) user/ >>=20 > Thanks, fixed. >=20 >> =3D Section 2 =3D >>=20 >> s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts >> = ]/[I-D.ietf-p2psip-concepts >> = ]/ >>=20 >=20 > Thanks, fixed. >=20 >> =3D Section 3.1 =3D >>=20 >> s/Append an 8 bit long short individual index value/Append an 8-bit >> individual index value/ >>=20 >=20 > O.K., done. >=20 >> =3D Section 4.1 =3D >>=20 >> s/an Access Control including/an Access Control List including/ >>=20 > Thanks, done. >=20 >> =3D Section 5.1 =3D >>=20 >> Same comment about I-D.ietf-p2psip-disco >> = as >> in Section 1. >>=20 > Done. >=20 > Thanks, > Thomas >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From nobody Wed Mar 23 13:51:12 2016 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 3F23D12D8DD for ; Wed, 23 Mar 2016 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=SfWaP4nI; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=G0xeBCiy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4xZzlHWRnGb for ; Wed, 23 Mar 2016 13:51:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7832512D8FF for ; Wed, 23 Mar 2016 13:51:02 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DBE5020DA5 for ; Wed, 23 Mar 2016 16:51:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 23 Mar 2016 16:51:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=OI102qHG6iFLAPq/HCEbKRhHhH8=; b=SfWaP4 nIA4uUrYee9K0igmwZwO9aX0LCu82qB7+e13teucSWfCl5oQMxLSWCUB1MSA/Cd3 Y5SI4dTH/wCweGYshiCpgtkTHQ6zskh1ngwUFezu1owh66fqK4v5hU0Frc06lnKm fjexqZzaZbA7LYoE4MZIZxFI4cFdIEk8Wfg74= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OI102qHG6iFLAPq /HCEbKRhHhH8=; b=G0xeBCiy1LkwDkb4w/aj9xWPOhV5gII+sPZ/f0EgdcrcADB asmJfWs1L5nEcLbujvVyWu1BcZY4gDTWli7c5eLxehh2/Pom3OzwE8KSFO38Eq8h f7/AWpu5Bvg6Sp784ks6VEB7tDxq+7Wk1l6yuFqhYbDU+kseQijsUMQcOtx4= X-Sasl-enc: NOcKa/LTwEzfS2Cw1m3KBlqIZRCqL3c2Md+HETPfbN3U 1458766261 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 1F3E2680230; Wed, 23 Mar 2016 16:51:01 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <488F2FA5-D434-49F5-8A83-7B4C33423971@cooperw.in> Date: Wed, 23 Mar 2016 13:51:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60A5B521-1593-405B-8104-F1AACCD951F2@cooperw.in> References: <56EF3475.2040009@haw-hamburg.de> <488F2FA5-D434-49F5-8A83-7B4C33423971@cooperw.in> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 23 Mar 2016 20:51:11 -0000 That should say secdir@ietf.org. > On Mar 23, 2016, at 1:21 PM, Alissa Cooper wrote: >=20 > Thanks, the changes look good and the explanations make sense. Marc = should go ahead and request the early secdir review by sending mail to = sector@ietf.org. >=20 > Alissa >=20 >> On Mar 20, 2016, at 4:38 PM, Thomas C. Schmidt = wrote: >>=20 >> Hi Alissa, >>=20 >> many thanks for the careful review. We have revised and resubmitted = the document accordingly. >>=20 >> For the details, please see our comments inline. >>=20 >> On 15.01.2016 00:03, Alissa Cooper wrote: >>> I have reviewed this document in preparation for IETF last call. I = have >>> a number of comments and questions that need to be resolved before = last >>> call can be initiated. I=92ve also included some nits below that = should be >>> resolved together with last call comments. >>>=20 >>> Given the nature of this document, I=92d like for the shepherd to = request >>> an early SECDIR review after the comments below have been resolved = so >>> that the authors and WG can receive security feedback before the >>> document progresses to IESG evaluation. >>>=20 >>=20 >> I assume this needs to be initiated by Marc (Petit-Huguenin) right = away? >>=20 >>>=20 >>> =3D=3D Substantive comments and questions =3D=3D >>>=20 >>> =3D Section 3.1 =3D >>>=20 >>> I think this section requires clarification. >>>=20 >>> How is the index value supposed to be initialized? Is it supposed to = be >>> chosen at random or set to 0 (or 1, as in the figure)? >>>=20 >>=20 >> It is now clarified that the (8 bit individual) index is under sole = control of the writing peer. The peer is free to use these bits = according to application needs. No interoperability issue, as the key = only requires uniqueness, no further semantic attached to it. >>=20 >>> I don=92t understand how this mechanism relates to how SSRCs are = chosen. >>> In fact RFC 3550 doesn=92t specify a particular algorithm to use, = but >>> merely provides one example. >>=20 >> The mechanism to build the keys is now more explicitly stated. The = pointer to RFC 3550 refers only to a method for calculating the = collision probability, no reference to assignment algorithms. >>=20 >>> Furthermore, I don=92t see how the collision >>> probably for the array index value, which selects the least = significant >>> three bytes from a cryptographically random Node-Id that must be 16 >>> bytes or longer, would be the same as for a randomly chosen 32-bit >>> integer. Could you explain? >>>=20 >>=20 >> The formula presented in RFC 3550 has a length parameter (L) and we = added that L=3D24 must be chosen in the present case. Otherwise, the = argument is that the selected 24 bits from a (cryptographically random) = Node-Id also form uniform pseudo-random numbers, since the selection = mechanism does not produce a bias. >>=20 >>> =3D Section 5 =3D >>>=20 >>> Are variable resource names expected to be UTF-8 strings? I think >>> somewhere in this section the internationalization expectations for >>> these strings need to be specified. >>>=20 >>=20 >> Resource names correspond to regular Reload resource names, thus = opaque (ASCII-encoded) strings of variable length up to 254 bytes. We = are not touching this here. >>=20 >>> =3D Section 5.3 =3D >>>=20 >>> (1) >>> I think this section needs to specify normative requirements on the >>> pattern construction to avoid duplicative or substring names as >>> described in 5.1 >>>=20 >>=20 >> Yes, we've included >>=20 >> "variable parts in elements defined in the overlay = configuration document MUST remain syntactically separated from the user = name part (e.g., by a dedicated delimiter) to prevent collisions with = other names of other users." >>=20 >>> (2) >>> "Configurations in this overlay document MUST adhere in syntax and >>> semantic of names as defined by the context of use. For example, = syntax >>> restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a = more >>> general naming is feasible in plain RELOAD." >>>=20 >>> I don=92t understand what the normative requirement is here or why = it is >>> needed. How is =93the context of use=94 defined? Shouldn=92t it be = up to the >>> specific protocol documents to define the required syntax and = semantics >>> for specific usages (e.g., the way draft-ietf-p2psip-sip does)? >>>=20 >>=20 >> Right, this was misleading. We changed to >>=20 >> "It is noteworthy that additional constraints on the syntax and = semantic of names can apply according to specific Usages." >>=20 >>=20 >>> (3) >>> "In the absence of a element for a Kind = using >>> the USER-CHAIN-ACL access policy (see Section 6.6 >>> = ), >>> implementors SHOULD assume this default value." >>>=20 >>> Why is this SHOULD and not MUST? Shouldn=92t implementations >>> conservatively assume that variable names are not allowed unless >>> explicitly specified? >>>=20 >>=20 >> We agree - changed to MUST. >>=20 >>> (4) >>> "If no pattern is defined for a Kind or the "enable" attribute is = false, >>> allowable Resource Names are restricted to the username of the = signer >>> for Shared Resource.=94 >>>=20 >>> I think this needs to account for an error condition where the = pattern >>> does not meet the pattern construction requirements, e.g.: >>>=20 >>> ""If no pattern is defined for a Kind, if the "enable" attribute is >>> false, or if the regular expression does not meet the requirements >>> specified in this section, the allowable Resource Names are = restricted >>> to the username of the signer for Shared Resource.=94 >>>=20 >>=20 >> Thanks, we forgot this - changed now. >>=20 >>> =3D Section 6.2 =3D >>>=20 >>> For privacy reasons, wouldn=92t it be better to overwrite every = entry in a >>> subtree when the root of the subtree gets overwritten? Otherwise the >>> list of users who were given write access may remain long after = their >>> access has been revoked. >>>=20 >>=20 >> Yes in general, but there are two constraints. >>=20 >> (a) Only the Resource Owner can overwrite all entries of a subtree = (entries of which may have different owners). Periodic checks of the = Owner may produce an unwanted extra load. >> (b) There may be use cases, where a subtree shall be temporarily = invalidated, but reactivated later (e.g., some behavioral monitoring = puts some peer under suspect, but later releases this). >>=20 >> For these reasons, we argue for a "SHOULD" here: >>=20 >> "To protect the privacy of the users, the Resource Owner SHOULD = overwrite all subtrees that have been invalidated." >>=20 >>> =3D Section 6.3 =3D >>>=20 >>> How strings are to be compared (e.g., as binary objects or whatever = it >>> is) needs to be normatively specified. >>>=20 >>=20 >> Yes, comparing binary objects is added, now. >>=20 >>> It is confusing to use normative language only in step 5 here. I = would >>> suggest either normatively defining each action or not using SHALL = here. >>>=20 >>=20 >> Yes, agreed and changed to: >>=20 >> "This final ACL item is expected to be the root item of this ACL = which MUST be further validated by verifying that the root item was = signed by the owner of the ACL Resource." >>=20 >>> =3D Section 6.6 =3D >>>=20 >>> "Otherwise, the value MUST be written if the certificate of the = signer >>> contains a username that matches to one of the variable resource = name >>> pattern (c.f. Section 5 >>> ) >>> specified in the configuration document" >>>=20 >>> It seems to me that matching the pattern is not sufficient =97 isn=92t= it >>> the case that both the user and domain portions of the user name in = the >>> certificate need to match the user and domain name portions present = in >>> the resource name? >>=20 >> Yes, this is made clearer now: >>=20 >> "contains a username that matches to the user and domain portion in = one of the variable resource name patterns" >>=20 >>> In general, the document seems to be missing >>> discussion of the implications of having the user name and the = resource >>> name diverge. I think this affects every operation that involves >>> comparing the two (or the Resource-Id, right?). >>>=20 >>=20 >> The logic is as follows: Store if (a) a regular USER-MATCH or = USER-NODE-MATCH works (we are regular owner), or if (b) a variable = resource name is successfully authenticated (we are owner using variable = naming - this includes matching of username *and* resource name), or if = (c) ACL authorization is in effect (we harvest trust delegation) for = this resource. >>=20 >> Otherwise, the store request must be denied, which we added = explicitly, now. >>=20 >>> I=92m also unclear about why policy for allowing access to shared >>> resources is being strictly coupled with policy for allowing = variable >>> resource names. Might there be cases where it makes sense to = authorize >>> one but not the other? >>>=20 >>=20 >> I don't see the strict coupling, here: First the check is done to = store based on USER-MATCH or USER-NODE-MATCH, which do not work with = variable resource names, then ... It is rather that USER-CHAIN-ACL = grants storing rights in both cases, variable naming and trust = delegation. This makes IMO sense, as it abstracts from the strict naming = authorities of USER-MATCH or USER-NODE-MATCH. >>=20 >>> =3D Section 8.2 =3D >>>=20 >>> This section misses the threat of a misbehaving peer who is = delegated >>> write access =97 that seems like an important case to cover. >>>=20 >>=20 >> O.K., we added a subsection on that. >>=20 >>> =3D Section 8.3 =3D >>>=20 >>> By =93publicly readable=94 do you mean =93readable by any node in = the >>> overlay=94? Admission to the overlay would still be access = controlled, >>> correct? >>>=20 >>=20 >> Yes, of course. We clarified. >>=20 >>> =3D Section 9.2 =3D >>>=20 >>> What is the significance of 17, other than that it is in the = unassigned >>> range? >>>=20 >> None, I guess it was just free. We changed to 'TBD'. >>=20 >>>=20 >>> =3D=3D Nits =3D=3D >>>=20 >>> =3D Section 1 =3D >>>=20 >>> The reference to I-D.ietf-p2psip-disco should be removed given that = the >>> document is several years old and not expected to advance as far as = I know. >>>=20 >>=20 >> Yup, this document died with the working group. >>=20 >>> s/from one authorized to another (previously unauthorized) user/from = one >>> authorized user to another (previously unauthorized) user/ >>>=20 >> Thanks, fixed. >>=20 >>> =3D Section 2 =3D >>>=20 >>> s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts >>> = ]/[I-D.ietf-p2psip-concepts >>> = ]/ >>>=20 >>=20 >> Thanks, fixed. >>=20 >>> =3D Section 3.1 =3D >>>=20 >>> s/Append an 8 bit long short individual index value/Append an 8-bit >>> individual index value/ >>>=20 >>=20 >> O.K., done. >>=20 >>> =3D Section 4.1 =3D >>>=20 >>> s/an Access Control including/an Access Control List including/ >>>=20 >> Thanks, done. >>=20 >>> =3D Section 5.1 =3D >>>=20 >>> Same comment about I-D.ietf-p2psip-disco >>> = as >>> in Section 1. >>>=20 >> Done. >>=20 >> Thanks, >> Thomas >>=20 >> --=20 >>=20 >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Wed Mar 23 14:29:23 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E174612D7F0; Wed, 23 Mar 2016 14:29:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160323212917.5912.28873.idtracker@ietfa.amsl.com> Date: Wed, 23 Mar 2016 14:29:17 -0700 Archived-At: Cc: draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Last Call: (A SIP Usage for RELOAD) to Proposed Standard X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 23 Mar 2016 21:29:18 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'A SIP Usage for RELOAD' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 25 10:48:36 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7112D527; Fri, 25 Mar 2016 10:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325174834.17987.77932.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 10:48:34 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-22.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 17:48:34 -0000 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 of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-22.txt Pages : 31 Date : 2016-03-25 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 25 12:22:48 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E55AA12D0A1; Fri, 25 Mar 2016 12:22:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325192246.17979.87486.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 12:22:46 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, p2psip@ietf.org, The IESG , draft-ietf-p2psip-diagnostics@ietf.org, rfc-editor@rfc-editor.org Subject: [P2PSIP] Protocol Action: 'P2P Overlay Diagnostics' to Proposed Standard (draft-ietf-p2psip-diagnostics-22.txt) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 19:22:47 -0000 The IESG has approved the following document: - 'P2P Overlay Diagnostics' (draft-ietf-p2psip-diagnostics-22.txt) as Proposed Standard This document is the product of the Peer-to-Peer Session Initiation Protocol Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ Technical Summary: The document defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information for connection and node status monitoring. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. 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: The Document Shepherd is Carlos J. Bernardos. The Responsible Area Director is Alissa Cooper.