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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
