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

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

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
> [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] °