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

"Thomas C. Schmidt" <> Tue, 27 January 2015 22:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 409691A9067 for <>; Tue, 27 Jan 2015 14:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1YsTxjxir0lY for <>; Tue, 27 Jan 2015 14:02:12 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC3941A9051 for <>; Tue, 27 Jan 2015 14:02:11 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,477,1418079600"; d="scan'208";a="24461537"
Received: from (HELO ([]) by with ESMTP/TLS/AES128-SHA; 27 Jan 2015 23:02:10 +0100
Received: from (2002:8d16:183c::8d16:183c) by (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id; Tue, 27 Jan 2015 23:02:10 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Tue, 27 Jan 2015 23:02:09 +0100
Message-ID: <>
Date: Tue, 27 Jan 2015 23:02:02 +0100
From: "Thomas C. Schmidt" <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13
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: Tue, 27 Jan 2015 22:02:14 -0000

Hi Roland,

many thanks for your careful reading and 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
    do 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)

Maybe I miss the point here - but destination lists are part of the 
RELOAD routing, and we simply use this mechanism. We want to establish 
an end-to-end connectivity with the help of the AppAttach messaging 
procedure and I cannot see a reason to restrict resp. interfere with 
RELOAD routing here.

Did I overlook something?

> - 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.

Yes, agreed. Corresponding adjustments have been made to sections 3.2 and 7.

> Minor:
> Sec. 1:
> - Several different notations like 'Node-ID "1234"', Node-ID 1234
>    or ID 1234 are used in this section.

O.K., thanks, fixed.

> 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

Thanks, fixed.

> 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.

Just to clarify: The SHOULD applies to the requester and the MUST 
applies to the storing node. The latter ensures that no improper records 
enter the overlay.

Putting the liberal SHOULD to the requester action was actually on 
purpose for the following reasons: The responsibility of enforcement 
clearly is with the storing node, which should be prepared for erroneous 
request. And there may be situations (which?) where nodes/implementers 
have reasons to consider it an unsuitable burden to perform the check. 
However, a SHOULD means that it is meant to be done, anyway.

So I'm hesitant to change ... but without strong opinion ;)

As for the response code, we added "Error_Forbidden".

> 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?

We added: "Otherwise, the connection MUST NOT be used and closed."
Thanks for the "route list": that was an ancient term-typo.

> 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

Thanks, fixed.

> 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 of RFC 6940. Simply a list of
> Destination entries without any preceding length field?!

Well yes, we're using the RELOAD destination list (term and definition) 
here. The above encoding describes the URI-encoding, not the 
representation of the data structure in the overlay.

> 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.

See the discussion above.

> 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.

Mhmm, the issue is discussed and treated in the RELOAD spec. I'm not 
really convinced that we should redefine RELOAD specifics. Also, from an 
implementers point of view, I would expect that this checking is already 
part of handling the destination lists. It appears a bit awkward if an 
implementation of this specific SIP usage adds generic route protection 
... don't you agree?

Are you o.k. with these responses or did I miss something?




Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
°                   Fon: +49-40-42875-8452 °
°    Fax: +49-40-42875-8409 °


Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
°                   Fon: +49-40-42875-8452 °
°    Fax: +49-40-42875-8409 °