Subject: [Simple] Draft ACE: ALG terminology

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Jun 2011 13:07:19 -0400

Howdy,
In the latest ACE draft sessmatch-12 (and previous versions of sessmatch), the term "ALG" is used to describe the middlebox.  I think this causes mass confusion and angst for people.  An "ALG" is generally used to describe a function that performs protocol modification in an inline fashion, without being an addressed entity - for example inside a router or NAT - by inspecting packet contents unbeknownst to the client application.  That is NOT what the ACE extension is meant to enable, afaik; nor is ACE necessary to enable such.  

For example, a 3GPP IBCF is not an "ALG", nor is a P-CSCF+BGF, nor is an SBC.  Instead, they are addressed hosts - the hosts to which the SIP+MSRP UAs target their packets/connections.  From a SIP perspective, such hosts are B2BUA's not ALGs; and from an MSRP perspective such hosts are transport relays, similar to SOCKS relays.  

This is not a small difference.  True "ALGs", such as those in routers/NATs, cannot be easily avoided by host applications, except by obfuscating their protocol traffic (e.g., by using encryption, or changing port numbers); and if they happen to use encryption or authentication then the ALG function no longer works, if it was needed.  A SIP B2BUA/Proxy, on the other hand, is addressed by the host application - the application can use TLS or IPsec to the B2BUA, or avoid the B2BUA by addressing a different next-hop.

The reason I bring this up is that several emails so far seem to believe this is actually about ALGs, and raise concerns about accommodating such devices.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 19:58:39 +0200

