Subject: [mobile-ip] Unverified HAO Processing - Recommendation note

From: [email-masked]
Date: Mon, 4 Mar 2002 16:35:01 -0600

Hello,

The following writeup provides a recommendation for unverified HAO 
processing by CNs. In order to gauge consensus from the WG, we
would like feedback from WG members by 5 PM Thursday of March 
7th, 02.

-Basavaraj

--------------------------------------------------------------------------------------------------

                 Unverified HAO Processing

          Rajeev Koodli, Jari T. Malinen and Charles E. Perkins

This note specifies the author's motivation and current
position. In order to move forward in an efficient manner it
would be beneficial if responses could make it clear they are
- a clarification (by putting CLARIFICATION: in the Subject
   field)
- an issue with a particular point (by ISSUE:)
- disagreement with the conclusion (by CONCLUSION:)

We would also like folks to state for the recommendation whether they
AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE,
please explain why. 

1. INTRODUCTION
===============

The IPv6 specification [1] requires that every IPv6 node
process the Mobile IPv6 Home Address Option (HAO) [2]. In the
recent analysis of Mobile IPv6, concerns were raised that such a
processing without verifying if the sender actually owned the Home
Address (HoA) could lead to certain security vulnerabilities
[3]. As a consequence, the unverified use of HAO has
not been recommended in the design team recommendation. In this
document, we describe a mechanism that allows a CN to process
unverified HAO as it is currently specified using some implementation
extensions. 

There are two concerns regarding the unverified use of HAO. First, any
node (attacker) may use a CN as a reflector to send packets to one or
more victims without being traced, since the CN's response is sent to
the HoA with the CN's IP address as the source IP address. This is the
traceability problem. As a matter of comparison, if a such a DoS
attack were to happen today, the source IP address in the unsolicited
packet would be the (typically spoofed) IP address of the
sender. Second, as a response to prevent such attacks, source ingress
filtering is used to block certain packets. With HAO, such a mechanism
cannot readily be used. The solution proposed here requires a CN to
include the source IP address of the packet in a response message from
the CN. This allows the owner of the HoA to determine, from the ``tag''
present in the packet, the true originator that caused the CN's
response. It thus provides traceability. Furthermore, a firewall 
filter can be set up to scan for the tag (i.e, the IP address of the
node causing the CN's response) and apply appropriate filtering rules.
Thus, it allows blocking of undesirable packets. 

We use the following acronyms in this document.

BC: Binding Cache
BCE: Binding Cache Entry
BR: Binding request
BDT: Bidirectional Tunneling
GN: A Generic IPv6 Node not using Mobile IPv6
HAO: Home Addess Option
HoA: Home Address

2. SOLUTION OVERVIEW
====================

The basic protocol is described by the following;

1. Packets arriving with HAO initiate tagging by creating an entry in 
   the unverified Binding Cache (BC) that the CN maintains. As a
   data structure, the unverified BC contains HoA and CoA (i.e., the
   sender's IP address). If an entry cannot be created,
   e.g., due to finite storage, then the CN sends a Binding
   Request (BR) indicating that the MN should use either RO or
   Bidirectional Tunneling (BDT). 

2. Packets arriving at the CN's address without HAO but with HoA as
   source IP address remove an existing entry. Care must be taken not
   to remove an entry when the MN reverse tunnels certain (e.g.,
   multicast) packets. For this, the following rule would apply.

            if (srcIPaddr == HoA)
               if (dstIPaddr != CN's IP addr)
                  do not remove tag from unverified BCE

3. If packets arrive with erroneous tags, a Home Agent drops those
   packets. It may optionally send an ICMP destination unreachable
   message in which it includes the correct tag (i.e., the correct CoA
   from its BC) that updates the unverified BCE. Meanwhile, any packet
   from the genuine MN with an HAO would also correct the CN's
   entry. On the other hand, the HA tunnels packets with correct tags
   to the MN. 

3. UNVERIFIED HAO OPERATION
===========================

When it receives a packet with HAO, if there is no entry in
its Binding Cache (BC), the CN inserts the source IP address (CoA) in a
small cache called unverified BC. When a packet needs to be sent to
HoA, the CN tags the packet with this CoA. This is the basic
idea. There are multiple ways in which the unverified BC can be
implemented. Indeed, it can be part of the normal Mobile IPv6 BC with
an appropriate attribute indicating that the tagged entry is
unverified. So, when the CN scans the BC, it would know exactly which
entry to tag and which one not to tag. It has also been suggested in
the mailing list that the unverified BC could be implemented as an
extension in a node's destination cache.

The operation when the CN is communicating with a MN is already
described by the above rules. So, we consider the scenario involving a
Generic IPv6 Node (GN). 

Consider the case where an attacker binds any GN's
address to a bogus or genuine CoA. 

a) When there is no on-going traffic between the CN and the GN;
   - the CN may send packets to the GN with a tag without the GN
     expecting them. The GN's response (TCP Ack, RTCP, etc) would
     wipe out the tag. 
   - the GN itself may initiate a session to the CN, in which case,
     there is no tagging in the CN's response.
   - if the GN's site is configured to filter packets containing
     the tag, those packets will be dropped. Since the unverified
     BCE needs refreshing, the entry will expire unless the 
     attacker keeps updating the entry. In any case, This is similar
     to receiving unsolicited packets in today's Internet. The
     presence of the tag however, allows traceability. 

b) If there is on-going traffic, the CN would start tagging packets
sometime during the session. 
   - if tagged packets reach the GN, there is no harm other than the
     tag overhead itself; the GN may simply ignore the tag and process
     the rest of the packet. Any packet transmission from GN to CN
     will force the CN not to tag. 
  - if an entity such as a firewall discards packets with the tag,
     then the traffic from CN to GN would be ``disrupted''. However,
     the tag disappears when the CN receives a packet from GN (without
     HAO) or if the lifetime of the tag expires whichever is earlier.
     
     Only when the GN is a ``one-way listener'', and the firewall
     is configured to discard such packets, is there a possibility
     to disrupt the traffic up to a maximum of the lifetime of the
     unverified BCE.  For this reason, we suggest a relatively short
     lifetime.

4. CN IMPLEMENTATION
====================

What follows is one possible way to implement the protocol on the
CN. There are others.

The CN state machine has two states. In the ``tagging'' state, there
is a tag present for the destination address (HoA) in the unverified
BC and hence the CN tags outgoing packets to that address. In the
``no-tagging'' state, there is no tag present for the HoA, and hence
the CN does not tag the outgoing packets to that address. Note that if
there is no entry corresponding to the destination address, there is
no Mobile IPv6 specific action required. 

The CN state machine can be descibed by the following diagram.

T1 and T2 are two different timers, initially set to zero.

                    ------ (until T2 expires)
                    |    |  
                    |    V
                  ----------    T2 expires
                  |   no   |----------+
                  |tagging |          |
                  |        |          V
                  ----------       ---------
        packet with ^              |       |
     srcIPaddr=HoA  |    +---------| start |
                    |    |HAO pkt  |       |
                    |    V         ---------
                  ----------           ^
                  |        |           |
                  |tagging |-----------+
                  |        |    T1 expires
                  ----------
                    ^    |
                    |    |  
                    ------ (until T1 expires)

1. The CN begins in the ``start'' state. If it receives a packet with
HAO, it moves to tagging state. If it does not, there is no special
action required. It moves back to ``start'' state from ``(no)tagging''
state if timer (T2)T1 expires.
 
2. When in tagging state if it receives a packet without HAO but with
HoA as the source IP address, and CN's address as the destination
address, the CN transitions to no-tagging state. However, if the
destination address in the received packet is 
not the CN's address (a multicast address for example), then it
remains in the tagging state. When it makes a transition
from tagging to no-tagging state, it remains in that state until a
randomized ``standby'' timer (T2) expires. 

3. When in no-tagging state, the packets without HAO are processed
normally. Those with HAO are silently discarded. When timer T2
expires, the CN moves to start state where it will start accepting
packets with HAO.

The net effect of this behavior is that when there is an attempt to
introduce a tag maliciously, there is quick repair and longer timeout
before the tag can appear again; on the other hand, if a MN moves away
from home and starts using HAO, those packets would be tagged
rightfully. The special case when the MN uses HAO for some packets but
reverse tunnels others is handled by the rule specified in Section 2.

The entries in the unverified BC may be subject to garbage
collection. When doing so, removing the active entries is not
recommended. In particular, if the CN is in no-tagging state with
T2 being non-zero, removing such an entry would mean that the CN
transitions to start state where it would accept HAO packets (as
opposed to disallowing HAO packets until T2 expires).

The typical values for both T1 and T2 are in seconds. The values for
T1 and T2 should be chosen based on the following guidelines. Note
that if an attacker introduces a spurious tag in the on-going
communication between the CN and the GN, then those tagged packets may
be dropped by a firewall. While the CN transitions immediately back to
no-tagging state upon receiving a packet without HAO from GN, in order
to reduce the number of potential packet losses in case the GN does
not send packets (while packets are being dropped by its firewall) to
CN, the value chosen for T1 should be short, 
perhaps of the order of few seconds. At the same time, the value
chosen for T1 should be sufficiently larger than the inter-packet
times so that the CN resides in tagging state long enough for a
genuine MN. We recommend using 4 seconds for T1. 
On the other hand, the value chosen for T2 should disallow introducing
a spurios tag by an attacker. Thus, this value should be relatively
larger, perhaps of the order of 10's of seconds. Note that a MN should
not force a CN to enter no-tagging state unless it is returning
home. The reverse tunneled packets do not make the CN enter no-tagging
state.

The state machine is summarized in the following table.

State           Event    ->  New state         Action

 start          non-HAO   -> no state change      -
 start          HAO pkt   -> tag,              start T1
 tag            HAO pkt   -> no state change,  update T1
 tag         T1 expires   -> start,               -
 tag           non-HAO    -> no-tag,      start T2, reset T1
no-tag          HAO       -> no-tag,      drop packet
no-tag       T2 expires   -> start,               -
no-tag          non-HAO   -> no state change,     -

5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING
=================================================

A MN may wish to simultaneously use, for whatever reasons, both HAO
and reverse tunneling. If a MN needs to use reverse tunneling while it
is using HAO, it should use HAO on those packets that it reverse
tunnels. Not doing so _could_ make some of its HAO packets to be
dropped, i.e., those HAO packets that arrive when the CN is in
no-tagging state. The exact number of packets that might be dropped
depends on, among other things, the holding time in no-tagging state,
and the likelihood of MN generating packets with HAO while the CN is in
no-tagging state. 

5. RECOMMENDATION
==================

It appears that with the proposed mechanism, the concerns raised
regarding the unverified HAO processing can be effectively
addressed. While the proposed mechanism may not be perfect, it
offers disincentives for an attacker to do harm and provides
sufficient correcting ability for a genuine node so that any potential
disruption can be quickly repaired. 

Recommendation R1 : We recommend that unverified HAO processing be
done according to the rules specified in Section 2. 

ACKNOWLEDGMENTS

The table for CN state machine is a result of a thorough review from 
Erik Nordmark.  

REFERENCES

[1] S. Deering and R. Hinden, ``Internet Protocol, Version 6 (IPv6)
    Specification'', RFC 2460.

[2] D. Johnson and C. E. Perkins, ``Mobility Support in IPv6''
   draft-ietf-mobileip-ipv6-15.txt, work in progress

[3] Mobile IPv6 Design Team, ``Home Address Option: design team
    recommendation'', Mobile IP mailing list, February 12, 2002.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Mar 2002 00:33:45 +0100 (CET)

Rajeev,

>    entry. On the other hand, the HA tunnels packets with correct tags

I don't understand what problem this part is solving.
It seems to mandate that Home Agents (a kind of routers) inspect the
content of the packets they forward into a tunnel to a MN, which isn't
good for performance.
The ICMP error to "correct" the tag seems a bit odd, since the reason
the tag has a particular value might be because an attacker is sending
packets with a HAO but with a different CoA ( = IP source address)
than the MN is using so I think you want to keep that "bad" tag and not
"correct" it.

>      unverified BCE.  For this reason, we suggest a relatively short

ISSUE: I think this is an understatement of the problem since this
issue appears e.g. with normal TCP connections and not just one-way listeners.
If the CN is sending TCP data segments and those do not reach the MN due
to the tag and firewall, the the MN will not send any TCP ACK segments
that will remove the tag.

> 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING

When an MN does this I assume it will send packets using triagular routing
with
	source = CoA, HAO = HoA
and using reverse tunneling with
	source = HoA, HAO = HoA
since the IP source address must be topologically correct.
Did I understand this correctly?

In that case what will the tags contain - the source address for the 
most recently received HAO packet?

What about an attacker than injects a packet with
	source = X, HOA = HoA
while the MN is using triangular routing. The writeup doesn't say
for how long time the tag would contain X vs. the original CoA.
If there is a significant rate of triagular packets from the real MN
I think an attacker might be able to "hide" its packets depending on
the details of how the tag value is replaced.
So I think those rules need to be understood to analyze this further.

  Erik

---

From: "Nitin J. Khanna" <[email-masked]>
Date: Mon, 4 Mar 2002 18:45:36 -0500

Hello,
	 I have recently graduated with a BS degree in Comp Eng and am a new
subscriber to this list. I am currently involved in implementing wireless
(802.11b) networks. I would like to contribute to the mobile-ip community
and in turn get a lot of valuable knowledge. 
Can someone please direct me such that I can come upto speed on the projects
being discussed on this list and corresponding goals to be achieved.

thanks,
Nitin J. Khanna

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 04 Mar 2002 17:54:54 -0800

Hello Erik,

thank you for your comments.

> content of the packets they forward into a tunnel to a MN, which isn't

The MN is isolated from the receipt of packets with spurious tags. In this
sense, the Home Agent offers filtering ability. On the other hand, the
protocol still works fine without assistance from the Home Agent.

> than the MN is using so I think you want to keep that "bad" tag and not

That's possible if a CN is able to tell the difference
between an attacker, a MN and an HA. Since the ICMP error is sent by
the HA, the CN could make use of the message to both keep the
``bad'' tag for diagnostics and correct the entry as well.

> that will remove the tag.

There are two cases a) and b) considered in Section 3, of which a) addresses
this aspect. When there is no on-going traffic between CN and GN, and if a
CN tags packets, those packets _may_ get dropped depending on the firewall
filter. However, since the timer for tagging state is shorter, no response from
GN would make CN to revert to start state.

> Did I understand this correctly?

Yes.

> most recently received HAO packet?

If source = HoA and HAO = HoA, the CN neither updates the tag
not does it remove the tag. This needs to be specified as such in
the document.

> for how long time the tag would contain X vs. the original CoA.

Since the CN cannot distinguish between the attacker and the MN,
it updates the tag right away. This is fairly obvious and thus I did not
add any text on this..However, those packets still reach
the Home Agent and the HA could correct the CN's entry. One
thing that might be useful to consider is that instead of dropping the packet
containing X as a tag, the HA may tunnel that packet also
to the MN. So, the MN always receives packets from the CN.

> the details of how the tag value is replaced.

An existing tag is updated right away if the CoA is different. So,
an attacker's source address is seen in the next outgoing packet
from the CN.

Regards,

-Rajeev

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Mar 2002 10:22:56 +0200 (EET)

be some misunderstandings.

High level view: is this intended as a completele replacement of the
current mechanism?  If HAO is authenticated, would it be ok to pass it as
before?

Another high level view: this *seems* to make DoS more traceable [however,
I'm not sure if significant enough numbers of vendors ever log the tag,
and the only way to get it would be to capture the packet and decode it
from hex].  However, this doesn't address the problem of being able to
send e.g. reflected UDP exploits (sure, there's a tag there but does a
script-kiddie care?).

> 2. SOLUTION OVERVIEW

Am I missing something blatantly obvious, but why wouldn't the simpler 
approach work?:

 if (dstIPaddr = CN's IP addr)
   if (srcIPaddr == HoA)
     remove tag 

I think this satisfies the rules above, *AND* more importantly, can be 
really implemented -- the proposed solution seems awfully intrusive to me
(must add checks like that in the forwarding path, probably) -- it seems 
much better to check for destination first. 
 
>    from its BC) that updates the unverified BCE. 

Would Home Agent revealing mapping between Home Address and CoA be 
counter-productive: there might be reasons to keep this secret from the 
prying eyes?  Did I miss something?

> small cache called unverified BC. 

You make an assumption that there is a BC in every CN.. that may not
necessarily be the case...

[skip the actual implementation etc.]

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Mar 2002 09:46:31 +0100 (CET)

> ``bad'' tag for diagnostics and correct the entry as well.

My point is that the ICMP error to "correct" the tag will make it impossible
to trace the attacker.
Suppose the CN gets HOA packets from the MN (src = CoA)
so that it is in tagging state.
Then packets arrive with the right HoA but with src = X.
This presumably (writeup isn't clear) causes the the CN to change the tag
in the unvHAO entry so say "tag with X".
Thus the HA or MN can tell that something is odd because of the tag not
being the CoA.
But if the HA "corrects" this so that the CN will tag with the CoA
then you are effective allowing the attacker to circumvent ingress
filtering and use the CoA as the source i.e. the victim MN can't tell
that the reflected packets originated from X any more.

So I don't think the CN can "correct" the entry since that would remove
the traceability.

> filter. However, since the timer for tagging state is shorter, no response
> from GN would make CN to revert to start state.

I agree that the timers limit the time of any black holes.
But my issue was with the description of the problem being limited
to one-way listeners when the problem in fact applies to things like
TCP uni-directional data transfer.

> not does it remove the tag. This needs to be specified as such in

OK - makes sense.

> containing X as a tag, the HA may tunnel that packet also to the MN. So, the
> MN always receives packets from the CN.

See above why you can't have the HA correct the tag at the CN.

It seems like the CN always need to take the most recent received 
HAO value (with the above exception for source = HoA and HAO = HoA)
and use that to tag outgoing packets.

But this would make it possible for an off-path attacker, which can send at
least as many packets per second as the MN, to prevent any packets from
making it in the reverse direction by sending packets with HAO and src=X -
with high probability the tag entry would contain X and not the CoA.

Am I missing something?

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 05 Mar 2002 10:26:23 -0800

> in the unvHAO entry so say "tag with X".

Right. For the same HoA, if there is a new CoA, that could be
because the MN moved. The CN updates the tag right away.

> Thus the HA or MN can tell that something is odd because of the tag not

Right. That's the idea.

> that the reflected packets originated from X any more.

I meant when the CN receives the ICMP error, it can potentially log
the existing tag entry and then correct it with what the HA sent. But,
I agree with you that doing both has its overhead; extra storage for the
bad tag. Also, from a protocol perspective, it is not necessary that the
tag is a `good' one; of course I would like it be a good one :-)

> TCP uni-directional data transfer.

Ok.

> with high probability the tag entry would contain X and not the CoA.

Let's see what is the effect.

- what is in the tag is less important compared to the presence of tag itself.
    So, packets should not be dropped because tag=X.
   Having said this, what is in the tag is important for diagnostics.
- if the CN sends an unsolicited packet because the attacker initiated
    a response, that response would contain the tag. So, there is traceability
- if the CN is responding to the MN's packets, but includes tag=X, what's
   the harm ? The MN (or the HA) can find out that someone is attempting
   to use the MN'a HoA. The packet as such is fine; in fact, it has important
   traceability information.

So, an attacker cannot disrupt the flow to a MN. Hope this is useful..

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Mar 2002 20:10:45 +0100 (CET)

>    Having said this, what is in the tag is important for diagnostics.

I think the content of the tag is important for traceback reasons
as well as for filtering reasons at a HA.

For instance, if an attacker sending packets with src=X and HOA=HoA
can cause packets to be reflected from the CN with dst=HoA, src=CN, tag=CoA
then it is as if the attacker had managed to send a packet
with src=CoA, HOA=HoA. The purpose of this exercise is to at least be
able to trace such cases in order for the MN (or HA) to get the value X
i.e. to know the IP address of the attacker.

>     a response, that response would contain the tag. So, there is

That assumes that the MN doesn't send packets to the CN with such timing that
the unvHAO cache entry always contains tag=CoA when the CN sends packets
(and never tag=X when the CN sends packets).
This is hard to predict since it depends on the timing patterns
of the application and transport protocols as well as the ability of the 
attacker to predict those patterns.

One way of trying to capture this is by asking a question about the 
requirements.

Imagine that P percent of the packets arriving at the CN have
	src=X, HOA=HoA
and 100-P percent have
	src = CoA, HOA=HoA
Then what is an acceptable range of percentage of packets sent
by the CN that have tag=X? (Call this value Q)
Is zero ok? Is close to zero ok? Should it be same order of magnitude as P?
Is 100% ok?

>    traceability information.

For one thing your writeup says that the HA is free (should?) drop such
packets.
If P is 10% then if Q becomes 100% then the off-path attacker has managed
a DoS attack against the MNs traffic.
If P is 10% makes Q become 0% then the off-path attacker has managed to do
undetectable reflection attacks.
 
> So, an attacker cannot disrupt the flow to a MN. Hope this is useful..

See above.

I think requiring that the HA pass packets indepedent of the tag value (i.e.
the tag value is purely for traceability) at least doesn't cause
problems in the case when Q becomes 100%.

   Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 05 Mar 2002 12:04:31 -0800

Erik Nordmark wrote:

>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think we are saying the same thing.. Note that I didn't say the
content of the tag is not important.

> i.e. to know the IP address of the attacker.

Couldn't agree more, never has disagreed.

> attacker to predict those patterns.

Actually, there is no such assumption. In any case,

- if the MN did not send any packets, CN's packets will contain tag=X.
- if the MN did send packets, tag=CoA

> Is zero ok? Is close to zero ok? Should it be same order of magnitude as P?

I don't know what you are trying to convey here..

- if tag=X, you know someone is trying to introduce a spurious tag.
- _if_ it so happens that you never see tag=X, the attacker has not succeeded
    in actually introducing the spurious tag
- if some packets contain tag=X, others contain tag=CoA, that's still ok; i.e.,
   there is no disruption.

Am I missing something here from a protocol perspective ?

> For one thing your writeup says that the HA is free (should?) drop such

In a previous e-mail, I did mention that we should consider HA tunneling
all packets regardless of the tag value. See below.

"Since ..... One
thing that might be useful to consider is that instead of dropping the packet
containing X as a tag, the HA may tunnel that packet also
to the MN. So, the MN always receives packets from the CN."

> a DoS attack against the MNs traffic.

This cannot happen when the HA tunnels all packets.

> undetectable reflection attacks.

For Q to be 0%, there has to be correcting operation, meaning packet flow
from the MN in such a manner that it exactly coincides with removing every
single tag=X, something you have expressed your own reservations above in
"That assumes that the MN doesn't send packets to the CN with such timing that
the unvHAO cache entry always contains tag=CoA when the CN sends packets
(and never tag=X when the CN sends packets).
This is hard to predict since it depends on the timing patterns
of the application and transport protocols as well as the ability of the
attacker to predict those patterns."

> problems in the case when Q becomes 100%.

I did mention this in a previous e-mail. Looks like it is good thing to specify
the HA to tunnel all packets.

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Mar 2002 21:59:17 +0100 (CET)

> - if tag=X, you know someone is trying to introduce a spurious tag.

Or trying to use the CN as a reflector for DoS purposes.
This is fine in the sense that it is observable by the MN (or HA) - they
can see the value X.

>     in actually introducing the spurious tag

Introducing a spurios tag isn't the original security problem we tried to
address, but a security problem which appeared in earlier versions of
your proposal.
The original security problem is reflection attacks using HAO that can
 - not be prevented using ingress filtering
 - not be detected

Thus my issue is about the original security problem.
What if the all packets arrive at the HA and MN with tag=CoA but the 
attacker X is in fact injecting 10 Mbps per second of packets (with
src=X, HAO=HoA) that get reflected to the poor MN (all with tag=CoA).
See below for examples.

> - if some packets contain tag=X, others contain tag=CoA, that's still ok; i.e.,

Yes, as long as you remove the suggestion that says:
3. If packets arrive with erroneous tags, a Home Agent drops those
   packets. It may optionally send an ICMP destination unreachable
   message in which it includes the correct tag (i.e., the correct CoA
   from its BC) that updates the unverified BCE. Meanwhile, any packet
   from the genuine MN with an HAO would also correct the CN's
   entry. On the other hand, the HA tunnels packets with correct tags
   to the MN. 
and instead require the HA and MN to process packets indepedent of
their tag value.

When the CN receives a mix of packets with src=X,HAO=HoA and src=CoA,HAO=HoA
it will hopefully mark a mix of packets with tag=X and tag=CoA
(and we need to figure out to ensure that at least some packets have tag=X
for traceability).

My point is that the tag value can't be use to filter out the bad
packets because there will not be any correlation between
the src of a packet received at the CN and the tag value of the response
to that packet when there are multiple packets in progress.

For example, if the attacker sends TCP SYN packets packets while the 
real MN is doing VoIP with the CN we could have this time line at the CN:
	src=CoA,HAO=HoA VoIP UDP packet received by IP
		tag value set to CoA
	src=CoA,HAO=HoA VoIP UDP packet received by IP
	src=CoA,HAO=HoA VoIP UDP packet received by IP
	src=X,HAO=HoA tcp syn port 80 received by IP
		tag value set to X
	VoIP UDP packet sent by IP - gets tagged with X
	VoIP UDP packet sent by IP - gets tagged with X
	VoIP UDP packet sent by IP - gets tagged with X
	src=CoA,HAO=HoA VoIP UDP packet received by IP
		tag value set to CoA
	TCP SYN ack sent by IP - gets tagged with CoA
	<repeat>

In the above extreme example the "good" packets all the get the "bad" X tag
and  the reflected attack packets get the "good" CoA tag.

Thus the HA and/or CN can't use the tag value to filter out the reflected
packets.

Reordering the packets in the above example we can also get
	src=CoA,HAO=HoA VoIP UDP packet received by IP
		tag value set to CoA
	src=CoA,HAO=HoA VoIP UDP packet received by IP
	src=CoA,HAO=HoA VoIP UDP packet received by IP
	src=X,HAO=HoA tcp syn port 80 received by IP
		tag value set to X
	src=CoA,HAO=HoA VoIP UDP packet received by IP
		tag value set to CoA
	VoIP UDP packet sent by IP - gets tagged with CoA
	VoIP UDP packet sent by IP - gets tagged with CoA
	VoIP UDP packet sent by IP - gets tagged with CoA
	TCP SYN ack sent by IP - gets tagged with CoA
	<repeat>

Thus none of the packets get tagged with X. This means that the HA and/or MN
can't even tell that they are subject to a DoS reflection attack using the
content of the tags. 

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 05 Mar 2002 19:22:02 -0800

Hello Erik,

> address, but a security problem which appeared in earlier versions of

A spurious tag means the attacker introduces his source IP address. There is
no security problem with it.

> src=X, HAO=HoA) that get reflected to the poor MN (all with tag=CoA).

It is a good "what if". If the attacker is injecting at the rate you mention,
I don't see how even a small percentage of packets do not contain tag=X,
and hence get traced.
I will wait for your examples..

> and instead require the HA and MN to process packets indepedent of

I don't know why this is still lingering..

- in an earlier e-mail I said the HA tunneling all packets is a good thing
- in my previous e-mail I said such a specification would be a good thing.

Did I indicate any reservations otherwise ? In any case, please note that I have
already agreed to this (after proposing it even earlier).

> (and we need to figure out to ensure that at least some packets have tag=X

You didn't respond to your own observation in the previous e-mail.

> to that packet when there are multiple packets in progress.

If the tag!=CoA, you know there is an attempt to use HoA. If your
argument is against using filtering, that's valid. Please also
specify where in the current text you would like this to be noted.

> Thus the HA and/or CN can't use the tag value to filter out the reflected

Ok. I am willing to include this "extreme example" in the document. You
can still ascertain that there is an attempt to cause reflection attack.

> can't even tell that they are subject to a DoS reflection attack using the

In this particular case, you cannot determine the source of TCP SYN. Here is a
way to resolve this: the CN must `commit' a new update only after sending at least
one packet with the existing tag!  A counter is set to one (or some small integer to

account for packet losses) when a new CoA (such as X) is received. When the MN's
VoIP packet is received, its CoA does not replace X until the counter is zero. The
counter is decremented every time an entry is tagged.
Downside: extra storage for another address. Still does not necessarily provide
the ability to put the bad tag on the bad packet. However, it provides the alarm
ability.

-Rajeev

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 06 Mar 2002 10:05:42 +0200

> (and we need to figure out to ensure that at least some packets have tag=X

This is an observation that makes me to think that using any
kind of cache for tagging is going to be very very hard.  In fact,
it looks like getting tagging "right", i.e. each packet is tagged
with exactly the source address that triggered its sending, is
impossible with caching techniques.  Changing the API, as we discussed
earlier, seems to fix the problem, and make tagging possible.

These observations lead me, personally, to the opinion that we should
make triangular routing and tagging an option.  It looks like it will
be extremely hard to require this from all CNs.  Indeed, it looks
much easier to require RR based RO from all CNs than this HAO
prosessing and tagging support.

As an option this seems to be fine, though, since the
problems are related to local implementation at the CN, not
the method as such.  That is, *assuming* that the CN does
tagging exactly correctly, it does not seem to open up new
security problems.  The hard part is getting the tagging
implemented correctly.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Mar 2002 10:34:40 +0100 (CET)

> Did I indicate any reservations otherwise ? In any case, please note that I
> have already agreed to this (after proposing it even earlier).

The reason I brought it up this time was that it would seem useful
for the HA to be able to filter such reflected DoS packets as you had
originally suggested. But the behavior of the tagging doesn't allow it.
Sorry for not making this clear.

> You didn't respond to your own observation in the previous e-mail.

Was I supposed to respond to myself?

> "That assumes that the MN doesn't send packets to the CN with such timing
> that the unvHAO cache entry always contains tag=CoA when the CN sends packets
> (and never tag=X when the CN sends packets). This is hard to predict since
> it depends on the timing patterns of the application and transport protocols
> as well as the ability of the attacker to predict those patterns."

> specify where in the current text you would like this to be noted.

I'm sufficiently confused by what problem we are trying to solve here
to not be able to suggest text.

Is the only problem we are trying to solve the ability for the MN/HA to tell
that it is likely under a reflection attack? It seems like it could tell
that e.g. by observing all the SYN ACK packets in my example.
Or are we also trying to give the MN/HA the tag(s) associated with the
attackers so that they could try to convince entities between the CN
and those attackers to filter out those packets?
(As already pointed out no filtering can be done between the CN and HA
on the tag content.)

It would be useful to agree on the goals before proceeding.
The goals of the DT proposal was "do no harm" i.e. don't open up new ways
that an attacker can circumvent prevention measures like ingress filtering
as well as not making it harder to detect/traceback the attackers.
As far as I can tell the goals of the unvHAO proposal are different, but
I don't have a good handle on exactly what the security goals are here.

> In this particular case, you cannot determine the source of TCP SYN. Here is
> a way to resolve this: the CN must `commit' a new update only after sending
> at least one packet with the existing tag!  A counter is set to one (or some
> small integer to
> account for packet losses) when a new CoA (such as X) is received. When the
> MN's VoIP packet is received, its CoA does not replace X until the counter
> is zero. The counter is decremented every time an entry is tagged.
> Downside: extra storage for another address. Still does not necessarily
> provide the ability to put the bad tag on the bad packet. However, it
> provides the alarm ability.

Once we know what the goals are we could actual discuss something closer
to proportial tagging as well.
Imagine where a MN is flooded due to multiple attackers.
It would be benefitial to be able to determine which source addresses
cause the most amount of flooding.
So there could be a small list of unvHAO source addresses that have been 
seen recently (LRU  replacement) with a counter of how many have been seen.
Those counters then effect the proportion of the tags.

Sure, this isn't capable to placing the bad tags on the bad packets either.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Mar 2002 10:54:16 +0100 (CET)

> prosessing and tagging support.

Just to clarify, are you saying that we should make "exact tagging"
an option (as opposed to the "cached/approximate tagging" we have
been discussing recently)

> security problems.  The hard part is getting the tagging

If it is optional we need the ability for the MN to determine whether
it can send unvHAO to a given CN. Seems to require a roundtrip exchange to
determine this.

Also, is the idea that nodes which implement exact tagging implement it
for all transports i.e. for UDP as well as TCP, ICMP echo, SCTP, etc?
The reason I ask is that it is easier to implement this as long as the 
application doesn't need to get involved, which it does for UDP at least.

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 06 Mar 2002 10:34:50 -0800

> Was I supposed to respond to myself?

I wasn't expecting you to do so :-) . I was referring to your text that I had
included in _my_ e-mail that seemed to suggest that it is harder for an attacker
to predict the timing patterns of applications on the MN.

> (As already pointed out no filtering can be done between the CN and HA

Let me try to clarify.

- provide traceability. This would be more than detecting a reflection
   attack is underway.
- allow for filtering. Here I see the confusion that arose above. I was
    thinking of filtering between CN and a GN, BTW. This was motivated
    by the fact that a GN's traffic should not be harmed, a point that Pekka
    Nikander had brought up earlier.. In that case, the
    packet mix would be between tag=X and no-tag. It is easier to
    distinguish; yet some good packets may get tagged with X, and may
    get dropped by a firewall. However, there is quick recovery. This is in
    the document, Section 3.
   As you rightly point out, this harder (due to approximate tagging) between
   CN and HA. However, as you say, you could offer such a possibility
   between CN and the attacker.
   [GN= Generic (non-mobile) IPv6 Node, MN at home]

> I don't have a good handle on exactly what the security goals are here.

The goals are not any different. The Introduction section refers to
traceability and filtering. If I could summarize this discussion, the proposal
- offers traceability
- facilitates filtering between CN and GN. It helps to see two different cases.
   First, e.g., the CN sends a TCP SYN ACK with tag=X. It gets dropped, which is
   what should happen. Second, during on-going session(s), tag=X
   appears, and the packet gets dropped. In this case, the min of {timer T1,
   next pkt arrival} wipes the tag out. Here, there is quick recovery from
   disruption.

I hope this is helpful..

> Those counters then effect the proportion of the tags.

Hopefully the above is useful. To summarize again, always offer traceability and
facilitate filtering with quick recovery (between CN and GN) were what we have
attempted to address. Between a MN and CN, the proposal relies on `auto repair'.

What should we do next ? I want to move forward :-)

Regards,

-Rajeev

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 06 Mar 2002 12:17:10 -0800

Hello Erik,

I think it's time to step back and take a look at the overall
situation in the discussion about Home Address Options (HAO).

In order to avoid the need to read zillions of previous notes,
I'd summarize the current status of the discussion as follows:

- We have defined "Unverified HAO" to be one for which the
  correspondent node (CN) cannot be sure that the care-of address
  is correct, and "Verified HAO" to be one for which the correspondent
  node has a Binding Cache entry, perhaps secured by the return
  routability test.

- We have proposed a scheme by which the CN tags outgoing
  packets with the care-of address claimed in a previously
  received unverified HAO.

- There are cases where it is difficult to tag outgoing packets in
  a way so that the outgoing packets are tagged with the same care-of
  address claimed in the incoming packet that evoked the response.

I believe that it is important to get this tagging capability
represented in the upcoming base Mobile IPv6 specification.
Here is a comparison of the advantages and disadvantages, on 
which we can try to make the decision.

    Unverified HAO allowable	Unverified HAO prohibited

-   Robust to cache entry       If CN times out or loses a Binding
    timeout and reclamation     Cache entry, MN traffic is blackholed

-   Fast response to packets    Delays for either reverse tunneling
    initiated by MN             or Binding Cache Entry establishment.
                                Worse if CN implements ONLY RR.

-   "Do No Harm" satisfied      Reverse tunneling and black-holing
                                is a "harm"

-   Vulnerability == "way_small"   Vulnerability == 0.

Briefly, I think that with the current tagging scheme, the
vulnerability is so microscopic, and the benefits quite
clearly worthwhile, that we should go for it.
To be completely honest, I do not have data to determine
whether the vulnerability is completely negligible, or
only very, very small.  I think that one could guesstimate
the likelihood of the occurrences that you described, based
on IP reordering pprobabilities, and it surely is a tiny
probability.   We have already designed ingress filtering
techniques that almost completely eliminate any lingering
abilities for attackers to mount this highly improbable attack.

Furthermore, I suggest that the tagging be considered a typical
part of a procedure to initiate the Return Routability establishment
for a Binding Cache entry.  This limits the window of vulnerability
even more.  It seems to be very natural.  It would not MANDATE
that the mobile node initiate the RR procedure, but that would
be the typical case, and it would be the case we should design
for general deployment.

We only have to specify in the upcoming draft what the format
of the tag should be, and that the CN is required to keep count
of the incoming unverified HAOs.  The way that the CN determines
what to put in the tag can be an appendix, and would pretty much
conform to the latest discussion that you have had with Rajeev.
The protocol would not depend on the degree of precision by
which the CN can determine the correct tag.  As has been
discussed, I can imagine that in the future a better method
(perhaps involving changes to the socket structure) could be
devised in the future, without changing the format of the tag.
That is why I believe this material belongs in the appendix.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Mar 2002 22:42:06 +0200 (EET)

On Wed, 6 Mar 2002, Charles E. Perkins wrote:
[snip]
> abilities for attackers to mount this highly improbable attack.

Which vulnerability?

If DoS reflecting is a vulnerability, I think I agree; packets will be 
tagged with something which can be traced (even though tracing may be very 
difficult at first because systems wouldn't support it).

If being able to spoof one's source address is a vulnerability, I don't 
think the proposal addresses this..?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 06 Mar 2002 12:53:42 -0800

Hello Pekka,

> Which vulnerability?

I was referring to Erik's observation that, given Rajeev's
state-based "best-effort" tagging proposal, packet reordering
at the CN could cause packets to be sent out with the "wrong"
tag.  The malicious care-of address would still be observable,
albeit in a different packet.  But this would be a very rare
occurrence.

> think the proposal addresses this..?

That is true.  We are assuming ingress filtering applies.
If not, then anyway there is no real discussion because
in that case the whole HAO design is just as traceable as
non-ingress filtered packets (i.e., not).

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Mar 2002 00:14:08 +0200 (EET)

> That is true.  We are assuming ingress filtering applies.

We may or may not be able to assume that.  

But unless ingress filtering is "smart" (c.f. Francis' approach), it won't
help for the address in HAO case: that can still be spoofed regardless of 
ingress filtering.

> non-ingress filtered packets (i.e., not).

There are some small variations there but nothing earth-shattering.

---

From: Kenichiro Iida <[email-masked]>
Date: Thu, 07 Mar 2002 21:54:29 +0900

Hi.

I read Mobile IPv6 I-D.
I have a question about Mobile IPv6.

In Mobile IPv6 Protocol, MN has the functions of forming CoA and sending BU.
I think, If AR(Access Router) can have these functions, there will be the 
following advantages.

(1) AR can form MN's new CoA and perform DAD before Handover.
(2) The delay to register with HA and CN is reduced, because the delay 
between AR and MN is eliminated.
      In case that the link between AR and MN is wireless, e.g. WCDMA, its 
transmission delay will be about several ten msec( 40-50msec ).
      If AR sends BU, this transmission delay is eliminated.

Are there any problems on this idea?
Could you give me any comments?

Best regards,

K.Iida

**********************************************
飯田　健一郎　(Kenichiro Iida)
松下通信工業（株）　モバイルコミュニケーションカンパニー
　　モバイルコミュニケーション開発センター　
　　基地局システム開発部　開発3課
〒239-0847 横須賀市光の丘5番3号
E-ｍａｉｌ ： [email-masked]
TEL ： 0468-40-5235　（内線 ：7-350-5399）
**********************************************

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Mar 2002 16:28:06 +0100 (CET)

> albeit in a different packet.  But this would be a very rare

Charlie,

there was no reordering in my examples.
There was just multiple concurrent "streams" of packets arriving at the CN - 
one stream being sent by the CN and one stream being sent by the attacker.

As such there is no assumption about the network reordering packets.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Mar 2002 16:42:26 +0100 (CET)

Charlie,

Some comments on the claimed benefits.

>     timeout and reclamation     Cache entry, MN traffic is blackholed

You seem to be forgetting that the unvHAO (just like the binding cache)
will be of finite size.
If you take that into account you'll see that the unvHAO is actually less
robust because a MN will send unvHAO which will be dropped during normal 
operation. Some error can be sent to the MN is this case but that is
after the packets have been lost.

I think an attacker can easily fill the unvHAO cache with garbage since
there is no verification of the information that goes in there.
Thus an attacker can send
	src=X HoA=::1 dst=cnn.com
and increase "1" until the unvHAO is filled.

Also, on the right you claim that timing out a BCE will cause packet loss
which isn't true. The MN knows the binding lifetime it its binding update list
which tell the MN for how long time it can continue to send HAOs.
The only case the strict HAO verification will drop packets (and send an
error to inform the MN) is when it has had a fatal loss of state
(i.e. crashed and rebooted).
This is normally a rather rare event and when it happens it will
disrupt the actual data traffic (TCP, RTP state being lost as well at the CN).
This is quite different than dropping packets during normal operation when
the unvHAO cache is full - whether due to high load or due to attacks.

>                                 Worse if CN implements ONLY RR.

What is the delay?
A MN which cares about performance presumably starts the data traffic
using reverse tunneling while the 1.5 roundtrips of RR+BU are
in effect. When it gets the BAck it can then switch to fully optimized path
in both directions.

> -   "Do No Harm" satisfied      Reverse tunneling and black-holing

We've talked about "do no harm" in the context of security.
You don't seem to be talking about security here so am I a bit confused.

> -   Vulnerability == "way_small"   Vulnerability == 0.

"way_small" > "do no harm"?

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Mar 2002 08:34:19 -0800

Hello Erik,

> You seem to be forgetting that the unvHAO (just like the binding cache)

No, and you are right that size matters here.  However, my model is
that the unvHAO will be somewhat less common, because typically nodes
would start to set up a Binding Cache entry.  This should be even more
true now that we have a reasonable way to do so, using the Return
Routability procedures.   So, I reckon that finite size (but nonzero)
should be O.K.  The size depends on how many mobile senders the
recevier expects to hear from.

> after the packets have been lost.

I think that nonzero cache size will be a lot more robust than zero
cache size!

> and increase "1" until the unvHAO is filled.

But this sort of behavior would be traceable to the source of the
attack, and amounts to a temporary decrease in robustness at cnn.com.
I admit it's not perfect, but it is improveable by techniques such as
we have discussed, and it's a lot better than nothing.

> which tell the MN for how long time it can continue to send HAOs.

This is also true, and we can hope that the mobile node will send Binding
Update packets before the cache times out.  However, these Binding Update
packets can be lost, and typically are not expected to be acknowledged.
Furthermore, there are cases where clocks can be skewed.  All in all,
I think that we can expect some timeouts to occur.

> (i.e. crashed and rebooted).

Not according to my understanding in the last paragraph.

> the unvHAO cache is full - whether due to high load or due to attacks.

I don't think this is right.  If we expect that the unvHAO entry is
temporary until the verifiable Binding Cache entry is set up, then
the scenario you describe is quite unlikely.

>>                                 Worse if CN implements ONLY RR.

It is faster to send packets directly to the correspondent node
than to use reverse tunneling.  It takes a while to set up a
Binding Cache entry, longer than reverse tunneling.  If the CN
implements only RR, and the mobile node requires something more,
then there will be even more delay.

> in effect. When it gets the BAck it can then switch to fully optimized path

I definitely agree with you.

> You don't seem to be talking about security here so am I a bit confused.

I didn't think it was very confusing!  But you are right, that this
effort to avoid harm is concerned with performance and robustness,
at no cost in security.

> "way_small" > "do no harm"?

I don't think there is any realistic harm done here, and I do
think that there is performance and robustness gains to be had
that are worthwhile.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Mar 2002 09:49:18 -0800

Iida-san,

Have you read draft-ietf-mobileip-fast-mipv6-04.txt? It includes
approaches to optimizing this.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Mar 2002 19:15:37 +0100 (CET)

> I think that nonzero cache size will be a lot more robust than zero

I agree about that!

But you didn't address my point that lack of robustness is caused by the
cache being finite.

> we have discussed, and it's a lot better than nothing.

Yes, but presumably cnn.com would see lots of unvHAO entries (assuming 
triangular is as useful as it is claimed) and it has no way to tell
good from bad.
Sure, if the src is identical for many it would be a hint.
But the attacker could easily pick source addresses from the /64 for its
subnet.

Of course, such an attacker could also use RR to fill the binding cache.
*BUT* that wouldn't cause packet drops for others - it would just cause
others to not be able to complete the RR/BU exchange.

> I think that we can expect some timeouts to occur.

If the packet flow continues then either the MN can do a BU or the CN can
send a BR some number of seconds before the binding expires.
In both cases should the MN discover that the binding did not get renewed 
it makes sense for the MN to revert to reverse tunneling.
I don't see what clock skew has to do with this - there are no absolute
times communicate in MIPv6. Relative times aren't effected by clock skew.

You seem to assume that the MN would not ask for a BAck.
I'm assuming that with strict HAO checks against be BCE it makes
a lot of sense for the MN to always ask for a BAck.

And even with unvHAO it makes sense for the MN to ask for a BAck
since without it the CN might continue to route packets to an old CoA until
the binding expires.

> Not according to my understanding in the last paragraph.

If you assume that MNs don't care about stale BCEs on the CNs (i.e. they
don't care if they don't receive packets from that CN) than of course
they don't care about robustness.

My point is that with strict HAO checks an MN can get robustness.
With unvHAO there will be packet loss when the unvHAO cache gets full.
As simple as that.

> the scenario you describe is quite unlikely.

I'm confused. You are assuming that the unvHAO cache will only/mostly be useful
for the 1.5 rtts until RO is setup? That makes no sense to me due to the
probability of the packet loss  issue with unvHAO.

> effort to avoid harm is concerned with performance and robustness,

Are you trying to put words in my mouth?
I think there are huge security problems caused by unvHAO.
Sigh.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Mar 2002 20:30:23 +0200

Hi Rajeev and Basavaraj, I have now read your proposal and would
like to offer some comments on it. (I'm still reading the rest
of the thread so I could learn something new later.)

> sender.

This is correct, but there's also a bit more to the traceability problem.
Namely, mechanisms are being added to the Internet to allow for tracing
packets regardless of possible forging of the source address. HAO
makes one of the trace schemes, itrace, not work as the interesting
leg of the packet's path will not generate traces to the victim.
This is however fixable with what we called 3-way itrace somewhere
in the DT notes. However, another (apparently a more popular) technique
called IPPT however can't be fixed this way.

> Second, as a response to prevent such attacks, source ingress
> response. It thus provides traceability.

Hmm... so we get traceability, but what about prevention a la
ingress filtering?

>    entry. On the other hand, the HA tunnels packets with correct tags

Destination unreachable is ok, but the process for sending correct
tags sounds dangerous. Could be used by bad guys as well.

>      unverified BCE.  For this reason, we suggest a relatively short

So, if I know an address that is likely to be filtered (e.g. 10.x.x.x)
and claim that as my CoA in a single packet to a CN with HoA=victim,
then victim's unidirectional traffic will be lost for a while?

> no-tag          non-HAO   -> no state change,     -

So, assuming this works well within an area where ingress
filtering is used, what happens to other areas? For instance,
if on this particular area (the place of the victim) we
don't have ingress filtering, then he could guess that
a mobile M is talking to correspondent C and hence C is at
the "tag" state. Then the attacker could send a spoofed
message with M as the source and with no HAO. Then C would
move to no-tag state, and drop all M's traffic for T2 time.

Note that without the tagging scheme, all the attacker could
possibly do is to inject some extra packets, not start dropping
real packets. Doesn't this violate the no-harm principle?

Also, consider what the attacker has to do in order to inject
the bad packet as above. He doesn't in fact have to even guess
TCP sequence numbers or anything like that, because for the purposes
of tag processing, it is enough to get one packet in, regardless
of whether TCP throws it away immediately or not.

In conclusion, I fear that while fixing a problem, we may
be introducing serious other problems. 

> 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING

Uh oh so we have an intermediate optimization (triangular routing) which
drops packets... I'm not too comfortable with this.

> addressed.

The traceability aspect wasn't addressed fully. We can now
trace things when the source addresses are right (e.g.
under ingress filtering) as the tag is carried along. However,
we would also need to address the case where it is not, and would
use something like itrace or ippt. The former appears to be fixable,
but the latter is not.

> While the proposed mechanism may not be perfect, it

Hmm... let's analyze this. The first issue that comes to my mind is
attacker's who might be filling the unvBCE memory on purpose, in order
to flush out necessary states related to the victim. The secod issue
that almost by definition, this scheme can't provide an authenticated
HoA in the tag option, not even in the RR sense of the word "authenticted".
So, regardless of how well we plug the holes we notice, there is going
to be other holes left that allow attackers to inject inappropriate
tags to the traffic, possibly causing packets to be dropped at firewalls
or the HA.

> done according to the rules specified in Section 2. 

DISAGREE. I think there are holes in traceability, at least on this
first read this appears to be introducing new holes, and the scheme
is relatively complicated. Wouldn't it be simpler to just require
RO from the CNs, if we are to require the CNs to hold state? Please
note that *every* CN has to implement this. If you use the BCE implementation
strategy, why wouldn't we at the same time bite the bullet and implement
and use RO itself?

However, I do have a constructive proposal on how we could go ahead
and still try to get something like this in the standards assuming we
*do* resolve the open issues somehow. I'd like to propose that the BR
message that reports lack of memory for unvBCE would be used to signal
the support for this feature. This way, we could go ahead with the base
MIPv6 RFC with bidir and RO, and *if* we get these issues solved, we can
introduce another RFC which specifies the following:

1) MNs can optimistically start to use triangular routing and unvHAOs
2) If they get a BR they will downgrade back to bidir and assume CN
    supports only the base RFC
3) If no BR, they proceed as planned

Disclaimer: when I read the rest of the thread, I might change my
mind about what I've said in this e-mail...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Mar 2002 20:49:09 +0200

> to that packet when there are multiple packets in progress.

This seems to be fundamental observation. *Any* non-socketApi solution necessarily
has to make a random/heuristic assignment of the tags to the outgoing packets.
If so, the solution can *not* be used to filter out bad guy's traffic as per
the original requirement.

The original requirement was to be able to see that address X somewhere
in the net is attacking us, and placing a filter at the ISP router to
block all packets with Src=X or Tag=X. However, if we can't guarantee
the right packets are tagged, we'll be dropping some real packets and
not all wrong packets. This isn't good.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Mar 2002 11:17:43 -0800

Hello again Erik,

> But you didn't address my point that lack of robustness is caused by the

The robustness problem will come when the cache is filled.
The cache can be sized so that under normal operation it will
rarely if ever be filled.  I thought that was implicit in what
I said.

> But the attacker could easily pick source addresses from the /64 for its

If this gets to be a problem, then the implementation can count
against prefixes instead of against 128-bit addresses.  I think
we are discussing a problem that is already unlikely, but if it
exhibits some hint of likelihood, then at that time the engineering
tradeoffs will become apparent.

> others to not be able to complete the RR/BU exchange.

This depends on the cache management strategy, and on the ability to
match outgoing tags with incoming packets as we have discussed.
The attacker is also traceable, so I don't see this as a serious
threat.  And, the downside is annoying, but temporary and nonfatal.
If it's really important, though, we could have a fallback position
by which mobile nodes that are frustrated with incomplete RR/BU
exchanges, to use reverse tunneling.

>>           ...........                          these Binding Update

Yes, but I think your statement points out that we are facing a loss
in responsiveness.  I hope we can avoid this sort of annoyance,
especially for interactive traffic.

> times communicate in MIPv6. Relative times aren't effected by clock skew.

It could be that, under attack, reverting to reverse tunneling
would be a useful strategy.  Instead of "clock skew", it would more
precisely be a problem only with skewed clock rates.  

> a lot of sense for the MN to always ask for a BAck.

This is introducing a need for a lot more signaling (approximately
double what unacknowledged Binding Update would require).  I had
always thought it was a good feature of Mobile IPv6 that we should
be able to avoid that.

> they don't care about robustness.

I am not at all making that assumption.  Stale Binding Cache entries should
be handled by handover techniques.  I do think that mobile nodes should
care about robustness and performance -- which is the main reason that I'm
involved in this discussion.  My statement in this quoted segment followed
from my previous statement about the possibility for cache entries to be
timed out or reclaimed.

> With unvHAO there will be packet loss when the unvHAO cache gets full.

I also think we should expect most HAOs to be verifiable.  I believe
that we can get greater robustness by allowing a small percentage of
HAOs to be acceptable, along the way towards establishing verifiability.

> probability of the packet loss  issue with unvHAO.

The probability of packet loss is zero, unless a node is under
attack.  The probability of attack is low, and the attacker is
traceable.  I am hoping that most HAOs will be verifiable, and I
am proposing that we allow some of them to be acceptable, and
tagged, prior to the moment when they are verifiable.

> Are you trying to put words in my mouth?

Erik, I am not trying to subvert your message.  The last clause is mine,
and I _thought_ the previous clause was implied by your statement.
You can tell me I was wrong about my inference, but please don't
make out like I am arguing unethically.

> I think there are huge security problems caused by unvHAO.

I think the problems are really microscopic!  And, that they
are only evident under malicious attack, which is in addition
benefitting from highly improbable and fortuitous chance
occurrence.  Most attackers would rather not go for a traceable
attack which is unlikely to succeed anyway.  I do not believe
that protecting against such unlikely attacks is worthy cause
for loss of performance and robustness.

> Sigh.

If this is an expression of frustration, then please try to view
my message as an attempt to build a better system.  I am not
doing this to frustrate you.

Regards,
Charlie P.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 07 Mar 2002 17:02:02 -0800

Some very brief notes on this thread I had no time following
unfortunately until now..

- On robustness: both verified and unverified caches are in reality
  finite in size. Both would have a similar error mechanism
  anyway so there is hardly a difference in robustness in
  RO-BC or unverified cache filling up. With the latter you
  may lose some packets in transit, but also with the former,
  it is just a cache and may get destroyed before or without
  new BU reaching the CN. In a worst case a RO data packet may
  be on path and get dropped in such a gap. This should not
  be a real argument.
- On traceability: support for traceability with current
  mechanisms as is cannot clearly be an assumption since a tag
  is a new construct. But we know traceability is possible
  due to the tag being an audit. It does not support all the
  ways tracing is done today but tracing in general can be
  supported given the right tool.
- On filterability: in CN: possible, between CN and a HA maybe
  possible with exact tagging. Best effort tagging gives
  the chance for the attacker to exploit tags being responses
  to packets with different CoA due to asynchrony of L3 stack
  and the applications. This was considered a real issue by
  some, but to really consider whether this is beyond do no
  harm, here are some more thoughts

  - Injecting packets to unsecured payload traffic by sending
    spoofed packets along a legal stream really is possible
    even without mobility. One just spoofs CN address inserting
    it to source address and adds those to the legal stream if on
    path. Exact tagging is actually addressing the case when
    tagging should also consider that application data traffic
    is unsecured. Tagging can hardly fix that, and given the
    source IP can be spoofed without mobility, the comparison
    in the discussion so far has not been completely fair.
    The definition of do-no-harm is not clear from the discussion
    thread. I still suspect tagging does not go beyond this
    when comparing to this non-mobility case.

  - What a filtering firewall really does is to also block the
    legal CN in the above non-MIPv6 case. If tagging is
    there, any packet prompting filtering on the CN-HA path
    can then cause blocking of all packets going to the
    destination HoA. Useful packets are lost but so are in
    the above case. There are only differences in nuances,
    now the attacker does not have to change source address
    and a filter has a different but equally stateless rule
    that instead of the source address filters by the
    destination address, while the tag gives the traceability.
    One could claim there is a difference in the added ability to
    do off path attacks with tagging but unless we have globally
    deployed martian filtering (which we do not have), one
    can also mount the above type of source spoofing attacks with
    non-mobility packets even from off-path locations.

  As a conclusion, I can live with the HOA tagging being an
  option with a separate specification added later on, to
  expedite the base specification, but do not yet understand
  the security arguments against tagging.

BR,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 08 Mar 2002 00:50:05 -0800

> I think there are huge security problems caused by unvHAO.

Since in today's discussion this was not exactly stated,
and I assume by unvHAO you here also include unvHAO when
the tagging method is used, I'd like to hear more of these
particular problems. Even if best effort tagging is used,
the only concrete security issue in the best effort
tagging proposal that I heard, was for this limited
case:

- with tags and response packets being out of sync, right
  packets may get wrong tags and vice versa making tag-based
  filtering drop wrong packets and pass right packets.

  But: any filter in and after CN can still drop both,
  based on the destination address, for example, if
  we drop both right and wrong packets to this HoA.
  Also, given the timer range behavior with the unverified
  HAO cache, and unpredictability of the reflecting
  application, attack packets can be entered only
  momentarily, which makes it hard to find those
  moments due to randomized timeout ranges.

  Could you help me to see where the added harm is?
  It is unclear to me how the above issue effectively
  differs from the case non-mobility attack packets have
  a spoofed source address and get to be filtered along
  with victim's traffic from the same source address?
  These can be launched on-path or even off-path and
  here the effect does not seem to essentially differ from
  the problem you stated for best effort tagging, a loss of
  valid packets in an intermediate filter (in HA domain's
  firewall, for example).

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Mar 2002 10:28:40 +0100 (CET)

Charlie,

A few comments.

> precisely be a problem only with skewed clock rates.  

I think the term is "clock drift".

The protocol can easily be designed to handle a maximum difference in drift.
For instance, if we assume that the drift difference will be less that 4%
(around 1 hour per day - I assume most systems have much less)
then the MN just needs to time out its notion of the CN having a BCE
in .96 times the actual lifetime value passed in the protocol.
Protocols like DHCP effectively already do this - make sure the 
address is refreshed quite a while before the lifetime says
it will expire.
So this is a no-brainer.

> always thought it was a good feature of Mobile IPv6 that we should

Without a BAck the RR scheme has 5 packets. With a BAck 6. Hardly twice
as much.
And if we need a BAck to make the protocol both secure and robust against
packet loss, what option do we have?

> tagged, prior to the moment when they are verifiable.

Assuming an infinite size unvHAO cache this is true.

I don't think computers/devices can be built so that they will never run
out of a particular resource unless they live in a completely predictable
environment. Connecting to the network makes the environment no longer
completely predictable. Thus CNs will run out of unvHAO space even
during non-attack scenarios. Carefully engineering of the CN will
presumably limit the cases during which this happens, but it be a non-zero
probability event. Thus I agree with your claim above.

Also, since we'd like the protocol to behave reasonably even during attack it
would seem prudent to think about the added loss caused by the unvHAO 
cache being full.

> make out like I am arguing unethically.

I didn't say there was anything unethical. I pointed out that by you stating
"but you are right, ..." you seem to say that I had said "at no cost in
security" which I never said and never intended to say.
This space is full of traceoffs between security, robustness, and performance.
Thus I think that all three need to be taken into account.
Your statement seemed to imply that I didn't think security mattered here
which is what made be react.

> I think the problems are really microscopic! 

Time to agree that we disagree and move on.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Mar 2002 10:38:49 +0100 (CET)

