Subject: Re: [Tsvwg] Re: SCTP/UDP encapsulation

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 14 Mar 2006 17:29:39 +0000

> -----Original Message-----
> From: Mark Butler [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2006 05:32 AM
> To: 'Caitlin Bestler'
> Cc: [email-masked]
> Subject: Re: [Tsvwg] Re: SCTP/UDP encapsulation
> 
> Caitlin Bestler wrote:
> 
> >>-----Original Message-----
> >>From: Mark Butler [mailto:[email-masked]]
> >>Sent: Monday, March 13, 2006 07:27 PM
> >>To: 'Michael Tuexen'
> >>Cc: 'Randall Stewart', [email-masked]
> >>Subject: [Tsvwg] Re: SCTP/UDP encapsulation
> >>
> >>Hello Michael,
> >>
> >>I think both user space and kernel space SCTP/UDP implementations would 
> >>work fine with the appropriate conventions.   Using UDP port 9899 for 
> >>this is a bit of a security problem, because any user level process can 
> >>bind to it and generate traffic for privileged SCTP ports (1..1023).  
> >>That weakens some forms of IP address/port based security.   I suggest 
> >>the following policy:
> >>
> >>    
> >>
> >
> >Perhaps an over simplistic question, but why bother to
> >enumerate special rules and API options at all?
> >
> >Isn't encapsulating SCTP over UDP have *exactly* the
> >same control and security issues as encapsulation
> >IPv6 over UDP?
> >  
> >
> Fortunately not. General purpose IPv6 / UDP encapsulation (as envisioned 
> by RFC4380) requires relay servers to bridge between IPv4 and IPv6 
> networks.  SCTP/UDP encapsulation can be easily and more effectively 
> done at the endpoints.  It is easy to make stateless network protocol 
> relays and virtually impossible to make stateless transport protocol 
> ones.  Doing SCTP encapsulation on a separate box has all the 
> complexities of NAT and none of the benefits.
> 
> Well designed options should have transparent default behavior.  Unless 
> an application needs to disable encapsulation fallback, or needs to 
> connect to an unusual port for some reason, or has other special case 
> requirements, SCTP_ENCAP will not need to be used.  The other rules are 
> for SCTP/UDP stack implementers only, and would take perhaps a dozen 
> lines of code to implement, at most.
> 

I was more thinking of Bump-in-the-stack solutions than bump-in-the-wire.
Then the solution would just work without any real performance penalty,
except for the "cell tax".

But you could eliminate the cell tax, but simply doing "bump-in-stack"
UDP encapsulation. My point is that the visibility and contrability
of "bump-in-the-stack" solutions can and should be consistent, no
matter how the packets are being wrapped (IPv6 tunneling, SCTP tunneling,
VPN, IPSEC, ...). Redebating the details for each wrapper just adds
an extra Gig or two to the long term email archives and makes
application programmers spend more time re-learning what the
rules are for each network protocol.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Butler <[email-masked]>
Date: Wed, 15 Mar 2006 00:56:03 -0700

>rules are for each network protocol.

I agree in regard to the API issues.  It is unfortunate that there is 
relatively little standardization of socket types, options, and 
semantics across transport protocols.  Why should TCP_NODELAY and 
SCTP_NODELAY be separate? A common option such as SO_NODELAY would be 
much better.  There are commonalities between TCP, SCTP, and DCCP that 
could benefit from a transport independent interface.

In this particular case, however, I think the real problem is that NAT 
is a fundamentally broken technology widely deployed in cheap little 
plastic boxes that rarely (if ever) have new firmware installed, 
particularly since the typical consequence of making a mistake is being 
cut off from the rest of the world.  For example, a while ago my local 
telco required me to switch from CAP to DMT to get a bandwidth upgrade 
(even though CAP was perfectly capable...).   So I went to the router 
manufacturer's web site, downloaded the DMT firmware, and waited for the 
appointed time, which I knew had arrived when my Internet connection 
went down without warning.

Then, (considering I wasn't ever going to get CAP service again), it was 
safe to re-flash the router.  After a few difficulties, the firmware 
upgrade worked, I made the appropriate configuration changes, and my 
connection worked again.  But of course if anything went wrong, I could 
be without a connection for a week or more.  For that and other reasons, 
re-flashing routers is not something a typical end user is inclined to do.

So we have a critical bottleneck technology like NAT, with built in 
obsolesence, that needs to be upgraded for any new transport protocol, 
essentially hardwired with a dozen different incompatible varieties, and 
a whole industry developing around working around its limitations.  One 
vendor sells a full rack size application layer gateway with a primary 
purpose of proxying SIP through corporate NAT boxes.  And that is for a 
market that certainly can re-flash their routers.

Aside from the more radical solutions, I wonder why something 
ridiculously simple like having NAT routers return ICMP messages 
containing with the external transport address whenever an outbound 
address translation is done, or perhaps in response to ICMP probes 
forwarded along the same path.

 - Mark