On 07/30/2014 01:39 PM, Martin Thomson wrote: > I see two potential failure paths here: in one, hosts adaptively > respond to damage by reducing what is protected. That is in line with > the opportunistic nature of the mechanism, but it allows an attacker > to erode any optional protections.
What does this give to the user? opportunistically encrypting the session protects against a passive eavesdropper. opportunistically providing integrity protection to parts of the packet headers doesn't protect against any attackers i'm aware of. Would this require some other API, whereby a tcpinc-aware client could query and detect that this protection had failed and then choose on its side to deal with this change in some way? > The other failure mode is where > you kill the connection in response to modifications, Or you could ignore the malformed packets without killing the connection in the hope that the protected packets will arrive shortly -- this would provide a defense against attackers able to inject packets but not able to block packets. (e.g. search for "race condition" in https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html) > and we thereby create a disincentive to deploy tcpinc. Right, this is an argument against making these header protections mandatory -- but i'm trying to clarify what people think it should mean to make these protections optional. --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
