On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)
<ananth(_at_)cisco(_dot_)com> wrote:
* The document never mentions the fact that this document is
IPR-encumbered. As far as I recall, much of the dicussion
within tcpm with respect to the level of requirements of this
document (MAY/SHOULD/MUST, etc.) had to do with this fact. I
believe the document should include a warning mentioning that
there's an IPR on the document, so that implementers can
consider this point in their decision of whether to implement
the described mechanisms or not.
I am confused what to do since this is being brought up very late in the
game. That said, there are *many* drafts/RFC's that have IPR on them in
the whole of ietf. Do all them explicitly state the IPR link ? I'll
leave it to the collective wisdom of the group and the chairs to offer
guidance on this matter.
I personally believe this should be noted in all RFCs on which there's
a known IPR. However, Joel Halpern mentioned this is not current
practice. If that's the case, I'd have no problem with leaving it "as
is". (FWIW, if you look at our tcp-security document, we do recommend
the implementation of the counter-measures you propose, but just note
that there's an IPR, and that implementers should research how this
would affect them).
* The document discusses blind attacks, and to some extent
assesses the difficulty in guessing the four-tuple that
identifies a TCP connection.
However, it does not even mention port randomization, which
is probably the most simple and straightforward approach for
mitigating blind attacks against TCP. This was raised by me
Well, the point is that source port randomization is something external
like Ipsec and nothing specfic to TCP. TCP will work with or without src
port randomization.
I disagree. Port numbers are a TCP mechanism. How you select them is a
TCP policy. The fact that there's no mandatory policy for selecting
the port numbers doesn't mean that they things like "port
randomization" are external.
Now the scope of this document is to improve
robustness to TCP esp. in cases where the TCP connection is not
protected by other means like TCP MD5 or TCP AO etc., Now this point is
very clear in the document. That said I have no issues putting a
reference to the port randomization in the document.
What I mean is that anybody that cares about this stuff (FWIW, I do)
would also implement port randmization, ISN randomization, etc. One
might argue that there's no use in enforcing the more strict
validation checks in your document if the stack uses easily
predictable (and global) ISNs, and easily predictable ports for the
outgoing connections.
and other quite a few times in the tcpm wg list, pre and post
wglc, but this comment was never addressed. It's particularly
curious that port randomization is not mentioned when tsvwg
is working on it (draft-ietf-tsvwg-port-randomization).
Yes, you did raise this issue last time, but I did defer it to the WG
and did not receive any response, so I simply left it at that.
IIRC, both Joe and me had agreed on this one (yeah, we did :-) ).
* Among the factors that determine how easy these attacks be
exploited is the window size. This document should provide,
at the very least, pointers with advice on what to do with
the tcp window. While quickly skimming through RFC 4953, it
It does mentions about the window size relationship, For example in the
beginning sections of the document we briefly mention the window size
and the # of packets that is required to generate a successful attack.
What I mean is: you should not use windows that are larger than
necessary. Using larger windows than necessary doesn't come for free
(e.g., it increases the chances of an attacker of successfully
performing these attacks).
* Yet another factor is TCP ISN randomization. At the very
least, this document could/should a pointer to RFC 1948. We
do offer a lengthy discussion of this and other issues in
draft-gont-tcp-security and
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
Why should it talk about ISN randomization since ISN randomization, is
somewhat orthogonal to the type of attack here, it is not even one of
the attack vector.
If I can predict the ISN, I don't have to guess it. Therefore, it's
easier to successfully perform the attack.
We could refer this, but the scope of the current document is about the
RST/SYN and Data attacks and mitigations, Since this document generally
refers RFC 4953 (which came after this document was written. BTW) I
think this should suffice, IMO.
I believe you should say something about this. How you address this is
a matter of choice. e.g., you could craft your own text (just mention
that sequence numbers should be generated in such a way that are not
easily guessable by an off-path attacker), reference RFC 1948, or
reference the work with did in the tcp-security I-D.
* The counter-measure of for the SYN-based reset attack may
have missed a common heuristics for the handling of SYN
segments. See pages 86 and
87 of the UK CPNI paper on TCP security. FWIW, we argue that
the processing of SYN segments proposed in [Ramaiah et al,
2008] should apply only for connections in any of the
synchronized states other than the TIME-WAIT state.
We just followed RFC 793 as the base and the changes are made w.r.t
that. TIME-WAIT may be an exception but doesn't RFC 793 already has that
language correct?
Well, the timestamps was published *after* RFC 793. So RFC imsply
doesn't address this, because timestamps didn't exist at the time.
* When it comes to TCP-based blind-connection reset attacks,
there's a much more trivial -- yet not discussed before? --
alternative. See Section 11.1.3 and Section 11.1.4 in
draft-gont-tcp-security and the CPNI paper
(http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf).
These variants should, at the very least, be mentioned and a
pointer provided to them as, at least in theory, are much
easier to exploit.
Those sounds like some new proposals (security and precedence) different
stacks would have taken different measures to address this issue.
Anyways this is something new and hence needs more discussion and
evaluation. Has these ideas been submitted in a draft to TCPM? (your
recent BCP document tcp-security, covers it ?)
Yes, the tcp-security I-D covers it. This stuff came as a surprise
while assessing RFC 793. One would expect that these attacks don't
work in practice--- but you never know. However, IETF-wise they do...
therefore I think it should be mentioned as another potential
connection-reset attack vector (*much* easier, as you don't even have
to guess the sequence number)
* When it comes to the data injection attack, Michael
Zalewski sketched another attack vector which may be easier
to exploit. We discuss it in Section 16.2 of
draft-gont-tcp-security and the CPNI doc, along with advice.
IMO, this vector should be mentioned, too.
This again is an attack which relies on the IP functionality and not
TCP.
This one I may grant.
I'm also glad that this doc is getting close to publication.
Five years working on a document is quite a lot of time!
Agreed. Esp when it has been running in the internet with multiple
vendors supporting these mitigations.
Agreed.
Thanks!
Kind regards,
--
Fernando Gont
e-mail: fernando(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org PGP
Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf