Subject: [Sip] francois' comments and why RFC4474 not used in the field

From: Jiri Kuthan <[email-masked]>
Date: Sat, 28 Mar 2009 21:02:29 +0100

As we were running out of time in the meeting, I wanted to
follow up on an argument which Francois has made: RFC 4474
works if the identity provider and verifiers are "next to
each other", thus we have no problem with this RFC.

/* hope I didn't misinterpret, let me know should that be
the case */

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.

I think the bottom line is the protocol is not really end-to-end.
It makes quite some assumptions about the quality of underlying
network (particularly about not changing SDPs) as opposed to
trying to deal with lack of it. In fact, SDP payloads are
changed at quite a number of devices: proxy servers, B2BUAs,
SBCs, you name it. Assuming there is nothing in the way
which won't change SDP is just NOT ROBUST.

Other way to look at it is it is function overloading. You ask
for identity and get message integrity -- consequently when
the latter fails, the former, which you really initially wanted,
fails too. ekr's argument is certainly right that a message
of certain origin but uncertain content is close to worthless.
OTOH, the particular piece, IP address and port numbers in SDP
are certainly not to be covered by a message integrity checks.
In fact, for accepting calls based on who is calling, as
a minimalistic application example, one does  not need
message integrity.

In conclusion, I do not think that RFC4474 can be of any help
(other than in controlled environments which beats its purpose)
as long as IP/port in SDP are message-integrity-protected.

-jiri

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 28 Mar 2009 23:33:18 -0500

I think our views are not that appart.

See belows.  

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]] 
> Sent: Saturday, March 28, 2009 13:02
> To: [email-masked]
> Cc: Audet, Francois (SC100:3055)
> Subject: francois' comments and why RFC4474 not used in the field
> 
> /* hope I didn't misinterpret, let me know should that be the case */

First part is currect, but I didn't say "thus we have no problem with
this RFC."

As you say, it only works if the identity provider and the verifier are
"next to each other". A federation of Enterprises for example. Or between
service providers.

However, one of the most predominant model today doesn't work like this.
A domain is often relying on a third party, a "service provider".

So it's really not "end-to-end". That was the point I was trying to make.

RFC 4474 appears to work fine for end-to-end identity: unfortunately,
many deployment models (perhaps the majority) and in fact, not end-to-end,
but mediated. In a typical scenario, each end would have it's own
"service provider", so 2 intermediaries.

> ALGs do in my experience appear in the middle, change SDP and 
> make thus the identity worthless.

Yes, I agree 4474 doesn't work if there are intermidiaries.

> I think the bottom line is the protocol is not really end-to-end.

EXACTLY!

> It makes quite some assumptions about the quality of 
> underlying network (particularly about not changing SDPs) as 
> opposed to trying to deal with lack of it. In fact, SDP 
> payloads are changed at quite a number of devices: proxy 
> servers, B2BUAs, SBCs, you name it. Assuming there is nothing 
> in the way which won't change SDP is just NOT ROBUST.
> 
> Other way to look at it is it is function overloading. You 
> ask for identity and get message integrity -- consequently 
> when the latter fails, the former, which you really initially 
> wanted, fails too. ekr's argument is certainly right that a 
> message of certain origin but uncertain content is close to worthless.
> OTOH, the particular piece, IP address and port numbers in 
> SDP are certainly not to be covered by a message integrity checks.
> In fact, for accepting calls based on who is calling, as a 
> minimalistic application example, one does  not need message 
> integrity.
> 
> (other than in controlled environments which beats its 
> purpose) as long as IP/port in SDP are message-integrity-protected.

Here is what I think:

RFC 4474 can work in the following situations:

1 - Enterprise-to-Enterprise: i.e., the network as a dumb pipe. The enterprises
have their own SBCs modifying SIP/SDP (or they can use ICE).

2 - Subscriber on Service provider A to Subscriber on service provider B: 
i.e., the "domain" for the first subscriber is actually that of the subscriber.
This can work for "residential users" and small enterprises.

3 - Any permutation of the above.

In all those cases, there is effectively end-to-end identity.

RFC 4474 does NOT work if it's not end-to-end. For example, if 
the "Enterprise" has it's own domain, but it relies on it's 
service provider to perform a number of functions. NAT traversal,
topology hiding, etc.

So, what can we do?  I see 2 possibilities:

1 - Make it end-to-end. This means tackling one by one the problem areas.
    Use TURN/ICE instead for relying on SDP payload manipulation. Use
    Call-ID and Contact headers that don't reveal topology, etc.

2 - Create a non end-to-end Identity assertion mechanism that is different
    from RFC 4474 and more secure than P-Asserted-Identity. I have a 
    feeling that it won't be trivial. We may have to define the 
    trust relationship between the ends and the intermediaries. 

What I was trying to say in the meeting is that for "end-to-end
identity", 4474 appears to work. But if the problem we are trying to
solve is NOT end-to-end identity, but strong mediated identity, then,
let's just say so. It's just a DIFFERENT problem to solve.

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 28 Mar 2009 22:31:50 -0700

> A domain is often relying on a third party, a "service provider".

I observed Hadriel's presentation from the very back of the
room.  My interpretation is that we lack consensus that there
are intermediate service providers.

Until consensus on that point is reached everything else is
for naught.

-d

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 29 Mar 2009 15:38:04 +0200

>> purpose) as long as IP/port in SDP are message-integrity-protected.

Thanks for the clarifications. I think we are on the same page then.

> In all those cases, there is effectively end-to-end
> 

Well, I'm afraid that 1 is too complicated to work. Bringing TURN/ICE to
work is already quite an enterprise, and as much success I wish to it,
I would be careful and avoid dependency on it (which is generally
a good protocol design practice anyhow).

2 is then probably the safer direction to me. The point is really that
RFC4474 is not having as broad applicability as we have hoped, and
leaving SIP without Identity is going to be real-time irritating,
compared to convenience of Email's off-line irritation.

Some of the RFC 4474 applicability limitations could be lifted by
reducing its integrity protection scope. I'm not sure how popular
will it be then (some have had different opinions on adoptability
of things relying on CA) but it  seems worth trying.

I would not dare to restrain ourselves to fixing RFC4474 though.
I'm very much in favor of testing other alternatives. IETF has
had a very successful tradition of testing several approaches.
A more ellaborated email on the topic was BTW recently written
by Dave Crocker: 
http://www.ietf.org/mail-archive/web/mmox/current/msg01233.html

Obviously DERIVE (or perhaps non-SIP based reverse verifications)
appears a feasible alternative to me (because  easy to deploy and
offering incentives to do so), but given the interest it is quite
certain there will be more different alternatives.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 29 Mar 2009 15:53:24 +0200

> Until consensus on that point is reached everything else is

I'm worried that "intermediate service providers" is a sort of
scenario which is underplaying the RFC4474 flaw.

The key problem is that RFC4474 is not robust. It ties likely-to-fail
integrity to identity, resulting in identity broken. Integrity is
likely to fail, because regardless how close the assertion party
is to the verification party, some sort of SDP-changer will be
there. Maybe "intermediate service provider" or an ALG. One can
argue that ALG has nothing to do there (quite rightfully so)
but relying on such not to be there is just way too brittle.

So I don't think the problem is we are missing a definition of
intermediate service provider. I think we are missing identity
vehicles that have robustness to overcome all sorts of middleboxes.

-jiri

---

From: Dean Willis <[email-masked]>
Date: Sun, 29 Mar 2009 23:08:43 -0500

> and make thus the identity worthless.

If they change the SDP,  they've changed the identity assertion. They  
need to re-assert. There might reasonably be a need to have a stack of  
assertions with diffs, so one could go back and see the original SDP,  
with its original key fingerprint and original verifiable signature,  
but just changing stuff and pretending the associated identity  
assertion hasn't changed is fundamentally bogus.

The MAIN reason, it seems to me, to want to change the SDP (and  
especially the key fingerprint) undetectably is to enable intercept  
(lawful or otherwise) without detectability. That just won't do.

Perhaps we only need are two different identity assertions; one on the  
original SDP with fingerprint, and one on whatever has resulted post- 
modification by the MITM attackers. Intermediate manipulations by yet  
more MITN attackers might well be worthless.

Let's put it another way: One of the very important things that RFC  
4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its  
protection of the other stuff in the SDP, such as the port numbers and  
IP addresses used for media, is just a side effect. Of course,  
changing the codec (transcoding) is going to break DTLS/SRTP quite  
horribly, so the codec information might as well be protected by  
Identity.

Would we be willing to accept a model where the fingerprint is  
preserved across SBCs but the IP address/port number information is  
not? I'm not saying that would be easy to produce; it would seem to  
require a very complex modification to RFC 4474's handling of SDP, or  
complementary fundamental changes to RFC 4474 and the DTLS draft  
family. But would it get us past this this stone wall?

If not, why not? And you're going to have to convince me that you're  
not just building a phone-tapper protocol here . . .

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Mar 2009 22:30:03 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Sunday, March 29, 2009 9:09 PM
> To: Jiri Kuthan; Jon Peterson
> Cc: SIP List; Francois Audet
> Subject: Re: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> 

It would not get us past this stone wall, because this very idea
was already proposed and already rejected,
http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.2

The reasons for the rejection, as I recall, were along the lines of "we 
don't want to require SRTP to provide identity".  That argument is 
countered with the ICE technique in Section 4.3 of the same draft; 
we could change that from ICE to something else that does not 
overload ICE semantics of course.  Other reasons included "but SBCs 
might [destroy | modify | manipulate]" the messages.  The counter 
argument to that is that the operators of SBCs have an incentive 
to allow identity through (namely, so that people will accept 
incoming SIP calls), very much like the long distance phone 
companies in the 1980's added echo cancellation tone detectors 
(because it was something needed by the end users).  Other arguments
questioned how non-Invite requests would get protection (also
answered in that same draft).

It is not a lack of solutions in this space.  It is a lack of 
participation by interested parties and an unwillingness to admit
that voice networks are using SBCs -- as if SBCs operated by service
providers are as real as the tooth fairy or Santa Claus.

> not just building a phone-tapper protocol here . . .

Strong identity makes it *harder* to build a phone-tapping system.  This
hop-by-hop signing thing that you are describing above, and Jon described at
the microphone, is transitive trust with extra CPU horsepower and something
you could fight better in a lawsuit when you learned that a service provider
lied.  I don't see a service provider getting very interested in the
additional capex, opex, and business risk of doing such signing, especially
compared to the three proposals on the table which require the service
provider do _no_ signing and no stronger attestation than today (same business
risk as today).

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Mar 2009 01:50:56 -0400

