Fernando,
I was modifying the document to update the last call comments and I
would want to make sure if we are on same page w.r.t to your comments.
Pl see inline.
-----Original Message-----
From: fernando(_dot_)gont(_dot_)netbook(_dot_)win(_at_)gmail(_dot_)com
[mailto:fernando(_dot_)gont(_dot_)netbook(_dot_)win(_at_)gmail(_dot_)com] On
Behalf Of
Fernando Gont
Sent: Thursday, April 16, 2009 10:15 PM
To: Anantha Ramaiah (ananth)
Cc: ietf(_at_)ietf(_dot_)org; tcpm(_at_)ietf(_dot_)org
Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure
(Improving TCP's Robustness to Blind In-Window Attacks) to
Proposed Standard
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).
I think we seem to have concluded this. As per Brian Carpenter's
suggestion I have done an iprnotified = yes in my xml2rfc. I hope that
should take care of this.
<snip>
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
It depends on how you view this document. To me, this document is about
improving TCP's robustness on some type of scenarios. It is not intended
to be a plethora of all possible TCP attacks and mitigations.
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 :-) ).
Like I said earlier, I have no issues putting a reference to port
randomization document. Can you suggest a right place for this?
* 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).
Provide advice on window sizes is deemed beyond the scope of this
document, IMO.
* 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.
Well, predicting ISN helps, but it really depends on how much volume of
data that got exchanged and the current sliding window snapshot (snduna
-- sndnxt) which really determines the acceptability of a segment.
* 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.
Why are you bringing in timestamps, the huerisitic suggested by RFC 1122
applies *without* timestamps in place.
Just to be clear : The current mitigation *does* not preclude any host
to have the TIME-WAIT hueristic suggested as a MAY condition in RFC
1122. The scope of the document is to only change the language w.r.t
793.
That said, I'll leave it to the collective wisdom of the WG to comment
on this, if there is a strong consensus I don't issues to add some text.
* 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)
Like I said this document has been only taking about the 3 attacks from
the beginning when this document was out (5 years), I see no point in
delaying this document any further by adding new attacks without the
consensus of the WG.
Thanks,
-Anantha
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf