Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails

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

 



>  My issue  is simply that all other analogous option/feature combinations in DCCP 
> are specified like this:
>
>    DCCP A MUST send Ack Vector options on its acknowledgements when Send
>    Ack Vector/A has value one, although it MAY send Ack Vector options
>    even when Send Ack Vector/A is zero.
>
> This was intentional; I can explain more if you care. 
Please do - I asked for that in the previous email.

I can not see the point of doing the above. 
It says "you MUST do A, but you MAY also not do A".

If a sender is permitted to add the option even if the negotiation means that
it is not permitted to use the option, it generates uncommitted data which gets
ignored by the receiver. This creates a lot of waste of bandwidth. Ack Vector
options are a good example - they have dynamic length, so at worst there are
several hundred wasted bytes per each packet when allowing the sender to go
ahead and ignore the feature negotiation.

I can see only disadvantages of allowing A and not-A. Apart from making the
implementation complex and confusing, it also opens a door for denial of service
attacks, a man in the middle could reformat most parts of the payload data simply
as an Ack Vector, flip the required bits of the checksum, and turn the bitstream
into random noise.

>> If there is something I may have misunderstood, please can you clarify.
>
> If:
> - the language about generating options used "MUST...MAY", instead of  
> "MUST...MUST NOT", and
I still can not see a reason why there should be a state between on and off.


> For instance, "Receivers MUST use previously specified mechanisms to 
> measure the round-trip time when Send RTT Estimate is zero; this document 
> does not define a standards-track method allowing receivers to use Sender 
> RTT Estimate options when the Send RTT Estimate is zero." [...])
Agree in principle with this suggestion -- this is also the result of the
discussions with 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