Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-osrtp-04 - Christer's review

From: Andy Hutton <[email-masked]>
Date: Thu, 24 May 2018 12:22:23 +0100

See below my responses to Christer's comments and sorry for the late response.

Andy

On 20 April 2018 at 08:58, Christer Holmberg
<[email-masked]> wrote:
>
> Hi,
>
> Below is my WGLC review.
>
> I base my review based on the assumption that the associated MMUSIC draft
> is not going to be progressed, and that draft-ietf-sipbrandy-osrtp is the
> ONLY deliverable related to OSRTP and SDP O/A.
>
> Also, some of my comments is repeating what I have said previously, but I
> include them in my review in order to have everything in one place.
>
>
> GENERAL:
> --------
>
> QG_1: The draft will be published as an Informational RFC (I know the
> reason, so no need to discuss that). Because of that, many SDOs will not
> be able to normatively reference it. So, if such SDO wants to adopt SDP
> O/A procedures of OSRTP (I know there are SDOs, or at least SDO members,
> interested in OSRTP), they would have to ³re-define² the procedures
> themselves.
>
> I wonder whether it would be useful to include some text/guidance
> regarding that in the document, i.e., recommending that such procedures
> are based on the procedures in the draft, for interoperability purpose etc?
>

[Andy H] - Personally I don't see the need for this but if you want
this and want to provide text I would not object.

>
> QG_2: There are no BUNDLE considerations. Even though it may seem obvious,
> I think it would be useful to indicate that the same security selection
> needs to be applied to all RTP-based m- sections within a BUNDLE group.
>
>

[AndyH] - Good idea.

> Section 1:
> ----------
>
>
> Q1_1: Shall we really reference individual drafts that will not progress?
> Couldn¹t we simply talk about ³based on previous work and studies done by
> Hadriel Kaplan"
>

[AndyH] - I would prefer to keep the reference to the individual draft
given that this draft is informational I think it is good information
to have and the kaplan draft referenced is well known.

>
> Section 3:
> ----------
>
> Q3_1: I don¹t understand the title of the section. Shouldn¹t it be ³SDP
> Offer/Answer Procedures²?

[AndyH] - I agrree that would be a better title for the section.

>
> Q3_2: Eventhough the document is Informational, since Section 3 does
> contain O/A text I think it should be done properly, describing how the
> offer is generated, how the answer is generated etc.
>

[AndyH - I believe the text has all the relevant information but it
could rewritten in the traditional form of "Generating the Initial SDP
Offer" and "Generating the SDP Answer" I don't have a strong opinion
on this but just want to get this done so whatever allows it to get
done gets my vote.

>
> Q3_3: There is no text on subsequent offers. If security has been
> negotiated in a previous O/A exchange, what profile values etc do I
> include in subsequent offers?
>

[AndyH] - I don't see any special procedures for subsequent offers it
is the same as the initial offer if we have to update the document it
may be worth pointing this out.

>
> Section 4:
> ----------
>
> Q4_1: Doesn¹t the last paragraph belong in the Applicability section?

[AndyH] - It is I think good to say when not to use these procedures
in the security considerations but it could also be considered part of
the applicability section. I think as long as it is stated in the
document we are okay.

>
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
> On 19/04/18 14:21, "Sipbrandy on behalf of Gonzalo Camarillo"
> <[email-masked] on behalf of [email-masked]>
> wrote:
>
>>Folks,
>>
>>I would like to start a WGLC on the following draft. This WGLC will
>>end on May 10th:
>>
>>https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-04
>>
>>Thanks,
>>
>>Gonzalo
>>
>>_______________________________________________
>>Sipbrandy mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/sipbrandy
>
> _______________________________________________
> Sipbrandy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipbrandy

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 May 2018 11:53:25 +0000

Hi,

>> Below is my WGLC review.
>>
>> I base my review based on the assumption that the associated MMUSIC 
>> draft is not going to be progressed, and that 
>> draft-ietf-sipbrandy-osrtp is the ONLY deliverable related to OSRTP and SDP O/A.
>>
>> Also, some of my comments is repeating what I have said previously, 
>> but I include them in my review in order to have everything in one place.
>>
>>
>> GENERAL:
>> --------
>>
>> reason, so no need to discuss that). Because of that, many SDOs will 
>> not be able to normatively reference it. So, if such SDO wants to 
>> adopt SDP O/A procedures of OSRTP (I know there are SDOs, or at least 
>> SDO members, interested in OSRTP), they would have to "re-define" the 
>> procedures themselves.
>>
>> regarding that in the document, i.e., recommending that such 
>> procedures are based on the procedures in the draft, for interoperability purpose etc?
>
> [Andy H] - Personally I don't see the need for this but if you want this and want to provide text I would not object.

I think it is important to inform the community that IETF do not (at the time of publishing the document) intend to define normative SDP O/A procedures for OSRTP, and that anyone who needs normative procedures will have to define them themselves.

...

>> Couldn't we simply talk about "based on previous work and studies done 
>> by Hadriel Kaplan"
>
> [AndyH] - I would prefer to keep the reference to the individual draft given that this draft is informational I think 
> it is good information to have and the kaplan draft referenced is well known.

Then please add a note saying that the work on the draft is not expected to continue, and that it is referenced only to give some background information. 

I sometimes get questions about the status of drafts that haven't progressed for a long time (or will never progress), so I think it is important to indicate that this draft will not progress.

...

>> contain O/A text I think it should be done properly, describing how 
>> the offer is generated, how the answer is generated etc.
>
> [AndyH - I believe the text has all the relevant information but it could rewritten in the 
> traditional form of "Generating the Initial SDP Offer" and "Generating the SDP Answer" I don't 
> have a strong opinion on this but just want to get this done so whatever allows it to get done gets my vote.

Yes, but we should still use the correct structure. I can provide some help, if needed.

> [AndyH] - I don't see any special procedures for subsequent offers it is the same as the initial offer if we 
> have to update the document it may be worth pointing this out.

Has there been discussions on whether the subsequent offer really is the same?

For example, if the initial O/A has resulted in SAVP, would you still use AVP in a subsequent offer?

Whatever the outcome, it needs to be documented.

> [AndyH] - It is I think good to say when not to use these procedures in the security considerations but it 
> could also be considered part of the applicability section. I think as long as it is stated in the document we are okay.

I still think it belongs in the Applicability section, but I will not argue about. You can keep it as it is :)

Regards,

Christer

---

From: Andy Hutton <[email-masked]>
Date: Thu, 24 May 2018 13:26:12 +0100

> Has there been discussions on whether the subsequent offer really is the same?

Not sure whether this has been discussed explicitly with regard to this draft.

> For example, if the initial O/A has resulted in SAVP, would you still use AVP in a subsequent offer?

Yes the recommendation would be to use AVP in a subsequent offer
otherwise things can go wrong when you consider things like 3PCC etc.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 May 2018 12:43:47 +0000

Hi,

> Not sure whether this has been discussed explicitly with regard to this draft.

Where has it been discussed? The MMUSIC draft doesn't say anything about subsequent offers either.

> Yes the recommendation would be to use AVP in a subsequent offer otherwise things can go wrong when you consider things like 3PCC etc.

What if the answerer, who included SAVP in the initial answer, sends a subsequent offer? Will it keep SAVP in that offer, or will it switch to AVP?

Regards,

Christer

---

From: Andy Hutton <[email-masked]>
Date: Thu, 24 May 2018 13:51:48 +0100

> What if the answerer, who included SAVP in the initial answer, sends a subsequent offer? Will it keep SAVP in that offer, or will it switch to AVP?

This really depends on the preferences of the answerer as to whether
it requires SRTP or is willing to try OSRTP it is the same
considerations as made when sending the initial offer.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 May 2018 13:11:40 +0000

Hi,

>> What if the answerer, who included SAVP in the initial answer, sends a
>>subsequent offer? Will it keep SAVP in that offer, or will it switch to
>>AVP?
>>
>

So, that endpoint is allowed to require SRTP, but the endpoint that sent
the initial offer must try OSRTP if it sends a subsequent offer???

I think the rules for subsequent offers shall be the same for both
endpoints, i.e., either shall both endpoints be allowed to ³require² SRTP
in a subsequent offer, OR both endpoints must try OSRTP in a subsequent
offer.

In addition, if security was NOT negotiated in the in the initial o/a
exchange, then I guess each endpoint can choose whether to use OSRTP or
not in subsequent offers?

Regards,

Christer

---

From: Andy Hutton <[email-masked]>
Date: Fri, 25 May 2018 12:06:08 +0100

> the initial offer must try OSRTP if it sends a subsequent offer???

The rules or probably more accurately the recommendations for both
endpoints are exactly the same in that when creating an offer the
decision on whether to try OSRTP or not depends on their own
preferences. This is true for both the initial offer and any
subsequent offers.

> in a subsequent offer, OR both endpoints must try OSRTP in a subsequent

As above the rules/recommendations for both endpoints are the same and
are dependent on their own preferences. If the endpoint is willing to
try OSRTP then it should do so in the subsequent offer for maximum
chance of interoperability but if its requires SRTP then it would not
make an OSRTP offer.

> not in subsequent offers?

Absolutely yes.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 May 2018 13:15:44 +0000

Hi Andy,

Below is a suggestion for an "SDP Offer/Answer Considerations" section.

Feel free to use, modify or throw in the trash bin :)

Regards,

Christer

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

X. SDP Offer/Answer Considerations

This section defines the SDP offer/answer considerations for opportunistic security. 

The procedures are for a specific m- section describing RTP-based media. If an SDP offer or answer 
contains multiple such m- sections, the procedures are applied to each m- section individually.

"Initial OPSRTP offer" refers to the offer in which oportunistic security is offered for 
an m- section for the first time within an SDP session.

X.1. Generating the Initial OPSRTP Offer

When an offerer sends an initial offer, in order to offer opportunistic security for a m- section descrbing
RTP-based media, the offerer MUST:

- indicate the RTP/AVP profile [RFC3551] (or the RTP/AVPF profile [RFCXXXX]) in the proto sub-field of the m- section; and
- include the SRTP keying attributes associated with one or more SRTP key managmenebt mechanism in the m- section:
-- In case of DTLS-SRTP key agreement [RFC5763], the keying attributes are provided using the SDP Fingerprint attribute.
-- In case of SDP Security Descriptions key agreement [RFC4568], the keying attributes are provided using the SDP Crypto attribute.
-- In case of ZRTP key agreement [RFC6189], the keying attributes are provided using the SDP zrtp-hash attribute.

X.2 Generating the Answer

When an answerer generates an answer to an offer which offers opportunistic security for an m- description 
[Section X.1], if the answerer accepts usage of SRTP and the indicated key management mechanism, the answerer generates
an answer and MUST:
- indicate one SRTP/AVP profile (or the SRTP/AVPF profile) in the proto sub-field of the corresponding m- section in the answer; and
- indicate the SRTP keying attributes associated with the chosen key management mechanism;

If the answerer does not accept the offered security for an m- section, but does accept the m- section, the answerer MUST 
indicate the RTP/AVP profile (or the RTP/AVPF) in the proto sub-field of the corresponding m- section in the answer, 
using normal procedures for negotiating non-secured RTP media. The answerer MUST NOT include any keying attributes in the m- section.  

If an m- section of the offer indicates previously negotiated SRTP, if the answerer accepts to continue using SRTP, 
the answerer will generate the corresponding m- section in the answer using the normal offer/answer procedures 
for SRTP and the used key management mechanism.

If SRTP has previously been negotiated, if a subsequent offer offers opportunistic security, the answerer
can choose to continue using SRTP (and generate the answer as described in the first paragraph above), or disable SRTP 
(and generate the answer as described in the second paragraph above).

Once the answerer has sent an answer, in which it indicates usage of SRTP for an m- section, the answerer will trigger normal procedures
associated with SRTP and the negotiated key management mechanism.

X.3 Offerer Processing the Answer

When the offerer receives an answer, if the answerer accepts the usage of SRTP, the answerer will trigger normal procedures associated
with SRTP and the negotiated key management mechanism.

X.4 Modifying the Session

When an offerer sends a subsequent offer, if SRTP has previously been negotiated for an m- section in the offer, the offerer MUST either:
- indicate the SRTP/AVP profile (or the SRTP/AVPF profile), indicating that the offerer wants to continue using SRTP; or
- re-offer opportunistic security, using the procedures in section X.1. As described in Section X.2, the answerer can choose to 
continue using SRTP, or switch to non-secure RTP.