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

["Thomas C. Schmidt" <[e-mail]>]

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
>>> [e-mail]
>>> 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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °