Cullen Jennings wrote:
Jiri, I would like to make sure I understand exactly what is broken
here. So, say some B2BUA that implements 4474, like SER is running at
iptel.org.
It can be even a proxy (well if we consider it then still legitimate enough
to call it a "SIP proxy" if it rewrites SDP).
And I have an account, say [EMAIL PROTECTED] Now my phone is
registered and sends an INVITE to SER with the From set to
"[EMAIL PROTECTED]". My understanding is SER edits the SDP then does the
4474 signature and sends it on.
That's a scenario which indeed DOES work -- SDP rewriting occurs before
signing
and there is no further rewriting before verification. Our
implementation is done
the way it works under these assumptions.
In detail: caller's proxy thinks the caller is behind a NAT and decides to
rewrite SDP in INVITE to include an RTP relay's address in it. it signs
the modified SDP. Note that message integrity check refers to what this
proxy
is receiving, not sending...which is still fine (at least for me). It
forwards
to recepient's proxy, which verifies the SDP. Then it can even rewrite
it too
(for sake of callee's NAT traversal for example) -- as long as downstream
entities trust this proxy to have done its verification job.
The problem is the assumption that we can manage to get the signer and
verifier
next to each other without an SDP rewriter in between them. It goes too
far in the
field despite I find it unfortunate. Shortly, there are incredibly many
"middleboxes" that stand in the way and change the SDP. These include:
SIP-aware firewalls (ALGs are IMO plain broken vehicle but they are in the
field), SBCs, load-balancers, and transcoders.
To make it clear: I don't think that the 4474 architecture is broken, I
think
that the assumption of the SIP path not being broken is too brittle. I was
initially hopeful that one could put 4474 in the administrative borders
so that interdomain trust is not damaged by intermediary SDP rewrites.
Unfortunately it seems that in the field any "atomic" link can be
still broken by some SDP re-writers.
The "right" architectural fix would be to make sure that there are no
SDP rewrites
between signer and verifier (much weaker assumption than end-2-end SDP
integrity)
which is IMO doable but is for some reason not being done. In lieu of which,
I think giving up on SDP integrity would allow better penetration by
being more
robust against such networks.
-jiri
So in the case you are discussing here, what exactly is broken that
stops iptel.org from both editing SDP and doing 4474?
_______________________________________________
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
