Re: draft-ietf-dccp-udpencap-03 - 6-tuple

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

 




DCCP'ers,

I have now implemented all the corrections in the UDP encaps draft, except for the issue of how we implement transport demultiplexing, where there seems to be multiple ideas. We clearly need to choose either
the 4-tuple demux or the 6-tuple demux.

Before we choose, can I suggest a version of the 4-tuple demux that also uses the encaps DCCP information. This assumes a 4-tuple {ip-src,ip-dst,udp-src,udp-dst} is expected per DCCP connection.

Here is my suggestion:

We demux incoming UDP encapsulated DCCP datagrams using only the UDP and IP information. However, if a flow is active (i.e. DCCP connection) using a particular 4-tuple, we then check the DCCP ports are the same as the cached value for the session that initiated the connection, if the cached info is different, the encaps returns a DCCP-Reset(Connection Refused) to abort the "additional conflicting" connection.

For an established flow, this requires a cache of the DCCP ports (32 bits). In most cases, a second flow that maps to the same UDP ports
would start  an initiation of a new DCCP session, and therefore the reset
would will simply abort this, and provide a high probability that this
would not disrupt any existing flow.

Others may immediately see a flaw, in which case do speak-up. Is something else better?

Gorry


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux