Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

From: "Michel Py" <[email-masked]>
Date: Sat, 27 Jul 2002 18:03:02 -0700

> Gregory Lebovitz wrote:
> So the question is whether the router would keel over on the auth
> checks, assuming (1) and > (2) were learned and done successfully.

Yes.

> Alex Zinin wrote:
> Besides, I've heard what people do is rate limit some
> stuff that goes up to the control plane to make sure the
> CPU does not go crazy even if an attack is mounted :)

Definitely something to do, but it has its limitations.
Let's say a router with 10 gbit of aggregated bandwidth routinely
processes 1 gbit of auth checks and begins to choke at 2 gbit of auth
checks. You rate-limit auth checks to 2 gbit.

If an attacker flows you with 3 gbit of useless packets that require an
auth check, it effectively denies half of the traffic that uses auth
checks, as the flow of auth checks would be 4 gbit (1 legit and 3
attacker); out of these 4, half of it would be dropped by the 2 gbit
rate-limit, which includes half of the legit 1 gbit.

On the side, I would say that to me it definitely is in the scope of
this WG to make recommendations such as: "If you use authentication, and
if your router can't handle it a line speed, you MUST rate-limit the
auth traffic to what you router is able to handle."
However, it might be too early for this.

Back to the task at hand, let's try to transform onions into routers.

The combination of the fact that auth checks are required AND that the
router can't process them at line speed has created a situation that
allows the attacker to take 50% of traffic off with 3 gbit of bandwidth,
where it would have needed 10 gbit of bandwidth without auth checks.

In this specific situation, I see three different things:

- A MITM vulnerability has been identified.

1. This vulnerability {MUST NOT | MAY | MUST} be countered by some form
of authentication.

2. If 1. == MUST, routers {MAY | MUST} be able to handle authentication
at line speed.

3. If 2. == MAY, you MUST rate-limit the authentication traffic to the
router's capabilities.

One of the challenges in making these choices would be:
- If MUST is chosen for 1., this tips the scale over the MUST side for
2., which likely includes hardware upgrade or replacements, and I see
router vendors with a smile up to their ears. Is this group ready to
make a recommendation that basically mandates authentication hardware in
each router?

Making these choices require a clear answer on:
- Is the cure better or worse than the vulnerability?
- If it is better, does the gain balance the consequences on the
protocol, which include but are not limited to reduced performance and
greater complexity?

I will finish by the remark that nothing in this post is specific to my
protocol (MHAP); I expect the issues to be the same with any protocol
that has to deal with the same scalability issues I have to.

Michel.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2002 22:39:52 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Michel" == Michel Py <[email-masked]> writes:
    Michel> Definitely something to do, but it has its limitations.
    Michel> Let's say a router with 10 gbit of aggregated bandwidth routinely
    Michel> processes 1 gbit of auth checks and begins to choke at 2 gbit of auth
    Michel> checks. You rate-limit auth checks to 2 gbit.

    Michel> If an attacker flows you with 3 gbit of useless packets that require an
    Michel> auth check, it effectively denies half of the traffic that uses auth
    Michel> checks, as the flow of auth checks would be 4 gbit (1 legit and 3
    Michel> attacker); out of these 4, half of it would be dropped by the 2 gbit
    Michel> rate-limit, which includes half of the legit 1 gbit.

  Unfortunately, your analysis, while correct, is far too simple if you
assume IPsec with symmetric keys.

  1) you have to get SPI#+destination address correct first.
  2) IPsec replay checks occur without any crypto to have occured.
  3) integrity checks (HMAC-MD5) occur next, and may have more bandwidth
     than decryption.
  4) finally, some crypto occurs.

  This means that for a DoS to occur, you have to have a box that can snoop
on the traffic enroute, and within 64-packets (which is a typical window size
for the replay counter), generate the junk that is needed to spam. 
  Not impossible, certainly, but not doable without specialized equipment.

  A DDoS attack is certainly possible, but there is going to be almost as
much traffic flowing from the tap point to the DDoS machines as there is
going to be originating from the DDoS boxes.

  Can you do a DDoS without bothering to get the SPI#/destination address
correct? Maybe. The question is, can a border router keep up with discarding
packets which the wrong SPI#? SPI# is a 32-bit unstructured quantity. So, a
bit harder to lookup than a route entry. 

  Let's say that in a programmable part it requires twice the cycles compared
to a destination address router lookup. A hash table implementation is more
likely than a patricia tree implementation. (nothing to stop one from using
a tree though)
  Hash tables are heurisically better than O(n), but typical case are only
constant better. Pathological case is linear. (n=# of SPIs, meaning that it
is the number of active unique sites that one is communicating with).
  If you have hardware assistance (not as likely), it is likely a CAM (binary
CAM only required), so it will be O(1), just like the destination address lookup will be.   

    Michel> Making these choices require a clear answer on:
    Michel> - Is the cure better or worse than the vulnerability?

  If the trust problem can be solved, then use the crypto.
  If the trust problem can not be solved, do not deploy, the system is too
easily hijacked.

]    Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
][email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto [
]    At the far end of some dark fiber - wait that's dirt!     |for everyone  [

---

From: Charles Lynn <[email-masked]>
Date: Sun, 28 Jul 2002 10:52:36 -0400 (EDT)

>   This means that for a DoS to occur, you have to have a box that
> can snoop on the traffic enroute, and within 64-packets (which is a
> typical window size for the replay counter), generate the junk that
> is needed to spam.
...
>   A DDoS attack is certainly possible, but there is going to be
> almost as much traffic flowing from the tap point to the DDoS
> machines as there is going to be originating from the DDoS boxes.

Wouldn't one only need to get a subset of the sampled packets?

>   Not impossible, certainly, but not doable without specialized equipment.

The specialized hardware could time stamp the sequence number sample
to allow the attacker to "guess" the right sequence number, then use
the special equipment to provide feedback to refine the guess.
Then, one might also have to get the TTL "right".

The attack is probably a lot harder in the wired internet than in
wireless nets.

>   Can you do a DDoS without bothering to get the SPI#/destination
> address correct? Maybe. The question is, can a border router keep up
> with discarding packets which the wrong SPI#? SPI# is a 32-bit
> unstructured quantity. So, a bit harder to lookup than a route entry.

I do not think so.  The typical selectors are src/dst addresses & ports,
and protocol = 104 bits, in the hardware.  For IPsec, one has src/dst
addresses, SPI, and ESP = 104 bits.  ESP even put the SPI bits at the
same packet offset as are the TCP/UPD port numbers.  Thus the needed
hardware is already there, except possibly for a "not" operator.

Charlie

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jul 2002 16:17:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Charles" == Charles Lynn <[email-masked]> writes:

    Charles> Wouldn't one only need to get a subset of the sampled packets?

  Yes, I'm saying "almost" - 1/20th is significant to me. The control load
on the coordinating machine will be high.

  Specifically, one needs to get the SPI#s, replay counters, and valid source
addresses. 

  The DDoS clients need to make sure that they go at the same speed. That's
going to take at least a control packet every 20 or 30 packets. 

  Otherwise one will get ahead, and the window will close on the other
senders, rendering their attacks easy to fend off.

    Charles> The attack is probably a lot harder in the wired internet than in
    Charles> wireless nets.

    >> unstructured quantity. So, a bit harder to lookup than a route entry.

    Charles> I do not think so.  The typical selectors are src/dst addresses & ports,
    Charles> and protocol = 104 bits, in the hardware.  For IPsec, one has src/dst

  Those are the selectors for entry into the tunnel/SA.
  We are attacking the decryption end of the tunnel, from the outside.

  If RFC2401bis makes the SPI# independant of all other fields for unicast
senders, and many implementations already keep the SPI# space unique per
machine, so why mention the other bits?

    Charles> addresses, SPI, and ESP = 104 bits.  ESP even put the SPI bits at the
    Charles> same packet offset as are the TCP/UPD port numbers.  Thus the needed
    Charles> hardware is already there, except possibly for a "not" operator.

  Yup. The hardware is probably already there.