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
[email protected]
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: +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
