Subject: [siprec] Ben Campbell's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 May 2015 16:11:15 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-siprec-protocol-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am concerned that this draft allows the recording session to downgrade
security from the communication session. It says "SHOULD NOT", but then
explicitly allows for the downgrade when the SRC and SRS are in the same
administrative domain. This seems to create a whole new "last hop
exception" for media, similar to the one for SIPS that we took so many
years to deprecate. (Except it's worse because the potentially insecure
hop goes to an endpoint not necessarily expected to be a party to the
media.)

Section 6.1.2 includes a "contract in place" as a form of recording
indication. The other mechanisms seem to say that a given call is being
recorded. A contract cannot do that, except in the degenerate case of
"all calls are recorded." This doesn't seem to fit the spirit of the
"MUST provide recording indication" language.

Section 12, 2nd paragraph says the SRC and SRS "MUST support SIP with TLS
and MAY support SIPS with
   TLS as per [RFC5630]". That actually downgrades the requirement for
SIPS support from that in 3261/5630. (3261 says you MUST support SIPS if
you support TLS.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The reference to 7245 is informational. Do you expect that a
reader/implementor could understand/implement this draft without
understanding the architecture and terminology from that RFC? The same
applies for 3550--I'm skeptical that one could implement this draft
without understanding RTP.

-- Figure 1: The text says the flow is basically the same whether the SRC
is in an endpoint or separate. This may be logically true, but the flow
really would change--none of of the flow between UA(A) and SRC would
exist.

-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS"
reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add
some motivation as to why this draft seems to prefer UPDATE.

-- 5.3: It seems odd to me that the SRC can ignore an explicit preference
not to record. Wouldn't it be better just to refuse to complete/accept
the call, if some policy overrides the end-user's preference?

-- Figure 3: If the UA prefers not to be recorded, shouldn't it express
that at setup time, rather than wait for the SRC to indicate recording is
happening? As shown, this almost guarantees a bit of media will be
recorded. (Seems like there should be some guidance about this in the
text.) The last paragraph of 6.1.2 seems to reinforce the problem by
suggesting the participant might base the decision to express a
preference on a tag that is optional for the SRC to send in the first
place.

-- 6.3, last paragraph: It seems odd that the requirement to render a
recording indicator be lower for a media server than for other UAs. This
seems to circumvent user notification in one of the most common uses of
recording these days.

-- 9.1 : The last bullet seems to be a motivation to not send metadata at
all, which is expressly forbidden in the first paragraph.

-- 9.2: The use of  the content-type value as the sole indicator that the
an UPDATE request should be interpreted as an request for a metadata
snapshot update is rather odd.  If you end up with new kinds of metadata
requests in the future, does each one get it's own media-type?

-- 12: If this doc is to depend on the security considerations in 6341,
that needs to be a normative reference--which is a bit of a pain because
I think it's an informational RFC.

-- 12.1: 
"recording session uses TLS" -- I assume that's for SIP? Also It's worth
discussing how mutual authentication applies if the SRC is in an end-user
device. Is it expected to have a client cert? No option to use  SIP
identity?

Also, I'm a bit uncomfortable assuming devices in the same administrative
domain automatically trust each other. It might be better to say "If they
trust each other..."

-- 12.2:

I get quite a bit of heartburn out of making Security Descriptions MTI
and dtls-srtp optional. I guess I may have to hold my nose on this one.

Editorial:

-- 4: 2nd paragraph: " ... does not represent the protocol"
 and first bullet: "Delivering recorded media in real-time as the CS
media"

I don't understand what either of those mean.

-- 5.1, 2nd paragraph: "B2BUA to bridge
the media between UA(A) and UA(B)"

Is there a reason not to use the terminology from RFC 7092? (e.g. “relay”
or “terminate” media)?

-- 7.3.1: The normative language in the first paragraph is redundant to
similar language in 6.3.