Subject: [dispatch] BEHAVE for B2BUAs charter proposal

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Oct 2011 20:24:41 +0000

Howdy,
a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.

This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.

Interest/comments/flames welcomed.

Description of STRAW Working Group
====================================
Name: Sip Traversal Required for Applications to Work (STRAW)

Problem Statement: 
Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between. 

In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.

It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.

The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.

For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.

Objectives:
The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.  

Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.

The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.

Initial Deliverables:
1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.

[also add a taxonomy document?]

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 14 Oct 2011 15:34:08 -0500

> Description of STRAW Working Group

I would be interested in participating in this effort. I think this is 
an excellent first-draft charter proposal.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2011 17:53:21 -0400

Hadriel,

Yes, we had an informal dinner meeting on this, I think in Mastricht. 
(Weren't you at it?) And IIRC we could not convince ourselves that 
anything we might produce would have any effect to justify the effort.

But SBCs continue to be ubiquitous on real deployments, and we continue 
to try to adjust new work so it will work with SBCs without any real 
specifications about how to do that.

So I do think there is justification for work on this subject. But the 
devil is in the details of exactly what the result of the work will be. 
I appreciate your effort to put together a charter that spells out a 
work plan. I think it is a reasonable start. But we should hammer on it, 
and eventually polish it, until we have a really clear direction that 
people buy into.

I'd be interested in working on this.

More inline.

	Thanks,
	Paul

> Description of STRAW Working Group

The key above is "for specific functions to work".
IMO enumerating what those things are will be a real task.
Even defining what sorts of things ought to be considered "functions" 
may be hard.

I think we need to at least agree as part of the charter what sorts of 
things need to be enumerated.

> Deliverables would indicate which types of B2BUAs would apply or not.

In the problem statement you seemed to declining to define types of 
B2BUAs. But here you seem to be suggesting that we have such a 
classification.

While I think the potential functions of B2BUAs is unbounded, I suspect 
it is possible to define some interesting types, and constrain what they 
do sufficiently to be useful.

SIP already did this, to a lesser degree than you are seeking: UA, 
Proxy, Registrar, Focus, Transcoder. (Transcoder is defined in 5369, but 
not in a form that puts it in the signaling path between UAC and UAS.)

> For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>

So, from the above I conclude that some examples of the "functions" you 
are considering are: loop detection/prevention, media-loopback test 
calls, media connectivity, media security.

> [also add a taxonomy document?]

Maybe two: taxonomy of functions, taxonomy of B2BUA types.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Oct 2011 23:17:07 +0000

On Oct 14, 2011, at 5:53 PM, Paul Kyzivat wrote:

> Yes, we had an informal dinner meeting on this, I think in Mastricht. (Weren't you at it?)

Not as far as I can recall. (and no I didn't partake of the "coffee shops" in Maastricht :)

> Even defining what sorts of things ought to be considered "functions" may be hard.
> I think we need to at least agree as part of the charter what sorts of things need to be enumerated.

You mean agree on what specific things in the future could be included in the charter in the future?

I'm thinking of just using the deliverables list for that level of detail.  Any change to deliverables requires a re-charter/update anyway right?  So we get to decide if something new is reasonable at that time.

> In the problem statement you seemed to declining to define types of B2BUAs. But here you seem to be suggesting that we have such a classification.

In the deliverable itself, ie inside the specific document/RFC, rather than saying the STRAW working group would only cover "SBCs" for example. 

But I was thinking we could have a taxonomy doc which enumerated B2BUA types as much as possible, so that the individual docs could just use the terms without repetition.

> So, from the above I conclude that some examples of the "functions" you are considering are: loop detection/prevention, media-loopback test calls, media connectivity, media security.

Ahh, no.  By "function" I didn't mean high-level thing like "media security".  I meant for a specific capability/extension/usage - i.e., one for DTLS-SRTP, a separate one for SDES, etc.  At least as a general rule I would expect discrete documents on discrete capabilities.  Obviously it would be up to the WG to decide that on a case-by-case basis anyway, and for DTLS-SRTP/SDES-SRTP they may decide to do both in one RFC.  I mean WG's make those types of decisions on deliverables in general anyway, but I put it in the charter as a guideline, so the WG would consciously make such a decision. (I guess this seems silly in hindsight)

-hadriel

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 14 Oct 2011 19:56:49 -0400

Dear Hadriel;

On Fri, Oct 14, 2011 at 4:24 PM, Hadriel Kaplan <[email-masked]> wrote:
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".

Yes. I organized this, at Maastricht, although it wasn't BEHAVE
specific. The conclusion was that SBCs had gotten away from us (i.e.,
that there is no standard definition of what an SBC does) and so there
wasn't consensus to take this further inside the IETF.

Regards
Marshall

 I do not know the conclusion of the discussion, but it appears there
was not enough interest at the time, or perhaps not enough concrete
work to do and people to do it.  Since that time, we've had several
I-Ds which could arguably fit in such a WG, or at least benefit from
one, if it applied to B2BUAs in general.
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Oct 2011 14:52:45 +0200

The essential blocker in Maastricht was that noone could identify a plan of work where it was expected that there might be consensus on the output.

Has that changed?

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 14 October 2011 22:53
> To: [email-masked]
> Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
> 
> Hadriel,
> 
> > a year ago or so, there was a thread and informal bar-bof around the
> topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the
> conclusion of the discussion, but it appears there was not enough interest
> at the time, or perhaps not enough concrete work to do and people to do
> it.  Since that time, we've had several I-Ds which could arguably fit in
> such a WG, or at least benefit from one, if it applied to B2BUAs in
> general.
> >
> > This email is to see if there's interest now, but with a slightly
> different tack: a concrete WG charter proposal, as described below.
> >
> > Within the context of the SIP protocol and architecture, a Back-to-Back
> User Agent (B2BUA) is any SIP device in the logical path between two User
> Agents performing a role beyond that of a Proxy as defined in RFC 3261.
> The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in
> order to terminate dead sessions by generating BYEs; or it may be a 3PCC-
> style agent only modifying SDP; or it may be a Session Border Controller
> performing such functions as in RFC 5853; or it may be an Enterprise PBX
> terminating REFERs and such; or it may be a complete UAS and UAC
> implementation with a PRI loopback in-between.
> >
> > In its most extreme form, the scope of the SIP protocol ends at the UAS
> of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In
> practice, however, users expect some SIP protocol aspects to go beyond the
> scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if
> the B2BUA was not an end unto itself; this is similar to the expectation
> that emails work when they cross from POP and IMAP to/from SMTP.
> >
> > It is impossible to normatively define all the behaviors of B2BUAs in
> general, or even subsets of them such as SBCs. Unlike consumer NATs,
> B2BUAs perform widely varying functions for purposes which may be unique
> to their environment, unique to their architecture, or unique to the
> wishes of their administrator.  Instead of defining all things a given
> type of B2BUA must do, a more practical objective would be to define what
> very few things any B2BUA must do to make a specific SIP mechanism work,
> and let the market decide whether to do those things.
> >
> > The name of this working group reflects that practical objective: if
> there were a thin straw between the SIP UAS and UAC of a B2BUA, what must
> be passed through that straw and used on each side.  Or viewed another
> way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback
> circuit, and if we could extend ISDN, what information would we carry in
> ISDN across the PRI for a specific SIP mechanism to work end-to-end.
> >
> > For example, the WG could produce a document which specifies that the
> Max-Forwards header field value should be copied and decremented across
> the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could
> then tell their B2BUA vendors to comply with the document, if the
> administrator so wishes.
> >
> > Objectives:
> > The objectives of the STRAW Working Group are to publish normative
> documents which define which SIP header fields, parameters, MIME bodies,
> body content fields/information, or media-plane characteristics are
> required to traverse between the User Agent "sides" of a B2BUA for
> specific functions to work.
> 
> > For example, a document defining the requirements for end-to-end DTLS-
> SRTP would not apply to B2BUAs which terminate media, such as transcoders
> or recorders.
> >
> > The intention of this WG is to document such requirements in separate
> documents, per SIP or media function, instead of as one document for all
> functions.  That will both reduce the time to publication, as well a
> provide B2BUA administrators and manufacturers with simple comply/no-
> comply criteria.
> >
> >
> > Initial Deliverables:
> > 3) A document defining the requirements for B2BUAs to support end-to-end
> and hop-by-hop media-loopback test calls.

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 15 Oct 2011 18:29:41 +0300

the subject is really interesting,
I like the idea to concentrate on a thin straw between the SIP UAS and UAC,
and specified what should (not sure if we can say MUST) be passed 
through that straw and used on each side.

this is a good start for a concrete charter proposal.

Ciao
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 11:35:20 +0530

Hadriel,

As Paul & others mentioned, there is a Bar Bof on SBC (one kind of
B2BUA) discussion in IETF-78 and there is no convergence. The aim of the
SBC Bar BOF meeting was to come up with Behave for SBC and not generic
B2BUA. The conclusion of the Bar BOF was that there is no way to define
exactly whatz SBC is in IETF? Also, it is possible to fix some of the
SBC issues in case the pattern of the issues is spelt out correctly in
IETF. 

Looking at the some of the proposed B2BUA work item, I guess that your
proposal is more lean towards B2BUA with media relay (RTP translator or
RTP endpoint to RTP endpoint) functionality. Some of the B2BUA
(Signaling only SBC) are signaling boxes and does not handle media
directly. In case B2BUA performs supplementary services handling, the
behavior is very different from passing the signaling through B2BUA.
Another variant wherein B2BUA with supplementary services may acts as
RTP translator. All the behavior are supported by different SBC in the
deployment. Hope you agree with me.

Infact, SIPConnect 1.1 standardization helps interop between SP SBC and
Enterprise SBC. Whether SIPConnect 1.2 shall solve your proposed issues
as the basic interop is ensured through SIPConnect 1.1. Here I'm
interested to know how this WG is different from what SIPConnect
achieves.

Also, most of your WG items are related to media (STUN, DTLS-SRTP,
SDES-SRTP). There is an existing WG item
(draft-ietf-mmusic-media-path-middleboxes-03.txt) which shall solve some
of the problem in case there is proper review and consensus.   

I'll be interested in your charter in case your charter is different
from future extension possibility of SIPConnect 1.2,
draft-ietf-mmusic-media-path-middleboxes-03.txt (SDP offer/answer),
session-id charter (loop detection),
draft-ietf-mmusic-media-loopback-16(media loopback). BTW, I guess that
hop-by-hop media loopback was proposed earlier.

Thanks
Partha

>Behalf Of Hadriel Kaplan
>Sent: Saturday, October 15, 2011 4:47 AM
>To: Paul Kyzivat
>Cc: <[email-masked]>
>> Yes, we had an informal dinner meeting on this, I think in
Maastricht.
>(Weren't you at it?)
>I'm thinking of just using the deliverables list for that level of
>detail.  Any change to deliverables requires a re-charter/update anyway
>right?  So we get to decide if something new is reasonable at that
time.
>In the deliverable itself, ie inside the specific document/RFC, rather
>than saying the STRAW working group would only cover "SBCs" for
example.
>
>But I was thinking we could have a taxonomy doc which enumerated B2BUA
>types as much as possible, so that the individual docs could just use
>the terms without repetition.
>
>>>
>>> Initial Deliverables:
>>> 3) A document defining the requirements for B2BUAs to support
end-to-
>end and hop-by-hop media-loopback test calls.
>> So, from the above I conclude that some examples of the "functions"
>you are considering are: loop detection/prevention, media-loopback test
>Ahh, no.  By "function" I didn't mean high-level thing like "media
>security".  I meant for a specific capability/extension/usage - i.e.,
>one for DTLS-SRTP, a separate one for SDES, etc.  At least as a general
>rule I would expect discrete documents on discrete capabilities.
>Obviously it would be up to the WG to decide that on a case-by-case
>basis anyway, and for DTLS-SRTP/SDES-SRTP they may decide to do both in
>one RFC.  I mean WG's make those types of decisions on deliverables in
>general anyway, but I put it in the charter as a guideline, so the WG
>would consciously make such a decision. (I guess this seems silly in
>hindsight)
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Oct 2011 14:34:45 +0000

> deployment. Hope you agree with me.

Yup.  And thus the charter I'm proposing is not about "SBCs" - it's about B2BUAs, and for both signaling-only and signaling+media plane B2BUAs.

> interested to know how this WG is different from what SIPConnect

SIPConnect is about the logical connection between an Enterprise and a Service Provider, defining a profile for basic behavior across that connection.  SIPConnect (and the SIP Forum itself) does not create standards, and as a profile merely says which standards should be supported for interop to work.  SIPConnect does not define behavior for particular devices, and doesn't even require there be B2BUAs (nor should it).  

In contrast, the STRAW Working Group I'm proposing would focus on defining very specific requirements for B2BUAs, in order for discrete SIP/media functions to work across them.  STRAW would not be a holistic "how do we make SIP trunks work" type thing but rather about specific mechanisms, nor would it focus solely on SIP trunks but rather be general.  This is at a different layer and scope than SIPConnect.

> of the problem in case there is proper review and consensus.   

I don't think so.  For one thing, it's basically a dead draft.  For another, it has lots of problems.  For example, see the email thread starting here:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html

> hop-by-hop media loopback was proposed earlier.

I don't know of any prior draft proposing hop-by-hop traceroute-type mechanism for media-loopback.  The draft-ietf-mmusic-media-loopback-16 mechanism itself is not the issue.

The session-id mechanism is *not* about loop detection. (and it's dangerous to use it for loop detection)
I plan to submit a draft for loop detection this week, but it's not too controversial I think - it just uses Max-Forwards and Max-Breadth as one would expect.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 11:15:00 -0400

Hadriel,

A question about your approach:

On 10/17/11 10:34 AM, Hadriel Kaplan wrote:

> In contrast, the STRAW Working Group I'm proposing
> would focus on defining very specific requirements for B2BUAs,
> in order for discrete SIP/media functions to work across them.
> STRAW would not be a holistic "how do we make SIP trunks work"
> type thing but rather about specific mechanisms,
> nor would it focus solely on SIP trunks but rather be general.

So, today we have a bunch of RFCs that define the various behaviors that 
constitute "SIP". And most of them define behaviors for various sorts of 
elements (UAC, UAS, Proxy, Registrar).

Determining compliance is then a matter of saying "this box conforms to 
RFC XYZ in the role of a (UAC, UAS, UA, Proxy, etc.)" Somebody drafting 
a purchase spec for equipment to build a sip *system* has to call out 
the components desired and the compliance required of each.

Groups like SIPForum, 3GPP, CableLabs define more elaborate profiles of 
what conformance means. But typically it comes down to saying that a box 
conforms to some list of RFCs while acting in one or more of those 
roles. Most of those also define how certain "features" should be 
realized using the basic sip mechanisms, and ensure that the RFCs 
defining those sip mechanisms are included in those called out for 
compliance. Doing a purchase spec for a system based on one of those 
specs is a matter of referencing the group-developed spec.

I guess you are proposing to develop a number of additional RFCs that 
will each define the behavior of a B2BUA in order that some particular 
"function" will work end-to-end even when the B2BUA is present between 
the ends.

Someone who is developing a purchase spec by themselves would then need 
to identify which of the "functions" are needed, and require compliance 
to them, in addition to other things. Its not clear to me whether this 
will be something well known to those building a system, or not. (It 
seems to require a level of understanding of how features are 
implemented that may exceed what a purchaser should be expected to know.)

In the case of the group-based specs, I suppose it would fall on the 
group to identify which of these new RFCs are important and require 
them. But it seems to me those groups have already defined the behavior 
required of B2BUAs in their systems, so this might not help them at all.

Can you please clarify how what you are proposing would typically be used?

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Oct 2011 17:16:10 +0200

> Interest/comments/flames welcomed.
I think it's high time to start this work. We have seen the need for it in the discussions around Asterisk
for a very long time. One could easily add SIP Identity for User Agents to this list, as RFC 4744 is 
horribly underspecified in this regard...

/O
> Description of STRAW Working Group

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Oct 2011 16:44:06 +0000

On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:

> I guess you are proposing to develop a number of additional RFCs that will each define the behavior of a B2BUA in order that some particular "function" will work end-to-end even when the B2BUA is present between the ends.
> 
> Someone who is developing a purchase spec by themselves would then need to identify which of the "functions" are needed, and require compliance to them, in addition to other things. Its not clear to me whether this will be something well known to those building a system, or not. (It seems to require a level of understanding of how features are implemented that may exceed what a purchaser should be expected to know.)
> 
> In the case of the group-based specs, I suppose it would fall on the group to identify which of these new RFCs are important and require them. But it seems to me those groups have already defined the behavior required of B2BUAs in their systems, so this might not help them at all.
> 

I would expect that RFCs published by the STRAW WG would be used in the same way as other RFCs published by the RAI area: by manufacturers/developers/product-managers, by system purchasers, and by other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs, SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing them.

For system purchasers: it's true that many wouldn't know the level of detail required to know to reference such an RFC, but it's also true that many *do* know such things. (or at least that appears to be the case, since I see plenty of RFIs/RFPs that are that detailed)

For device manufacturers: a lot of them already know what they need to do for most things, but a lot of them apparently don't know, or don't care, or can't due to their architecture.  Take the Max-Forwards case, for example: plenty of B2BUAs create a new/reset Max-Forwards header value on their UAC side for forwarded requests.  We've seen this cause unbounded loops in real deployed networks.  Either the B2BUA vendors don't know better, or don't care, or can't do it.  Having a published RFC means that the purchasers can point to a MUST statement in an RFC and tell the vendor to do it, or if the vendor can't do it then the purchaser can (a) know the vendor can't and take some other steps to prevent loops, and/or (b) decide to choose another vendor.

For "group-based-specs": it's true some of them define behavior of B2BUA's in their group-system (not all of them do, BTW)... and obviously some or even all RFCs created in STRAW might not help those groups at all.  That's ok.  They don't need our help.  But there are a lot of SIP domains built that are not based on group-specs.  Virtually every Enterprise SIP deployment, for example.  And I think for some functions, the IETF is the most logical place to define how it works across B2BUAs because the technical competence/knowledge for the particular function is in the IETF.  Like the DTLS-SRTP case, for example.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 13:55:17 -0400

Hadriel,

OK, I guess you see it the same was I was interpreting it.
I certainly agree that having this info is better than *not* having it.
But it will further increase what must be understood to correctly spec a 
system to be assembled out of piece parts. Without this info its hard to 
spec it at all - you have to hope for the best, that your vendors can 
tweak things until the system works.

If all goes well, the existence of a spec for some function will lead 
those who make B2BUAs think "maybe I should support that", where 
previously they weren't forced to think about it at all.

ISTM it would be *nicer* if we could have classifications for different 
sorts of B2BUAs, and rules for their behavior, as we have for UAs and 
Proxies. But it may be that real devices don't fall into those neat 
classifications well enough for that to work in practice. And what you 
propose doesn't preclude doing that later.

	Thanks,
	Paul

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Mon, 17 Oct 2011 13:52:54 -0400

> This email is to see if there's interest now, but with a slightly
different
> tack: a concrete WG charter proposal, as described below.

This is sorely needed. I would be interested in participating.

Cheers,
Shaun

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Hadriel Kaplan
> Sent: Friday, October 14, 2011 4:25 PM
> To: [email-masked] list
> Subject: [dispatch] BEHAVE for B2BUAs charter proposal
> 
> Howdy,
topic of
> "Should the IETF have a BEHAVE WG for SBCs".  I do not know the
conclusion of
> the discussion, but it appears there was not enough interest at the
time, or
> perhaps not enough concrete work to do and people to do it.  Since
that time,
> we've had several I-Ds which could arguably fit in such a WG, or at
least
> benefit from one, if it applied to B2BUAs in general.
> 
different
> tack: a concrete WG charter proposal, as described below.
> 
> Within the context of the SIP protocol and architecture, a
Back-to-Back User
> Agent (B2BUA) is any SIP device in the logical path between two User
Agents
> performing a role beyond that of a Proxy as defined in RFC 3261.  The
B2BUA
> may be as simple as a session-stateful Proxy becoming a B2BUA in order
to
> terminate dead sessions by generating BYEs; or it may be a 3PCC-style
agent
> only modifying SDP; or it may be a Session Border Controller
performing such
> functions as in RFC 5853; or it may be an Enterprise PBX terminating
REFERs
> and such; or it may be a complete UAS and UAC implementation with a
PRI
> loopback in-between.
> 
> In its most extreme form, the scope of the SIP protocol ends at the
UAS of the
> B2BUA, and a new SIP protocol scope begins on its UAC side.  In
practice,
> however, users expect some SIP protocol aspects to go beyond the scope
of the
> B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA
was not
> an end unto itself; this is similar to the expectation that emails
work when
> they cross from POP and IMAP to/from SMTP.
> 
general,
> or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs
perform
> widely varying functions for purposes which may be unique to their
> environment, unique to their architecture, or unique to the wishes of
their
> administrator.  Instead of defining all things a given type of B2BUA
must do,
> a more practical objective would be to define what very few things any
B2BUA
> must do to make a specific SIP mechanism work, and let the market
decide
> whether to do those things.
> 
there
> were a thin straw between the SIP UAS and UAC of a B2BUA, what must be
passed
> through that straw and used on each side.  Or viewed another way, if a
B2BUA
> were in fact a UAS and UAC connected with a PRI loopback circuit, and
if we
> could extend ISDN, what information would we carry in ISDN across the
PRI for
> a specific SIP mechanism to work end-to-end.
> 
Max-
> Forwards header field value should be copied and decremented across
the B2BUA,
> if the B2BUA wishes to prevent loops.  Administrators could then tell
their
> B2BUA vendors to comply with the document, if the administrator so
wishes.
> The objectives of the STRAW Working Group are to publish normative
documents
> which define which SIP header fields, parameters, MIME bodies, body
content
> fields/information, or media-plane characteristics are required to
traverse
> between the User Agent "sides" of a B2BUA for specific functions to
work.
> Deliverables would indicate which types of B2BUAs would apply or not.
For
> example, a document defining the requirements for end-to-end DTLS-SRTP
would
> not apply to B2BUAs which terminate media, such as transcoders or
recorders.
> functions.  That will both reduce the time to publication, as well a
provide
> B2BUA administrators and manufacturers with simple comply/no-comply
criteria.
> 
> 
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify
specific
> features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to
loop
> detection/prevention.
end-to-end and
> hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support
DTLS-SRTP (RFC
> 5764) end-to-end.

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Mon, 17 Oct 2011 22:03:03 +0200

Think it shall be RFC4474

Agree, it is underspecified and in parts to some extents way overloaded.
- Signs elements that will be modified by SBCs
- Signs things that have only marginally to do with the originators identity
- does nit clearly distinguish between the originators domain and a phone number
- ...

However it seems to be quite difficult and likely becomes even more complex if we add things like federations and cross PKI certificate acceptance.

My guess is that we to take a lot of usability issues in to consideration if we want to make it really useful. e.g. initial enrollment and certificate renewal.

Besides usability, one shall think about reducing the functionality to sign the originating identity and domain only. This still would allow to protect the sip message by other means. This approach has the advantage of separating transport security and the originating identity. With this clear separation, authentication would become transparent to SBCs and other servers in the setup path. With that, any element in the call path can validate the caller ID and decide on further authorization. This would also be relevant for the recently signed CALLER-ID Act.

Willi

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 16:31:30 -0400

> Besides usability, one shall think about reducing the functionality to sign the originating identity and domain only. This still would allow to protect the sip message by other means. This approach…

IIUC you are in essence suggesting signing a blank sheet of paper and 
then sending it. The recipient will know that the sheet was blank when 
signed, and gets to decide whether to believe other stuff on the 
received sheet.

When you say "protecting the message by other means", presumably you 
mean transitive trust, since a lot of what matters in the message is 
changed by the B2BUAs. The point of 4474 was to get beyond transitive trust.

	Thanks,
	Paul

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Mon, 17 Oct 2011 22:53:12 +0200

On 17.10.2011, at 22:31, Paul Kyzivat wrote:

> IIUC you are in essence suggesting signing a blank sheet of paper and then sending it. The recipient will know that the sheet was blank when signed, and gets to decide whether to believe other stuff on the received sheet.

Not really a blank shet of paper ;-). Just the identity of the originator but not the parts of the message that can be changed on link by link. Other elements shall be protected link by link if necessary. As such the digest will be reduced to a minimum and can be forwarded transparently throughout the chain.

> 
> When you say "protecting the message by other means", presumably you mean transitive trust, since a lot of what matters in the message is changed by the B2BUAs. The point of 4474 was to get beyond transitive trust.

Guess transitive is the best way since all other stuff can only be protected on a link by link base. Did we not have the same problem with IPsec as well?

On top of this, I believe that the final solution must be a user centric authentication anyhow and with that we can only accept a digest with information that will not be modified throughout the communication path. e.g. originating id, terminating id and possibly the timestamp. 

Thanks

Willi

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 03:37:37 +0530

Hadriel/Paul,

I like the idea of classification of B2BUA because it helps to
understand the function (service) of specific classification of B2BUA.
Few of the B2BUA classification shall be

1) 3PCC
2) SBC (SIP signaling normalization only)
3) 3PCC + media handling
4) SBC + media handling