> This is not a small difference.  True "ALGs", such as those in routers/NATs, cannot be easily avoided by host applications, except by obfuscating their protocol traffic (e.g., by using encryption,…

I understand the rest of your mail, but don't get what you mean in
this last paragraph in which you are talking about ALG-enabled devices
(as routers) and B2BUA's.

Of course a B2BUA handles the application protocol at application
level, so it does not perform ALG functions.

In the other side an ALG-enabled device (as a NAT router)  handles the
application protocol (i.e. SIP) at UDP/TCP level (not respecting
Internet layers) so it's not a B2BUA.

Ok, so an ALG-enabled device is not a B2BUA, and a B2BUA is not an
ALG-enabled device. And what? Where is the confusion? the draft
clearly talks about ALG devices, those which don't work at application
level (but at transport level). sessmatch/ACE mechanism is just useful
for SIP ALG enabled nodes in the network, no more.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 20:04:14 +0200

Hadriel,

This confusion is created by the very idea of trying to legitimate the use of intermediates in a by design end-to-end protocol with clients and servers. 

The only thing sure about ALG is that they break things by design. When they work, is an exception.

ALG terminology? Google for it. The word failure is associated with it in each result.

On Jun 10, 2011, at 7:07 PM, Hadriel Kaplan wrote:

> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Jun 2011 16:13:06 -0400

> for SIP ALG enabled nodes in the network, no more.

The draft uses the term "ALG", but actually is intended to address the B2BUA case... *SIP* B2BUA's.  If the SIP B2BUA wants to relay the MSRP session traffic, legacy MSRP requires it to also be either an RFC 4976 MSRP Relay, or an MSRP B2BUA.  Sessmatch is an extension to let it do so as a transport-layer relay instead, for the MSRP layer.  

We can argue about whether it's useful to do that, whether there's demand, etc.  But we shouldn't be arguing about it "breaking the Internet model", because it does NOT.  It changes what layer the middlebox does the relaying at for MSRP traffic, and obviously it changes MSRP, but that's kinda the point.  We could just as well argue about why MSRP was ever defined the way it is, creating such a ridiculously heavy relay architecture, but there's no point to debating that... we're proposing an alternate way to avoid it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Jun 2011 16:22:30 -0400

> ALG terminology? Google for it. The word failure is associated with it in each result.

I don't rely on Google for it - I rely on Wikipedia. :)
http://en.wikipedia.org/wiki/Application-level_gateway

I honestly don't believe the author of the draft, nor the other proponents for it, actually intend for sessmatch to address/aid "ALGs", as defined by Wikipedia.  I believe they don't, because the example in the draft is a 3GPP IBCF (and previously SBCs have been used as an example as well).  An IBCF, SBC, etc. is NOT an "ALG". 

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2011 20:24:10 -0400

Hadriel,

On 6/10/2011 1:07 PM, Hadriel Kaplan wrote:

> For example, a 3GPP IBCF is not an "ALG", nor is a P-CSCF+BGF, nor is
> an SBC.  Instead, they are addressed hosts - the hosts to which the
> SIP+MSRP UAs target their packets/connections.  From a SIP perspective,
> such hosts are B2BUA's not ALGs; and from an MSRP perspective such
> hosts are transport relays, similar to SOCKS relays.
>
> This is not a small difference.  True "ALGs", such as those in
> routers/NATs, cannot be easily avoided by host applications, except by
> obfuscating their protocol traffic (e.g., by using encryption, or
> changing port numbers); and if they happen to use encryption or
> authentication then the ALG function no longer works, if it was
> needed.  A SIP B2BUA/Proxy, on the other hand, is addressed by the host
> application - the application can use TLS or IPsec to the B2BUA, or
> avoid the B2BUA by addressing a different next-hop.

I'd like to clarify something you seem to be saying about an SBC and/or 
B2BUA. (Because I think there are things calling themselves SBCs that 
aren't truly B2BUAs and hence aren't actually *any* well defined sip 
entity.)

AFAIK a UA always has an address which addresses itself, that it inserts 
as the Contact address of sip messages it sends. And so a B2BUA also has 
this property, on each "side". A UA, and a B2BUA, end up receiving 
messages that contain their address in the R-URI and that have no Route 
header. (A very clear example of a B2BUA is a conference focus. All the 
participating devices know they are exchanging signaling with the focus.)

IMO a device that receives and processes sip messages while there is 
still a non-empty Route header, or that receives messages that contain 
some address other than its own in the R-URI, is not a UA/B2BUA.
It can be a proxy if it follows the 3261 rules for proxies. If it 
doesn't follow the rules for proxies, then it is not a well defined sip 
server of any sort.

This includes devices that claim to be proxies except that they 
sometimes generate their own 200 responses to REGISTER, or sometimes 
originate an in-dialog BYE.

AFAIK an SBC could in some cases be constructed as a B2BUA, but in 
many/most cases SBCs is actually an example of the less-well-defined 
"thing". And ISTM that ALGs as Wikipedia defines them are also this 
fuzzy sort of thing. I don't know if there is a meaningful distinction 
between an ALG and an SBC.

Do you find this taxonomy valid, or do you have something different in mind?

	Thanks,
	Paul

BTW, if this turns out to be an interesting discussion we should move it 
to some other list. But I'll leave it here for now, since that is where 
the context has been established.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Jun 2011 07:13:42 +0200

> We can argue about whether it's useful to do that, whether there's demand, etc.  But we shouldn't be arguing about it "breaking the Internet model", because it does NOT.  It changes what layer the…

Hi Hadriel, please take a look to the mail sent by Paul Kyzivat in
which the definition of B2BUA is described.

Main question is: should the box you name "B2BUA" receive the client's
request when performing RFC 3263 resolution on request Route/RURI? or
not? If not, that is not a B2BUA but a SIP "interceptor".

Or maybe the scenario is like this?:

  [email-masked] ----> InBoundProxy (dom.com) -----> MSRP M2BUA ------>
Registrar (dom.com) ----> [email-masked]

In this case, of course, the MSRP B2BUA is a valid SIP entity an
receives the request from the InBoundProxy due to local policy (i.e.
for anchoring the media).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 11 Jun 2011 14:36:43 +0200

Hadriel,

Wikipedia is a nice dictionary. 

Please also get down to the reality where things are pasted from the real life by many people having the problem we aim to prevent happing again with MSRP:

http://www.voip-info.org/wiki/view/Routers+SIP+ALG

You are a good engineer, you must understand the things explained there.

Adrian

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jun 2011 12:53:48 -0400

Paul,
The distinction I'm trying to point out is not Proxy vs. B2BUA vs. something in between, but rather that they're not "ALGs".  An "ALG" is a function performed transparently - i.e., by an inline device such as in a Router.  The SIP messages aren't addressed to it even at the IP layer, and the TCP connection is not actually terminated at the ALG.  For example an FTP ALG: the FTP ALG in a NAT only "works" because all packets between the two happen to cross it due to IP routing, and FTP is in cleartext.  If IP routing changes to route around the ALG, or were FTP to run over TLS, the ALG would not work.

I'm fairly positive that an "ALG" is not the type of device the seesmatch draft is trying to support.

Other comments inline...

> participating devices know they are exchanging signaling with the focus.)

I don't know of any normative language that says a UAS can only receive messages without Route headers or with itself in the RURI.  The only language around that I know of is this in 3261:
   If the Request-URI does not identify an address that the
   UAS is willing to accept requests for, it SHOULD reject the request
   with a 404 (Not Found) response.
Luckily, the UAS side of SBCs are willing to accept requests for a lot. ;)

If your UAC in cisco.com is set to use a PBX as its local outbound proxy for all requests, and the UAC generates a request to [email-masked], the request will have a RURI not belonging to the PBX when the PBX receives it, but the PBX can still act the role of B2BUA, replacing the Contact with itself, etc.

Arguably a true P-CSCF is not a full B2BUA because it does not put itself in the Contact, but it does mess with SDP, generate BYEs, hide Via/Record-Route, etc.

> doesn't follow the rules for proxies, then it is not a well defined sip 

I'm a little confused by your description of server types based on what SIP headers/fields they receive.  If I build a pure rfc3261 UAS (eg, a softphone) and someone sends it a SIP request with a Route header or a RURI not identifying it, does that change the type of device I built?  What if my UAS has a config setting that, when enabled, makes my UAS do something with such a request other than reject it?  It just seems weird to describe role in terms of what you receive, as opposed to what you do. (maybe I'm taking you too literally)

Regardless, as you've said many times, the terms aren't really system types but rather "roles", which can change dynamically based on policies/situations. 

> between an ALG and an SBC.

Afaik most "SBCs" are constructed to perform the role of B2BUAs.  At least of the half dozen vendors or so I know of, which comprise most of the SBC market.  There are probably devices which claim to be SBCs that are inline ALGs instead, just as there are probably devices which claim to be Proxies but aren't.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jun 2011 13:32:19 -0400

> not? If not, that is not a B2BUA but a SIP "interceptor".

Afaik, the type of devices sessmatch is actually trying to support are indeed either the host/server resolved through rfc3263 resolution, or reached/routed-through due to local policy on the client.

For example, if [email-masked] generates a request to [email-masked], the middlebox doing sessmatch-type msrp-relaying is either the SIP server resolved by rfc3263 for dom.com, or alice uses it due to local policy - for example its her UA's configured "outbound-proxy" (even though it isn't a Proxy).

> for anchoring the media).

Right, it's more likely this for SIP:

[email-masked] --> InBoundProxy --> Registrar --> OutBoundProxy --> [email-masked]

InBoundProxy and OutBoundProxy happen to be middleboxes able to relay media at a transport layer, by acting as SIP B2BUAs.  For every "media" type other than MSRP, including other TCP-based ones such as rfc4582 BFCP, such middleboxes typically perform relaying at the transport layer, splicing together TCP sockets or UDP ports without modifying application payload.  

There are some exceptions like SRTP encryption or codec transcoding, which obviously require going higher layers... but that comes at a price - a price either in terms of reduced capacity or additional hardware to handle it.  Legacy MSRP has such a cost, and any additional cost/price for MSRP is a big problem. (for example additional cost is the number one cited reason carriers say they don't do much SRTP)  A secondary problem is installed base: there are tens of thousands of such middleboxes already deployed, most of which can do sessmatch without replacement... but not legacy MSRP.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jun 2011 13:59:54 -0400

> http://www.voip-info.org/wiki/view/Routers+SIP+ALG

Right, I concur with that voip-info wiki page.

I am fairly confident those are not the type of devices sessmatch is really aimed at "helping".  I doubt any of those ALG products will even support sessmatch, let alone legacy MSRP.  Sessmatch is really aimed for SIP middleboxes: IBCFs, P-CSCFs, SBCs, etc.

But let's pretend this is about helping ALGs... router/NAT vendors are motivated to create ALGs to "fix" protocols that would otherwise break due to NAT, when the protocol is popular enough to warrant it.  MSRP isn't popular enough yet, but someday it may be (I think we all hope it *will* be).  So if that day comes, and we DON'T have sessmatch, the ALG will be modifying the SIP/SDP *AND* the to-address/from-address inside MSRP messages.  Do we really want ALGs to be parsing and modifying (and screwing up) MSRP messages as well, or would we rather they just muck with SIP/SDP and leave MSRP alone?

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Sat, 11 Jun 2011 13:31:44 -0500

(as individual)

> I am fairly confident those are not the type of devices sessmatch is really aimed at "helping".  I doubt any of those ALG products will even support sessmatch, let alone legacy MSRP.  Sessmatch is…

I concur.

> But let's pretend this is about helping ALGs... router/NAT vendors are motivated to create ALGs to "fix" protocols that would otherwise break due to NAT, when the protocol is popular enough to warr…

I'd personally rather that ALGs, particularly the ones in residential gateways where the users either don't know how to, or just plain can't, turn them off, stop trying to add value to SIP applications at all. They should eave it to the endpoints to figure things out, with the various NAT traversal technologies we've been trying to standardize. (And by "add value", I mean "break").

But I'm not sure what that means for this draft :-)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Jun 2011 08:13:53 +0200

Hi,

>From a SIP/SDP perspective, what is relevant for sessmatch, is that the box we are talking about anchors media either by modifying the SDP c/m-line, or by enabling MSRP B2BUA functionality.

Whatever else it does, when it comes e.g. to doing DNS lookups on the R-URI, adding Record-Route headers etc is in my opinion not relevant as far as sessmatch is concerned.

So, I would suggest that we choose *a* term, and then add some definition text to clarify that. Maybe "Intermediary" would be a "neutral" term?

Then, if people want to have a more general and wider discussion about SBCs, ALGs etc, I agree with Paul that such discussion should take place elsewhere, because it is not MSRP specific, neither is it the intention of sessmatch to provide such description.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 11. kesäkuuta 2011 3:24
> To: [email-masked]
> Subject: [Simple] terminology - B2BUA / SBC / ALG / "other"
> 
> Hadriel,
> 
> > SIP+MSRP UAs target their packets/connections.  From a SIP 
> > SIP+perspective,
> > needed.  A SIP B2BUA/Proxy, on the other hand, is addressed by the 
> > host application - the application can use TLS or IPsec to 
> the B2BUA, 
> > or avoid the B2BUA by addressing a different next-hop.
> 
> I'd like to clarify something you seem to be saying about an 
> SBC and/or B2BUA. (Because I think there are things calling 
> themselves SBCs that aren't truly B2BUAs and hence aren't 
> actually *any* well defined sip
> entity.)
> 
> AFAIK a UA always has an address which addresses itself, that 
> it inserts as the Contact address of sip messages it sends. 
> And so a B2BUA also has this property, on each "side". A UA, 
> and a B2BUA, end up receiving messages that contain their 
> address in the R-URI and that have no Route header. (A very 
> clear example of a B2BUA is a conference focus. All the 
> IMO a device that receives and processes sip messages while 
> there is still a non-empty Route header, or that receives 
> messages that contain some address other than its own in the 
> R-URI, is not a UA/B2BUA.
> It can be a proxy if it follows the 3261 rules for proxies. 
> If it doesn't follow the rules for proxies, then it is not a 
> well defined sip server of any sort.
> 
> This includes devices that claim to be proxies except that 
> they sometimes generate their own 200 responses to REGISTER, 
> or sometimes originate an in-dialog BYE.
> 
> AFAIK an SBC could in some cases be constructed as a B2BUA, 
> but in many/most cases SBCs is actually an example of the 
> less-well-defined "thing". And ISTM that ALGs as Wikipedia 
> defines them are also this fuzzy sort of thing. I don't know 
> if there is a meaningful distinction between an ALG and an SBC.
> 
> BTW, if this turns out to be an interesting discussion we 
> should move it to some other list. But I'll leave it here for 
> now, since that is where the context has been established.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 13 Jun 2011 09:49:49 +0200

Hi,

> Whatever else it does, when it comes e.g. to doing DNS lookups on the R-URI, adding Record-Route headers etc is in my opinion not relevant as far as sessmatch is concerned.

I agree. B2BUA functionality could be used for the SIP part but this specification could be used to anchor MSRP media and fix NAT issues (for MSRP).

> So, I would suggest that we choose *a* term, and then add some definition text to clarify that. Maybe "Intermediary" would be a "neutral" term?

I personally don't find the term ALG confusing, but I understand the points that have been risen. Intermediary could work.

> Then, if people want to have a more general and wider discussion about SBCs, ALGs etc, I agree with Paul that such discussion should take place elsewhere, because it is not MSRP specific, neither i…

Agreed.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Jun 2011 18:09:02 +0200

> InBoundProxy and OutBoundProxy happen to be middleboxes able to relay media at a transport layer, by acting as SIP B2BUAs.  For every "media" type other than MSRP, including other TCP-based ones su…

Thanks for the explanation. So then, if those SBC are real/valid SIP
nodes within the path, why does SIP over TLS makes media anchoring
imposible for them? This is, alice speaks SIP over TLS with the SBC,
and the SBC with bob, so the SBC *can* read/modify the SDP in order to
anchor media.

But in all these threads, it was assumed that SIP over TLS made
imposible the "work" of ALG boxes. I do know it's imposible for real
ALG boxes (routers which don't speak SIP but just inspect plain text
messages and perform painful substitutions) to anchor media when SIP
goes through TLS, but in an SBC this should not be a problem, so are
all of us speaking about SBC's?

Or do I miss something?

> There are some exceptions like SRTP encryption or codec transcoding, which obviously require going higher layers...

Why SRTP is a problem? The encoding/decoding is made by real endpoints, right?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jun 2011 12:22:55 -0400

> I'm fairly positive that an "ALG" is not the type of device the seesmatch draft is trying to support.

I haven't been following the sessmatch discussion very closely, so I 
guess I don't know about that.

(W as really trying to shanghai your comment to discuss something else. :-)

> Other comments inline...

I'd like to take that discussion out of the simple mailing list.
Perhaps it belongs in sipcore, but I think its still to half baked for 
that, so instead I'm going to continue on sip-implementors.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Jun 2011 10:24:36 +0300

Hi Hadriel,

> The distinction I'm trying to point out is not Proxy vs. B2BUA vs.
> something in between, but rather that they're not "ALGs".  An "ALG"
> is a function performed transparently - i.e., by an inline device
> such as in a Router.  The SIP messages aren't addressed to it even at
> the IP layer, and the TCP connection is not actually terminated at
> the ALG.  For example an FTP ALG: the FTP ALG in a NAT only "works"
> because all packets between the two happen to cross it due to IP
> routing, and FTP is in cleartext.  If IP routing changes to route
> around the ALG, or were FTP to run over TLS, the ALG would not work.
> 

I agree with you the use of the term ALG in the draft is confusing. I
actually made the same comment to the authors a while ago because the
first time I read the draft, I made the same interpretation as you did
(i.e., ALG are not explicitly addressed).

I agree the draft should be clear when describing how addressing works.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Jun 2011 11:16:04 +0200

Hi,

In the latest version (-13) we talk about "middleboxes" instead, and we have also added clarification/definition text.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: 27. kesäkuuta 2011 10:25
To: Hadriel Kaplan
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other"

Hi Hadriel,

> is a function performed transparently - i.e., by an inline device such 
> as in a Router.  The SIP messages aren't addressed to it even at the 
> IP layer, and the TCP connection is not actually terminated at the 
> ALG.  For example an FTP ALG: the FTP ALG in a NAT only "works"

I agree with you the use of the term ALG in the draft is confusing. I actually made the same comment to the authors a while ago because the first time I read the draft, I made the same interpretation as you did (i.e., ALG are not explicitly addressed).

Cheers,

Gonzalo