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

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 13 Mar 2006 23:37:35 +0000

> -----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 encapsulationg
IPv6 over UDP?

Why not just borrow those solutions?

In fact, rather than SCTP over UDP over IP, why not do
SCTP over IPv6 over UDP over IPv4?

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

---

From: Mark Butler <[email-masked]>
Date: Mon, 13 Mar 2006 22:32:44 -0700

Caitlin Bestler wrote:

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

>Why not just borrow those solutions?
The problem spaces are quite different for encapsulating a transport 
protocol vs. a network protocol.

>SCTP over IPv6 over UDP over IPv4?
That is a good solution for connecting SCTP/IPv6 endpoints through an 
IPv4 network.  It doesn't work well for connecting  SCTP/IPv4 endpoints 
however. Each node would require an IPv6 stack, an assignment from a 
common IPv6 address space, and access (direct or tunnelled) to an IPv6 
routing infrastructure.

[OT: It seems to me that one of the biggest limitations working against 
IPv6 right now is the 1500 byte Ethernet frame size.  Unlees routers can 
learn to intelligently drop fragmented IPv6 datagrams, all those useful 
extended headers either gradually decrease the percentage of the MTU 
available for actual data, or multiply to proportion of "bad put" in the 
network, the same way early ATM switches randomly killed parts of AAL5 
PDUs while happily forwarding on the rest....

The IEEE folks are apparently not at all interested in standardizing 
increased Ethernet frame sizes, so I think the burden lies with router 
manufacturers to identify and drop fragmented IP datagrams as a logical 
unit, instead of dropping fragments without regard to any others.  Then 
we could use much larger IP datagram sizes (~64KB) and concern ourselves 
less with performance stealing header overhead, for most types of 
headers anyway.  The current IPv6 situation is like the ATM "cell tax" 
all over again.]

 - Mark

---

From: Mark Butler <[email-masked]>
Date: Tue, 14 Mar 2006 03:33:19 -0700

Caitlin,

I can see how Teredo or something similar could be very useful for 
solving a more general problem - that of two SCTP/IPv4 endpoints trying 
to communicate when both are behind a NAT device.  My comments were 
focused on solving the simple problem where an SCTP client with a 
private IP address and port establishes communication with a server with 
a public IP address and port.  Nothing particularly special required to 
do that, just some straightforward conventions. 

The primary reason one might use a socket option to specify a 
non-standard UDP service port is a workaround to allow multiple SCTP/UDP 
supporting Internet servers to operate behind a SCTP/UDP oblivious NAT 
router, by using conventional UDP port forwarding with a different UDP 
service port for each one.   This is an awkward solution because 
applications would have to specify two ports to make a connection.  A 
better solution is:

(1) SCTP/UDP aware NAT routers should maintain state and apply SCTP port 
forwarding rules based on the encapsulated SCTP port, so as to allow a 
single standard UDP service port to be used.

For peer-to-peer SCTP/IPv4 communication behind NAT devices, the Teredo 
protocol is unneccessarily complicated.  The need for a Toredo relay 
would go away, and the functions of the Toredo server would be cut in 
half.  What would remain is a server to mediate new connections through 
NAT devices.  STUN [RFC3489] is a protocol designed for just that.  The 
advantage is that STUN does not require any additional headers.

[OT: On a more general note - perhaps instead of all these byzantine NAT 
traversal techiniques, we should recognize that the status quo actually 
corresponds to variable length network addresses and support them 
explicitly, not in the core routers, but in end systems and NAT 
devices.   i.e. If I have private address 10.0.0.2 and sit behind public 
address 198.18.67.23 my public VLA is 198.18.67.23.10.0.0.2.     An IP 
packet is composed is two logical stacks, on containing a the source VLA 
and one containing the destination VLA.  On the outbound path, a NAT 
device logically pushes its next level higher IP address on the source 
VLA stack.  On the inbound path a NAT device logically extracts pops off 
its next level higher IP address from the destination VLA stack.

This requires a lot of state to be maintained by the NAT devices, with 
attendant problems.  One way to remedy the situation would be to store 
the full source and destination VLAs in an IP extension header, have NAT 
devices substitute the appropriate IP addresses at each level as is done 
now, leave the ports alone, and instead of using a connection state 
table on the inbound path, extract the next inner level IP address from 
the destination VLA.   On the outbound path, validate the source VLA at 
each NAT stage, and return an ICMP error or equivalent notifying the 
sender of what its proper VLA should be, based on the combination of the 
previously validated VLA suffix, and the VLA prefix known to the NAT 
device. That would provide one means of VLA discovery, much simpler and 
more reliable than STUN, at the cost of extra header space.

Then modify end system applications, transport protocols, and address 
containing ULPs to support IPv4 VLAs as an alternative to common support 
for IPv4 and IPv6.  If VLAs are restricted to be four layers deep (i.e. 
up to three layers of NAT devices between any endpoint and the core 
public Internet), they will fit nicely in a 128 bit field comparable to 
an IPv6 address. Eight level max VLAs (up to 32 bytes) would probably be 
a better long term choice.

The primary effect of VLAs would be to restore the end-to-end nature of 
the Internet, by making transforming non portable private IP addresses 
into portable, publically routable VLAs, so that every workstation, VoIP 
phone, Cell phone, PDA, etc. could provide standard services without 
relying on a byzantine mess of application layer gateways and NAT 
traversal techniques.

It hardly needs to be said that if IPv6 were widely adopted tommorrow, 
we would have a new address space shortage.  There isn't enough room for 
each customer to have a :/48 (let alone two for redundancy) with a 
scalable routing prefixes.]

 - Mark

Mark Butler wrote:

> 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.
>
> IPv4 network.  It doesn't work well for connecting  SCTP/IPv4 
> endpoints however. Each node would require an IPv6 stack, an 
> assignment from a common IPv6 address space, and access (direct or 
> tunnelled) to an IPv6 routing infrastructure.
>
> [OT: It seems to me that one of the biggest limitations working 
> against IPv6 right now is the 1500 byte Ethernet frame size.  Unlees 
> routers can learn to intelligently drop fragmented IPv6 datagrams, all 
> those useful extended headers either gradually decrease the percentage 
> of the MTU available for actual data, or multiply to proportion of 
> "bad put" in the network, the same way early ATM switches randomly 
> killed parts of AAL5 PDUs while happily forwarding on the rest....
>
> manufacturers to identify and drop fragmented IP datagrams as a 
> logical unit, instead of dropping fragments without regard to any 
> others.  Then we could use much larger IP datagram sizes (~64KB) and 
> concern ourselves less with performance stealing header overhead, for 
> most types of headers anyway.  The current IPv6 situation is like the 
> ATM "cell tax" all over again.]
>
>  - Mark
>