Re: [tcpm] feedcback on tcp-secure-05

[Pekka Savola <[e-mail]>]

Note: I have not read the spec.  I'd intend to do it once it gets into 
WGLC.  But some follow-up to some of Joe's points below,

On Thu, 13 Jul 2006, Joe Touch wrote:
> The doc continues to have a detailed but somewhat incomplete discussion
> of the attack scenario; the point of tcp-antispoof was to provide a much
> more detailed version of that discussion that should not be
> recapitulated but rather cited.

You couldn't just simply cite it without any summary though, as 
antispoof is heading Informational, and doing so would likely require 
a down-ref.

> No reasoning is given for numeric limits to ACK throttling (why 10 in 5
> seconds? why not a ratio of the number of conventional ACKs provided)

Simpler to implement, maybe?

> The doc should also indicate that preventing these attacks does NOT
> prevent ICMP attacks (and cite Gont's draft in this regard); it would be
> useful for the security considerations to address whether ICMPs should
> be blocked altogether and what the impact of that would be. Without such
> blocking, it's not clear what the utility of this solution would be.

First of all, your last comment is correct only in isolation, i.e., 
when ICMP attack protections have not been implemented but this is. 
In reality, all vendors have implemented ICMP attack protections for 
at least about 1.5 years.

I do no think this document should be saying anything about blocking 
ICMPs.  On the other hand, reference to ICMP attacks would probably 
make sense.  Whether there should be more extensive discussion of ICMP 
attacks might or might not make sense, depending on the how heavily 
this doc would depend on the security discussion of tcp-antispoof.

> The specific modifications suggested are given as loosely discussed
> recipes rather than a specific list of the modifications to TCP; IMO,
> the latter should be required.

I'd agree that specific modifications would likely be preferable.

In section 3.2 the text says:

    Instead, this document requires that implementations MUST perform the
    following steps in place of those specified in [RFC0793](listed
    above).

Just to be clear, I'd rather say:

    Instead, this document requires that implementations that
    implement this specification MUST perform the
    following steps in place of those specified in [RFC0793](listed
    above).

or something like that.  This doc is not making the behaviour of 793 
incompliant, surely.  But rather introducing a specification that, if 
implemented, must be done in a certain way.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm