[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01



Well, you asked...

There are two ways that I think are a lot simpler, one more radical than the
other.

First, the "less" radical approach.

For SIP, just spec TCP for transport and have the UAs punch holes through
the Firewall/NAT and keepalive them.  This I think is sort of what Dean was
eluding to in an earlier email.

For media, ICE is a solution.  But, it seems overly complex to me.  Consider
this article:

http://www.heise-security.co.uk/articles/82481

When you see the address of the incoming media in the SDP, just punch a hole
in the FW/NAT.

Second, the "more" radical approach.

If we really want to solve the NAT problem simply, we need to revisit the
basic assumption that signaling and media are on different transport ports.
We could use the basic idea in IAX2 of separate address space behind the
transport port number.  We've already breached the multiplexing of multiple
protocols onto a single transport address.  Why not do it right?  Allow
STUN, SIP, and RTP to all use the same transport address and use another
address behind the port number to de/mux them.

Here's the basic architecture of IAX2 for those that haven't seen it
(http://www.ietf.org/internet-drafts/draft-guy-iax-02.txt):

       +-----------------+                     +------------------+
       | Stream          |                     |           Stream |
       | Number          |                     |           Number |
       |  +-+            |                     |            +-+   |
       |  | |---+        |                     |        +---| |   |
       |  +-+    \       |                     |       /    +-+   |
       |  +-+     \ Port |     +---------+     | Port /     +-+   |
       |  | |---+  \+-+  |     |   IP    |     |  +-+/  +---| |   |
       |  +-+    \_ | |<------>| Network |<------>| | _/    +-+   |
       |  ...     _ +-+  |     +---------+     |  +-+ _     ...   |
       |  +-+    /       |                     |       \    +-+   |
       |  | |---+        |                     |        +---| |   |
       |  +-+            |                     |            +-+   |
       +-----------------+                     +------------------+
             Host 1                                   Host 2


Something completely different.  Like I said before, I would prefer the
separation of signaling and media on separate ports but the NAT problem in
my opinion, along with the close relationship between signaling and media
streams, makes it untenable.

FM


-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug at acm.org] 
Sent: Friday, January 05, 2007 10:32 AM
To: Frank W. Miller
Cc: sip at ietf.org; 'Juha Heinanen'
Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01

Frank W. Miller wrote:
> Do you honestly think that there wouldn't be NAT if the world were
> completely IPv6?  NAT may have originally been put in place to alleviate
the
> IPv4 address exhaustion problem but separation of address spaces is more
> useful than that, no matter how big the address spaces are.  

What about distributed firewall?

http://www.cs.columbia.edu/~smb/papers/distfw.html

> While I would
> luv for the public Internet to be purely end-to-end wrt IP addresses, this
> just is never going to happen again.  

I agree, but it is not a reason to not try to improve things.  NAT,
firewalls, load balancers, B2BUA and SBC are the cancer of Internet.

> The early days of a few hundred VAXs
> all happily talking to each other directly are long gone.  The days of
trust
> are gone forever and NAT is just one reflection of that.
> 

So, how do you solve the problem of using a SIP endpoint behind a NAT? a
SIP endpoint been defined as running on UDP AND TCP.  Because this is
the problem here.

-- 
Marc Petit-Huguenin
Home: marc at petit-huguenin.org
Work: marc at 8x8.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip