Subject: Re: [martini] Middlebox needs - admitting inbound requests

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Mar 2010 15:15:13 +0100

Yes, I would have expected a middlebox providing this NAT function on message contents should be sufficiently stateful to allow the opposite to happen in the reverse direction. I still have a hard time understanding why the middlebox needs explicit knowledge of registered AORs (user parts) in order accomplish this type of functionality.

John

> -----Original Message-----
> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: 28 February 2010 20:52
> To: Tyler Parkin; Elwell, John; Adam Roach; Spencer Dawkins
> Cc: Bernard Aboba; MARTINI
> Subject: RE: [martini] Middlebox needs - admitting inbound requests
> 
> Hi Tyler,
> 
>   I believe some SBCs that "NAT" as you describe would (or 
> could) use a
> unique port on the northbound side per registered entity. So the SBC
> would be able to maintain a mapping from the client-side 
> contact/routing
> info to a unique northbound address/port that it would 
> receive requests
> on (for requests towards the SIP PBX). In this case, there 
> shouldn't be
> any problems routing the request.
> 
>   Also, I think the MARTINI-Shaken approach wouldn't have a problem in
> this case either, since the domain portion of the request uri 
> (from the
> "SSP") contains a domain name representing the enterprise/PBX, rather
> than an IP address derived from the contact.
> 
>   Thanks
>      Brian
> 
> -----Original Message-----
> From: Tyler Parkin [mailto:[email-masked]] 
> Sent: Friday, February 26, 2010 1:04 PM
> To: Elwell, John; Lindsay, Brian (CAR:AR00); Adam Roach; 
> Spencer Dawkins
> Cc: Bernard Aboba; MARTINI
> Subject: Re: [martini] Middlebox needs - admitting inbound requests
> 
> 
> > ----- Original Message -----
> > From: "Elwell, John" <[email-masked]>
> > To: "Tyler Parkin" <[email-masked]>; "Brian Lindsay"
> > <[email-masked]>; "Adam Roach" <[email-masked]>; "Spencer 
> > Dawkins"
> > <[email-masked]>
> > Cc: "Bernard Aboba" <[email-masked]>; "MARTINI"
> > <[email-masked]>
> > Sent: Friday, February 26, 2010 5:34 AM
> > Subject: RE: [martini] Middlebox needs - admitting inbound requests
> >
> >
> > Tyler,
> >
> > I found this thread a little mixed up between outbound 
> requests from 
> > the PBX and inbound requests  to the PBX, so I am not sure I 
> > understood everything.
> > [tyler] sorry for the confusion, I think we're looking at it in 
> > different directions... inbound to me is inbound to the 
> SSP, where to 
> > you inbound is to the PBX.  I guess we'll stick w/ inbound = to the 
> > PBX
> >
> > As far as inbound request are concerned, I think with gin-01 the 
> > problems you raise should be solvable, but it perhaps 
> requires use of 
> > Proxy-Require, as already discussed. The middlebox does not need to 
> > know exactly which E.164s are implicitly registered, but 
> when it gets 
> > a request to the PBX's IP address (presumably with Route indicating 
> > the IP address of the middlebox) it should assume the E.164 in the 
> > user part is indeed a registered AOR.
> > [tyler] my point is that the middlebox doesn't get a request to the 
> > PBX's IP address.
> [JRE] Why not? If the Contact URI contains the IP address (as in
> gin-01), this will be registered at the registrar and will be returned
> as the target of an inbound request to the PBX.
> 
> > The softswitch/registrar generating the call doesn't know 
> the PBX's IP
> 
> > because it was masked during the initial registration.
> [JRE] Why would it be masked? I understand that the registrar 
> would not
> see the IP address at the transport level from which the REGISTER
> request arrived at the middlebox, but it would see the IP 
> address in the
> Contact URI.
> [Tyler] In most scenarios where a middlebox (aka SBC) exists, the SBC
> performs two-way NAT functions, and NAT's the headers/URI's 
> for inbound
> and outbound messaging.  Therefore, a request received on the public
> side from user@PBXIP is sent to the registrar as 
> user@SBCPRIVATEIP.  The
> oposite direction (SSP -> PBX) is received by the SBC as 
> user@SSPIP and
> NAT'd to user@SBCPUBLICIP.
> 
> > Any
> > requests from from the registrar/softswitch to the 
> middlebox (destined
> 
> > for the PBX) will only have user@middlebox, perhaps w/ a cookie.
> > The middelbox
> > needs to map user@middlebox to whatever IP/host originally 
> registered.
> > Today, the middlebox keeps a cache where the initial (individual) 
> > registration might be [email-masked], and the registration 
> forwarded to 
> > the registrar is [email-masked].  That way when the registrar sends a 
> > request to the middlebox for [email-masked] it maps it to 
> [email-masked] 
> > and all is good.
> > If the middelbox doesn't have knowledge of the user (because of 
> > implicit),
> [JRE] Are you suggesting that each user behind the PBX would register
> with a different IP address, so you need to know whether it 
> is user1 or
> user2 in order to send requests to 11.11.11.11 or 22.22.22.22? If so,
> that is not the scenario that MARTINI is addressing. MARTINI is
> addressing the case where requests to user1, user2 etc. on a given PBX
> all need to be routed to the PBX's IP address. So as long as the
> middlebox knows the request needs to go to the PBX, it doesn't need to
> know that particular user.
> [Tyler] Agreed, I shouldn't have used the term user.  The middlebox in
> this scenario wouldn't care about individual users, it's point of
> contact is the PBX.  All PBX's send register requests to the middlebox
> from different IP's/domains, granted.  After NAT, however, all the
> requests from the SBC to the registrar appear to come from 
> the same IP.
> We NAT in both directions, which is pretty standard, so we 
> don't expose
> core equipment to the public, and we don't expose end user IP's to
> peers.  Plus it allows virtual route tables internally and 
> resolves any
> issues with overlapping address space.
> 
> > it can't make the mapping unless it has something else to 
> associate to
> 
> > the original implicit reg (like a cookie, or knowledge of the 
> > extensions).
> >
> > Now concerning outbound requests (this was what my earlier 
> message was
> 
> > about, although somewhere further back that got brought 
> across to this
> 
> > thread rather than the thread concerning outbound requests, so the 
> > thread title was wrong). Assuming an entity has knowledge of 
> > registered E.164 numbers, it is not clear to me how it 
> would deal with
> 
> > a request where the From/PAI in the request from the PBX is 
> not one of
> 
> > the implicitly registered ones. This can arise, for example, if the 
> > request originates elsewhere in the enterprise and "breaks 
> out" to the
> 
> > SSP via this particular PBX. Or if the call originated 
> elsewhere and 
> > was forwarded by the PBX to the SSP. I appreciate that there may be 
> > some arrangements between PBX and SSP where this is forbidden by 
> > policy, but in the general case I would expect it to work, 
> so that the
> 
> > callee has a correct AOR to which it can make a return call.
> > [tyler] methods dealing with this situation today (A calls B, B 
> > forwards the call to C) would use from=A and PAI=B, where B is a 
> > registered endpoint (and billable by the SSP).  Not sure if that's 
> > what you're asking?
> [JRE] Yes, that was what I was asking, and I know that it sometimes
> works the way you describe, but this is bad because PAI=B is 
> wrong - it
> is not compliant with RFC 3325, since it is not the source of the
> request. If the callee used that to make a return call, the 
> return call
> would arrive at the wrong place. For example, if a customer 
> calls me on
> my office number and the PBX forwards it to my home via the SSP, if my
> phone stores the PAI as the caller's number and I try to make a return
> call, the return call goes to my office phone, not to my customer.
> [Tyler] The source of the forward leg of the call is B, not 
> A.  Calling
> area requirements and n11 need to be based on B.  Why would the callee
> use PAI to return a call?  That would be in violation of 3325 as well
> since it would obviate any callerid blocking/suppression requirements.
> I guess whether the PBX should strip PAI before sending it to 
> your phone
> is arguable.  Agreed, using PAI to assert a different ID than From
> (where from isn't private) might not strictly adhere to 3325, but I
> think alternate ID's vs suppressed ID's is splitting hairs a little.
> 
> John 
> 
>

---

From: "Tyler Parkin" <[email-masked]>
Date: Mon, 1 Mar 2010 13:03:40 -0500

All I asked is that the behavior of network elements beyond the PBX also be 
described in the draft.  Even within this forum we've had two different 
suggestions on how a middlebox *could* behave to support then GIN 
proposal... one involved different ports on the private side of the 
middlebox and the other included the use of a cookie.  I didn't say explicit 
knowledge of the extensions is the only method, only that the mechanism used 
between the middlebox(es) and the registrars should be defined in this 
document so that the implimentation is standardized.  IMO, without 
describing that behavior, this draft won't be widely (or at least quickly 
adopted) due to interop issues between other vendors in the call flow.

Regards,

Tyler

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Brian Lindsay" <[email-masked]>; "Tyler Parkin" 
<[email-masked]>; "Adam Roach" <[email-masked]>; "Spencer Dawkins" 
<[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Monday, March 01, 2010 9:15 AM
Subject: RE: [martini] Middlebox needs - admitting inbound requests

Yes, I would have expected a middlebox providing this NAT function on 
message contents should be sufficiently stateful to allow the opposite to 
happen in the reverse direction. I still have a hard time understanding why 
the middlebox needs explicit knowledge of registered AORs (user parts) in 
order accomplish this type of functionality.

John

> =

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Mar 2010 21:43:55 +0100

Tyler,

Thanks for the clarification. So there is no impact on the Requirements draft. I will leave it to others to comment on whether they believe the interface between a middlebox and a registrar should be specified as part of MARTINI.

John

> Sent: 01 March 2010 18:04
> To: Elwell, John; Brian Lindsay; Adam Roach; Spencer Dawkins

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 21 Mar 2010 19:26:07 -0400

I think having SBC's use unique ports per PBX would be a really bad way to go.  I don't know what other's experiences were with that, but we've got a mode setting for doing it that way because some registrars required it be done that way, but it had really nasty issues merely because of that mechanism.  Like you can't get more than ~60k subscribers per IP; if UA's move/go-away you have to decide when you can reclaim ports; if you're completely rebooted then the ports get allocated in a different order which confuses registrars; if you need to switch to TCP for some messages/cases then the mapping can't possibly be kept; you get the idea.

I think it's been discussed before on this list (or maybe it was in SIP-Forum), that one clean way would be for the SBC to insert a Path header identifying itself and a cookie, and that cookie provide the route or registration-cache-key information it needs.  Or it can insert a Path with pretty much anything it needs - as long as the core registrar/proxies support Path and thus reflect the received Path list by adding them as Route header lists for the requests they route to the PBX through the SBC.

Of course some things in Martini may well require changes in middleboxes, but that's why there's the option-tag. :)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Lindsay
> Sent: Sunday, February 28, 2010 3:52 PM
>   I believe some SBCs that "NAT" as you describe would (or could) use a
> would be able to maintain a mapping from the client-side contact/routing
> info to a unique northbound address/port that it would receive requests
> on (for requests towards the SIP PBX). In this case, there shouldn't be
> this case either, since the domain portion of the request uri (from the
> To: Elwell, John; Lindsay, Brian (CAR:AR00); Adam Roach; Spencer Dawkins
> > I found this thread a little mixed up between outbound requests from
> > different directions... inbound to me is inbound to the SSP, where to
> > problems you raise should be solvable, but it perhaps requires use of
> > know exactly which E.164s are implicitly registered, but when it gets
> > The softswitch/registrar generating the call doesn't know the PBX's IP
> 
> [JRE] Why would it be masked? I understand that the registrar would not
> request arrived at the middlebox, but it would see the IP address in the
> Contact URI.
> performs two-way NAT functions, and NAT's the headers/URI's for inbound
> side from user@PBXIP is sent to the registrar as user@SBCPRIVATEIP.  The
> oposite direction (SSP -> PBX) is received by the SBC as user@SSPIP and
> > requests from from the registrar/softswitch to the middlebox (destined
> 
> > needs to map user@middlebox to whatever IP/host originally registered.
> > registration might be [email-masked], and the registration forwarded to
> > request to the middlebox for [email-masked] it maps it to [email-masked]
> > and all is good.
> with a different IP address, so you need to know whether it is user1 or
> requests from the SBC to the registrar appear to come from the same IP.
> We NAT in both directions, which is pretty standard, so we don't expose
> peers.  Plus it allows virtual route tables internally and resolves any
> > it can't make the mapping unless it has something else to associate to
> 
> > Now concerning outbound requests (this was what my earlier message was
> 
> > about, although somewhere further back that got brought across to this
> 
> > registered E.164 numbers, it is not clear to me how it would deal with
> 
> > a request where the From/PAI in the request from the PBX is not one of
> 
> > request originates elsewhere in the enterprise and "breaks out" to the
> 
> > SSP via this particular PBX. Or if the call originated elsewhere and
> > policy, but in the general case I would expect it to work, so that the
> 
> works the way you describe, but this is bad because PAI=B is wrong - it
> request. If the callee used that to make a return call, the return call
> would arrive at the wrong place. For example, if a customer calls me on
> [Tyler] The source of the forward leg of the call is B, not A.  Calling
> I guess whether the PBX should strip PAI before sending it to your phone
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:46:31 +0100

Path makes sense. Is it a problem to require support for Path by the SSP?

/Hans Erik van Elburg

On Mon, Mar 22, 2010 at 12:26 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> I think having SBC's use unique ports per PBX would be a really bad way to
> go.  I don't know what other's experiences were with that, but we've got a
> mode setting for doing it that way because some registrars required it be
> done that way, but it had really nasty issues merely because of that
> mechanism.  Like you can't get more than ~60k subscribers per IP; if UA's
> move/go-away you have to decide when you can reclaim ports; if you're
> completely rebooted then the ports get allocated in a different order which
> confuses registrars; if you need to switch to TCP for some messages/cases
> then the mapping can't possibly be kept; you get the idea.
>
> I think it's been discussed before on this list (or maybe it was in
> SIP-Forum), that one clean way would be for the SBC to insert a Path header
> identifying itself and a cookie, and that cookie provide the route or
> registration-cache-key information it needs.  Or it can insert a Path with
> pretty much anything it needs - as long as the core registrar/proxies
> support Path and thus reflect the received Path list by adding them as Route
> header lists for the requests they route to the PBX through the SBC.
>
> Of course some things in Martini may well require changes in middleboxes,
> but that's why there's the option-tag. :)
>
> -hadriel
>