On 3/12/2015 2:29 AM, Tero Kivinen wrote:
> Gregory Maxwell writes:
>> I don't think "don't protect the headers" is an accurate description
>> of Honolulu if it also leaves the system exposed to resets, as there
>> clearly was a fair amount of concern expressed about spurious resets.
> 
> Even if we protected the headers, that would not automatically protect
> against resets. Resets are hard to protect against, and for those we
> most likely need something different than what can be done by the
> protecting the header. 

That's incorrect. See TCP-AO.

>> I'd like to reemphasize that any passive attacker infrastructure also
>> trivially has the capability to inject a few packets-- just by having
>> access to any non RPF filtered network connection anywhere in the
>> world, without being a full scale man-in-the-middle.
> 
> Yes. And there is also difference in blind insertion attacks and
> attacks where the attacker can see all the traffic. I.e. if attacker
> can see port numbers, tcp sequence numbers etc, that can allow much
> more efficient attacks, even when it cannot remove any packets from
> the network. On the other hand attacker with that capability can also
> quite easily do limited packet deletion attacks, 

I think you're confusing two different levels of capability:
        - snooping and injecting traffic
        - deleting traffic

The former can be quite easy compared to the latter.

> for example
> configuring firewall filtering rules in the intermediate devices, and
> with those they can do targetted active attacks.
> 
> Anyways protection against prevasive monitoring is the important thing
> here, the limited protection against active attacks is secondary
> objective. If you want proper protection against active attacks, use
> IPsec, TCP-AO or some other method that will provide that.

Fair enough. Good reason for me to move forward with TCP-AO-ENC in TCPM,
where I had intended it anyway...

Joe

_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to