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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2005 17:29:58 -0500

Here are some comments after a first read of this new draft:

I'm not sure exactly how to interpret these requirements. They require a 
lot of features, but don't distinguish between features that must always 
be applied, and that that must be available but that are 
enabled/disabled by policy. In fact, while there is a lot of mention of 
policy in the discussion, there is NO mention of policy in the 
requirements themselves. I would expect to see a lot of requirements 
about how policy is described and how it affects the actions of the SBC.

Also, it seems to me that there are two kinds of things that need to be 
specified about SBCs:
- what they are capable of doing - the kinds of things they might
   change in requests going by
- the things they are guaranteed NOT to do.

The latter is at least as important as the former. It will hopefully 
allow us to reason about when an SBC will/won't break something. I would 
like to see both kinds addressed in the requirements.

Section 5.1.1 seems to say that an SBC must always hide topology. But 
the need to perform this may depend on the kind of relationship that 
exists with the peer.

The requirement on modifying SIP headers seems weak to the point of 
uselessness, because it doesn't say which headers may be modified, what 
kinds of modifications might be made, or the conditions that might 
determine this. The end result is that this just says an SBC MAY mess up 
my sip message in any way it chooses.

Section 5.1.3 talks about inserting/deleting/relaying 
P-Asserted-Identity headers. You have described the SBC as having an SBC 
Network and an External Network. To do anything other than delete 
P-Asserted-Identity it needs to have some kind of trust relationship 
with two networks. I believe this requires quite a bit more explanation.

The rest of section 5.1.3 has a lot of words, but it appears the bottom 
line is just that an SBC is going to break the identity mechanism. This 
needs to be made much clearer. It probably could be coordinated with 
discussions about policy - some policies are compatible with identity, 
others are not.

You discuss bandwidth admission control, but not the set of 
conditions/assumptions that must hold before it is possible for an SBC 
to do this. Assuming you are talking about media bandwidth, how do 
determine at the start of a call what the bandwidth requirements for the 
session are? I think you can only do this by bounding the bandwidth for 
a call (e.g. enough for a single audio stream with particular 
characteristics) and blocking calls, or changes to calls, that request 
more. It would be good to discuss what you have in mind when multimedia 
calls are a possibility. E.g.
- what if in the middle of my session I add video to my audio call?
- what if I send an offerless invite, and the reply offers an
   MSRP over TLS session rather than voice?

There is mention of the need for the SBC to act as an RTP translator. 
But there is no mention of what it should/must do for non-RTP media 
streams. What about TCP or TLS streams for floor control or MSRP?

	Paul

_______________________________________________
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

---

From: "Mike Hammer" <[email-masked]>
Date: Wed, 2 Feb 2005 10:24:45 -0500

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.

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. 

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.

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.

Mike

   >-----Original Message-----
   >From: [email-masked] 
   >[mailto:[email-masked]] On Behalf Of Paul Kyzivat
   >Sent: Tuesday, February 01, 2005 5:30 PM
   >To: sipping
   >Subject: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
   >
   >I'm not sure exactly how to interpret these requirements. 
   >They require a lot of features, but don't distinguish 
   >between features that must always be applied, and that that 
   >must be available but that are enabled/disabled by policy. 
   >In fact, while there is a lot of mention of policy in the 
   >discussion, there is NO mention of policy in the 
   >requirements themselves. I would expect to see a lot of 
   >requirements about how policy is described and how it 
   >affects the actions of the SBC.
   >
   >Also, it seems to me that there are two kinds of things 
   >that need to be specified about SBCs:
   >The latter is at least as important as the former. It will 
   >hopefully allow us to reason about when an SBC will/won't 
   >break something. I would like to see both kinds addressed 
   >in the requirements.
   >
   >Section 5.1.1 seems to say that an SBC must always hide 
   >topology. But the need to perform this may depend on the 
   >kind of relationship that exists with the peer.
   >
   >The requirement on modifying SIP headers seems weak to the 
   >point of uselessness, because it doesn't say which headers 
   >may be modified, what kinds of modifications might be made, 
   >or the conditions that might determine this. The end result 
   >is that this just says an SBC MAY mess up my sip message in 
   >any way it chooses.
   >
   >P-Asserted-Identity headers. You have described the SBC as 
   >having an SBC Network and an External Network. To do 
   >anything other than delete P-Asserted-Identity it needs to 
   >have some kind of trust relationship with two networks. I 
   >believe this requires quite a bit more explanation.
   >
   >The rest of section 5.1.3 has a lot of words, but it 
   >appears the bottom line is just that an SBC is going to 
   >break the identity mechanism. This needs to be made much 
   >clearer. It probably could be coordinated with discussions 
   >about policy - some policies are compatible with identity, 
   >others are not.
   >
   >conditions/assumptions that must hold before it is possible 
   >for an SBC to do this. Assuming you are talking about media 
   >bandwidth, how do determine at the start of a call what the 
   >bandwidth requirements for the session are? I think you can 
   >only do this by bounding the bandwidth for a call (e.g. 
   >enough for a single audio stream with particular
   >characteristics) and blocking calls, or changes to calls, 
   >that request more. It would be good to discuss what you 
   >have in mind when multimedia calls are a possibility. E.g.
   >But there is no mention of what it should/must do for 
   >non-RTP media streams. What about TCP or TLS streams for 
   >floor control or MSRP?
   >
   >	Paul
   >
   >
   >Use [email-masked] for questions on 
   >current sip Use [email-masked] for new developments of core SIP
   >

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 3 Feb 2005 23:10:45 -0500

