Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 27 January 2015 18:56 UTC

Return-Path: <cjbc@it.uc3m.es>
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 648531A891F for <p2psip@ietfa.amsl.com>; Tue, 27 Jan 2015 10:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 eNRD8FASG6_v for <p2psip@ietfa.amsl.com>; Tue, 27 Jan 2015 10:56:43 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABCE1A88DB for <p2psip@ietf.org>; Tue, 27 Jan 2015 10:56:43 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 64F1B15278F1; Tue, 27 Jan 2015 19:56:41 +0100 (CET)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 4A1F31527622; Tue, 27 Jan 2015 19:56:41 +0100 (CET)
Message-ID: <1422385001.2887.45.camel@it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: "Thomas C. Schmidt" <t.schmidt@fu-berlin.de>
Date: Tue, 27 Jan 2015 19:56:41 +0100
In-Reply-To: <54C6074B.9030405@fu-berlin.de>
References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> <54C6074B.9030405@fu-berlin.de>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21288.001
X-TM-AS-Result: No--21.709-7.0-31-1
X-imss-scan-details: No--21.709-7.0-31-1
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/SfxlJv-ZkTxj5odxrS-AEas_3Xk>
Cc: "p2psip-chairs@tools.ietf.org" <p2psip-chairs@tools.ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: <http://www.ietf.org/mail-archive/web/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: Tue, 27 Jan 2015 18:56:48 -0000

Hi Thomas,

Can you please post a revised version of the draft including these
changes.

Carlos

On Mon, 2015-01-26 at 10:22 +0100, Thomas C. Schmidt wrote:
> Hi Roland,
> 
> apologies for the very late pick-up of the subject.
> 
> Please see answers inline:
> 
> On 06.09.2014 01:46, Roland Bless wrote:
> 
> > I carefully read the document and didn't find any real show stoppers,
> > but IMHO the document would benefit from some clarifications
> > as indicated below.
> >
> > Major:
> > - Normally a SIP registration times out after some period
> >    (usually given in the REGISTER message)
> >    I guess that the mechanism is replaced in P2PSIP by the
> >    lifetime parameter in the StoredData. If this is the case
> >    I'd like to see it mentioned explicitly.
> >
> 
> Yes, you are right. We added in Section 3.1:
> 
>    "Note that
>     the registration lifetime known from the regular SIP REGISTER method
>     is inherited from the lifetime attribute of the basic RELOAD
>     StoredData structure (see Section 7 in [RFC6940])."
> 
> > - It is unclear how SIP and SIPS should be realized, because
> >    AppAttach only allows to create DTLS/UDP or TLS/TCP connections
> >    (cf. OverlayLinkType in IceCandidate).
> >    "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted
> >    SIP messages over the connection as in normal SIP."
> >    Sending "plain" (I guess non-secured) SIP message is not possible
> >    if AppAttach doesn't allow for UDP-only connections.
> >
> 
> This may be somewhat confusing: Plain SIP sends SIP messages "plainly" 
> over transport, while SIPS requires the presence of transport layer 
> security. As the current Reload Link Layer is built on (D)TLS secure 
> Internet transport, there is actually always some transport layer 
> security established within the KBR region. However, this should not 
> prevent users to make "plain SIP" calls using plain SIP URIs, and SIPS 
> requires end-to-end transport security that include endpoint 
> certificates and protected links to clients.
> 
> We've added the following clarification:
> 
>    "It is noteworthy that according to [RFC6940] all overlay links are
>     built on (D)TLS secured transport.  While hop-wise encrypted paths
>     does not prevent the use of plain SIP, SIPS requires end-to-end
>     protection that may include client links and endpoint certificates."
> 
> 
> 
> > - I guess that the destination list should contain only
> >    NodeIDs, or are ResourceIds and OpaqueIDs also permitted?
> >    If not, then the calling/initiating peer should check
> >    that condition and some action must be defined if the
> >    destination list is non-conforming (maybe discard
> >    this destination list)
> >
> > - The Draft should clearly specify how to map AORs
> >    to Resource-IDs as required by RFC6940, sec. 5.2:
> >     o  Define how the Resource Name is used to form the Resource-ID where
> >        each Kind is stored.
> >    I guess that the AOR is mapped by using the overlay hash function
> >    after stripping the scheme (like sip:, sips:) from it. But that
> >    should be defined explicitly.
> >
> > Minor:
> > Sec. 1:
> > - Several different notations like 'Node-ID "1234"', Node-ID 1234
> >    or ID 1234 are used in this section.
> >
> > Sec. 2:
> > OLD:    include the scheme (e.g sip:) as the AOR needs to match the
> > NEW:    include the scheme (e.g. sip:) as the AOR needs to match the
> >
> > Sec. 3.3:
> >
> >     o  A Store is permitted only for AORs with domain names that fall
> >        into the namespaces supported by the RELOAD overlay instance.
> >
> >     and then
> >
> >     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).
> >
> > the first formulation suggests that the latter quotation should use
> > rather MUST than SHOULD (the Storing Peer MUST also verify this).
> >
> >     Before a Store is permitted, the storing peer MUST check that:
> >
> >     o  The AOR of the request is a valid Resource Name with respect to
> >        the namespaces defined in the overlay configuration document.
> >
> > What would be the proper reaction if this condition is not fulfilled?
> > I guess a StoreAns with Error_Forbidden, but that could/should also be
> > mentioned.
> >
> > Sec. 5.1:
> >
> >     the responding peer MUST present a certificate with a Node-ID
> >     matching the terminal entry in the route list.
> >
> > route list wasn't introduced before and I guess destination list
> > would be the right term here. Moreover, what is the reaction if
> > there is a certificate mismatch, i.e., the Node-ID doesn't match
> > the one in the certificate? Should the connection be torn down?
> >
> > Sec. 5.2:
> > typo
> > OLD:   that want to assure maintanance of sessions individually need to
> > NEW:   that want to assure maintenance of sessions individually need to
> >
> > Sec. 6:
> >     GRUUs in RELOAD are constructed by embedding a
> >     base64-encoded destination list in the gr URI parameter of the GRUU.
> >
> > I guess that the destination list is encoded in the same way as
> > described in section  6.3.2.2. of RFC 6940. Simply a list of
> > Destination entries without any preceding length field?!
> >
> > Sec. 7:
> >
> >
> >     sip_registration_route
> >
> >        a destination list which can be used to reach the user's peer.
> >
> > if there are any restrictions like only Node-IDs allowed or the
> > last entry must be a Node-ID, no Resource-IDs allowed, that could
> > be mentioned here, too.
> >
> > Sec. 8:
> >
> > What about destination lists that contain back and forth routes
> > like 1234 5678 1234 5678 1234 4444 5678 1234 7777?
> > This may be used for traffic amplification as mentioned in
> > sec. 13.6.5. of the RELOAD spec. Therefore, an additional
> > check at the StoreReq receiving node may be useful, even
> > if destination lists are checked by RELOAD.
> >
> > Regards,
> >   Roland
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > P2PSIP@ietf.org
> > https://www.ietf.org/mailman/listinfo/p2psip
> >