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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 27 Jan 2015 19:56:41 +0100

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-masked]
> > https://www.ietf.org/mailman/listinfo/p2psip
> >

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 27 Jan 2015 20:01:28 +0100

Hi Carlos,

yes, will be finished tonight. I've just a few steps to complete ...

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 °

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 27 Jan 2015 20:09:46 +0100

Thanks!

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 27 Jan 2015 23:02:02 +0100

Hi Roland,

many thanks for your careful reading and apologies for the very late 
pick-up of the subject.

   "Note that

   "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."

>    destination list is non-conforming (maybe discard

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?

>    should be defined explicitly.

Yes, agreed. Corresponding adjustments have been made to sections 3.2 and 7.

>    or ID 1234 are used in this section.

O.K., thanks, fixed.

> NEW:    include the scheme (e.g. sip:) as the AOR needs to match the

Thanks, fixed.

> I guess a StoreAns with Error_Forbidden, but that could/should also be

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".

> 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.

> NEW:   that want to assure maintenance of sessions individually need to

Thanks, fixed.

> 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.

> last entry must be a Node-ID, no Resource-IDs allowed, that could

See the discussion above.

> 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

-- 

--