Subject: RE: [tcpm] feedcback on tcp-secure-05

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 13 Jul 2006 11:04:10 -0700

Inline comments...

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 10:28 AM
> To: [email-masked]
> Subject: [tcpm] feedcback on tcp-secure-05
> 
> I had the following comments on v05.
> 
> Joe
> --------
> 
> 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.
> 
> The doc cites a *very* old version of tcp-antispoof, too.

Is the suggestion to take out some verbiage on the attack scenario(s)
mentioned in the document. If so which sections are of concern?

The comment of citing a new version of tcp-antispoof is taken and will
be relected in the upcoming version.

> 
> 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)

The reasoning given for numeric limits is by no means meant to reflect
the exhaustive set of possibilities for ACK throttling. Is the
suggestion to provide a complete list of ACK throttling possibilities?

> 
> TCP-MD5 isn't considered as a useful protection from these 
> attacks (and it is).

Using TCP-MD5 makes the attacks described in this document much harder
than without MD5.
So beats me as to why TCP-MD5 isn't useful. Can you please elaborate? 

> 
> The use of both IPsec-AH and IPsec-ESP is suggested for 
> on-path attacks, where only one of the two is required.

Ok.

> 
> 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.

Ok.

> 
> The middlebox considerations (sec 8.1) declare that some 
> behavior is noncompliant, but don't consider whether it 
> already exists and how to make their system avoid ACK wars 
> that might result (e.g., to detect and quench such a war, 
> which seems separate from ACK throtling per se).

Will re-read the text and see if we can make changes in this aspect.

> 
> -----------------------------------------
> THIS IS THE BIG POINT REGARDING REVISION:
> 
> 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.
> 
> -----------------------------------------

"Loosely discussed recipes"  couldn't parse this. Can you pl elobarate
or propose some text that can be considered for addition in the next
revision?

> 
> The blind data injection attack suggests that the window of 
> vulnerability can be as large as the amount of unacknowledged 
> data, which can be as large as the window. This means that 
> even if the RST attack is reduced from a fraction of the 
> windowsize to 1, a similarly detrimental attack can still 
> occur from data injection. 

Yes, but it depends on the application's response to the "bad data".
Just to give an example : For BGP it would mean connection tear down
whereas for other applications it may or may not.

> This needs to be discussed in the 
> security considerations, and continues to render the utility 
> of the RST protection of limited comparable value.

Hmm. RST protection is still needed. To put it shortly the document
outlines the robustness initiatives that can performed at the transport
layer (TCP) against some attacks (RST/SYN and data injection)

-Anantha

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 11:09:26 -0700

> mentioned in the document. If so which sections are of concern?

That should be obvious in the doc, the section that outlines the problem
can be condensed to a summary paragraph and a citation.

> suggestion to provide a complete list of ACK throttling possibilities?

No, just to give a reason for picking the numbers 10 and 5, and whether
those numbers are context-dependent or not (i.e., if some assumptions
change, then would the numbers change?)

> So beats me as to why TCP-MD5 isn't useful. Can you please elaborate? 

To be more clear, the document doesn't describe that TCP-MD5 solves this
problem. I'm asking that the doc say what you do above. ;-)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 15 Jul 2006 15:42:45 -0300

> > not clear what the utility of this solution would be.

I don't think tcpsecure should make any advice on what to do with ICMP.

Just make it clear that the introduced mechanisms do not prevent 
ICMP-based attacks against TCP, and provide a pointer to 
draft-ietf-tcpm-icmp-attacks-00.txt .

If you are going to make any other statement on this issue, state 
that the ICMP-based attacks are easier to perform, and thus should be 
mitigated (if not, it's ICMP that is the "weakest link in the chain").

You could also add that, fortunately, virtually every implementation 
has mitigated the ICMP attacks described in 
draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not 
all) the counter-measures described in that draft.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Jul 2006 21:56:34 -0700

Fernando Gont wrote:
> If you are going to make any other statement on this issue, state that
> the ICMP-based attacks are easier to perform, and thus should be
> You could also add that, fortunately, virtually every implementation has
> mitigated the ICMP attacks described in
> draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not all)
> the counter-measures described in that draft.

That last point doesn't obviate the issue that ICMP packets - even
validated by the mitigations in the draft above - are still easier to
spoof and can be spoofed by third parties than any of the attacks in
tcp-secure.

I.e., they remain the weakest link, and worrying about tcp-secure
protections is nonsensical by comparison, UNLESS ICMPs are entirely
blocked.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Jul 2006 05:33:01 -0300

>spoof and can be spoofed by third parties than any of the attacks in

The counter-measures in the ICMP attacks draft eliminate the 
ICMP-based connection reset, eliminate the Source Quench attack, and 
require the attacker to be a Man In the Middle (*) for him to 
successfully perform an attack against the PMTUD mechanism.

(*) Even if he was able to sniff the traffic that corresponds to the 
connection, his attack (*) wouldn't succeed - He should be able to 
selectively drop packets that correspond to the attacked connection.

It is clear that with the ICMP counter-measures in place, TCP-based 
attacks are "the weakest link in the change". You don't need to "drop 
them all".

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 06:41:14 -0700

Fernando Gont wrote:
> The counter-measures in the ICMP attacks draft eliminate the ICMP-based
> connection reset, eliminate the Source Quench attack, and require the
> attacker to be a Man In the Middle (*) for him to successfully perform
> an attack against the PMTUD mechanism.

The countermeasures there also violate the specific text in RFC1122,
*without* noting (as per my other email) the "particular circumstances".
Instead, it makes the general recommendation to change hard to soft errors.

I've repeatedly said that the text below directly negates the
requirement in RFC1122. That NEEDS to be directly highlighted in your
doc (the text that says that 1122 allows this is incorrect):

     "For security reasons,
      it would be fair to treat ICMP port unreachable messages as soft
      errors (or completely ignore them) when they are meant for
      protocols that have their own mechanism for reporting this error
      condition."

Again, I'm not going to debate this further either. I'll be glad to
remind the ADs during review; if they agree, fine.

> attacks are "the weakest link in the change". You don't need to "drop

Even as soft errors, such ICMP errors could be interpreted by the
application as indicating a legitimate error that causes the connection
to be dropped, even though the only reason is attack.

However, perhaps I'm speaking more of what the ICMP draft should be
corrected to be, rather than what it is ;-) Short of changing RFC1122,
you're stuck regarding hard errors and resets, due (notably) to the
DIRECT LANGUAGE in 1122 that equates the two.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 17:45:07 -0300

At 10:41 18/07/2006, Joe Touch wrote:

[Talking about the ICMP attacks draft]

>       protocols that have their own mechanism for reporting this error

Joe, this already was in my list of changes. There are a bunch of 
comments from Mark, Pyda, Fred, you and others that I will 
(hopefully) address in the next revision of the draft.

Now, as per Anatha's e-mails, there's ambiguity in RFC 1122 respect 
to this issue. There's a MUST and a SHOULD on the issue of what is 
supposed to be the correct reaction to a port unreachable.

So, would you agree with the draft mentioning the ambiguity, and, as 
in the case of the other ICMP error codes, stating why it would make 
sense to treat them as soft errors, instead? (The "SHOULD" allows for 
that, after all).

>to be dropped, even though the only reason is attack.

This assumes that:
a) The system in question does not honor the "recommendation" in the 
ICMP attacks draft
b) ICMP error messages are passed to the application. In the Sockets 
API, they are passed only after a USER TIMEOUT.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 14:23:24 -0700

Fernando Gont wrote:
> comments from Mark, Pyda, Fred, you and others that I will (hopefully)
> address in the next revision of the draft.
> 
> Now, as per Anatha's e-mails, there's ambiguity in RFC 1122 respect to
> this issue. There's a MUST and a SHOULD on the issue of what is supposed
> to be the correct reaction to a port unreachable.
> 
> So, would you agree with the draft mentioning the ambiguity, and, as in
> the case of the other ICMP error codes, stating why it would make sense
> to treat them as soft errors, instead? (The "SHOULD" allows for that,
> after all).

The specific reason and conditions for the SHOULD *must* (my must) be
addressed, IMO (presumably "connect established" at least, or making
forward progress at most - with caveats about change of behavior - for
better or worse - in certain multipath scenarios as already raised).

The existence of the ambiguity *must* also be specifically noted.

If these are already repeating previous conclusions, that's fine. ;-)

> a) The system in question does not honor the "recommendation" in the

You're making recommendations about what the TCP should do regarding the
errors; that's not the same as what the application on top of TCP would do.

> API, they are passed only after a USER TIMEOUT.

I don't recall anything in 1122 about how quickly soft errors must be
passed to the app, but they MUST be passed to the app. This implies that
soft errors aren't passed if a user timeout doesn't occur, which seems
like another violation that should be noted.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 19:36:41 -0300

At 18:23 18/07/2006, Joe Touch wrote:

[(was Re: [tcpm] feedcback on tcp-secure-05)]

>better or worse - in certain multipath scenarios as already raised).

Okay.

So,

* The condition for all the so-called hard errors to be treated as 
soft errors is that the conenction must be in any of the synchronized states.
* The reason for not honoring the SHOULD is that in hostile 
environments, its an attack vector that is easier to perform than 
others. (I will note the ambiguity in the case of port unreachables)
* The good thing of the change is that it mitigates the above threat, 
and also improves TCP's robustness in the case of multipath scenarios.

Let me know if you agree with these and/or if I missed anything.

>errors; that's not the same as what the application on top of TCP would do.

I think this would be out of the scope of the document?

>like another violation that should be noted.

This seems out of scope, too.  We are not doing anything new wrt to 
whether TCP should handle ICMP errors to applications or not.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 16:52:33 -0700

Fernando Gont wrote:
> * The condition for all the so-called hard errors to be treated as soft
> errors is that the conenction must be in any of the synchronized states.