Thanks
Partha

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Monday, October 17, 2011 11:25 PM
>To: Hadriel Kaplan
>Cc: Ravindran Parthasarathi; <[email-masked]>
>>> Someone who is developing a purchase spec by themselves would then
>need to identify which of the "functions" are needed, and require
>compliance to them, in addition to other things. Its not clear to me
>whether this will be something well known to those building a system,
or
>not. (It seems to require a level of understanding of how features are
>> I would expect that RFCs published by the STRAW WG would be used in
>the same way as other RFCs published by the RAI area: by
>manufacturers/developers/product-managers, by system purchasers, and by
>other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs,
>SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing them.
>>
>> For system purchasers: it's true that many wouldn't know the level of
>detail required to know to reference such an RFC, but it's also true
>that many *do* know such things. (or at least that appears to be the
>case, since I see plenty of RFIs/RFPs that are that detailed)
>>
>> For device manufacturers: a lot of them already know what they need
to
>do for most things, but a lot of them apparently don't know, or don't
>care, or can't due to their architecture.  Take the Max-Forwards case,
>for example: plenty of B2BUAs create a new/reset Max-Forwards header
>value on their UAC side for forwarded requests.  We've seen this cause
>unbounded loops in real deployed networks.  Either the B2BUA vendors
>don't know better, or don't care, or can't do it.  Having a published
>RFC means that the purchasers can point to a MUST statement in an RFC
>and tell the vendor to do it, or if the vendor can't do it then the
>purchaser can (a) know the vendor can't and take some other steps to
>prevent loops, and/or (b) decide to choose another vendor.
>>
>> For "group-based-specs": it's true some of them define behavior of
>B2BUA's in their group-system (not all of them do, BTW)... and
obviously
>some or even all RFCs created in STRAW might not help those groups at
>all.  That's ok.  They don't need our help.  But there are a lot of SIP
>domains built that are not based on group-specs.  Virtually every
>Enterprise SIP deployment, for example.  And I think for some
functions,
>the IETF is the most logical place to define how it works across B2BUAs
>because the technical competence/knowledge for the particular function
>is in the IETF.  Like the DTLS-SRTP case, for example.
>>
>> -hadriel
>>
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Oct 2011 22:17:32 +0000

Have you looked at:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-taxonomy-00.txt

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 03:59:54 +0530

Hadriel,

Thanks for sending B2BUA taxonomy draft. It will be good starting point
to discuss. I'll review and provide my comments.

Thanks
Partha

>From: Hadriel Kaplan [mailto:[email-masked]]
>Sent: Tuesday, October 18, 2011 3:48 AM
>To: Ravindran Parthasarathi
>Cc: Paul Kyzivat; <[email-masked]>
>>> But it will further increase what must be understood to correctly
>spec
>> a
>>> system to be assembled out of piece parts. Without this info its
hard
>>>>> Can you please clarify how what you are proposing would typically
>be
>>> used?
>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 18 Oct 2011 09:57:21 +0530

I would be interested in this work and this is a good start. We have a
lot of B2BUA that continues to add lots of functionalities without any
real specifications on how to do that. 
I will review your taxonomy draft and provide my comments.

Regards,
Ram

> Sent: Saturday, October 15, 2011 1:55 AM
> topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know
> the conclusion of the discussion, but it appears there was not enough
> interest at the time, or perhaps not enough concrete work to do and
> people to do it.  Since that time, we've had several I-Ds which could
> arguably fit in such a WG, or at least benefit from one, if it applied
> to B2BUAs in general.
> 
Back-to-Back
> User Agent (B2BUA) is any SIP device in the logical path between two
> User Agents performing a role beyond that of a Proxy as defined in RFC
> 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming
> a B2BUA in order to terminate dead sessions by generating BYEs; or it
> may be a 3PCC-style agent only modifying SDP; or it may be a Session
> Border Controller performing such functions as in RFC 5853; or it may
> be an Enterprise PBX terminating REFERs and such; or it may be a
> complete UAS and UAC implementation with a PRI loopback in-between.
> 
UAS
> practice, however, users expect some SIP protocol aspects to go beyond
> the scope of the B2BUA's UAS side, and be traversed onto its UAC side,
> as if the B2BUA was not an end unto itself; this is similar to the
> expectation that emails work when they cross from POP and IMAP to/from
> SMTP.
> 
> B2BUAs perform widely varying functions for purposes which may be
> unique to their environment, unique to their architecture, or unique
to
> the wishes of their administrator.  Instead of defining all things a
> given type of B2BUA must do, a more practical objective would be to
> define what very few things any B2BUA must do to make a specific SIP
> mechanism work, and let the market decide whether to do those things.
> 
> there were a thin straw between the SIP UAS and UAC of a B2BUA, what
> must be passed through that straw and used on each side.  Or viewed
> another way, if a B2BUA were in fact a UAS and UAC connected with a
PRI
> loopback circuit, and if we could extend ISDN, what information would
> we carry in ISDN across the PRI for a specific SIP mechanism to work
> end-to-end.
> 
> documents which define which SIP header fields, parameters, MIME
> bodies, body content fields/information, or media-plane
characteristics
> are required to traverse between the User Agent "sides" of a B2BUA for
> SRTP would not apply to B2BUAs which terminate media, such as
> transcoders or recorders.
> 
> documents, per SIP or media function, instead of as one document for
> all functions.  That will both reduce the time to publication, as well
> a provide B2BUA administrators and manufacturers with simple
comply/no-
specific
loop
> detection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-
DTLS-SRTP
> (RFC 5764) end-to-end.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 18 Oct 2011 09:00:15 +0200

> Besides usability, one shall think about reducing the functionality to sign the originating identity and domain only. This still would allow to protect the sip message by other means. This approach…
Seems like there are some issues to discuss here. Also, why is not the Identity-Info header signed? It points to where
the certificate exists, but can easily be changed by middlemen unless I've missed something.

/O

---

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 13:48:50 +0000

> the certificate exists, but can easily be changed by middlemen unless I've missed something.

It doesn't matter if the Identity-Info header is changed by a middleman.  Doing so doesn't help the middleman lie about anything.  

Either the middleman modifies the Identity-Info to point to a different certificate, which will correctly invalidate the 4474 signature (which a middleman can do any number of other ways).  Or the middleman can point to a different location for the same certificate so the signature remains valid, but that still doesn't help the middleman do anything since it can't change the SIP message without invalidating the signature.

-hadriel

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 19 Oct 2011 09:55:38 +0200

Correct!

 The validation will fail in either case. However, in case the whole message including the identity info is changed, the validation relies on the trust-relation to the trusted third party which of course will be rejected due to the fact, that there is no CA certificate for the fake certificate-authority in the system of the relying party. In that case, a weak validation code can open a loophole if they do not traverse the whole chain.
... just think about people that answer to all web-browser certificate validation requests with "Always Trust" because they do not know better.

Such cases are more likely with an unsigned identity info.

Willi

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Oct 2011 09:22:43 -0600

As Hadriel points out, including it does not improve the security and by not including it, it makes it easier to provide alternative methods to get the certificate in the future. Some people preferred an HTTP approach, other SIP, and in the P2PSIP case you might want to do if very differently. I don't think it's a big deal one way or the other, but not signing as many things as possible make some types of extensions and changes easier.  

On separate note, much of the design of 4474 was done to meet B2BUA use cases yet none of that is written down in any coherent form. I can certainly see value in a WG such as straw documenting some of the ways that B2BUA can use and work with 4474.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 27 Oct 2011 17:37:12 +0200

> On separate note, much of the design of 4474 was done to meet B2BUA use cases yet none of that is written down in any coherent form. I can certainly see value in a WG such as straw documenting some…
Agree.
>> Either the middleman modifies the Identity-Info to point to a different certificate, which will correctly invalidate the 4474 signature (which a middleman can do any number of other ways).  Or the…

Well, my current network object to hate is the SSL HTTP Proxys. In SIP, that would mean a proxy that rips out identity and identity-info and resigns with another certificate, that is approved in the ua's.

After reading your responses, I ACK that signing identity-info doesn't matter. Need to put my thinking hat on again, I suppose.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 17:54:24 +0000

> On separate note, much of the design of 4474 was done to meet B2BUA use cases yet none of that is written down in any coherent form. I can certainly see value in a WG such as straw documenting some…

Oh that'll be fun.  Should we start by going back to the massive email threads five years ago and hitting "re-send"?  
:)

The STRAW concept is to document what very little needs to be passed from the UAS to UAC side of B2BUAs to make something work.  I'm not sure a STRAW is big enough for 4474 - probably needs a PIPE (Providing Identity by Passing Everything).  ;)

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 31 Oct 2011 09:59:30 +0100

> Oh that'll be fun.  Should we start by going back to the massive email threads five years ago and hitting "re-send"?  
;-)
I would appreciate any pointers if you can memorize some keywords and find them though. Would be good to get some background reading.

> The STRAW concept is to document what very little needs to be passed from the UAS to UAC side of B2BUAs to make something work.  I'm not sure a STRAW is big enough for 4474 - probably needs a PIPE…

Right :-)

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 17:06:00 +0000

> I would appreciate any pointers if you can memorize some keywords and find them though. Would be good to get some background reading.

Some thread starting points spanning a few years:
http://www.ietf.org/mail-archive/web/sip/current/msg14996.html
http://www.ietf.org/mail-archive/web/sip/current/msg23939.html
http://www.ietf.org/mail-archive/web/sip/current/msg24361.html
http://www.ietf.org/mail-archive/web/sip/current/msg27169.html

I'm sure there are many more email threads.

Some drafts about the problems with 4474 and/or attempts to solve them, which probably spurred email threads and thus can be used to search for them:
draft-elwell-sip-e2e-identity-important-03
draft-rosenberg-sip-identity-coexistence-00
draft-rosenberg-sip-rfc4474-concerns-00
draft-wing-sip-identity-media-02
draft-fischer-sip-e2e-sec-media-00
draft-kaplan-sip-uris-change-00
draft-kaplan-sip-asserter-identity-01
draft-kaplan-sip-baiting-attack-02

phone-number issues relevant to identity/4474:
draft-elwell-sip-e164-problem-statement-01
draft-schwartz-sip-e164-ownership-01
draft-wing-sip-e164-rrc-01
draft-darilion-sip-e164-enum-00

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 31 Oct 2011 19:36:52 +0100

> draft-darilion-sip-e164-enum-00

Thank you. Seems like I need to get stuck in an airport again...

/O :-)