Subject: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Nov 2015 15:31:18 -0600

I have been selected as the Applications Area Directorate early
reviewer for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt
Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP)
        Back-to-Back User Agents (B2BUAs)
Reviewer: Vijay K. Gurbani
Review Date: 2015-11-16
IETF Last Call Date: 2015-11-17
IESG Telechat Date: 2015-12-03

Summary: This draft has minor issues, and is ready for publication as
a Proposed Standard once these issues are resolved.

I will also (strongly) suggest that the editors go over the draft for
grammatical touches to eliminate the sort of issues present in the Nits
section.  This will make the draft more readable and provide it the
gravity it needs for a standards track document.

Major: 0
Minor: 3
Nits: Many

Minor:

- S3.1.1, second to last paragraph (beginning with "[RFC4474] provides
  ... the signature."): Isn't this only true if the originating UAC
  used rfc4474 and inserted the appropriate headers.  Or is the
  assumption that rfc4474 is always used, and therefore, a media relay
  B2BUA must be careful and not modify the fingerprints?

- S3.1.2, first paragraph: "The identity integrity protection
  procedures described in Security Considerations section..."

  Described in the Security Consideration section of which document?
  The document under review or some other one (rfc7092)?

- S3.1.2.2: I am not sure what your takeaway is at the end of this
  section.  You seem to be making the case that a B2BUA cannot
  modify the RTP headers and RTCP packets.  But then you go on and
  say that this can be mitigated by using different keys, and that
  with "such an approach" (aside: define "such an approach"), the
  B2BUA is not aware of the keys used to decrypt the media payload.
  Well, the B2BUA is never aware of such keys, since they are
  negotiated end-to-end (over the B2BUA), so I am at a loss to see
  what is the point of this section.

Nits:

- Abstract: s/media plane, rather than/media plane rather than

- Abstract: s/This document describes the behavior such B2BUAs can
   adhere to/This document describes the behaviour of such B2BUAs/

- S1.1: s/The fingerprint, identifies/The fingerprint identifies

- S3.1.2:
  s/There are two types of media-aware relay/There are two types of
  media-aware relays/

- S3.1.2.1: (For readability)
  s/This kind of media aware relay/A RTP/RTCP aware media relay/

- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/

  (If you want to retain "the", perhaps you may consider renaming
  Bob to Donald!  Sorry, bad joke, I know.)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 17 Nov 2015 09:17:19 +0000

Hi Vijay,

Thanks for your review and feedback. Please see inline

-----Original Message-----
From: "Vijay K. Gurbani" <[email-masked]>
Date: Tuesday, 17 November 2015 at 3:01 AM
To: "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Tuesday, 17 November 2015 at 3:01 AM

>  B2BUA must be careful and not modify the fingerprints?

Right. This is true only when RFC4474 is used.
We have re-worded the text to say the same. Here is the proposed new text:

NEW:
"When <xref target="RFC4474"/> is used forDTLS-SRTP sessions, the
fingerprint attributes are integrity protected.
Thus, under circumstances when <xref target="RFC4474"/> is used, B2BUAs
cannot terminate the DTLS-SRTP session without invalidating the signature
and
causing the session to fail.

>  The document under review or some other one (rfc7092)?

Described in section 5 (Security Consideration) of this document. I will
re-word to say the same.

>  what is the point of this section.

The idea of the section is to highlight that with current mechanisms it is
not possible for B2BUA modify headers with out being a DTLS endpoint.
In future (with PERC) it is possible that a B2BUA can modify the
headers/RTCP packets but still have no access to the RTP payload.

>- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/

Thanks. Will fix all the above Nits

Regards,
Ram