[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

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



> 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.
>
I can see how this might work, but I find no immediate benefit in it. It shifts
the complexity from memory (4 instead of 6) to algorithm.

IMHO this all shows a tendency to go from an initially simple tunneling-like
service (which could declare DCCP-UDP connections dead after some timeout of
inactivity) to a stateful DCCP middle-box, which is more difficult to specify
and implement.


[Kernel List]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Linux Resources]

Powered by Linux