Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-08

Thanks to the work that the authors and other contributors have put into
describing these practices. I have a handful of relatively minor comments.

---------------------------------------------------------------------------

During the development of this document, was there any discussion of the
issues raised by draft-ietf-mmusic-sdp-uks?  Minimally, it seems that the
problem described there should be summarized and an informative link to that
document provided, probably somewhere in §3.1.

---------------------------------------------------------------------------

§4:

>  needs to be repeated at the endpoint obtain the end-to-end assurance.

Nit: "...at the endpoint to obtain end-to-end assurance."
                         ^^       ^

>  Intermediaries supporting this specification MUST NOT block or
>  otherwise redirects calls

Nit: "...redirect..."


---------------------------------------------------------------------------

§4:

>  STIR
>  authentication services MUST signal their compliance with this
>  specification by adding the "msec" header element defined in this
>  specification to the PASSporT header.

The use of the term "header element" threw me off for a few moments. It almost
sounds like the document is proposing a new  PASSporT parameter, rather than
defining a new value for the "ppt" parameter. I think this means to say
something like "...by adding a PASSporT with a type of "msec"..."

This phrasing also appears in section 8.

---------------------------------------------------------------------------

§4.1:

>  service on behalf of an entire domain, just as in SIP an proxy server

Nit: "...a proxy server..."

---------------------------------------------------------------------------

§4.3:

>  Identity header for the recipient of an INVITE.  The procedures in

Nit: "...Identity header field..."

---------------------------------------------------------------------------

§4.3:

>  STIR [RFC8224] provides integrity protection for the SDP bodies of
>  SIP requests...

I thought that generalized body protection was one of the things we removed
between 4474 and 8224. On a quick check, it looks like the only body-level
integrity protection 8224 affords is "a=fingerprint" attributes. I propose:

  "...provides integrity protection for the fingerprint attributes in SIP
  request bodies..."

(and similar changes for the other two mentions of "body" in this paragraph)

---------------------------------------------------------------------------

§4.4:

>  Identity header in a SIP request with an unrecognized PASSporT type

Nit: "...Identity header field..."

---------------------------------------------------------------------------

§6:

>  Another class of entities that might relay SIP media are back-to-back
>  user agents (B2BUAs).  If a B2BUA follows the guidance in [RFC7879],
>  it may be possible for those devices to act as media relays while
>  still permitting end-to-end confidentiality between user agents.

I'm a little surprised to see no mention of the interaction between B2BUAs and
the "trust on first use" technique described in Section 4.1. In particular, an
endpoint that is persistently behind a B2BUA, where that B2BUA implements the
Identity handling described in this document (acting as an endpoint) could
persistently receive the same identity for a remote user -- where that remote
identity is actually one created by the B2BUA.

I don't think mitigation is something this document needs to figure out; but I
think the situation should be called out explicitly.

---------------------------------------------------------------------------

§7:

>  In order to best enable end-to-end connectivity between user agents,
>  and to avoid media relays as much as possible, implementations of
>  this specification must support ICE [RFC8445].

It seems this is intended to be a normative "MUST."

---------------------------------------------------------------------------

§7:

>  ...will come in an UPDATE
>  sent in the backwards direction a provisional response and
>  acknowledgment (PRACK)...

I can't parse this clause. I think it means to say:

   ...will come in an UPDATE
   sent in the backwards direction, a provisional response, and
   a provisional acknowledgment (PRACK)...

Taking over as the responsible AD from Ben.

Very glad to see this work coming to a close.

= Section 3.2 =

OLD
Work is already underway on defining approaches to opportunistic media security for SIP in [I-D.johnston-dispatch-osrtp]

NEW
At the time of this writing, work was underway to define approaches to opportunistic media security for SIP in [draft-ietf-sipbrandy-osrtp]

= Section 4 =

s/at the endpoint obtain/at the endpoint to obtain/

= Section 5 =

Please update the OSRTP citation to point to draft-ietf-sipbrandy-osrtp.

= Section 10 =

Presumably "PASSporT Type registry" should say "PASSporT Resource Priority Header (rph) Types registry."