Subject: Re: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 17:18:24 -0500

Brian Rosen wrote:
> Mike
> 
> In a former life, I spent some time talking to carriers, and tried to argue
> against deploying SBCs.  Topology hiding is one of the things carriers are
> convinced is of great value to them.  I predict your arguments will fail.  I
> think we will find it more fruitful to deal with the issues that topology
> hiding presents than trying to force carriers to not do it. 
> 
> I am hopeful that eventually it will dawn on these guys that their
> competition doesn't use SBCs, and can offer customers better service at
> lower cost without them.  That might take a while.
> 
> In the mean time, SBCs do topology hiding.  Get over it.

I don't doubt the truth in this. But that doesn't mean we shouldn't 
understand the reasons why it is being done, and to which addresses.

If for no other reason, this affects policy. I think there are more 
setting to this knob than just "hide"/"don't hide". And, as is discussed 
later in this thread, it may turn out that there are reasons that can 
better be solved in other ways.

> Your point about security mechanisms vs e.g. SBC rewriting of SDP is another
> issue altogether.  I hope that we can figure out what the requirements are,
> and provide alternative mechanisms to meet those requirements that will not
> break cryptographically protected signaling.

Me too. But if topology hiding extends to hiding media addresses, then 
this may be unavoidable. If there are degrees of topology hiding, and 
other solutions to problems, then it will help here too.

	Paul

