Subject: [Mip6] review of draft-dupont-mipv6-3bombing-00.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 03:35:15 +0200

Hi Francis,

And thanks for writing this draft. I think we need it.

I pretty much agree with all that you say in the draft. I think
prohibiting alternate care-of address option is a good idea,
and it should be studied further.

I'd like to expand a little bit on what you say in under
2.3 regarding route optimization.

As you have pointed out, anyone can spoof the source address
of a TCP SYN packet, so we generally can not worry too much
single request - single response attacks. Except where mechanisms
to defeat ingress filtering are provided, which you also mention.

As Christian pointed out in his e-mail explaining the security
background for early binding updates, and is also discussed in
Section 2.5 of [1], we also need to consider the possible
amplification factor. The problem with bombing attacks in the
RO case is using first a right address, getting to see TLP sequence
numbers so that fake acks can be sent, and then moving
the stream to the victim's address. This can be devastating,
at least under some conditions. The difference to a regular
TCP SYN spoofing is that you actually get to see some
inital part of the traffic, which may make things easier
for the attacker. Having said this, [1] notes that different
TLPs and different TCP implementations behave in different
ways regarding this attack. It might be useful to shed
some further light on this, to figure out exactly how
serious (or not) this attack is.

There is a related issue that has to do with the level
of ingress filtering support in the Internet. We have
more or less accepted the situation where this support
is not universal. So, we can assume that we can be targets
of e.g. spoofed TCP SYNs or reflected packets. I would
not like to make this any worse by making it possible to
be a victim of a stream of packets.

Comments?

--Jari

[1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Feb 2004 11:21:28 +0100

In your previous mail you wrote:

   
=> for multiple responses either the transport implementation is very buggy
and the attacker can guess what it has to put in fake acks, or the
attacker is on the return path and can look at responses.
I have a real concern about reflection attacks: they seems to be easy
(i.e., no effective defense) when the attacker is closed to the victim,
for instance on the same link.

   the stream to the victim's address.

=> the amplification factor is very limited: a window plus some
retransmits. IMHO it is more efficient for the attacker to use more
reflectors, and this does not reveal anything about the position of
the attacker.

   This can be devastating,
   
=> I don't believe in this attack because it does not give something
against the real defense, i.e., against the ingress filtering, and
of course it reveals many things about the attacker.

=> IMHO the important thing is to introduce *no* new ways to bypass
the ingress filtering or any efficient defense against (D)DoS attacks.
And I believe this is the case of optimized RO schemes when fake
alternate care-ofs are forbiden.

Regards

[email-masked]

---

From: Mark Doll <[email-masked]>
Date: Mon, 16 Feb 2004 14:28:02 +0100

On Mon, 16 Feb 2004 11:21:28 +0100

> reflectors, and this does not reveal anything about the position of

There's an important difference between traffic that the CN sends after
an Early Bindung Update compared to the traffic it sends in a reflection
attack due to a faked source address: All packets carry a type 2 routing
header revealing the home address of the attacker to the host under
attack.

Regardless how many CNs an attacker uses for his attack, they all insert
the same home address in the routing header---and the home address has
been checked via the HoTI/HoT messages. So the attacked host knows for
shure who attacks him and the only advantage an attacker gains through
misusing EBUs is the amplification factor, IMHO.

To close this last security gap, the CN should implement a scheme
limiting the amount of data it sends after an EBU and before a fully
authorized BU to the amount of data traffic is has sent to the old CoA
in the last few seconds before the EBU (or maybe to twice of the
amount).

Regards,
	Mark.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Feb 2004 15:16:13 +0100

=> I have another simple suggestion: close the congestion window,
i.e., behave on hand-off of the peer as a packet was lost...

---

From: Mark Doll <[email-masked]>
Date: Mon, 16 Feb 2004 17:02:04 +0100

On Mon, 16 Feb 2004 15:16:13 +0100

> i.e., behave on hand-off of the peer as a packet was lost...

This does not work for UDP streams.

Thinking of TCP, I suppose some packets will always be lost during a
handover---as long as we do not use something like an anticipated
handover starting from the old care-of address with all its security
implications. So TCP will go through slow start anyway. And beeing able
to force TCP into slow start means that we intermix layers. Is this a
good idea? (*)

Mark.

(*) This is not a rhethorical question. I've just never been thinking
about the pros and cons.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 16 Feb 2004 11:41:05 -0800

Hello folks,

I would also hope to avoid any TCP-specific solution.

Regarding slow-start:

Mark Doll wrote:

> Thinking of TCP, I suppose some packets will always be lost
> during a handover

This is not true.  With a simple context transfer approach
that includes redelivery of (approx. 2) redundantly buffered
packets, we can get terrific performance for voice.  With a
few more buffered packets, probably video.

The determiniming factor, is how long is required for the
reassociation to finish.  That can take a long time with
today's products, but it doesn't absolutely have to.

>            ....                            And beeing able
> to force TCP into slow start means that we intermix layers.
> Is this a good idea?

Basically, no.

There has been a lot of discussion about cross-layer design
recently.  I think it should be reframed as enabling one
layer to acquire relevant information that _may_ be more
efficiently provided by another layer.  I think it's a much
better way for sane and simple designs to result.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Feb 2004 14:45:37 +0100

=> it should work with congestion controlled streams.

=> if some packets will always be lost the answer is yes, if this
assumption is false no, but in any case as the path has changed
something should be done, i.e., upper layers should get the "hand-off"
event. BTW in experiments I saw very different behaviors between
TCP connections with different profiles (for instance telnet (interactive)
and FTP (bulk transfer)) so IMHO it's worth our attention.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Feb 2004 14:52:51 +0100

=> but IMHO you believe in the usefulness of congestion control (:-).

   Regarding slow-start:
   
=> this was more a slow-restart.

   
   
=> in this case you don't send a RR/RO signaling to the CN,
i.e., I agree but your argument doesn't apply.

=> this has been more about layer 2 / layer 3. In the case
we are talking about something should be done, perhaps not
what I proposed in addition to limit the sending buffer...

Regards

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Feb 2004 09:31:28 -0800

> to force TCP into slow start means that we intermix layers. Is this a

Doesn't have to be the case if something like FMIP is used.

            jak