Subject: [straw] Stephen Farrell's No Objection on draft-ietf-straw-b2bua-stun-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 12 May 2015 16:54:38 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-straw-b2bua-stun-05: No Objection

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-straw-b2bua-stun/

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

- 4.2, but maybe also elsewhere: should such a b2bua be
REQUIRED to announce itself as a b2bua that forces itself
into the media stream in some manner? Or more broadly, if we
are now (for the 1st time?) standardising b2bua behaviours,
then ought we mandate that such entities make their
prescence or even some flavour of their functionality known
in-band?  Even if we do not mandate such behaviour,
shouldn't we at least define how a b2bua that wants to be
visible ought do that? (And if we have done the above
already, or discussed and discarded the above already, then
great, and that shows how much I know:-)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 13 May 2015 12:30:57 +0000

Hi Stephen,

See inline

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Wednesday, 13 May 2015 5:24 am
To: The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Victor Pascual <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Stephen Farrell's No Objection on draft-ietf-straw-b2bua-stun-05:
(with COMMENT)

>https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/

RFC 7092  section 3.2.3 already defines media termination B2BUAs. We are
just defining how ICE
processing is done for such B2BUA.

Ram

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 May 2015 14:58:05 +0100

> processing is done for such B2BUA.

7092 is an informational taxonomy, which is a fine thing
but is not a standard. This draft is aiming to be a PS, so
I think my question has yet to be answered.

S.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 May 2015 09:13:27 -0500

Hi Stephen,

You are correct this would be the first PS to specify behavior for 
media-terminating B2BUAs. But the scope of the draft is strictly about 
behavior with ICE, not behavior in general. If we required an 
interception signal here, we would create the odd situation where B2BUAs 
that handle ICE are required to signal it, but media termination B2BUAs 
that don't do ICE don't have to.

I realize that is not a very satisfying answer. If we could find an 
author for a draft on privacy considerations for media terminating 
B2BUAs, I would support it.

Ben.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 May 2015 15:18:59 +0100

Hiya,

On 13/05/15 15:13, Ben Campbell wrote:
> media-terminating B2BUAs. 

Ok, thanks.

> But the scope of the draft is strictly about
> behavior with ICE, not behavior in general. 

That's totally fair.

> If we required an

Well, my question isn't (only) about privacy but more about
us defining a way for a b2bua that wants to be standards
compliant to show the rest of the universe that it's there.
I accept that some vendors and some deployments might not
do that but isn't there an onus on us to say how one might
do that, now that we're "blessing" b2bua's as being a thing
worth standardising?

If it were done, I agree it probably ought be a standalone
document just saying "here's how I, a b2bua, say I'm here"
probably with some discussion (if that discussion isn't
already all in 7092).

Cheers,
S.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 13 May 2015 14:20:57 +0000

Hi Ben, Stephen,

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Wednesday, 13 May 2015 7:43 pm
To: Stephen Farrell <[email-masked]>
Cc: Cisco Employee <[email-masked]>, The IESG <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Victor Pascual <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: Stephen Farrell's No Objection on
draft-ietf-straw-b2bua-stun-05: (with COMMENT)

>B2BUAs, I would support it.

The privacy considerations with B2BUAs when handling media are discussed
in 
https://tools.ietf.org/html/draft-ietf-straw-b2bua-dtls-srtp-00#section-4

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 May 2015 09:36:11 -0500

On 13 May 2015, at 9:20, Ram Mohan R (rmohanr) wrote:

>>>> RFC 7092  section 3.2.3 already defines media termination B2BUAs. 
>>>> We
>>>> are
>>>> just defining how ICE

Hey, look, another B2BUA PS :-)

 From Stephen's response to my email, I think "privacy considerations" 
may not have been the correct term. Nevertheless, this draft might be a 
better target for Stephen's original comment. (Assuming the value of 
such an "I'm in your media path" signal for cleartext media is marginal 
at best.)

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 May 2015 09:38:14 -0500

> media-terminating B2BUAs.

Oops, I spoke too soon--there is RFC 7332. But that one is way more 
specialized than this one :-)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 May 2015 15:39:11 +0100

Hiya,

> such an "I'm in your media path" signal for cleartext media is marginal

The security and privacy properties of such a signal will be
interesting and subtle all right, esp. if it's not universally
turned on as we might prefer. But: all's I was asking about
now is if we're gonna define the basic signal. (Really, I don't
think so far ahead mostly:-)

I'm totally happy if you put that definition wherever you think
best.

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 May 2015 11:23:44 -0400

> I'm totally happy if you put that definition wherever you think

Note that we also have the siprec work, where we *do* have a signal to 
indicate that there is something in the path messing with media. But 
that is also specialized.

We also have the isFocus indicator that is used in SIP signaling for 
conference servers - another special case of B2BUA.

And note that *some* B2BUAs (SBCs) are in some ways analogous to NATs. 
Is there any precedent about NATs signaling (or not) their presence that 
might be applicable to analogous B2BUAs?

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 13 May 2015 21:36:35 +0000

Hi Stephen - 

I’m forwarding this response from Paul Kyzivat that I don’t think you weren't copied on, but I do think is pertinent info to consider in the context of the response I am about to send you in another email.

Cheers,

Gonzalo

> Begin forwarded message:
> 
> From: Paul Kyzivat <[email-masked]>
> Subject: Re: [straw] Stephen Farrell's No Objection on draft-ietf-straw-b2bua-stun-05: (with COMMENT)
> Date: May 13, 2015 at 11:23:44 AM EDT
> To: <[email-masked]>
> 
> Note that we also have the siprec work, where we *do* have a signal to indicate that there is something in the path messing with media. But that is also specialized.
> 
> We also have the isFocus indicator that is used in SIP signaling for conference servers - another special case of B2BUA.
> 
> And note that *some* B2BUAs (SBCs) are in some ways analogous to NATs. Is there any precedent about NATs signaling (or not) their presence that might be applicable to analogous B2BUAs?
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 13 May 2015 22:29:13 +0000

> On May 13, 2015, at 10:39 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I’m glad you raised this point as I think it is useful to consider more broadly an explicit signaling mechanism for on-path B2BUA involvement/interference. As you have seen from various responses that what exists today are a variety of point solutions for very specialized B2BUA use-cases. Thus, I strongly feel trying that inserting it in this document is not appropriate as this happens to be yet another very specific case (that of B2BUA performing ICE processing).  

That said, we have been kicking around some ideas over the past few months about a more generic mechanism akin to what you are requesting.  At a high level it proposes the B2BUA explicitly register with a tag indicating/advertising it is a B2BUA. The idea being that once the endpoint knows it is know that it’s a B2BUA (and not the terminating endpoint) a decision can be made or policy applied. The specificity of the tag would need to be decided by the WG as to whether it is a generic B2BUA tag or a more granular tag indicating the type of B2BUA and its level of of involvement in the media path (in the context of RFC 7092). This is currently not in scope for the current milestones in STRAW. We were planning to raise this with the chairs to gauge interest in getting this work added. This would be the optimal course of action IMO.

> I'm totally happy if you put that definition wherever you think

Ooops...See above.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 May 2015 12:12:59 -0400

> That said, we have been kicking around some ideas over the past few months about a more generic mechanism akin to what you are requesting.  At a high level it proposes the B2BUA explicitly register…

ISTM that this is closely related to e2e security.

A fundamental fact of life with SIP is that the call establishment 
mechanism is built to support ambiguity about who the callee will be. 
Midpoint elements are given discretion about where the call is routed. 
And identification of who is on the other end isn't provided by default.

B2BUAs often capitalize on this. From a signaling perspective, the 
caller thinks the call is terminated by the first B2BUA in the call 
path. What happens beyond that point can be totally hidden from the caller.

*If* there was mutual authentication between the caller and the callee, 
and the caller was satisfied that the identified callee was who he 
wanted to be connected to, then there would be less need for 
identification of the identity and/or properties of intermediaries 
involved in setting up the signaling. Even then, there would be no 
assurance that the call was not being relayed to others by the known 
callee, but that is unavoidable and there is somebody to blame.

Absent that, it isn't evident to me that simply announcing the presence 
of B2BUAs would add much value.

	Thanks,
	Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 May 2015 18:13:58 +0100

> ISTM that this is closely related to e2e security.

I've got to say I don't see that myself, if what you meant was that
signalling middlebox presence is only worthwhile if one has a working
e2e security scheme. (Basing anything related to SIP on a presumption
of e2e security seems fairly fraught;-)

IIRC, one of the things from RFC3424 that I thought was spot-on was
the idea that if midleboxen declare their existence then things are
likely to work out better overall. So, I'd argue that defining some
way for b2buas to declare themselves would be useful and could find
uses. Whether implementers and deployments would bother to support
that and turn it on is a separate question, but if they did, then I
reckon it'd help in various ways, not all of which we might be able
to see today. And it'd at least create the potential to authenticate
those middleboxes to user agents and to one another without them
having to impersonate anyone.

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 May 2015 13:45:05 -0400

> of e2e security seems fairly fraught;-)

The rest of the message, after that first statement, elaborated on what 
I meant by that.

> having to impersonate anyone.

It is possible that having the indication would be helpful in some way. 
But other than using it to debug problems I can't imagine what that 
would be.

Note that there would be challenges to announcing it. For one thing, it 
would probably be necessary to signal the sorts of nuances in B2BUA 
features described in RFC7092. But beyond that would be getting the 
description to the interested parties. One of the primary uses of B2BUAs 
(SBCs) is to hide topology, names, and addresses of intermediaries. So 
it is likely that any information provided would be stripped out.

My main point is that if I knew who I thought I was talking to, and had 
the path secured to that entity, then it wouldn't matter so much what 
else is along the path. Right now the caller in some sense "thinks" it 
is talking to the first B2BUA on the path. But he doesn't know much 
about who that is, so he doesn't object.

	Thanks,
	Paul