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

[Gerrit Renker <gerrit@xxxxxxxxxxxxxx>]

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