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

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 Feb 2005 10:26:43 -0500

Thanks for all the comments.

I am trying to summarise some problem areas and I need feedback and
comments...

- Arbitrary SIP header modification. This seems to be one of the key
problems which can be introduced by an intermediate entity. This could be an
SBC or an application server from what I can gather in all the past emails.
If the caller encrypts the headers or uses any identity mechanisms, then
this problem should go away in theory, but we get into the following
problem:

- How do intermediate devices (like SBCs or application servers) do "things"
(like call teardown, initiate re-INVITEs, modify/inspect SDP) in a manner
that there is no perceived man in the middle attack. I think the
idenity-RFC/draft also identify this as an open problem.

I have lumped up the SBC and application servers into the intermediate
entities and I think that may aggravate a few folks. I expect to hear some
good arguments.

Requirements to keep in mind: actions of intermediary need to be trusted by
end users. In addition, intermediate entities should also be able to do the
"things" I identified above. I expect to get a few flames on this too.

Thanks - Medhavi.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, February 10, 2005 2:39 PM
> To: Medhavi Bhatia
> Subject: Re: [Sipping] Re: draft-bhatia-sipping-sbc-00.txt
> 
> 
> 
> Medhavi Bhatia wrote:
> >  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.
> >
> > [MB] Paul I meant ACL's which use certificates instead of IPs. What
other
> > techniques are you talking about ?
> 
> I thought you had spoken of source IP addresses.
> 
> But here you are talking about TLS certs. So for instance I somehow know
> I should be trying to connect to sip:[email-masked], so I
> establish a TLS session there, using my cert. The SBC decides whether it
> likes my cert or not?
> 
> This is not really my field. But I have an impression there are a number
> of techniqes that can work at the IP level. Would like to just nail down
> the fundamental requirements and let the people who know about solutions
> chime in.
> 
> 	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: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 18:11:57 -0500

> "things" I identified above. I expect to get a few flames on this too.

In many cases there is at least *some* trust in the intermediate 
entities. (We trust that the proxy will send the request on to the real 
destination if possible.)

I think the biggest problem here is *disclosure*. It isn't sufficient to 
be told - oh, there is going to be this SBC in all calls, and it is 
going to do *stuff* to the messages going by, but it will all be *good 
stuff*. That isn't sufficient for us to design and implement new 
features with any assurance that they will continue to work.

If there is going to be topology hiding, then there should be a 
specification of what is done to achieve it: specific headers removed in 
one direction and replaced in another, other headers where an address is 
replaced with another, and what happens when traffic is addressed to 
that address. Etc.

If there is disclosure and then specific products don't conform to what 
has been disclosed there are remedies. But if there is no disclosure 
then there are no remedies.

	Paul