What is it in the SDP that you feel is integral to the identity of the sender of the request?  If I send an offer-less Invite and sign it with rfc4474 does it not confirm my identity, because there was no SDP?  Clearly it would indicate that the signed sender did not send SDP, so it prevents a MITM from inserting one, but does it actually let a MITM change the Identity of the sender of the request if it inserts one?

You say below that one of the important properties is that it protects the dtls-srtp fingerprint, presumably because that allows it to tie the identity of the sender of the SIP request to the identity of the media.  Every draft proposal thus far to do rfc4474 differently has included the ability to sign that fingerprint, specifically for that purpose.  The question is whether the IP-Addr/port of the media is itself integral to the identity of the sender, or not.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Monday, March 30, 2009 12:09 AM
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Mar 2009 02:00:11 -0400

> (lawful or otherwise) without detectability. That just won't do.

No, that's not at all the main reason.  RFC4474 is already not end-to-end.  It's signed by a middlebox in the originating domain, and verified by a middlebox in the terminating domain.  There is ample opportunity to change the SDP at either of those domains to perform lawful intercept. 

The main reason to change SDP is to steer the media, for numerous reasons.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Mar 2009 10:32:50 -0500

> Sent: Sunday, March 29, 2009 06:38
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: Re: francois' comments and why RFC4474 not used in the field
> 
> Well, I'm afraid that 1 is too complicated to work. Bringing 
> TURN/ICE to work is already quite an enterprise, and as much 
> success I wish to it, I would be careful and avoid dependency 
> on it (which is generally a good protocol design practice anyhow).
> 
> RFC4474 is not having as broad applicability as we have 
> hoped, and leaving SIP without Identity is going to be 
> real-time irritating, compared to convenience of Email's 
> off-line irritation.

1 is definitively difficult to implement. However, I'm quite afraid that
2 is actually worst...
 
> Some of the RFC 4474 applicability limitations could be 
> lifted by reducing its integrity protection scope. I'm not 
> sure how popular will it be then (some have had different 
> opinions on adoptability of things relying on CA) but it  
> seems worth trying.

My fear is that by doing so, we will not do something that
will be substantially better than P-Asserted-Identity.

But like you said, it may be worth trying.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Mar 2009 10:46:44 -0500

> No, that's not at all the main reason.  RFC4474 is already 
> not end-to-end.  It's signed by a middlebox in the 
> originating domain, and verified by a middlebox in the 
> terminating domain.  There is ample opportunity to change the 
> SDP at either of those domains to perform lawful intercept. 

End-to-end means from end domain to end domain. So 4474 is
end-to-end.

Again, if enterprise A wants to talk to enterprise B, without
some service provider spying or redirecting media for their
own potentially nefarious purposes, then 4474 is a perfect
way to ensure that you are talking to who you think you are
talking to.

The fact that these enterprise may or may not be using their
own SBCs to deal with NAT traversal and topology hiding is
not relevant.

> The main reason to change SDP is to steer the media, for 

It should be up to the Enterprise to decide if it is willing
to deal with a man-in-the-middle. If it does not, then it
can use 4474.

If it does, then it's not end-to-end security. This is probably
acceptable to many enterprises, provided that they can trust
their service provider.

So again, perhaps what we need is a non end-to-end secure identity.
Perhaps something that requires a broker/service provider.

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 13:18:23 -0500

On Mar 30, 2009, at 1:00 AM, Hadriel Kaplan wrote:

> No, that's not at all the main reason.  RFC4474 is already not end- 
> to-end.  It's signed by a middlebox in the originating domain, and  
> verified by a middlebox in the terminating domain.  There is ample  
> opportunity to change the SDP at either of those domains to perform  
> lawful intercept.

RFC 4474 can be used end to end. It all depends on which cert is used  
to sign the identity, where that signing occurs, and where it gets  
checked. For stupid legacy phones, it can be signed and checked at  
middleboxes operating under some level of transitive trust. For  
smarter devices, it happens in the endpoint.

Signing and checking at the endpoint, coupled with the DTLS  
fingerprint check. enables end-to-end verification of media integrity  
and privacy. Once you start ripping these signatures out in the middle  
of the network and replacing them, we have lost this absolutely  
critical property. If transit providers even think it MIGHT be  
reasonable to rip out the signatures, then we have lost the key  
functionality. Removing signatures MUST BE FORBIDDEN. Adding new ones  
might be ok.

I might be willing to compromise on the mechanism (I've already  
proposed several potential approaches to doing so), but I'm unwilling  
to compromise on the fundamental requirement for this end-to-end  
applicability.

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 30 Mar 2009 18:59:51 +0200

Dean Willis wrote:
> with its original key fingerprint and original verifiable signature, but 
> just changing stuff and pretending the associated identity assertion 
> hasn't changed is fundamentally bogus.

Hi Dean,

My argument has been that including SDP's IP address and port numbers
in message integrity check is not an identity assertion, but a protocol
shortcoming (certainly well-meant, but making things hard to deploy).
I really think that identity and integrity of SDP are two different things.

Or do you think that these elements somehow belong to identity assertion?

> (lawful or otherwise) without detectability. That just won't do.

In the field, the desire to change SDP I have witnessed is due to NATs.
We don't have TURN & ICE in the field and I'm quite worried that very
few care today. In fact, SDP rewriting has been in use for so long, that
I consider TURN's success chances very marginal. Other I have witnessed
is transcoding.

To make it clear: I'm not opposed to all sorts of integrity protection.
I'm just worried that if we try to solve identity in a single package
with integrity of ever changing SDP, we will unlikely succeed.

> original SDP with fingerprint, and one on whatever has resulted 
> post-modification by the MITM attackers. Intermediate manipulations by 
> yet more MITN attackers might well be worthless.
> 
> Let's put it another way: One of the very important things that RFC 4474 
> does is protect the DTLS/SRTP key fingerprint. Arguably, its protection 
> of the other stuff in the SDP, such as the port numbers and IP addresses 
> used for media, is just a side effect. Of course, changing the codec 
> (transcoding) is going to break DTLS/SRTP quite horribly, so the codec 
> information might as well be protected by Identity.
> 
> Would we be willing to accept a model where the fingerprint is preserved 
> across SBCs but the IP address/port number information is not? I'm not 
> saying that would be easy to produce; it would seem to require a very 
> complex modification to RFC 4474's handling of SDP, or complementary 
> fundamental changes to RFC 4474 and the DTLS draft family. But would it 
> get us past this this stone wall?

Logically yes, integrity of some pieces that are known not to be useful
to be rewritten would be ok.

The practicability is of course another question, on which many may have
different opinions. Should mine be asked, I would be in favor of using
confidentiality protocols that do not have dependencies in general,
and dependencies on protocols with unenforceable identity in particular:
zRTP.

> 
> If not, why not? And you're going to have to convince me that you're not 
> just building a phone-tapper protocol here . . .

I haven't been working on a phone-tapper, even though a media-relay or
transcoder could be labeled so for marketing purposes :-) zRTP actually
makes it gracefuly through media relay while confidentiality remains
preserved.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 30 Mar 2009 19:33:53 +0200

> Perhaps something that requires a broker/service provider.

I think that there is a lot of confusion around putting together
identity and integrity. It is not that I must have one for the other.
I can have identity without integrity of SDP and still be in position
to accept/decline a call based on who is calling me. If I'm worried
about media confidentiality, I can add zRTP.

As long as identity remains clearly separated from other stuff, we can
do quite some things. Most of the confusion seems to come from packaging
it with other functionalities. 4474 without integrity of the IP:port
in SDP would work, DERIVE (as e2e representaive) would work, certainly
many other things as well.

Let's face it,  integrity of whole SDP payload is illusive and any
functionality  relying upon it undeployable.

-jiri

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 13:27:32 -0500

> http://tools.ietf.org/html/draft-wing-sip-identity- 

I'm hoping that we've developed a broader understanding of the problem  
since the last time this was circulated,

> answered in that same draft).

Given that a clever on-path attacker could disrupt "identity" without  
changing the port/address presentation, I fail to see how protecting  
them proves anything.

> provider do _no_ signing and no stronger attestation than today  

You misunderstand the hop-by-hop signing approach I described. By  
adding signatures, rather than replacing them, the original media and  
DTLS key identifier properties are preserved. The stack of signatures  
and new SDPs provide an audit chain for figuring out what happened and  
for a basis of transitive trust where end-to-end trust is not  
existent, but do not impede the ability for end-to-end when the  
endpoints have that capability.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 13:29:35 -0500

> End-to-end means from end domain to end domain. So 4474 is

RFC 4474 can also be used user-agent to user-agent, phone to phone.
> Perhaps something that requires a broker/service provider.

How is this not P-Asserted-Identity? What real property does such an  
identity assertion have that PAID lacks?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 13:40:38 -0500

On Mar 30, 2009, at 11:59 AM, Jiri Kuthan wrote:

>> If they change the SDP,  they've changed the identity assertion.  
>> They need to re-assert. There might reasonably be a need to have a  
>> stack of assertions with diffs, so one could go back and see the  
>> original SDP, with its original key fingerprint and original  
>> verifiable signature, but just changing stuff and pretending the  
>> associated identity assertion hasn't changed is fundamentally bogus.
>

The argument has been made that these elements might provide  
additional clues to identity. For example, if I see something that is  
coming from what I know is your IP address, and see that it was signed  
by your proxy, whose cert I trust, I might be inclined to believe this  
assertion more than I would believe it if the source address  were  
coming from a node that had a reverse record in alqueda,org.

In the absence of a DTLS or zRTP protection of the media path, I'd be  
likely to give fairly heavy weighting to this IP address comparison,  
even though we know it's not 100% it is MUCH better than nothing.

Of course, I'd rather have an identity mechanism that actually works  
with DTLS than one than doesn't but "works just a little" for  
unprotected media.

So personally, I'd be willing to give up signing of IP address/port  
numbers when a media key fingerprint is present. But if there's no  
media key fingerprint in the signaling (or in the protocol, as zRTP),  
then I  want to see the address and port numbers included.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Mar 2009 13:44:13 -0500

> I think that there is a lot of confusion around putting 
> together identity and integrity. It is not that I must have 
> one for the other.
> I can have identity without integrity of SDP and still be in 
> position to accept/decline a call based on who is calling me. 
> If I'm worried about media confidentiality, I can add zRTP.

If relying on dead-beat end-users for enforcing security, then
sure, you can use ZRTP. Those end-users are the same guys who
keep clicking accept anytime theirs browsers tell them the certificate
is invalid.

When the private conversations unlawfully recorded gets leaked,
or when somebody impersonates an important person, the individual who 
gets fired is the IT guy who recommended using ZRTP.

Anyways, I digress.

I think the argument for the proponents of RFC 4474 is that
you can not separate identity from media security. If 4474
allows for intercepting the media, than the identity of the
interlocutor is wrong.

What you are arguing for is a mechanism that asserts the
identity of the sender of the signalling only (SIP), and not the
media.

Perhaps this what we need. I believe that the current DTLS proposal
actually relies on 4474 for the fingerprinting. I guess we would
need something else.

It's almost as if we would need something like 4474 between originating
domain and Service Provider, and then 4474 again between Service provider
and destination domain.

---

From: Anthony D Pike <[email-masked]>
Date: Mon, 30 Mar 2009 15:09:16 -0400

inline

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. •

[email-masked] wrote: -----

To: Hadriel Kaplan <[email-masked]>
From: Dean Willis <[email-masked]>
Sent by: [email-masked]
Date: 03/30/2009 02:18PM
cc: SIP List <[email-masked]>, Francois Audet <[email-masked]>, Jon Peterson <[email-masked]>
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

I am 100% in agreement with this normative text above. I also believe that Both the Signalling and Media need to be asserted ( this is not the case in 4474), the mechanism is TBD, but I believe this should be a requirement. Think of your children I have a 5 year old girl growing up in a next generation environment, if Identity is not completely solved in the next few years, then shame on us for not helping to protect the next generation! My 0.02c worth.

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 30 Mar 2009 15:25:11 -0400

Francois has said it, and so has Jiri.  

" I think that there is a lot of confusion around putting together identity and integrity." 

" I really think that identity and integrity of SDP are two different things."

Put me down as +1

The need is IDENTITY first and foremost.

Adam

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 14:48:49 -0500

> The need is IDENTITY first and foremost.

Is that signaling identity, or media identity, or both?

Is either useful alone?

I'm thinking that a lot of people are demanding signaling identity  
without media identity, and haven't really thought about the  
consequences of that decision because they grew up with a telephone  
system that  essentially lacks the distinction.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Mar 2009 12:51:26 -0700

> > Strong identity makes it *harder* to build a phone-tapping 
> system.   
> > This
> > you could fight better in a lawsuit when you learned that a 
> service  
> > provider

You are right, I had misunderstood.  Your proposal is different
from the proposal that Jon described at the microphone.  However,
it would disclose the entire path which SP's appear reluctant to
do -- else they would not remove Via headers (I understand most
SPs, using SBCs, remove Via headers).

-d

---

From: Michael Procter <[email-masked]>
Date: Mon, 30 Mar 2009 21:01:24 +0100

> Is that signaling identity, or media identity, or both?

I think it is at least a bit useful.  If Alice calls Bob, Bob can ensure
that the signalling for the call originated from Alice.  He can't assert
that the media is to/from Alice yet, but it is a start.  More usefully,
if Eve calls Bob, Bob can see that it isn't Alice.  A positive result
from signalling-only identity isn't as useful as you might hope.  But a
negative result is still interesting.

Is that enough of a solution to still be useful?  There are still
several holes in it, but it is better than we have at present.

> system that  essentially lacks the distinction.

Indeed.

Michael

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Mar 2009 21:55:50 +0100

Jiri, 

> Behalf Of Jiri Kuthan
> Sent: 28 March 2009 20:02
> To: [email-masked]
> Cc: Francois Audet
> Subject: [Sip] francois' comments and why RFC4474 not used in 
> the field
> 
[JRE] Exactly. Moreover, when media are secured by some means (SRTP in
the case of RTP) and if SDP contains a fingerprint of the certificate
used to secure the media, there is absolutely no need to sign the IP
address/port. They can quite happily change without impacting the
security of media. Of course, if media isn't secured, it is a slightly
different matter, but I doubt that signing the IP address and port
really buys us much. So you might as well not include IP address and
port in the signature, and if they are changed by intermediate SBCs, no
problem.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Mar 2009 21:56:30 +0100

Jiri, 

> Sent: 29 March 2009 14:38
> To: Francois Audet
> Cc: [email-masked]
> TURN/ICE to
[JRE] I am open to such alternative suggestions. I think the problem
with DERIVE was that it still was impacted by the idiosyncrasies of SIP,
i.e., B2BUAs and backwards compatibility with UACs. Perhaps we need a
non-SIP-based solution.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Mar 2009 21:57:08 +0100

Dean, 

> Sent: 30 March 2009 19:18
> To: Hadriel Kaplan
> Cc: SIP List; Francois Audet; Jon Peterson
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf  
> >> Of Dean
> >> Willis
[JRE] Yes, that is a positive feature of RFC 4474, the fact that it can
be used end-to-end, end-domain-to-end-domain, or even end-domain-to-end
or end-to-end-domain. In other words, the authentication and
verification functions can be in the endpoint or an end domain
intermediary.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Mar 2009 21:57:40 +0100

Jiri, 

> Sent: 30 March 2009 18:00
> To: Dean Willis
[JRE] I am concerned about more than just confidentiality of media. I
believe integrity protection (of certain data) and authentication are
also important. There is only limited value on agreeing an encryption
key with an unknown entity.

John

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Mar 2009 17:25:44 -0400

inline:

> system that  essentially lacks the distinction.

 From an end user perspective, I would assert that the most important 
thing is probably the media. If the callerID says, "this is bob", what 
is important to the user, is that when I pick up the phone and start 
talking, it will be Bob who hears me, and Bob that I hear.

Consider this litmus test:

If the signaling actually came from Mary (perhaps as a third party), but 
the media goes/comes to/from Bob, who should appear on the caller ID? I 
say - Bob.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 01:48:10 +0200

Dean Willis wrote:
>>> need to re-assert. There might reasonably be a need to have a stack 
>>> of assertions with diffs, so one could go back and see the original 
>>> SDP, with its original key fingerprint and original verifiable 
>>> signature, but just changing stuff and pretending the associated 
>>> identity assertion hasn't changed is fundamentally bogus.
>>
> The argument has been made that these elements might provide additional 
> clues to identity. For example, if I see something that is coming from 
> what I know is your IP address, and see that it was signed by your 
> proxy, whose cert I trust, I might be inclined to believe this assertion 
> more than I would believe it if the source address  were coming from a 
> node that had a reverse record in alqueda,org.
> 
> numbers when a media key fingerprint is present. But if there's no media 
> key fingerprint in the signaling (or in the protocol, as zRTP), then I  
> want to see the address and port numbers included.

I perfectly agree with the suggestion "relax about changed IP/port in SDP
if media secured".

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 01:55:39 +0200

> allows for intercepting the media, than the identity of the

That's indeed the argument. In other words, how can be message
of certain origin valuable if of uncertain content. Are you
sure to whom you are sending your RTP packets to? (Ironic
answer: with 99% probability to your enterprise's ALG ;-))

The argument is valid, but unfortunately I believe SDP rewriting
is here to stay, in places we have not anticipated. These SDP
rewriters render the extra security value much less useful then
we have hoped for.

> identity of the sender of the signalling only (SIP), and not the

Yes.

> actually relies on 4474 for the fingerprinting. I guess we would

That's indeed a problem. Could be addressed by DTLS doing it somewhere
else or 4474 changed to cover less.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 01:58:32 +0200

> port in the signature, and if they are changed by intermediate SBCs, no

Yes, that's the point. -jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 02:08:21 +0200

> i.e., B2BUAs and backwards compatibility with UACs. Perhaps we need a

Hi John,

that may be very well true, in the end SIP is quite complex nowadays and
overloading it with more stuff may make things possibly worse.

I'm just wondering what folks thing about reverse verification per DNS.
While not providing such a good granularity as SIP does, there is still
some better-than-nothing value in it. What I find appealing about it is
there is some prior experience (our domain for example is using SPF).
Also, identity established via DNS is not worthless -- changing DNS
names to change identity is associated with some prohibitive cost.

Any other ideas?

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 03:03:29 +0200

> the media goes/comes to/from Bob, who should appear on the caller ID? I 

There is a timing aspect in favor of placing identity in signaling --
I would like to know whose call is ringing before I answer (if I do).

-jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Mar 2009 22:12:48 -0400

inline:

Jiri Kuthan wrote:

>> If the signaling actually came from Mary (perhaps as a third party), 
>> but the media goes/comes to/from Bob, who should appear on the caller 
>> ID? I say - Bob.
> 

You can still have that. Just don't ring the phone until early media has 
been exchanged and verified. Indeed if you were doing an ICE-style thing 
per Dan's draft, you'd get that for free.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Mar 2009 19:53:07 -0700

For everybody's reference, can you point to Dan's draft?

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 31 Mar 2009 05:20:42 +0200

Jonathan Rosenberg wrote:
>>> thing is probably the media. If the callerID says, "this is bob", 
>>> what is important to the user, is that when I pick up the phone and 
>>> start talking, it will be Bob who hears me, and Bob that I hear.
>>>

Hi Jonathan,

Ok, that's feasible in a sense. And there is certain beauty in getting the
security attributes associated with RTP packets, to which they belong.
(I like this about zRTP). A particular example where this would perform
well is today's PSTN directory service, which connects me to the final
recipient, while still the directory's service phone number appears on
my phone. (well, with connected identity one could actually handle
it using signaling too...)

What I'm anxious of is the idea of to do "x" you also have to do
"y" which you need for "z" anyhow -- doesn't that impair the feasibility?
Could not we find something that is just as easy as to do "x" do "x"?

-jiri

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Mar 2009 23:07:44 -0500

> I would like to know whose call is ringing before I answer (if I do).

So, we need identity in signaling, we need identity in media, and we  
need the two identity expressions to match.

That's what we get with RFC 4474 and DTLS/SRTP.

Why were we trying to change it to protect something else?

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Mar 2009 21:15:49 -0700

> From: Francois Audet [mailto:[email-masked]] 
> Sent: Monday, March 30, 2009 7:53 PM
> To: Jonathan Rosenberg; Jiri Kuthan; Dan WING
> Cc: SIP IETF; Uzelac, Adam; Dean Willis

It is
http://tools.ietf.org/html/draft-wing-sip-identity-media-02

other proposals in the same sphere,
http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00
http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01

-d

---

From: Anthony D Pike <[email-masked]>
Date: Tue, 31 Mar 2009 00:39:24 -0400

This general approach looks interesting I need time to digest the Kaplan doc.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 31 Mar 2009 09:49:06 +0200

This litmus test seems to mixup presentation with Identity.

All identity presentation services I know of are based on signaled identity.
Of course a more advanced identity presentation service can be devised that
also incorporates media identity. But this can become quite complicated,
imagine 1 session containing multiple media streams coming from different
entities, what do I present?  Or will this not be allowed anymore?

The first thing I would be interested in is who is trying to setup a session
with me, and if I trust that someone. If I have more stringent requirements
also on the media integrity then I need something additional.

/Hans Erik van Elburg

On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg <[email-masked]>wrote:

>>> thing is probably the media. If the callerID says, "this is bob", what is
>>> important to the user, is that when I pick up the phone and start talking,
>>> it will be Bob who hears me, and Bob that I hear.
>>>
>>> the media goes/comes to/from Bob, who should appear on the caller ID? I say
>>> - Bob.
>>>
>>
> been exchanged and verified. Indeed if you were doing an ICE-style thing per
> Dan's draft, you'd get that for free.
>
> -Jonathan R.
>
>
>
> --

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 31 Mar 2009 10:06:16 +0100

Hans Erik,
 
I think the issue is to verify that the media is to/from the same user
as the signalling. I agree it would be complex if we were dealing with
different users.
 
John

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hans Erik van Elburg
	Sent: 31 March 2009 08:49
	To: Jonathan Rosenberg
	Cc: SIP List; Uzelac, Adam; Dean Willis
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field

	All identity presentation services I know of are based on
signaled identity. Of course a more advanced identity presentation
service can be devised that also incorporates media identity. But this
can become quite complicated, imagine 1 session containing multiple
media streams coming from different entities, what do I present?  Or
will this not be allowed anymore?
	
	The first thing I would be interested in is who is trying to
setup a session with me, and if I trust that someone. If I have more
stringent requirements also on the media integrity then I need something
additional. 
	
	/Hans Erik van Elburg

	On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg
<[email-masked]> wrote:

		inline: 

		Jiri Kuthan wrote:

				 From an end user perspective, I would
assert that the most important thing is probably the media. If the
callerID says, "this is bob", what is important to the user, is that
when I pick up the phone and start talking, it will be Bob who hears me,
and Bob that I hear.

				If the signaling actually came from Mary
(perhaps as a third party), but the media goes/comes to/from Bob, who
should appear on the caller ID? I say - Bob.

			There is a timing aspect in favor of placing
identity in signaling --
			I would like to know whose call is ringing
before I answer (if I do).

		You can still have that. Just don't ring the phone until
early media has been exchanged and verified. Indeed if you were doing an
ICE-style thing per Dan's draft, you'd get that for free. 

		-Jonathan R.

		-- 
		Jonathan D. Rosenberg, Ph.D.                   111 Wood
Avenue South
		Cisco Fellow                                   Iselin,
NJ 08830
		Cisco, Voice Technology Group
		[email-masked]
		http://www.jdrosen.net                         PHONE:
(408) 902-3084
		http://www.cisco.com
		_______________________________________________
		
		Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
		This list is for NEW development of the core SIP
Protocol
		Use [email-masked] for questions on
current sip
		Use [email-masked] for new developments on the
application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 08:55:41 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg
> Sent: Monday, March 30, 2009 5:26 PM
> 

So what does 10.0.200.6:45001 mean to you?  Bob or Mary?
And since the SDP only indicates where to send your media to, not where it comes from, what does it mean to you to get a session request where the caller asks you to send media to 10.0.200.6:45001, but it can come from anywhere?

The thing is an IP:port is NOT an Identity.  It's not a secure assertion of anything.  Signing it doesn't *prove* anything.  It neither prevents media spoofing injection nor interception.  It's only the signing of the dtls fingerprint by binding it to the signaling identity that provides strong "media" identity.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 09:02:25 -0400

> Sent: Tuesday, March 31, 2009 12:08 AM
> 

Well, for one, you can get identity in signaling and identity in media using DTLS/SRTP *without* using RFC-4474 as currently defined.  We're trying to get it to NOT protect things that don't need to be protected for identity to be attained.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Mar 2009 09:15:03 -0400

Hans beat me to it with his reply - if there is more than one media 
stream (e.g. audio/video), and they come from different sources, then 
what to you display?

Dean says these and the signaling identity should match. Modulo the 
problems we are trying to solve with intermediaries, that will be the 
situation in the majority of cases. But the general case is:
- one, none, or maybe more than one, identity for the signaling
- one, none, (or maybe more than one?), identity for each media stream

With that jumble of stuff you need to decide what to present to the 
user. If all are the same then no problem. If you have a UI that permits 
display of them all, then no problem. (Except user confusion.) But if 
there is disagreement among the sources and you can only present one, 
then do you: pick one, or pick none?

At the moment that seems to be a common case. We may be able to get some 
sort of identity for one of these, but can't verify that it applies to 
all (where "all" usually means signaling + audio) and we can at most 
display one.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 09:27:50 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, March 30, 2009 2:18 PM
> To: Hadriel Kaplan
> 

Ummm.... nafaik.  If your AoR is of the form [email-masked], then even if your UA endpoint has a cert and signs the request, any middlebox which has a cert for "domain.com", or "*.domain.com", can willy-nilly replace your signature and do lawful interception.  

> functionality. Removing signatures MUST BE FORBIDDEN. Adding new ones

I don't think anyone wants to remove signatures.  (of course mandating they don't get removed is like mandating to set the evil bit if you're bad :)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Mar 2009 11:41:11 -0500

> So what does 10.0.200.6:45001 mean to you?  Bob or Mary?

It means "Not Dean's home phone, which I know uses a 192  
address . . ." If I knew Bob and Mary well, I might have a clue there  
too.

Not perfect, but better than nothing.

Enough better than nothing to bother with? I don't know. I'd like to  
hear Jon's take on that.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Mar 2009 11:42:53 -0500

On Mar 31, 2009, at 8:02 AM, Hadriel Kaplan wrote:

>
> Well, for one, you can get identity in signaling and identity in  
> media using DTLS/SRTP *without* using RFC-4474 as currently  
> defined.  We're trying to get it to NOT protect things that don't  
> need to be protected for identity to be attained.

umm, I believe RFC 4474 is what correlates the identity-in-media with  
the identity-in-signaling. The media identity expression is not  
particularly useful without its correlation to signaling and thence to  
a "human readable" identity expression.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 12:51:35 -0400

> Sent: Tuesday, March 31, 2009 12:43 PM
> To: Hadriel Kaplan
> 

> Why were we trying to change it to protect something else?

I meant we don't have to use 4474 in particular to accomplish the same goal - for example, any one of the other proposals thus far provide you that same binding.  Just because 4474 gets you that binding, doesn't mean another mechanism can't, nor that changing what 4474 protects removes that binding.  We're trying to protect only what actually needs to be protected to get you that binding.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Mar 2009 11:52:45 -0500

On Mar 31, 2009, at 8:27 AM, Hadriel Kaplan wrote:
> Ummm.... nafaik.  If your AoR is of the form [email-masked], then  
> even if your UA endpoint has a cert and signs the request, any  
> middlebox which has a cert for "domain.com", or "*.domain.com", can  
> willy-nilly replace your signature and do lawful interception.

Not quite.

Here's how I understand it to work:

If the signing cert is [email-masked] instead of domain.com, then the  
middlebox would need to work with a CA to mint a cert having that full  
name. A more typical scenario would have the middlebox use a cert with  
name "domain.com". The verifying node can tell the difference.

But even better, with RFC 4474 I might have a connection to AT&T. I  
might use this connection to send a call with an Identity header for "[email-masked] 
". If you have any relationship with me at all, you know AT&T isn't  
likely to have the private key for the softarmor.com CA certificate or  
for my private certificate issued by that CA. So AT&T isn't a MITM  
attacker in this scenario.

Of course, if AT&T's accursed SBC strips off my RFC 4474 Identity  
header and inserts their own useless declamation asserting some bogus  
phone number then my assertion is useless, we could have a MITM, and  
I'm changing carriers.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 13:14:56 -0400

> Sent: Tuesday, March 31, 2009 12:53 PM
> 

Not as I read 4474.  The verifier will be getting a From AoR of [email-masked], and a cert for domain.com.  That passes the verification check.  The verifier had no idea that the original cert was for "[email-masked]", because it won't be downloading that cert, because the Identity-Info header would have been changed to point to the domain-wide cert, and the signature would have been recalculated using the domain-wide cert. (assuming a middlebox in the domain wanted to do this)

Again, this isn't really a problem - presumably you trust your own domain.  I was just pointing out that the protected portion of this is domain-to-domain, not end-to-end.  Most people are fine with that, as am I.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 31 Mar 2009 16:31:47 -0600

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

Cullen <in my individual contributor role>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Apr 2009 03:00:54 +0200

Cullen wrote:

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

Isn't that the function of the text that was placed in section 8 of

http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03

If it is not, then what do you think is missing.

regards

Keith

> Behalf Of Cullen Jennings
> Sent: Tuesday, March 31, 2009 11:32 PM
> To: Jiri Kuthan
> Cc: [email-masked]; Francois Audet
> > 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.
> 
> 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.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 31 Mar 2009 19:24:08 -0600

In all of section 8, the only reason I find of why things are changed is

"For media steering purposes, B2BUAs in intermediate domains need to  
modify the IP address c-lines and the port in m-lines."
Even this one line leaves me confused about what intermediate domains  
are in the deployment cases where this happens and if we are talking  
about email style address or e.164 style addresses. What an example is  
of a deployment where things like this happen and why the middle (not  
the end domains) do the media steering. When I ask this of example  
people give me, if often turns out what is really wanted is not media  
steering but the middle to be able to hide the fact that they actually  
delivered the call to a third provider for PSTN termination.

Pretend 4474 does not even exist for a minute. I don't think it is  
unrealizable of me to ask what the problem is we are trying to solve.  
Saying 4474 is does not solve the problem may or may not be true but  
we are unlikely to have a good conversation about about what we should  
do until we understand what we are trying to accomplish.

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Apr 2009 01:52:46 -0500

On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote:

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

It might be useful to counter this with "If RFC 4474 isn't broken, why  
isn't it being deployed?" 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. Technically correct or not, ordering this to  
flow out is likely to give you wet feet.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Apr 2009 01:58:12 -0500

On Mar 31, 2009, at 8:24 PM, Cullen Jennings wrote:

> Even this one line leaves me confused about what intermediate  
> domains are in the deployment cases where this happens and if we are  
> talking about email style address or e.164 style addresses. What an  
> example is of a deployment where things like this happen and why the  
> middle (not the end domains) do the media steering. When I ask this  
> of example people give me, if often turns out what is really wanted  
> is not media steering but the middle to be able to hide the fact  
> that they actually delivered the call to a third provider for PSTN  
> termination.
>

I'll agree that topology hiding is a use case for port/address  
obfuscation that results in RFC 4474 not working, thereby preventing  
DTLS/SRTP key fingerprinting when topology-hiding occurs.

Design alternatives include tunnels and STUN relays combined with  
header obfuscation  and UA support for selective obfuscation for the  
offer. While these sorts of triggerworks might work, they're a lot  
more complex than just editing the SDP.

--
Dean