Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16

Alissa Cooper <alissa@cooperw.in> Mon, 08 February 2016 22:34 UTC

Return-Path: <alissa@cooperw.in>
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 256501B343B for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:34:53 -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 LVJDCRoPPbKx for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:34:51 -0800 (PST)
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 52CB81B3432 for <p2psip@ietf.org>; Mon, 8 Feb 2016 14:34:51 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C2682212D6 for <p2psip@ietf.org>; Mon, 8 Feb 2016 17:34:50 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 08 Feb 2016 17:34:50 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= 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=eOx65HBwSv3nura5L+EQP4Uo1/Q=; b=akr7yO m+v1xwXGN/kZ/wd3SjackQ0Am0dr3EDu7aHA9TaqciEWq2LGrP7kKUMIEC7VQZKY IFGwlns8asWqfCIkvqiveQnGdvl7IROy5E3LPCzuCx/5MM7mdUAwfv3PbkAta9Mc Ja+8HW1swT5dx9gQwe5WYsNo2hmk6sBdxvSFE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=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=eOx65HBwSv3nura 5L+EQP4Uo1/Q=; b=H/X0yk/+vLFbYyFrqNLtWA8B95aNA8lZgyz1yoS7fzVk2xs UOkXRFwaBc/2STtStlH+EpaMBHiyeaQgKx8GODcmRqZUEBon81Q3QwOg3tS8uAan usHdDs9XoZx/NFUUFexDfP1Z97TpDiishJBnRGzV5sW8XqTd9/T08zaDkrCE=
X-Sasl-enc: KVpuliMK2pTmjeeHj3c3hDspFjW8Sk5H76yrKQ6N7KJh 1454970890
Received: from dhcp-171-68-20-80.cisco.com (dhcp-171-68-20-80.cisco.com [171.68.20.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 514E568010F for <p2psip@ietf.org>; Mon, 8 Feb 2016 17:34:50 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <D1766CFB-B7CF-4D0B-AB08-09EA5FABAE1C@cooperw.in>
Date: Mon, 8 Feb 2016 14:34:49 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5596511D-5D26-4792-B5AE-69DF327D5BAF@cooperw.in>
References: <D1766CFB-B7CF-4D0B-AB08-09EA5FABAE1C@cooperw.in>
To: P2PSIP WG <p2psip@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/tDIbvCn_xxaJnndzkn7i863yZMA>
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 <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 22:34:53 -0000

Is anyone in the WG able to respond to these comments and questions?

Thanks,
Alissa

> On Jan 15, 2016, at 1:58 PM, Alissa Cooper <alissa@cooperw.in> 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.
> 
> 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).
> 
> 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.
> 
> = 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?
> 
> = 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?
> 
> (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.
> 
> 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.
> 
> Example of Domain Patterns: dht\.example\.com .*\.my\.name
> 
> In this example, any AOR will be accepted that is either of the form <user>@dht.example.comle.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 <domain-restrictions> 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].
> 
> The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> 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]).
> 
> 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 <domain-restrictions> element. The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> 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].
> 
> Inclusion of a <domain-restrictions> 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 “enable” 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 “enable” attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element.
> 
> Example of Domain Patterns: dht\.example\.com .*\.my\.name
> 
> In this example, any AOR will be accepted that is either of the form <user>@dht.example.comle.com, or ends with the domain "my.name".
> 
> = 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).
> 
> = Section 8.2.4 =
> 
> (1)
> By "public" you mean "visible to all nodes in the overlay," correct?
> 
> (2)
> "Methods of providing
>   location and identity privacy are still being studied."
> 
> Is this true, specifically for P2PSIP?
> 
> 
> == Nits ==
> 
> = Section 1 =
> 
> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/
> 
> 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.
> 
> = 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.
> 
> = 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.
> 
> = Section 5.1 =
> 
> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/
> 
> = Section 6 =
> 
> I don't think you need the normative MAY here.
> 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip