> On Mar 11, 2019, at 10:51 AM, Paul Wouters <[email protected]> wrote: > > On Mon, 11 Mar 2019, Christian Hopps wrote: > >> Here's some new work on improving IP traffic flow security. I've requested a >> presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF >> 104, and will hopefully be able to present this work at that time as well. > > Thanks. I did a quick read and I'm still digesting this, but one thing > seems a concern: > > We utilize a send only (i.e., no response expected) IKEv2 > INFORMATIONAL exchange (37) to transmit the congestion information > using a notification payload of type TFS_CONGEST_INFO (TBD). The The > Response bit should be set to 0. As no response is expected the only > payload should be the congestion information in the notification > payload. > > This very much violates the state machine model of IKEv2, and I would > not be in favour of this without strong arguments of why requiring a > response (even if empty) is harmful.
The strongest case I can give is that this data represents "telemetry" and is sent at a constant rate, there's no need to make it reliable (and resending queues of them seems bad if they aren't being ack'd). There are other ways to skin this cat though. :) One option is that instead of sending a new CC info report on the interval timer expiry if we haven't received a response "ack" yet, we simply update the data (last seq num seen, drop count and timestamp) we sent previously to be current, keep the message ID the same and resend the message. Would changing the data in the message prior to resending be preferable? Thanks, Chris. > > Paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
