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 6.3.2.2. 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?
Thanks,
Thomas
--
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: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt 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 °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
