Subject: Re: [straw] AD Eval of draft-ietf-straw-b2bua-stun-04

From: "Ben Campbell" <[email-masked]>
Date: Fri, 24 Apr 2015 17:08:04 -0500

(+straw)

Hi, Ram

Please make sure that any subtantive changes are copied to the working 
group list, so people can have a chance to say something if they object 
to changes. (I don't expect a new WGLC unless unless there are big 
changes).

More comments inline:

On 22 Apr 2015, at 9:08, Ram Mohan R (rmohanr) wrote:

> Hi Ben,
>
> Thanks for your review. Please see inline for my responses.
>
> -----Original Message-----
> From: Ben Campbell <[email-masked]>
> Date: Tuesday, 21 April 2015 2:52 am
> To: "[email-masked]"
> <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, 
> "[email-masked]"
> <[email-masked]>
> Subject: AD Eval of draft-ietf-straw-b2bua-stun-04
>
>> Hi,
>>
>> This is my AD Evaluation of draft-ietf-straw-b2bua-stun-04. I 
>> appreciate
>> the effort on this, but I think it needs a bit more work before it 
>> goes
>> to IETF last call. Please see details below.
>>
>> Thanks!
>>
>> Ben.
>>
>> Substantive Comments:
>>
>> -- Section 1:
>>
>> The introduction offers way more background than is really needed to
>> motivate this document. It's almost a history of SBCs and NAT 
>> traversal.
>> I won't push to remove some of it, but there are parts that are 
>> likely
>> to trigger debates that are not really central to the goals of 
>> document.
>
>
> This was added based on some of the feedback from folks who reviewed 
> the
> draft and they wanted to see some history and motivation for writing 
> this
> draft. Please let us know any specific text which you think are likely 
> to
> create debates.
> I will be happy to re-word/remove them.
>

I don't have specific requests for removal. The section just seems more 
detailed than necessary for the purpose. But if there were things 
requested during review in the working group, then that's okay.

>
>
>
>> -- Section 2:
>>
>> If the terms are defined in 3261, do you need to redefine them here?
>> (These are not the 3261 definitions; they are from RFC 7092.)
>
> Ok will remove the redundant definition
>
>
>
>>
>> -- section 3: "Such B2BUAs MUST ensure that they don¹t change IP
>> address in c= line, port in m= line"
>>
>> It seems odd to have this with a 2119 MUST. Isn't the fact that such
>> B2BUAs never change the media path part of the definition of a
>> "SDP-Modifying Signaling-only B2BUA"? If so, this is a statement of
>> fact, not a normative statement.
>>
>> If the sentence survives, consider changing "... MUST ensure that 
>> they
>> don't ..." to "... MUST NOT ...".
>
> This is needed because as the definition "SDP-Modifying Signaling-only
> B2BUA" says these kind of B2BUAs [ defined in RFC 7092]
> Can change parts of SDP. While changing it has to ensure that it does 
> not
> change IP address in c= and port in m= lines other wise it will create
> problems for ICE

Yes, 7092 allows them to change parts of SDP. But if they change the M 
or C lines, they are redirecting media by definition, which puts them 
out of this category in the first place. (Not counting changes which 
affect nothing at all.)

OTOH, it's probably reasonable to say that such B2BUAs MUST NOT change 
other attributes with ICE semantics.

>
> Re-worded this to ³MUST ensure that they don¹t Š"

I'm a bit confused--it already says "MUST ensure that they don't". It 
would be better to say "MUST NOT..."

>
>>
>> -- Section 4 and subsections:
>>
>> I find the distinction between "ICE Termination" and "ICE 
>> Passthrough"
>> confusing. The term "passthrough"  sort of fits for passing through 
>> ICE,
>> but not so much the connectivity checks. It seems to me that the "ICE
>> Passthrough" section really describes a hybrid model, where some ICE
>> negotiation is passed through, some added, and the B2BUA may or may 
>> not
>> be on the media path at all.
>>
>> It seems like the real functional difference is that an "ICE
>> Termination" b2bua is always on the media path, and the "ICE
>> Passthrough" b2bua is optionally on the media path. (or on the media
>> path for part of the media.)
>
> That¹s correct. It is not a passthrough as is rather a hybrid. 
> Essentially
> this section describes
> an approach where media can directly flow between endpoints if ICE
> succeeds and flows via B2BUA only
> if endpoints cannot reach directly (as determined by ICE)
>
> I could not get a better name. Thought of names like ³ICE 
> optimization by
> flowing around B2BUA² but it looks too lengthy.
> Any suggestions ?

I think the fundemental difference is the first category requires media 
termination by the B2BUA. This may be due to some reason completely 
unrelated to NAT traversal. The second category only terminates if it 
needs to for NAT traversal. So maybe something like "Required Media 
Termination" and "Optional Media Termination" Or as an alternative, 
"media-plane" B2BUAs, and "Conditionally media-plane B2BUAs]

>
>>
>> -- Section 5, last paragraph:
>>
>> As used, ram-straw-b2bua-dtls-srtp needs to be a normative 
>> reference.. That may be a bit of an issue, unless that draft is ready 
>> to progress
>> really soon now, or you want to delay this one until that one is 
>> ready.
>> Is this paragraph really needed for the purposes of this draft?
>> (assuming we plan another standards track draft that will say the 
>> same
>> thing in more detail?)
>
> Removed the text and reference to this draft.
>

I think that makes sense, but please make sure the working group sees 
the change.

