Subject: Re: [Sipping] new draft on session policies in SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 14:51:20 -0400

Yes, yes, more responses to ancient mail - my apologies...

[email-masked] wrote:
> True that this solution does seem to get out of the sticky solution of
> SDP 
> mangling by essentially "replicating" the elements in the body
> to be changed  into new headers.
> 
> If this is adopted as a way forward, then essentially all UA's need to
> be 
> aware of the fact that special processing needs to be done on behalf of 
> midcom proxies, because these special proxies can't do it themselves. 
> 
> My only issue with this is that this now mandates NAT (for example) 
> awareness onto the UAs - which is taking a step away from trying to make
> UAs unaware of such translations in the network.

Having been working on these nasty NAT issues for a long time, I have 
come to the conclusion that the only really viable solutions all involve 
the endpoints becoming aware of the existence of NAT, so that they can 
properly handle it. I believe this is actually an instantiation of the 
end-to-end principle. Given that nats exist, the best place to deal with 
them is at the ends.

An example is midcom itself. Ultimately, midcom found that when proxies 
try to control the firewalls, you end up in all kinds of hard topology 
problems. How does the proxy know which firewalls are traversed by 
media? There really is no solution to this. Ultimately, the right answer 
(IMHO) is that the controls on the firewall/NAT are executed by the 
endpoints by passing messages along the media path, since these control 
messages will traverse the firewalls/NATs that need to be controlled, by 
nature of the underlying IP routing. There is a bof on this subject at 
the next IETF (tist bof).

Another example is STUN. Look how easy the whole problem becomes when 
the UA itself can actually put the right IP address inside the SDP in 
the first place.

> 
> Again, while this soln. does address e-e encryption issues,

The far, far, far more important issue is the authentication and message 
integrity issues.

> it also does
> 
> so by replicating (and therefore exposing) part of the SDP information
> (at least IP:ports ) that had  been encrypted in the first place in the 
> body.  So can we not live with the part that needs NATTing not be e-e 
> encrypted
> in the first place ? 

If not, then you can't make a call.

The problem is that right now, there is no middle ground. If there is 
some aspect of the session description you wish to hide (such as the 
codec list), but you don't care about exposing your IP/port, there is no 
way to do that and still traverse a firewall or NAT.

My proposal exposes ONLY what is needed for traversal, and nothing more.

> 
> The benfits mentioned about this soln. allowing "routing" of media
> streams 
> is very interesting though. However, I am not sure practically
> if its more desirable to keep the UA unaware of such translations and
> let 
> such a n/w deploy an "FCP" who does the dirty work instead
> as today and live with the issue of not being able to totally perform
> end 
> - end encryption for the  _full_ message body.

There are other problems beyond just encryption. I mention 
authentication above as far more serious. The draft talks about others, 
including the problems of consent, failure handling and robustness, 
future proofing (i.e., introduction of SDPng), and Require handling.

> Why not simply change the term "Firewall Control Proxy" to "Firewall 
> Control Agent" :-) ? (that takes care of not offending the dictats of
> the 
> bis)

Its not about names. Its about putting the proper functions in the 
proper places, for the right reasons.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: David Oliver <[email-masked]>
Date: Mon, 24 Jun 2002 16:24:24 -0500

Comments <DCO> inline...

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked] <mailto:[email-masked]>
Tel:   210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, June 24, 2002 3:21 PM
To: David Oliver
Cc: 'Henry Sinnreich'; [email-masked]; [email-masked]
Subject: Re: [Sipping] new draft on session policies in SIP

David Oliver wrote:
>
> A much better solution would be for the ISP to provide a NAT-managing
> SIP
> proxy as part of their service, allowing simple NAT-aware SIP clients to
> traverse their NAT. This seems a reasonable duty of the ISP, in the same
> way
> that an apartment owner would provide all residents a key, when the
> owner
> places a lock on the main door.

I would never in a million years hand over control of my home nat to a 
proxy server run by my ISP or anyone else for that matter, even if I 
personally wrote the code for said proxy. In fact, many ISPs consider 
NATs anathema (they equate them to stealing IP addresses), and so I find 
it unlikely they would do this.

<DCO> I now see there are two ways to parse "their NAT" - I meant for the
ISP to provide the proxy to allow the client to traverse the ISP's NAT.
</DCO>

As for a proxy managing a NAT that the ISP owns, well, thats all fine. 
However, the really big problem is that your ISP is not likely to be 
your SIP provider. The wireless folks may attempt to prevent that, but 
in wireline access it is definitely the case today. None of the retail 
voip providers that I am aware of are ALSO ISPs. I somehow doubt that 
Earthlink would allow net2phone or deltathree to control its NATs.

<DCO> The NAT-managing proxy would not need to be your SIP provider; it
certainly would not be a PSTN gateway like net2phone or deltathree. In an
ideal world, it would be a minimal courtesy service to allow ISP customers
to get past their ISP's NAT to the SIP provider. In the real world, it does
seem unlikely that a DSL ISP would want to provide *any* way to get a voice
connection past their NAT; to DSL ISPs, a NAT ensures income from the POTS
connection! </DCO>

-Jonathan R.