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

From: "Parolkar, Satish" <[email-masked]>
Date: Thu, 10 Feb 2005 09:10:37 -0600

Re: the comment "For topology hiding and IP address hiding, there is a
market requirement definitely."
I am not sure whether Topology Hiding was a requirement provided to the
vendors by Service Provider community OR if it was a feature marketed by
the vendor community.

Topology Hiding was marketed as a Security mechanism.  Internal IP
addresses exposed to the peer networks through VIA, RECORD-ROUTE and
SERVICE-ROUTE. If Topology Hiding does not help Security, it need not be
a mandatory S/BC technical requirement. 

The IETF S/BC document needs to clarify the true purpose of Topology
Hiding. The e-mail thread so far indicates (1) ACL (2) Private Networks
(3) dis-intermediation as the reasons for Topology Hiding. Why not state
them in the document.

Thanks,

Satish

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

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

Shai Mohaban wrote:
> 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.

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

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.

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

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

>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Mike Hammer
>>Sent: Tuesday, February 08, 2005 10: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

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Feb 2005 10:59:17 -0500

> vendors by Service Provider community OR if it was a feature marketed by

Amen! I hope we end up with a list of requirements that the consumers of 
these devices have, rather than a list of what the manumfacturers of the 
devices want to supply.

> (3) dis-intermediation as the reasons for Topology Hiding. Why not state

I don't understand (1) or (2) as requirements *for topology hiding".

If you use ACLs so that I only have access to the SBCs in your network, 
then it doesn't matter if I can see addresses of other components, 
because I won't be permitted to access them.

Private networks are an even simpler case. If you have nodes in your 
network that have private addresses that aren't globally reachable, then 
there is no particular reason to hide them, because I can't reach them 
anyway.

In both cases, the issue isn't address hiding at all - it is ensuring 
that those visible addresses that should be used by a peer are in fact 
addresses that can be used. This is at least related to the problems 
that GRUUs and STUN are intended to solve. This may require adding or 
replacing certain addresses, but doesn't require hiding any.

There also seems to be a lot of overlap here with what firewalls do. I'm 
not wild about firewalls either, but at least they are better understood 
than SBCs. The relationship should be carefully identified, both in the 
requirements, and in any solution documents that follow. In the 
requirements, any required relationship should be mentioned.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Feb 2005 11:28:52 -0500

The term "topology hiding" seems misleading. The case identified, namely 
  limiting the number of source IP addressing, has little to do with 
hiding and shouldn't be labeled as such. This is more of a "media 
funneling" issue. The requirement is probably even too low-level if 
stated as such; rather, the higher-level requirement seems to be that 
the provider receiving media streams wants to be sure that the media is 
coming from the right party. This could be solved by some form of 
media-level authentication, including SRTP.

The notion that not exposing IP addresses (e.g., in Via headers) that 
are otherwise reachable offers any type of security is very close to 
voodoo security.

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 10 Feb 2005 11:54:53 -0500

I'd agree that topology hiding as a term is misleading especially when
addresses need to be changed because of routing reasons (private networks).

ACLs is how things are deployed today and I see them evolving at layer4 and
above. Consider this case: A carrier of carriers, SPB (sometimes called a
middle carrier connecting two CLECs) is trying to use IPSec/TLS. SPA -- SPB
-- SPC. SPB does not want to whole world to be able to connect to it because
of limited business relationships. The ACL on SPB needs to say that "allow
certificate of SPA". Today, this is mostly done just using IP address
(voodoo), but this will just evolve as deployments of TLS start happening. I
don't see how ACLs go away.

Also if SPB has a firewall each peering with SPA and SPC, I'd be interested
to know how that is traversed w/o cooperation between proxies of SPA, SPB
and SPC. The endpoint can only participate in traversal of the firewalls
connecting them to SPA and SPC networks.

-Medhavi.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Feb 2005 13:23:27 -0500

> don't see how ACLs go away.

 From your description above, the requirement of SPB is that it needs a 
way to allow traffic only from sources it has a business relationhip with.

ACLs based on source IP address may be *a* solution, and maybe you see 
it as the only viable solution. But lets figure that out rather than 
taking is as a given. I know there are other techniques than ACLs based 
on source IP address.

	Paul