I agree with these. It would also be useful to add - to the last one -
that this *changes* how TCP would behave in multipath scenarios and/or
path changes, which *may* make TCP less likely to _correctly_ rapidly
disconnect from a session when a routing change occurs that disconnects
endpoints.

(i.e., there are cases that this might not be the best choice; trading
robustness for reactiveness to failure is typical, but not always the
only choice).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Jul 2006 03:26:37 -0300

>robustness for reactiveness to failure is typical, but not always the

I understand what you mean. However, the message codes to which we 
are changing from hard to soft errors (protocol unreachable and port 
unreachable) are not the ones that would reflect a routing change.

In the case of ICMP frag needed (if TCP does not implement PMTUD), it 
might be an indication of a routing change. Although implementing TCP 
without PMTUD, and at the same time setting the DF bit in the packets 
seems to me, at the very least, very weird.

Or am I missing something?

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2006 08:13:43 -0700

Fernando Gont wrote:
> I understand what you mean. However, the message codes to which we are
> changing from hard to soft errors (protocol unreachable and port

Sorry - long time since I got into this level of detail. We're talking
about dest unreachable codes 2-4, i.e.:
	2 protocol
	3 port
	4 frag needed and DF set

Changing these from hard to soft AFTER connection establishment means:

	- slower reaction (if at all?) to host reconfiguration
		2,3 - dynamic reloading of protocol module fails
		3 - unexpected application termination (?)
			although TCP can send a RST in this case,
			ICMP should also generate port unreachable (?)

Reloading protocols isn't unheard of (netgraph, etc.). Failure of that
protocol has many consequences, and at some level nonresponsiveness is
its own signal, but softening these signals basically means you are
assuming that protocols don't change once a connection is up. That's a
NEW assumption and should be noted.

	- slower/no reaction to path change
		4 - change in path MTU

> seems to me, at the very least, very weird.

This could indicate a new tunnel, turning on encryption, etc. too. And
path changes happen.

As to the case where ICMP Frag needed should generate a hard error,
consider:
	- simple TCP stack that lacks PMTUD
	- an intermediate device sets the DF bit

I saw that case a few years ago. Changing hard to soft changes reaction
to that event.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Jul 2006 20:22:54 -0300

>                 2,3 - dynamic reloading of protocol module fails

Agreed in the case of protocol unreachable. But for port unreachable, 
the protocol module is there.

>                         ICMP should also generate port unreachable (?)

What I recall is that the idea of making TCP abort connections upon 
receipt of port unreach had to do with accomodating implementation 
that rejected connection requests with ICMP port unreachables, rather 
than with RSTs.

In the case of TCP, only RSTs should be sent. As a matter of fact, 
sending both RSTs and port unreachables could be used by an attacker 
as a bandwidth amplifier.

>NEW assumption and should be noted.

Agreed. In this case, we are limiting the discussion to TCP, though.

>         - slower/no reaction to path change

IMHO, this would kill robustness. In TCP, you implement PMTUD, or 
don't set the DF bit.

>to that event

Well, that seems non-compliant, anyway. Also, for robustness-sake, 
you probably don't have many choices other than keep retransmitting.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2006 22:00:01 -0700

> the protocol module is there.

That depends on what protocol; port unreachable would happen for the
application protocol failure.

> receipt of port unreach had to do with accomodating implementation that
> rejected connection requests with ICMP port unreachables, rather than
> with RSTs.
> 
> sending both RSTs and port unreachables could be used by an attacker as
> a bandwidth amplifier.

1122 allows both. It makes specific statements that the RST isn't a
replacement for the ICMP. It might be OK to say that if a RST is
generated then the ICMP shouldn't be, but that'd be in an 1122
'host-wide' document, not in an ICMP document (which shouldn't discuss
snooping the TCP segments).

You're implying that ICMP port unreachable should never be sent when
there is a functioning TCP (i.e., protocol unreachable is OK, but never
port) - and THAT is your rationale for treating them as soft errors. If
that's the case, then they should be silently dropped, and you are
REALLY changing 1122.

> Agreed. In this case, we are limiting the discussion to TCP, though.

I was talking about TCP - e.g., loading a new implementation of TCP.

> IMHO, this would kill robustness. In TCP, you implement PMTUD, or don't
> set the DF bit.

Or you expect the connection to go down because of the specified
behavior of ICMP. That might allow a host to try a different path,
different endpoint, etc. more quickly.

> Well, that seems non-compliant, anyway.

Based on what? I could find nothing that prohibits a node from setting
the DF bit - that could occur when fragmentation is not desired (fate
sharing over wireless links, e.g.) even though the end system can
support it.

> Also, for robustness-sake, you
> probably don't have many choices other than keep retransmitting.

That's what happens due to your proposed modification. If these errors
are still hard, then the connection goes down and you can recover at the
application layer by trying a different endpoint, different parameters,
etc. - something that might change the path properties.

Joe