> Brian
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Mike Hammer
>>Sent: Tuesday, February 08, 2005 3:02 PM
>>To: 'Medhavi Bhatia'; 'Paul Kyzivat'; 'sipping'
>>Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>
>>Medhavi,
>>
>>I'm still trying to drive toward the business reasons first and getting to
>>the technical solution afterward.  What is the threat?
>>
>>All the efforts thus far to hide one's customer base have not helped stop
>>the churn of cell phone service providers, so I don't expect it to succeed
>>in the IP space either.  Build a fragile service that breaks too often and
>>folks will go to another SP.  As for ACLs, there are problems with basing
>>security on unauthenticated identities.  I would prefer to use real
>>cryptographic-based mechanisms to ensure security.  Speaking of which, if
>>SDP were encrypted would the service break?
>>
>>Hiding a topology is not that big an issue, sure.  But, making sure the
>>end-user's service works in spite of that is a big issue.  My concern is
>>that you are taking a point product viewpoint, while the system view
>>suffers.
>>
>>There might be reason to hide the fact that the INVITE went through half a
>>dozen proxy/application servers between the IP phone and the public-facing
>>proxy (via header manipulation), but that doesn't mean you have to
>>preclude
>>the endpoint advertising a publicly accessible IP address in the SDP.  One
>>might argue that hiding IP addresses of those intermediate devices makes
>>it
>>harder to target requests to them and enables a firewall to reject any
>>requests from outside that go directly to those devices.  (this is all
>>hypothetical)  One could also argue that communication between those
>>servers
>>should be over encrypted links to begin with, which might address the
>>supposed security concern.  The key questions are what is being hidden and
>>why?
>>
>>If we can't document, socialize, and agree on that, then there is probably
>>not a real need here.
>>
>>Mike
>>
>>   >-----Original Message-----
>>   >From: Medhavi Bhatia [mailto:[email-masked]]
>>   >Sent: Tuesday, February 08, 2005 2:16 PM
>>   >To: 'Mike Hammer'; 'Paul Kyzivat'; 'sipping'
>>   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >
>>   >Mike, Paul
>>   >
>>   >If we are looking for one compelling reason why topology
>>   >hiding is necessary, there isn't one. NATs are good
>>   >examples. If we can avoid using private networks and shift
>>   >to IPv6, then NATs are not required. However, service
>>   >dis-intermediation (one provider steals anothers'
>>   >customers) is a real problem which exists in some networks,
>>   >ACLs do get used in the real world.
>>   >
>>   >To me, topology hiding is not a big issue here. At the
>>   >signaling level it can be done using a proxy or B2BUA. IP
>>   >address hiding at the media level requires SDP inspection
>>   >and is an issue. So is identity and some header
>>   >manipulation related features. Do we (and possibly others
>>   >on the list) agree on these three ?
>>   >
>>   >-Medhavi.
>>   >
>>   >-----Original Message-----
>>   >From: [email-masked]
>>   >[mailto:[email-masked]] On Behalf Of Mike Hammer
>>   >Sent: Monday, February 07, 2005 11:36 AM
>>   >To: 'Medhavi Bhatia'; 'Paul Kyzivat'; 'sipping'
>>   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >
>>   >Medhavi,
>>   >
>>   >You could still have the traffic sourced from knowin IP
>>   >addresses and with some assurance it is coming from who you
>>   >think it is coming from.  Use IPSEC.  This does not require
>>   >you to preclude the inner IP addresses being end-to-end and
>>   >would provide real security.  Security through obscurity is
>>   >known to not work and is easily discovered and subverted.
>>   >
>>   >I don't think this model of captive IP endpoints will work.
>>   > End-users will have many options and if using one SP
>>   >network makes the service more fragile, then they will soon
>>   >find another SP that does not.  And if need be, regulations
>>   >will be instituted to be sure they can.  I think it best if
>>   >we avoid doing suboptimal things and inviting regulation.
>>   >
>>   >Mike
>>   >
>>   >
>>   >   >-----Original Message-----
>>   >   >From: Medhavi Bhatia [mailto:[email-masked]]
>>   >   >Sent: Friday, February 04, 2005 9:40 PM
>>   >   >To: 'Mike Hammer'; 'Paul Kyzivat'; 'sipping'
>>   >   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >   >
>>   >   >Mike,
>>   >   >
>>   >   >A technical reason for hiding (topology/ip addresses) would
>>   >   >be the existence of private networks, provider hosted VPNs.
>>   >   >From a network management perspective, service providers
>>   >   >frequently use access control lists where traffic is
>>   >   >expected to come from a fixed set of IP addresses. Probably
>>   >   >because of security reasons. A non technical reason may be
>>   >   >that in some cases, especially when wholesale traffic is
>>   >   >exchanged between providers, they seldom want their
>>   >   >terminations to know anything about the originations.
>>   >   >This is more likely to happen in markets with frequent
>>   >   >"shopping around" for rates like the VoIP wholesale.
>>   >   >
>>   >   >I put some more responses inline.
>>   >   >
>>   >   >-----Original Message-----
>>   >   >From: [email-masked]
>>   >   >[mailto:[email-masked]] On Behalf Of Mike Hammer
>>   >   >Sent: Friday, February 04, 2005 11:22 AM
>>   >   >To: 'Medhavi Bhatia'; 'Paul Kyzivat'; 'sipping'
>>   >   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >   >
>>   >   >Medhavi,
>>   >   >
>>   >   >Thanks for the reply.  I am hoping you will take the
>>   >   >initiative to drill down on each of the issues.  Your
>>   >   >responses to the various comments are a start.  As you had
>>   >   >noted, if you reorganize into the four sections, it would
>>   >   >be good to note the conditions where each functionality is
>>   >   >needed or where it may not be needed, e.g. interworking may
>>   >   >not be necessary if the "inner"
>>   >   >and "outer" interfaces use the same technologies and
>>   >   >include these in the SLAs.
>>   >   >
>>   >   >I was not suggesting that you invented the topology hiding,
>>   >   >but this feels like the proverbial story about outdated
>>   >   >usefulness.  The British Army once filmed an artillery unit
>>   >   >in operation because they suspected that they had too many
>>   >   >men that could be put to better use doing other things.
>>   >   >While watching the film, they noticed that most of the men
>>   >   >were busy aligning the gun, moving the ammo, plotting the
>>   >   >trajectories, etc.  But, one guy in the film seemed to be
>>   >   >doing nothing but standing around.  When they contacted the
>>   >   >unit and asked what his job was, they were told his job was
>>   >   >to hold the horse's reins so they wouldn't run away at the
>>   >   >sound of the cannon!  This, long after horses had been
>>   >   >replace by motorized vehicles.
>>   >   >
>>   >   >The problem I have is that when thinking about how the IP
>>   >   >addresses would be used in the signaling, I want to
>>   >   >advertise the public IP in the INVITE offer and get back a
>>   >   >public IP in the answer.  But, this presumes I know the
>>   >   >ultimate direction the media will travel.  If I don't pick
>>   >   >the right media gateway, I may be telling the remote party
>>   >   >to take an inefficient route to get to me, and vice versa.
>>   >   >Thus, to settle on the right set of NNI NATs, it might
>>   >   >require multiple signaling iterations, but that would only
>>   >   >delay session setup.  My conclusion was that, assuming that
>>   >   >the user has a NAT on the UNI it is best to assign the
>>   >   >public IP addresses as close as possible to the users, i.e.
>>   >   >to their NAT device.  There are many roads that reach my
>>   >   >front door, but there is only one front door, so it is
>>   >   >always the right choice.  If the gate address is the city
>>   >   >gate, or a gateway to the country, there will be many ways
>>   >   >to reach me, many of them sub-optimal.  Finally, my public
>>   >   >IP address that I have now works fine and the Internet
>>   >   >routes to me very well.  If it ain't broke, don't fix it.
>>   >   >So, I ask again.  Exactly what is it that needs to be
>>   >   >hidden and why?
>>   >   >
>>   >   >I have the same problem with your hop-by-hop problem below.
>>   >   > SDP is supposed to be end-to-end, meaning all the way from
>>   >   >phone to phone.  Maybe network hop by network hop will be
>>   >   >an improvement over the switch-by-switch hopping, but I
>>   >   >still get the feeling there is a tendency to use familiar
>>   >   >designs, i.e. the PSTN.
>>   >   >
>>   >   >[MB] I don't think hop-by-hop is the real problem here. A
>>   >   >tradeoff between efficiency, security and quality may
>>   >   >determine the media path. The most common deployment of
>>   >   >SBCs is probably similar to NATs where media and signaling
>>   >   >are assumed to go together. There are others: routing of
>>   >   >the media can be driven by policy. I don't see why a
>>   >   >content provider (ASP) would force the media to go through
>>   >   >its network. A provider who owns the network may want to
>>   >   >engage in traffic management. SBCs can also be integrated
>>   >   >with routers. I think the 3G P-CSCF/PDF fits this description.
>>   >   >
>>   >   >Also, I understand that there may be QoS issues to deal
>>   >   >with that may affect the routing.  How this gets injected
>>   >   >into the routing is an interesting problem.  I think some
>>   >   >more details on the SP policy magic pixie dust needs to be
>>   >   >worked out.  It would be great if the accountability of the
>>   >   >traffic flows looks more like an electronic Easy-pass lane
>>   >   >operating at highway speed, rather than the old
>>   >   >coin-operated toll-booths that lead to the well-known
>>   >   >traffic backups at ever state border.  Will the media
>>   >   >border elements look more like the former or the latter?
>>   >   >
>>   >   >Last, does a SBC really sit "at the border" or is it simply
>>   >   >the last session-level device that needed to process the
>>   >   >signaling, and may sit somewhere centrally in the SP network?
>>   >   >
>>   >   >[MB] I think if the SBC is not functioning as a media hop,
>>   >   >then it exists on the SIP border (if one exists) and could
>>   >   >be central in the SP network.
>>   >   >
>>   >   >Mike
>>   >   >
>>   >   >
>>   >   >   >-----Original Message-----
>>   >   >   >From: Medhavi Bhatia [mailto:[email-masked]]
>>   >   >   >Sent: Thursday, February 03, 2005 11:41 PM
>>   >   >   >To: 'Mike Hammer'; 'Paul Kyzivat'; 'sipping'
>>   >   >   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >   >   >
>>   >   >   >
>>   >   >   >Mike,
>>   >   >   >
>>   >   >   >Thanks for comments. See responses below.
>>   >   >   >
>>   >   >   >-----Original Message-----
>>   >   >   >From: [email-masked]
>>   >   >   >[mailto:[email-masked]] On Behalf Of Mike Hammer
>>   >   >   >Sent: Wednesday, February 02, 2005 10:25 AM
>>   >   >   >To: 'Paul Kyzivat'; 'sipping'
>>   >   >   >Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
>>   >   >   >
>>   >   >   >To add my 2 cents:
>>   >   >   >
>>   >   >   >This draft talks mostly in terms of mechanisms that are
>>   >   >   >required without stating what the problem is they are
>>   >   >   >trying to solve.
>>   >   >   >
>>   >   >   >Case in point:  the "need" to hide IP addresses.  I was
>>   >   >   >disappointed that there was not more explanation of why it
>>   >   >   >was necessary to hide IP addresses in the face of all the
>>   >   >   >problems that NATs have had on peer-to-peer applications.
>>   >   >   >It would also be good to address what the effect of
>>   >   >   >transition to IPv6 would have on such address-hiding needs.
>>   >   >   > At the IETF-61 SBC BoF it was suggested that IP addresses
>>   >   >   >needed to be statically assigned and provisioned to support
>>   >   >   >peering relationships, yet there was not enough time to
>>   >   >   >delve into why knowledge of IP addresses constituted a
>>   >   >   >security mechanism.  I think a draft such as this should
>>   >   >   >lay out the case for such an approach and explain why other
>>   >   >   >alternatives are inadequate.
>>   >   >   >
>>   >   >   >[MB] I guess we are not re-inventing the topology hiding
>>   >   >   >problem in this draft. References to topology hiding are in
>>   >   >   >the old SIP RFC (2543) and 3261 (where Via Hiding was
>>   >   >removed) etc.
>>   >   >   >
>>   >   >   >This draft also assumes a dynamic complete topology
>>   >   >   >knowledge in order to make bandwidth resource decisions for
>>   >   >   >the network.  It would seem that some explanation of how
>>   >   >   >this knowledge is maintained as well as why alternative
>>   >   >   >mechanisms for making CAC decisions, e.g. through use of
>>   >   >   >RSVP-based mechanisms, would not satisfy the business need,
>>   >   >   >once that need is adequately fleshed out.
>>   >   >   >
>>   >   >   >[MB] This boils down to if we are dealing with a QoS
>>   >   >   >border, which would mean that the QoS mechanisms in the SBC
>>   >   >   >Network and External Network are separate (for example,
>>   >   >   >DiffServ/RSVP etc)
>>   >   >   >
>>   >   >   >This draft should also address what the effect of security
>>   >   >   >mechanisms will have on the ability of the SBC to modify
>>   >   >   >things like encrypted SDP.  If the use of an SBC precludes
>>   >   >   >many security mechanisms from being deployed, the
>>   >   >   >ramifications of such restrictions should be
>>   >explored in detail.
>>   >   >   >
>>   >   >   >[MB] Encrypted SDP can be deployed. However the model is
>>   >   >   >hop-by-hop as 5.1.2 says.
>>   >   >   >
>>   >   >   >Last, I didn't see any mention of mobility's effect on the
>>   >   >   >use of SBCs.  My concern here is that the session signaling
>>   >   >   >might need to head West, say to Japan, while the media
>>   >   >   >heads East, say to France.  Forcing the media to follow the
>>   >   >   >signaling to Japan and then to follow it to France will
>>   >   >   >lead to non-optimal media paths and shrink down the time
>>   >   >   >needed by endpoints and intermediate points to process the
>>   >   >   >media packets to impossibly low constraints.  Clearly, some
>>   >   >   >discussion of mobility/nomadicity is needed.
>>   >   >   >
>>   >   >   >[MB] I think you are assuming that the SBC always routes
>>   >   >   >the media. This is far from true. Service provider policy
>>   >   >   >typically dictates the media path and that is what the SBC
>>   >   >   >should implement on a session basis. I think Christian also
>>   >   >   >brought this up and this probably needs mention in the
>>   >   >   >traffic management section. An interesting example is that
>>   >   >   >the service provider may provide a more controlled
>>   >   >   >environment for the media.
>>   >   >   >
>>   >   >   >Mike
>>   >   >   >
>>   >   >[snip]
>>   >   >
>>   >   >_______________________________________________
>>   >   >Sipping mailing list
>>   >https://www1.ietf.org/mailman/listinfo/sipping
>>   >   >This list is for NEW development of the application of SIP
>>   >   >Use [email-masked] for questions on
>>   >   >current sip Use [email-masked] for new developments of core SIP
>>   >   >
>>   >
>>   >_______________________________________________
>>   >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>   >This list is for NEW development of the application of SIP
>>   >Use [email-masked] for questions on
>>   >current sip Use [email-masked] for new developments of core SIP
>>   >
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments of core SIP
>>
> 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP