|
|
Folks-
(chair hat off)
Below are my comments on the icmp-attacks draft. IMO, despite I don't
see this document as near ready yet.
allman
Meta:
* The document is too prescriptive if indeed it is to be an
informational type of document and not an update to the relevant
specifications.
As one egregious example (there are more), section 6 steps
through that SQ messages are not supposed to be sent (RFC1812],
but if received a host MUST react [RFC1122]. This supposed
informational document then goes on to say: "Thus, hosts should
completely ignore ICMP Source Quench messages meant for TCP
connections."
To me, this is a bogus avenue for an informational document to
take. I.e., if one takes only the text from 1122 and this
document you'd surely assume this document was updating 1122
with new thinking. But, if one looks at the document class then
you'd be left with being required to follow 1122 and react to SQ
messages if you wanted to be compliant. So, this sort of thing
leaves us in a real mess, IMO.
(There are other cases of this - e.g., the end of page 12
effectively recommending against the "hard error" classification
in RFC1122 in favor of a "soft error" treatment.)
There are some SHOULDs in the previous documents and if this
document wants to simply clarify or offer some suggested
approaches within these SHOULDs then that's fine for an
informational, I guess. But, the document should be very clear
when it is taking that approach. And, for cases where these is
no wiggle room in the current specifications we should not be
trying to make some wiggle room.
Note #1: I have zero heartburn with saying that hosts should
ignore SQ messages. My heartburn is with leaving things all
ambiguous in the RFC series.
Note #2: I cannot clearly reconstruct why the WG decided to head
down the informational path at this point. I would be happy to
see that changed such that we can make these sorts of actual
changes to the current specs.
Note #3: Just because there are no capital letters doesn't mean
the text doesn't come off as prescriptive. I.e., the tone and
the words themselves are as important in my eyes as whether one
writes "must" or "MUST".
Basically, I think I am agreeing with Joe and Bora here... as it
stands if this document were an informational RFC I think it'd
be a backdoor change to the previous specifications. I think we
need to think this through very carefully and craft appropriate
text if we want to progress as an informational because the
IESG, it would seem to me, would be well within the bounds of
reasonableness to reject this sort of document for leaving
things in an inconsistent and ambiguous state.
* The analysis of the threat these attacks impose needs to be much
more carefully laid out. The current analysis is glib. E.g.,
in section 2.2 the text says: "If we assume the attacker knows
the two end systems involved in the TCP connection to be
attacked,". Why would we assume that? The argument continues
that Internet services use well-known ports which leaves only
one ephemeral port to be guessed. But, first *which* well-known
port is involved in the connection? There are lots of them.
The text seems to conclude that the worst case here is that you
need to brute force 64K packets to get one wedged into the
connection (which in general is very short, as well). I think
that is wildly overblown as a general argument. You *might* be
able to make this sort of case if you scope down to some case
where it is actually plausible that you'd know some of this
information (e.g., the BGP case). But, this document is not at
all careful about showing perspective as to when ICMP messages
are an actual threat and when they are not.
* I don't think the revised PMTUD algorithm is a fit for this
document. The revised algorithm may be perfectly fine (I would
need to think on it more before I made up my mind one way or
another). But, the algorithm goes beyond the scope of simply
fixing a security problem. If this document wants to do only
the security related stuff then that's fine. But, I think the
larger work ought to be split out and made into its own
document. We have a WG that is working on PMTUD and this would
seem at first cut to be under their purview.
Section 1:
* "While the security" --> "While the possible security"
Section 2.1:
* "network congestion and rate-limiting" --> "network congestion
or rate-limiting"
Section 2.1.1:
* "report network errors" --> "report errors"
* It's not clear to me why the middle two paragraphs are in here.
Why are we calling attention to these two things specifically
right here?
Section 3:
* I am not an IPsec guru. So, I don't understand a few things...
(1) If I am using IPsec and get an ICMP back then how is that
supposed to be processed. In principle I *might* be able to
match it to a connection because I saw the data go out on
some connection and so I could still validate the first bits
included in the reply. Right? I don't expect this happens
because stacks don't hang onto packets they put on the wire
to compare against, right?
(2) So, are you hosed if you use IPsec? That is, are your
choices to either ignore them or to pass them to all
connections between two addresses? This draft argues
against that sort of practice, but should it? I.e., can't
that lead to a PMTUD black hole or something?
For an IPsec-idiot this document is sort of a mess. I really
don't know how this all plays together after reading the
document. (Note: I am not advocating re-writing other things,
but a sketch and some references would be nice.)
Section 4.3:
* I share the uneasiness expressed on the list with regards to
this section. It's usefulness seems low and at least needs
better motivation. One could put an extra warning in here that
general egress filtering is useful and should be done. E.g., so
I don't forge an ICMP that is supposedly from Joe's machine.
Section 5.1:
* "TCP is handled" --> "TCP is handed"
* I didn't go back and look, but the notion of "frag needed" as a
hard error seems odd to me. I think the document could
certainly clarify this a bit. It's certainly not treated as a
hard error.
* More glibness about the ease of the attack: "even being
off-path, an attacker could reset any TCP connection taking
place". Of course, I cannot prove this statement wrong. But, I
am willing to bet that in an empirical way it could not be shown
to be accurate either.
Section 5.2.1:
* It's not clear to me why you apply protocol unreachables to
certain states and don't do the same thing to port unreachables.
Sections 6 & 7:
* I don't quite understand the distinction between a
"throughput-reduction" attack and a "performance-degradation"
attack. It seems like these two attacks should be subsections
of the same section such that I don't have to think about
whether there is a real reason for the distinction.
Section 7.1:
* "(PMTUD) mechanism lets" --> "(PMTUD) lets"
* "error message to sending" --> "error message to the sending"
* You could cite the TCP model (Padhye 1998, Mathis 1997, etc.)
which clearly shows the impact of packet size on performance.
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|