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

Thanks!

On Tue, 2015-01-27 at 20:01 +0100, Thomas C. Schmidt wrote:
> 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
> >>>
> 