Paul,

Our responses inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Tuesday, February 01, 2005 5:30 PM
To: sipping
Subject: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

[MB] There are 4 main kinds of policy we identified in the draft. security,
traffic mgmt, interworking and transcoding. I guess the draft doesn't say
that explicitly anywhere. Thanks for pointing that out. I am not sure how
exactly we can describe policy descriptions on the SBC beyond what is in the
draft, but whatever can be done would be useful. I am sure there will be
some more comments in this area.

[MB] This should be addressed in the next version. I think we want to nail
the interworking/harmonization section down a bit more which will address
this area. I hope the first version helps in understanding the problem a bit
and people will have suggestions keeping that in mind.

Section 5.1.1 seems to say that an SBC must always hide topology. But 
the need to perform this may depend on the kind of relationship that 
exists with the peer.
[MB] I think that either security is required or it is not. The levels
argument is quite fuzzy and only complicates the behavior.

[MB] I think if security is not a border characteristic, then the SBC must
relay. The draft does mention that the SBC has a trust relationship with the
SBC Network only. 

[MB] I am expecting the identity folks to comment and then maybe fix the
behavior.

[MB] We attempted to narrow down the b/w management problem to keeping track
of how much bandwidth is used on the "interconnect" between the SBC and the
External Network. Looking at an INVITE or 200 OK etc which may be going into
the network or coming out of it doesn't tell much about how the media stream
is going to flow. For example, the application server for an endpoint in the
external network could be in the SBC Network and the media traffic could be
directly flowing between two endpoints in the external network while the
call signaling goes through the SBC Network (somewhat like media path
optimization). My guess is that it is best that the SBC simply monitors what
is going on and rejects calls if the utilized capacity increases the limit
on the interconnect. The reject depends on the SIP message as you point out
and there is no way to reject something in a 200 OK or ACK. So this needs to
be thought through a bit more (deleting the body or sending a combination of
4xx/BYE to the caller and callee etc). One of the requirements is that the
offer must never be altered by the SBC.

[MB] I think the RTP Translator requirement should be only for the
transcoding scenario. It needs to be fixed in the draft. Thanks.

	Paul

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 3 Feb 2005 23:41:03 -0500

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:

[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. 

[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)

[MB] Encrypted SDP can be deployed. However the model is hop-by-hop as 5.1.2
says.

[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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Feb 2005 00:13:40 -0500

more comments inline.

	Paul

> some more comments in this area.

Well, I presume this work may eventually result in a draft specifying 
the behavior of an SBC. I would expect to see explicit requirements 
around policy, that would then be satisfied by explict policy control 
mechanisms:
- various kinds of security policy (authorization rules, options for
   various degrees of address hiding, etc.)
- traffic management policies - I'm really interested to see what you
   have in mind here.
- policies for interworking - I suppose this might specify kinds of
   perversions that might be applied to messages to make them work with
   various kinds of non-conforming devices.
- whatever a transcoding policy might be. Perhaps that would be
   specification of transcoders and their capabilities.

I gather you have a lot of very specific ideas about what is needed. But 
whatever those are doesn't peek thru at all well in the document. (If 
you don't know what is needed, then why is this work being done?)

> and people will have suggestions keeping that in mind.

Simple suggestion: do no harm.

> argument is quite fuzzy and only complicates the behavior.

I disagree. You apparently have a very specific idea what you mean by 
security, but I don't.

I find that my house is secure enough because it has locks on the doors. 
I don't feel a need to keep secret who lives in my house. I don't much 
understand this concept of address hiding at all. I guess it is an 
attempt at security by obscurity, which is generally considered a bad 
technique.

Surely there can be many kinds of contractual arrangements between 
peers. If I have a very close relationship with a peer then I may well 
not feel any need to keep the addresses of the nodes in my network a 
secret. When there is a need to peer with a mortal enemy I may want more.

The degree that you attempt to hide things may well make the difference 
between connections that work and those that don't. For instance, what 
if there are addresses in parts of the message that the SBC doesn't 
understand? If it is being paranoid it may drop any headers it doesn't 
understand, to ensure that no addresses sneak through. But that could 
break lots of things. If not in such a paranoid mode it might let 
headers it doesn't know go through.

> relay. The draft does mention that the SBC has a trust relationship with the

That doesn't seem right to me. P-Asserted-ID depends on trust 
boundaries, and presumably the SBC is the edge of a trust boundary. For 
messages coming in from outside, it is responsible for the validity of 
any assertions that it adds or lets through. It doesn't seem a casual 
thing to do.

Similarly, the SBC is responsible in some cases for removing assertions 
from messages leaving the trust boundary.

Seems like policy is needed about this.

> External Network.

You did? I missed that.

In any case, I still don't get how you can do this as an admission 
control policy without some mechanism for determining how much bandwidth 
will be needed by this session. Since it isn't obvious how you would 
determine that during session establishment this really deserves more 
explanation.

> Looking at an INVITE or 200 OK etc which may be going into
> on the interconnect.

If you are going to call this admission control, which rejects calls, 
then it can only make its decisions at call initiation time. So what 
does it do if demand changes after calls are established?

In any case, this sounds like magic to me. You suggest that media 
traffic which flows only outside the SBC network doesn't count. (And 
presumably media traffic which flows only *inside* the SBC network 
doesn't count either. You seem to be concerned only with traffic which 
flows across the boundary. But in general there is no way to tell how 
the traffic will flow just by examining the addresses.

So, if there are requirements to determine what path the traffic will 
follow, then those ought to be called out.

> The reject depends on the SIP message as you point out

Really! I had the impression that SBCs usually/often modify the offers 
and answers in order to insert their own RTP translator into the path.

Something else that needs to be spelled out better.

---

From: "Mike Hammer" <[email-masked]>
Date: Fri, 4 Feb 2005 11:21:36 -0500

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.

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?

Mike

   >From: Medhavi Bhatia [mailto:[email-masked]] 
   >Sent: Thursday, February 03, 2005 11:41 PM
   >To: 'Mike Hammer'; 'Paul Kyzivat'; 'sipping'
   >[mailto:[email-masked]] On Behalf Of Mike Hammer
   >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 
   >[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]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 4 Feb 2005 21:40:27 -0500

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,

[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.

[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

[snip]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 4 Feb 2005 23:26:09 -0500

Paul,

We will add some use cases next. I do have a small comment below.

[MB] If it is a QoS border, then the SBC should simply relay the PAI. I'd
assume in most cases, when there is a trust boundary, then it operates as
you described.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Feb 2005 00:37:09 -0500

Your comment below seems to imply a scenario where a service provider's 
trusted network is partitioned into two parts with different QoS 
disciplines, and an SBC is translating between them. Is that what you mean?

(The SBC - a floor wax *and* a desert topping. :-)

	Paul

Medhavi Bhatia wrote:
>>relay. The draft does mention that the SBC has a trust relationship with
> 
> the
> 
>>SBC Network only. 
> 
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sat, 5 Feb 2005 09:46:33 -0500

Paul, you crack me up! Yes. I am talking about an enhanced DiffServ border
element.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Saturday, February 05, 2005 12:37 AM
To: Medhavi Bhatia
Cc: 'sipping'
Subject: Re: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

	Paul

---

From: "Mike Hammer" <[email-masked]>
Date: Mon, 7 Feb 2005 11:35:57 -0500

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

   >Sent: Friday, February 04, 2005 9:40 PM
   >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. 
   >
   >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
   >
   >

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 8 Feb 2005 14:15:44 -0500

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,

Mike

---

From: David R Oran <[email-masked]>
Date: Tue, 8 Feb 2005 14:42:22 -0500

On Feb 8, 2005, at 2:15 PM, Medhavi Bhatia wrote:

> necessary, there isn't one.
Good. Then why is it in the requirements?

> NATs are good examples. If we can avoid using
> real problem which exists in some networks,
Where? BGP does not NAT between ASs.

> ACLs do get used in the real
> world.
>
What does this have to do with address hiding? Acls get used to stomp 
on traffic you want to prevent from going any further.

> To me, topology hiding is not a big issue here.
Good.

> At the signaling level it
> can be done using a proxy or B2BUA.
It can, but there's a tradeoff - it inhibits fault isolation and 
diagnosis.

> IP address hiding at the media level
> requires SDP inspection and is an issue.
It also requires SDP *modification* and that's an even bigger issue. It 
also requires that the media and signaling have partially or totally 
coupled routing, which is the biggest issue of all.

> So is identity and some header
I agree on the taxonomy pretty much, but not that the taxonomy leads to 
any particular set of requirements.

Dave.

>>> environment for the media.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Mike Hammer" <[email-masked]>
Date: Tue, 8 Feb 2005 15:02:02 -0500

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

   >Sent: Tuesday, February 08, 2005 2:16 PM
   >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.
   >
   >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 
   >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
   >
   >
   >   >Sipping mailing list  
   >https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Feb 2005 15:34:45 -0500

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.

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.

Brian

> Sent: Tuesday, February 08, 2005 3:02 PM

---

From: Tom Taylor <[email-masked]>
Date: Tue, 08 Feb 2005 15:44:42 -0500

There's something missing in this discussion: topology hiding as a means of 
providing a single point of contact.  This came up in the mini-BOF discussion: 
it's simpler for the administrator of an enterprise firewall, for instance, to 
allow for traffic to and from a single service-provider address than all the 
possible addresses to which the traffic may flow.

I'm just saying what I heard - flame away if I didn't understand the point 
properly :-{

David R Oran wrote:
> What does this have to do with address hiding? Acls get used to stomp on 
> traffic you want to prevent from going any further.
> 
> It can, but there's a tradeoff - it inhibits fault isolation and diagnosis.
> 
[snip]

---

From: "Shai Mohaban" <[email-masked]>
Date: Tue, 8 Feb 2005 23:53:23 +0200

I am not trying to make the case for why topology hiding is good or not
but here are a couple of reasons why some carriers are using it today:

1) Access control - in peering scenarios many carriers actually impose a
hard limit on the number of IP addresses they are willing to allow VoIP
traffic to come in from a peer (4 is not an uncommon choice). This is
done e.g. because they generally have a firewall (or just access lists
in the ingress router) limiting incoming traffic and they want to limit
the number of access lists/rules that they need to maintain. This pretty
much mandates the peer to use something like an SBC (or a number of
them) with these IP addresses. It enables the peering carrier to move
around and add entities like gateways, SIP servers, etc without needing
to re-publish the new addresses towards the other carrier (who would
then otherwise need to re-configure the ACLs accordingly).

2) Packet size reduction, believe it or not...  It seems UDP is still
the most common transport for SIP and as the networks become larger and
more complex the SIP messages also tend to get larger. Some parts of
topology hiding, such as route stripping, are used to reduce the overall
message size and prevent fragmentation.

> Sent: Tuesday, February 08, 2005 10:02 PM
>    >This list 
> is for NEW development of the application of SIP

---

From: "Mike Hammer" <[email-masked]>
Date: Tue, 8 Feb 2005 17:13:02 -0500

Tom,

Thanks for speaking up.  I'm sure there are a lot more angles to the meaning
of this buzzword.  I was only trying to stir up the pot a little to see what
floated up.  I'm not confident that there is a common understanding, and
therefore will be common behavior.  I'm also wondering whether the current
BEHAVE work will cover SBC's too.

Mike

   >From: Tom Taylor [mailto:[email-masked]] 
   >Sent: Tuesday, February 08, 2005 3:45 PM
   >To: David R Oran
   >Cc: Medhavi Bhatia; 'Paul Kyzivat'; 'sipping'; 'Mike Hammer'
   >There's something missing in this discussion: topology 
   >hiding as a means of providing a single point of contact.  
   >This came up in the mini-BOF discussion: 
   >it's simpler for the administrator of an enterprise 
   >firewall, for instance, to allow for traffic to and from a 
   >single service-provider address than all the possible 
   >addresses to which the traffic may flow.
   >
   >I'm just saying what I heard - flame away if I didn't 
   >understand the point properly :-{
   >
   >David R Oran wrote:
   >> 
   >hiding is 
   >>> NATs are good examples. If we can avoid using private 
   >networks and 
   >>> shift to IPv6, then NATs are not required. However, service 
   >customers) is a 
   >> It also requires SDP *modification* and that's an even 
   >bigger issue. 
   >> It also requires that the media and signaling have partially or 
   >> totally coupled routing, which is the biggest issue of all.
   >> 
   >>> manipulation related features. Do we (and possibly others on the 
   >>> list) agree on these three ?
   >>>
   >> I agree on the taxonomy pretty much, but not that the 
   >taxonomy leads 
   >> to any particular set of requirements.
   >> 
   >> Dave.
   >> 
   >[snip]
   >

---

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

Shai Mohaban wrote:
> the number of access lists/rules that they need to maintain.

None of the above implies any requirement for topology hiding. When no 
hiding is going on, there are lots of addresses I may discover that will 
never have any need to address directly. If attempting to address them 
failed I would not be upset.

> This pretty

Yes, if you want to limit the points of ingress then you will have to do 
something. Lets capture that as a requirement in its own right, rather 
than as a (bogus) justification for topology hiding.

> message size and prevent fragmentation.

If that is a requirement, then lets capture that one too. Header 
stripping is one solution to that problem, but not the only one. And 
note that some techniques for topology hiding (e.g. cryptographic 
obfuscation) may increase message size.

	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 9 Feb 2005 07:25:20 -0600

Hi, Mike,

My understanding is that BEHAVE specifically had SBCs out-of-scope, 
and that the SIPPING session was the result of a desire to discuss 
SBCs without distracting BEHAVE.

I wouldn't be surprised to se an SBCBEHAVE start up in parallel, but 
don't expect SBCs to go back into BEHAVE.

Spencer, who is pretty sure there is not a common understanding of 
what's good and bad about topology hiding...

From: "Mike Hammer" <[email-masked]>
To: "'Tom Taylor'" <[email-masked]>; "'David R Oran'" 
<[email-masked]>
Cc: "'Paul Kyzivat'" <[email-masked]>; "'sipping'" 
<[email-masked]>; "'Medhavi Bhatia'" <[email-masked]>
Sent: Tuesday, February 08, 2005 4:13 PM
Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 9 Feb 2005 12:10:15 -0500

-----Original Message-----
From: Mike Hammer [mailto:[email-masked]] 
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,

[MB] Topology Hiding just seems one of the mechanisms SPs want to use. It is
just part of solution. There are so many Tier-3 and Tier-2 providers using
SIP today. 100% of them are relying on THIG right now. I would assume the
Tier-1 SPs would use THIG in addition to other mechanisms. Also, SPs do not
necessarily use identity to do accept calls, they use the a security
association with the previous hop. This could be TLS, IPSec in addition to
an ACL. For mobile SPs, IP address hiding at the media level does not seem
to be a requirement, but the first hop proxy specs require that the UA not
encrypt the SDP. 

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.  
[MB] The endpoint could do STUN, that is not an issue here. A STUN server
placed between the endpoint's firewall and the first hop proxy would solve
the NAT traversal problem in most cases. However this is just part of the
solution. Assume we have a call going from ep1--SP1--SP2--SP3--ep2. Now ep1
and ep2 can use a STUN server in SP1 and SP3 domain. What if SP2 has a NAT
facing SP1 and SP2. How do we traverse those NATs if the SDP is encrypted by
the endpoint ? I like TLS as the solution. On a high level, this just makes
a case for the SDP to be encrypted in a hop by hop fashion.

One
[MB] 

Mike

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 9 Feb 2005 14:57:58 -0500

Let me just summarise the discussion a bit and maybe then we can move on to
some of the other key issues. For topology hiding and IP address hiding,
there is a market requirement definitely. There are three main requirements:
dis-intermediation, private networks, ACLs. ACLs are part of a bigger
security framework and I am sure there are ways to do this using IPSec and
TLS. Not everyone will deploy these. This is clear to me. Private networks
are always going to be there. I know dozens of Wall Street Firms who are
only increasing their growth (and VLAN technology is there).
Dis-intermediation is a big problem in Tier-2 and Tier-3 environments and we
have learnt of some Tier-1 environments where this has been exposed as a
requirement. Here is my two cents: THIG at the signaling level really is not
a big issue. At the media level, this creates a requirement for the SDP to
be visible to the proxy -- note that I am not saying that the SDP is in
plain text. What I want to now find out is that are there other applications
too which require the SDP to be visible to the proxy ? I do know of two more
- the UE/P-CSCF in IMS is like that and multiple firewall traversal (>2).

RFC 3329 and TLS based hop by hop security really seems to be a good
solution to promote. In general any hop-by-hop security mechanism (even
S/MIME) would be OK too. If this seems like a reasonable closure on the THIG
issue, we can move to the identity and header manipulation issues. Comments
etc ?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Tuesday, February 08, 2005 5:26 PM
To: Shai Mohaban
Cc: 'sipping'; 'Medhavi Bhatia'; 'Mike Hammer'
Subject: Re: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

	Paul

---

From: "Mike Hammer" <[email-masked]>
Date: Wed, 9 Feb 2005 17:46:52 -0500

Medhavi,

You talk about Tiers of SPs.  How about we clarify as follows:

There are no more than two ITSPs, one serving the caller, one serving the
called party, where the same ITSP can serve both parties.  (There is also
the possibility of none, but good luck getting connected, especially when
one side or the other logs off.)

There may be one or more ISPs:  access, intermeidate, terminating.  

The ITSP serving a party may be the same as any combination of the ISPs or
none.

Is this tier concept useful for ISPs?  Maybe.
Is this tier concept useful for ITSPs?  That's debatable.

Mike

[snip]

   >[MB] Topology Hiding just seems one of the mechanisms SPs 
   >want to use. It is just part of solution. There are so many 
   >Tier-3 and Tier-2 providers using SIP today. 100% of them 
   >are relying on THIG right now. 

{snip]

   >[MB] The endpoint could do STUN, that is not an issue here. 
   >A STUN server placed between the endpoint's firewall and 
   >the first hop proxy would solve the NAT traversal problem 
   >in most cases. However this is just part of the solution. 
   >Assume we have a call going from ep1--SP1--SP2--SP3--ep2. 
   >Now ep1 and ep2 can use a STUN server in SP1 and SP3 
   >domain. What if SP2 has a NAT facing SP1 and SP2. How do we 
   >traverse those NATs if the SDP is encrypted by the endpoint 
   >? 

[snip]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 9 Feb 2005 21:50:19 -0500

Mike,

By Tiers, I was referring to how big/powerful the SP is. I don't quite
understand the ITSP example below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Hammer
Sent: Wednesday, February 09, 2005 5:47 PM
To: 'Medhavi Bhatia'; 'Paul Kyzivat'; 'sipping'
Subject: RE: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt

Medhavi,

Mike

[snip]

{snip]

[snip]

---

From: "Mike Hammer" <[email-masked]>
Date: Thu, 10 Feb 2005 09:45:08 -0500

Try these combinations:

Access ISP=Time-Warner
Originator-ITSP=Vonage
Intermediate ISP=MCI
Terminating-ITSP=Comcast 
Terminating ISP=Verizon DSL

Or

Access ISP=Time-Warner
Originator-ITSP=Time-Warner
Intermediate ISP=MCI
Terminating-ITSP=Comcast 
Terminating ISP=Comcast

Or 

Access ISP=Verizon DSL
Originator-ITSP=ATT
Intermediate ISP=ATT
Terminating-ITSP=ATT 
Terminating ISP=Deutsche Telekom DSL

Mike

   >Sent: Wednesday, February 09, 2005 9:50 PM
   >By Tiers, I was referring to how big/powerful the SP is. I 
   >don't quite understand the ITSP example below.
   >
   >There are no more than two ITSPs, one serving the caller, 
   >one serving the called party, where the same ITSP can serve 
   >both parties.  (There is also the possibility of none, but 
   >good luck getting connected, especially when one side or 
   >the other logs off.)
   >
   >The ITSP serving a party may be the same as any combination 
   >of the ISPs or none.
   >