Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13
"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Sun, 07 September 2014 20:56 UTC
Return-Path: <prvs=3201633d3=schmidt@informatik.haw-hamburg.de>
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 2807E1A0711 for <p2psip@ietfa.amsl.com>; Sun, 7 Sep 2014 13:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 zyVC-l_rva5h for <p2psip@ietfa.amsl.com>; Sun, 7 Sep 2014 13:56:01 -0700 (PDT)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE881A069B for <p2psip@ietf.org>; Sun, 7 Sep 2014 13:56:00 -0700 (PDT)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 07 Sep 2014 22:55:58 +0200
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 4A41410679D7; Sun, 7 Sep 2014 22:55:58 +0200 (CEST)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17049-07; Sun, 7 Sep 2014 22:55:57 +0200 (CEST)
Received: from [192.168.178.49] (e178060140.adsl.alicedsl.de [85.178.60.140]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id AB04D10679CF; Sun, 7 Sep 2014 22:55:56 +0200 (CEST)
Message-ID: <540CC653.30705@informatik.haw-hamburg.de>
Date: Sun, 07 Sep 2014 22:55:47 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Roland Bless <roland.bless@kit.edu>, "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>, "p2psip@ietf.org" <p2psip@ietf.org>
References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de>
In-Reply-To: <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Archived-At: http://mailarchive.ietf.org/arch/msg/p2psip/wZ8fkrFscGeEwyYdt_AxnCYoDcc
Cc: "p2psip-chairs@tools.ietf.org" <p2psip-chairs@tools.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
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: Sun, 07 Sep 2014 20:56:05 -0000
Hi Roland, many thanks for your careful comments. We will need a few days to return details / an updated version of the draft ... Cheers, Thomas On 06.09.2014 01:46, Roland Bless wrote: > Hi, > >> The WGLC will be open till the 8th of September, so we have time enough >> even there is August in the middle. We kindly ask the WG to review the >> document and provide comments. > > That was a good decision due to vacation time in August:-) > > 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. > > - 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. > > - 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 > -- 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 °
- [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Carlos Jesús Bernardos Cano
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Marc Petit-Huguenin
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Roland Bless
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Thomas C. Schmidt
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Carlos Jesús Bernardos Cano
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Thomas C. Schmidt
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Carlos Jesús Bernardos Cano
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 Thomas C. Schmidt