Hi Cullen,
I'm not sure I understand all of the sensitivity of the cat skin peeling
business :-). I'm just wondering if there are other folks who consider
telling
callee who is calling him by demonstrating a traceable not-worthless address
important. And in particular doing so in a robust way that most likely
survives
ALG/SBC/evil-middlebox traversal (especially being resilient against such
common things as SDP rewrites, whatever today's SIP path topology is).
Or do you think this is not important or we have it or I haven't articulated
the point in a sensible way?
-jiri
Cullen Jennings wrote:
On Apr 1, 2009, at 12:52 AM, Dean Willis wrote:
On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote:
On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
I'm worried this is only a wishful thinking. While perfectly
logical, still even in such constrained setups some bizzar
ALGs do in my experience appear in the middle, change SDP
and make thus the identity worthless.
The thing I keep asking is can we make a list of reason why SDP and
headers get changes and in what scenarios they do this. I think it
will be hard to sort how to fix this without being clear what needs
to be fixed.
For example, one of the things we might want to say is something
like: the Phone is behind a NAT and connects to it's proxy /
registrar for its' domain. That proxy/b2bua whatever mucks with
IP/ports in the SDP for NAT traversal. Then we could ask if 4474 is
broken in this case or not and what might be a good way of solving
the problem of having UAs behind NATs.
You seem to be trying to construct an argument for "why 4474 isn't
broken" based on being able to transform every use case where RFC 4474
breaks to one where it doesn't, generally by mandating a different
approach to solving problems (TURN vs, SDP fixup, for example). You
seem to expect this to prove that RFC 4474 is fine as-is, needing no
modification to its A/M signing.
No Dean. I am trying to get to what is the problem - and what I see
happening is several people trying to transform that into Jon and Cullen
are blocking work in this space which is not at all true - I would love
to see some progress in this space.
It might be useful to counter this with "If RFC 4474 isn't broken, why
isn't it being deployed?"
It's not needed in the bulk of todays deployments. Deployments using
email stye addresses are directly connecting often with mutual TLS or an
equivalently bound VPN. When enterprise B gets a call from
[email protected] and it came over a TLS connection that had a certificate of
a.com, well you get something that meets B's authorization needs with
just that. For deployments using E.164 style addresses - they are pretty
much all capable of connecting in and out of the PSTN and there is no
interest in a security properties greater than what PSTN provides as
that is acceptable for most these users. This can easily be accomplished
with PAI and a transitive trust model. In fact, many of these
deployments have SP A talking to SP B talking to SP C and B explicitly
wants to hide that they used SP C instead of terminating the call
themselves. B needs to make it look like to A like B terminated the call
into the PSTN vs handing it to C. These sort of deployments require B to
look to A like the end not the middle.
I expect that the answer is "because users currently expect to correct
their topological issues using SBCs instead of the tools that work
with 4474. You might not think they have legitimate reasons for doing
it this way, but the fact remains -- that's how they do it.
You expect it might be one thing - fair enough, other disagree. What I
am suggesting will be the best way to make progress is to find out what
they do and what needs caused them to do it. Sure, for any problem,
there will be multiple ways to skin the cat. You are accusing me of
saying that the only way people are allowed to skin the cat is using a
potato peeler and that most people probably will not use a potato peeler
for cats no matter what I want. I am not in the slightest telling people
they have to use a potato peeler - I'm arguing that until we have some
common ground on if we are trying to peel a cat or potato or both, we
are unlikely to make progress on the best tool(s) for the job.
Technically correct or not, ordering this to flow out is likely to
give you wet feet.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