>
>>
>> -- Abstract
>>
>> Last sentence is oddly constructed. Proper handling is in support of 
>> the
>> first goal, not a goal in itself, right?
>
> Re-worded the abstract to below
>
> OLD:
> Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
>  are often designed to be on the media path, rather than just
>  intercepting signaling.  This means that B2BUAs often act on the
>  media path leading to separate media legs that the B2BUA correlates
>  and bridges together.  When acting on the media path, B2BUAs are
>  likely to receive Session Traversal Utilities for NAT (STUN) packets
>  as part of Interactive Connectivity Establishment (ICE) processing.
>  It is critical that B2BUAs handle these STUN messages properly.
>
>  This document defines behavior for a B2BUA performing ICE processing.
>  The goal of this draft is to ensure that ICE used for NAT and
>  Firewall traversal of multimedia sessions works when there are B2BUAs
>  in place and the B2BUAs handle STUN messages properly.
>
>
>
> NEW:
> Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
>  are often designed to be on the media path, rather than just
>  intercepting signaling.  This means that B2BUAs often act on the
>  media path leading to separate media legs that the B2BUA correlates
>  and bridges together.  When acting on the media path, B2BUAs are
>  likely to receive Session Traversal Utilities for NAT (STUN) packets
>  as part of Interactive Connectivity Establishment (ICE) processing.
>
>  This document defines behavior of B2BUAs handling STUN
>  messages received as part of the ICE procedures used for NAT and
>  Firewall traversal of multimedia sessions.
>
>

Thanks, that works for me.

[...]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 26 Apr 2015 17:07:06 +0000

Hi Ben,

See inline

STRAW WG,
Please see the diffs that I have incorporated, let me know if any one has
concerns with the same.

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Saturday, 25 April 2015 3:38 am
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: AD Eval of draft-ietf-straw-b2bua-stun-04

>would be better to say "MUST NOT..."

Sorry I changed the sentence as per suggestion in my local copy but
replied the other way around in email.
I have already incorporated the changes to say “MUST NOT..”

>"media-plane" B2BUAs, and "Conditionally media-plane B2BUAs]

I think “Optional Media Termination” sounds better to me. Unless some one
in WG has a better suggestion, I will stick to this.

>I think that makes sense, but please make sure the working group sees

Yes. Attached is the diff that I plan to publish

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 27 Apr 2015 17:33:39 -0500

Hi Ram,

Thanks for resolving the editorial comments--this version looks quite a 
bit better. Here's some comments on the proposed version 05.

-- Section 2:

I think I missed this on the first round, but the reference to RFC7092 
for definitions needs to be normative if those references are important 
to understand this draft. That's a bit of an issue since 7092 is an 
informational RFC--but if it's the right thing to do we can still do it. 
(It just means we have to call out the normative reference to an 
informational RFC in the IETF last call.)

-- Section 4.1, 2nd paragraph:

You changed the first mention of passthrough to "optional ICE 
termination". But the paragraph goes on to mention "ICE passthrough". 
Did you mean to have both?

-- section 4.2, first sentence:

With the new terminology, I suggest saying "A B2BUA that wishes to 
_always_ be ..."

-- section 4.3, first sentence:

Likewise, I suggest" If a B2BUA is willing to be in the media path if 
needed for NAT traversal, but does not otherwise require it..."

-- Section 5, 2nd paragraph:

You clarified which appendix in the reference, but if you responded to 
my question about whether that guidance was security related, I missed 
it. The point of the question was that it wasn't clear to me why this 
was mentioned in the security considerations rather than elsewhere in 
the draft.

Thanks!

Ben.

[...]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 28 Apr 2015 06:41:41 +0000

Hi Ben,

Please see inline

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Tuesday, 28 April 2015 4:03 am
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [straw] AD Eval of draft-ietf-straw-b2bua-stun-04

>informational RFC in the IETF last call.)

Yes. I think it should be normative as the reference we make in 7092 [
about the different type of B2BUAs and its scope] is pretty important to
understand this draft.
So I will move the reference to normative.

>Did you mean to have both?

Removed the references to ICE passthrough and replaced it with optional
ICE termination every where.

>With the new terminology, I suggest saying "A B2BUA that wishes to

Sure. Changed

>needed for NAT traversal, but does not otherwise require it..."

Ok Changed.

>was mentioned in the security considerations rather than elsewhere in

On re-looking at Appendix A of 5245 I see that it does not give any
security considerations. So I am planning to remove this sentence from
draft.
Section 4.2 of the draft talks about ICE lite mode and refers to 5245
which describes LITE mode. So there is no need for this line in security
consideration.

Attached is new diff.

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 28 Apr 2015 15:28:10 -0500

Hi,

I think this version is ready to go to IETF last call. If the authors 
and chairs agree, please submit it and I will kick off the last call.

Thanks!

Ben.

On 28 Apr 2015, at 1:41, Ram Mohan R (rmohanr) wrote:

>>> Please see the diffs that I have incorporated, let me know if any 
>>> one
>>> has
>>> concerns with the same.
>>>
>>>
>>>
>> [...]
>
>
> [Diff_ draft-ietf-straw-b2bua-stun-04.txt - 
> draft-ietf-straw-b2bua-stun-05.txt.html]
>
> [draft-ietf-straw-b2bua-stun-05.txt]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 29 Apr 2015 03:07:40 +0000

Thanks Ben.

I just posted a revision of the draft.

Ram