Jari,

>   be on path and get dropped in such a gap. This should not

The above should not be a real argument :-) :-)

Seriously,
I think there is a big difference between the case when the CN reboots
and losses all state (including transport and application state) i.e. looses
the BCE state compared to the unvHAO idea of effectively
doing "send and prey" that an unvHAO entry can be created on the CN.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Mar 2002 10:53:56 +0100 (CET)

Jari,

sorry for being inexact - the unvHAO name has been used for the proposal
to do best effort tagging but I realize this isn't necessarily the
only case.
So my statement applies to unvHAO handling using best-effort tagging.
Using exact tagging (where every "response packet" is tagged with the
IP source address in the corresponding "request packet")
seems to avoid these security issues at the expensive of additional 
implementation complexity which needs to cross the API and effect UDP
applications.

I think I've expressed my security concerns several times on the list already.
Do I need to repeat them?

>   we drop both right and wrong packets to this HoA.

Yes, but that will then effect the legimate traffic.
The goal of handling DoS attacks is to maximize the number of
bad packets being filtered while minimizing the effect on
legitimate traffic.
With reflection it isn't always possible to avoid effect on legitimate
packets as Vern's paper (in DT writeups) point out.
But what you propose above makes MIPv6 cause additional causes where
filtering can not be very exact.

>   moments due to randomized timeout ranges.

Huh?
Are you talking about the case when one entitity (attacker or good guy) is
using HAO and the other isn't?
Or the case when both are using HAO? The latter is the place with the most
problems.

>   with victim's traffic from the same source address?

Think of case with some ingress filtering (but never perfect) that
will prevent arbitrary source address spoofing.
Add attackers doing DoS and the need to filter those out
close to where the pain is being felt (and the CN might not feel
any pain from such an attack).

   Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 11 Mar 2002 14:01:31 -0800

> doing "send and prey" that an unvHAO entry can be created on the CN.

Now honestly, if one compares the cases of a node quickly
establishing RR-verified cache entries and unvHOA entries,
both can be done rather rapidly and for different addresses.
Both caches can be filled and both caches should be of
limited size. If one does not have an explicit limitation
with RR-verified cache, it usually causes reservation of space
from heap and is in a way worse because it can disturb other
operation by making (k)mallocs fail for other uses. Having a
restricted size also for RR-verified cache is _better_ than
not having one. The UnvHAO space even had a rate limiting
functionality specified unlike the verified BC. I still
do not see any relevant difference in the memory filling
behavior, hence on robustness.

BR,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 11 Mar 2002 17:24:07 -0800

Erik,

> So my statement applies to unvHAO handling using best-effort 
> tagging. Using exact tagging (where every "response packet" is
> tagged with the IP source address in the corresponding "request
> packet") seems to avoid these security issues at the expensive
> of additional implementation complexity which needs to cross
> the API and effect UDP applications.

Since we are here considering unsecured applications, and to
understand do-no-harm, the comparison should be done against
what one can do with non-HAO packets. In unsecured packets,
putting the spoofed HoA to the source address causes the same
effect. Ingress filtering from the attacker to CN can be used
for both, from CN to victim GN or HA, with non-mobility packets
we have imperfect source based filtering, or with tagging,
imperfect source+destination or tag based filtering.

> I think I've expressed my security concerns several times
> on the list already. Do I need to repeat them?

I have tried to read through and found two, buffer behavior,
non-exactness of tagging, and I am trying to see the added
harm in them. Am I missing some others?

> filtering can not be very exact.

Similarity to the non-mobility source-spoofed packets is
striking, so that one cannot help asking, is this just having
actually the same cause non-mobility packets already provide. 
Granted, a new rule to a firewall is needed to do something
based on destination address (HA/GN) and source address (CN),
or with the risk of mis-tagging, the tag itself.

> Are you talking about the case when one entitity
> (attacker or good guy) is using HAO and the other isn't?

With ongoing sessions for this case there is "inertia" 
which causes the non-HAO guy to keep the session easier.
Mis-tagging requires switching between the good guy and
bad guy and that takes time. During this time responses
most likely are already gone, because switching takes a
small timeout. During this timeout the responses to requests
have gone to their right addresses and there is only a
small probability for mis-tagging. If timeouts are made to 
follow responsiveness of the overall system, the probability
can most likely be kept close to zero. Granted if the
responses become slow, packets get dropped, but that
may happen even for UDP applications if the load is
bad enough.

> Or the case when both are using HAO? The latter is the
> place with the most problems.

This is the case when MN and A compete for the HAO and
MN must be able to move quicker from CoA to another.
But here, too, if one uses rate-limiting of a small
timeout (one of the two timers in the solution) to
rate-limit how quickly changes are accepted and the
legitimate MN also uses the same rate-limiting (plus
a small delta), the bad guy must hit half of the delta
to get in. So both CN and MN having rate limiting with
obeying the faster timer, they can make it so that this
timer gives CN stack the time not to mix the packets.

With extensions such as BET, such a rate limiting
may be already occurring naturally in MN.
Attacker must pace his attacks really precisely
to hit the occasion to cause alteration back and
forth for the mis-tagging to happen. The small
guard time allows for a relatively frequent mobility
while it gives time for CN not to mis-order outgoing
packets. If the guard time is larger than RTT variation,
and variation of CN packet reordering probability,
the hole for the attacker is near zero.

t0 ---- guard_t - mn_t

The attacker must hit between guard_t and rate limiting
mn_t (when next packet after new CoA from the good MN
arrives). Then it must again wait to let mn take its
turn and again the same. Otherwise mis-tagging does
not happen (only one guy causes the traffic and that
is both traceable and filterable based on tags).

> any pain from such an attack).

CN source spoofing can be done at will at any time, and also
off-path if there is no source-based (ingress and martian)
filtering everywhere, even the best effort tagging limits
the chances of mis-tagging to very small.

To summarize: the differences are so minimal that I have
not understood the more harm argument here. It would be
even fair to call source spoofing much easier than causing
mis-tagging. And even with mis-tagging one would have the
same granularity of filtering as with source spoofing
prevention. Both victim's and attacker's packets from/to
one address get dropped at worst.

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Mar 2002 14:57:47 +0100 (CET)

> imperfect source+destination or tag based filtering.

How can today's ingress filtering (that looks at only the IP source
address field) be able to filter out packets between the attacker and the CN?
Those packets would have an IP source address that is topologically
correct for the attacker.

> may happen even for UDP applications if the load is

You didn't answer my above question of what case you are talking about.
Which case should I assume you were talking about?

In the case of one entity using HAO and the other is not the timer
mechanism effectively gives preference to not using HAO.
So this seems to be workable.

> timer gives CN stack the time not to mix the packets.

Are you referring to a modification to the unvHAO proposal that was sent to
the list? I don't find references to the above in that proposal.

Is the rate limiting you are proposing here a limit on the rate
at which the recorded tag value can change? Or something else?
Will the CN verify the source address in the received packets against
the recorded rate-limited change tag value?
[As you can tell I have no idea what change you are proposing to
the unvHAO proposal.]

> is both traceable and filterable based on tags).

Will the CN discard packets that have the wrong source address?

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 12 Mar 2002 12:52:51 -0800

Erik,
> How can today's ingress filtering (that looks at only the IP
> source address field) be able to filter out packets between the
> attacker and the CN? Those packets would have an IP source
> address that is topologically correct for the attacker.

If we still discuss the HAO reflection (right?), first,
there needs to be a method by which we can detect
attacking packets by content to be able to filter
them anywhere. If we consider the attacker-CN leg,
which is before the reflection, these are still
originated directly by the attacker, not yet by
the reflecting CN. Hence, the source address is
directly that of the attacker and normal ingress
filtering should apply as long as the attack can
be detected there by packet content (by TCP SYN
in packets, for example).

> You didn't answer my above question of what case you are
> talking about. Which case should I assume you were talking about?

Oops, grouping of your question did not make it explicit,
yes, the case above is that of either party not tagging.

> Are you referring to a modification to the unvHAO proposal
> that was sent to the list? I don't find references to the
> above in that proposal.
> 
> Will the CN verify the source address in the received packets
> against the recorded rate-limited change tag value?

Let me just defer answers to all these to a revised text.
This would actually make the issues more traceable than
from this thread.

> Will the CN discard packets that have the wrong source address?

Not necessarily. If MN and CN have roughly similar idea
of minimal timing, there can be a very short period during
which CN can discard or defer reception of such packets,
depending on whether zero loss in all circumstances vs.
more decreased probability for attacks is desired. Timing
uses a gap that occurs only when MN changes CoA. Let us come
back to that in a revised writeup later..

BR,

-Jari