Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13
"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Tue, 27 January 2015 19:01 UTC
Return-Path: <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 C12F81A82E2 for <p2psip@ietfa.amsl.com>; Tue, 27 Jan 2015 11:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 EpvoiUv6ezYK for <p2psip@ietfa.amsl.com>; Tue, 27 Jan 2015 11:01:42 -0800 (PST)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CC11A70E1 for <p2psip@ietf.org>; Tue, 27 Jan 2015 11:01:42 -0800 (PST)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from <schmidt@informatik.haw-hamburg.de>) id <1YGBOK-001Ygn-1X>; Tue, 27 Jan 2015 20:01:36 +0100
Received: from e178062006.adsl.alicedsl.de ([85.178.62.6] helo=[192.168.178.49]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from <schmidt@informatik.haw-hamburg.de>) id <1YGBOJ-002tXt-RS>; Tue, 27 Jan 2015 20:01:36 +0100
Message-ID: <54C7E088.6020102@informatik.haw-hamburg.de>
Date: Tue, 27 Jan 2015 20:01:28 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: cjbc@it.uc3m.es
References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> <54C6074B.9030405@fu-berlin.de> <1422385001.2887.45.camel@it.uc3m.es>
In-Reply-To: <1422385001.2887.45.camel@it.uc3m.es>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 85.178.62.6
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/DwvMfNNCMxsIIqu663uXB3HAcTY>
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
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 19:01:46 -0000
Hi Carlos, yes, will be finished tonight. I've just a few steps to complete ... Thomas On 27.01.2015 19:56, Carlos Jesús Bernardos Cano wrote: > 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 >>> -- 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