Subject: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommenda tion note

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 6 Mar 2002 16:52:58 -0600

Rajeev, Jari and Charlie,

My initial comments are interspersed. I have not had time to review all of
the other related posts on the list so there may be duplicate
comments/concerns.

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

[GM]This firewall where would it be physically and which of the node(s) is
it providing these services for and how do you propose that the state
necessary to perform the filtering gets installed in the node(s). I have
inferred you mean some sort of external firewall to these victim nodes and
not a firewall on the hosts themselves where the net gain would be
negligable from a processing standpoint; though I am not certain this is
what you mean? Firewall the HA, MN, CN, Firewall all nodes, etc..? I am
concerned about the route optimisation getting blocked altogether.

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

Is this cache to be a MUST or a SHOULD for all IPv6 nodes?

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

[GM]Clarification:
What would prevent another node in between the HA and the CN from destroying
the entry for a valid MN? - asside1 - not sure if this is an anyworse
problem because a TCP reset could have similar affects unless access control
lists are used with standard non-mobile nodes? Note-all this recent MIPv6
work seems to be very familiar to the experimental VISA work with an end to
end spin that went on in the late 80's.

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

[GM] Clarification: Some may see a malicious cache exhaustion hole unless
the HA sends an indication to the CN that the MN is bogus. Of course the CN
would still have to store the state for the bogus MN in order to drop it or
notify some external trusted firewall to block it on behalf of the CN which
is also an exhaustion hole for the firewall. Is this what you meant by
firewall?

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

[GM]However, as pointed out earlier, this could certainly be used to disrupt
ongoing communications. I.e. an organization could exploit this to make
another organizations' resources look flaky and/or of poor quality. I think
we have a very recent and vivid example with the mobile IP mail list itself.

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

[GM] Same as above with the caveat that these disruptions and attack
scenarios exist in the non-mobile IPv6 with (to a lesser extent) or without
(to a greater extent) ingress filtering. 

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

[GM] MITM for a short period - same old no worse response.

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

[GM] A firewall where and how would it know to discard, etc..

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

[GM] I can live with this; however, cellular operators probably won't like
this unless you build a proxy or something for these updates, etc.. I don't
like the idea that a firewall could block route optimized communications
from occuring. I suspect the default for these firewalls will be to block it
entirely. A completely sucure method with no security holes and that simply
can't be blocked by firewalls seems to be a superior solution in that the
users could actually be guaranteed the functionality.

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

[GM] My first glance appears that it is not much worse than the threats to
plain old IPv6 without mobility; however, it served to remind us of the
holes that really ought to be plugged first in non-mobile IPv6 before people
go off dumping billions into its deployment. I am very pleased to actually
see some of this work to fix these holes starting up in other WGs. I am also
pleased that at least people have seemed to come to the conclusion that
state must be kept at least on the CN to do any form of route optimization.
 
> Recommendation R1 : We recommend that unverified HAO processing be
> done according to the rules specified in Section 2. 

[GM] This seems like quite a large and somewhat complex change to possibly
all IPv6 hosts for such a quick decision without interoperability,
simulation etc.. Perhaps a more formal ID that is separate from the IPv6
spec should be done first that clarifies many of the points above. I would
rather have the group find a solution that has no holes and even allows for
route optimization both ways as the state to do it at all is similar. As
usual I am always interested in the question about SHOULD and MUST above.
Even with a hopeful answer to this, I'm a bit leary of such a change for
only half the gain and so late in the game.

Thanks,

Glenn

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 06 Mar 2002 19:20:17 -0800

Hello Glenn,

thank you for reading the document and providing your
comments. I will try to answer your concerns below.

Regards,

-Rajeev

Glenn Morrow wrote:

> [GM]This firewall where would it be physically and which of the
> node(s) is it providing these services for and how do you propose that
> the state necessary to perform the filtering gets installed in the
> node(s). I have inferred you mean some sort of external firewall to
> these victim nodes and not a firewall on the hosts themselves where
> the net gain would be negligable from a processing standpoint; though
> I am not certain this is what you mean? Firewall the HA, MN, CN,
> Firewall all nodes, etc..? I am concerned about the route optimisation
> getting blocked altogether.
>

Our document does not propose there be firewalls, much less indicate
where they need to be. IF there is a firewall protecting a node, then
such a firewall may drop the tagged packets.
I am not sure I understand your concern regarding RO packets
being blocked. I don't see how they will be blocked. On the other
hand, a tag may follow the same format as RO packet (RH type 2).
Is that your concern ? I would support using the same format, but
I agree that a firewall must not drop packets insensitively.

> Is this cache to be a MUST or a SHOULD for all IPv6 nodes?

Tagging is MUST. Since it could be implemented differently,
the unverified BC is a SHOULD.

> What would prevent another node in between the HA and the CN from
> destroying the entry for a valid MN? - asside1 - not sure if this is
> an anyworse

In fact some _could_ overwrite it. If it does, it's IP address is seen
in the response packet from the CN and hence could be traced. Also,
a packet from MN with HAO would correct it back.

> problem because a TCP reset could have similar affects unless access
> control lists are used with standard non-mobile nodes? Note-all this
> recent MIPv6 work seems to be very familiar to the experimental VISA
> work with an end to end spin that went on in the late 80's.
>

I an not familiar with the VISA story. Perhaps you could
explain that to me another time :-)

> [GM] Clarification: Some may see a malicious cache exhaustion hole
> unless the HA sends an indication to the CN that the MN is bogus. Of
> course the CN would still have to store the state for the bogus MN in
> order to drop it or notify some external trusted firewall to block it
> on behalf of the CN which is also an exhaustion hole for the firewall.
> Is this what you meant by firewall?
>

I see you have interpreted the proposal differently. The CN only
maintains the mapping from HoA to CoA. And, the CoA could
be malicious node's IP address. If a malicious node fills the available
space with multiple HoA's all mapped to the same CoA (which BTW
itself is a red flag),
- any packets from the rightful owners of those HoAs would replace
   the tags
- tags themselves timeout unless there is traffic
- the CN's firewall could set up a filter for the bad CoA.

Does this answer your concern ?

> [GM]However, as pointed out earlier, this could certainly be used to
> disrupt ongoing communications. I.e. an organization could exploit
> this to make another organizations' resources look flaky and/or of
> poor quality. I think we have a very recent and vivid example with the
> mobile IP mail list itself.
>

Two things can happen right ?

- packets with tag make it to the GN, which responds back. The tag
    disappears
- GN's firewall drops packets with tags. This might be a good thing
    if the traffic is unsolicited. If it was good traffic, then any
packet
    from GN would remove the tag or the CN times out the tag. Once in
    no-tagging state, the CN stays there for a long time.

> scenarios exist in the non-mobile IPv6 with (to a lesser extent) or
> without (to a greater extent) ingress filtering.
>

See above. Good you point that some of the issues persist. We are
trying to stick with do no harm.

> [GM] A firewall where and how would it know to discard, etc..

This would be the GN's firewall. As I mentioned
earlier, we do not specify the firewall operation. We
only allow for a firewall to use tags to filter.

> [GM] I can live with this; however, cellular operators probably won't
> like this unless you build a proxy or something for these updates,
> etc.. I don't like the idea that a firewall could block route
> optimized communications from occuring. I suspect the default for
> these firewalls will be to block it entirely. A completely sucure
> method with no security holes and that simply can't be blocked by
> firewalls seems to be a superior solution in that the users could
> actually be guaranteed the functionality.
>

Certainly we are not proposing to block RO packets. We are
also not proposing that the firewall block tagged packets.
The text regarding the firewall is there to illustrate the
operation _if_ a firewall blocked tagged packets.

> [GM] My first glance appears that it is not much worse than the
> threats to plain old IPv6 without mobility; however, it served to
> remind us of the holes that really ought to be plugged first in
> non-mobile IPv6 before people go off dumping billions into its
> deployment. I am very pleased to actually see some of this work to fix
> these holes starting up in other WGs. I am also pleased that at least
> people have seemed to come to the conclusion that state must be kept
> at least on the CN to do any form of route optimization.
>
>

ok.

> [GM] This seems like quite a large and somewhat complex change to
> possibly all IPv6 hosts for such a quick decision without
> interoperability, simulation etc.. Perhaps a more formal ID that is
> separate from the IPv6 spec should be done first that clarifies many
> of the points above. I would rather have the group find a solution
> that has no holes and even allows for route optimization both ways as
> the state to do it at all is similar. As usual I am always interested
> in the question about SHOULD and MUST above. Even with a hopeful
> answer to this, I'm a bit leary of such a change for only half the
> gain and so late in the game.
>

Let me try to clarify few things.

- the requirement (i.e., MUST) is that tagging be specified
    for CNs while processing unverified HAO. As a matter of
    comparison, a CN includes HoA in a routing header when
    verified BC exists.
- there can be multiple implementations supporting the
    above requirement. Each requirement however has to
    ensure that every tag is represented in at least one outgoing
    packet from the CN. This is to ensure that no tag is
    overwritten and hence not traced.
- what we have described in the document is one implementation.
    It has been recently termed as "best-effort" tagging and I
    personally don't mind the name. Since there is considerable detail,
    I can understand your overall characterization of the proposal as
    complex. I do hope that you draw the distinction between the
    policy (i.e., tagging) and the mechanism (i.e, BE tagging described
    in the document), and draw a different conclusion on tagging itself
    as a proposal.

In our proposal, we have attempted to provide traceability and the
possibility to do filtering (most likely at the CN's domain to weed out
attacker's packets traced via the tag). I may not have seen the holes
apparent to you. So, please explain any while keeping in mind that we
are trying to stick with do no harm (i.e., not raise the bar).

---

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

> concerned about the route optimisation getting blocked altogether.

Glenn,

I think that the discussion I and Rajeev had on the list
resulted in the above statement about "the IP address of the
node causing the CN's response" no longer being true.

A firewall in front of a non-mobile node (a GN) can be configured to drop
all tagged packets without too bad effects since the state machine on the CN
is designed to effectively favor generating non-tagged packets.

But what can't be done is to have a firewall in front of a HA (or as part
of a HA) filter based on the actual tag value since that would make
it trivial for any attacker on the Internet to cause many good packets
to be dropped by such a filter.

   Erik

---

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

> are trying to stick with do no harm (i.e., not raise the bar).

Rajeev,

I'm trying to understand how such filtering would happen
in practise - how can the HA/MN get the CN's domain to install a filter
specifically for one MN?

Imagine a practical case where by PDA is being attacked using *.cnn.com
as the CNs.
Do I give cnn a call to have them install a filter for
	src=X, HAO=me
for inbound packets?

This is very different than handling DoS attacks today because a customer
can interact with their ISP (an entity with which the customer has a business
relationship) and that ISP can interact with their upsteam ISPs or peers
(with which the ISP has a business relationship).

But there isn't a business relationship between me and all CNs in the world.

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Mar 2002 10:24:15 -0800

Hello Erik,

> in practise - how can the HA/MN get the CN's domain to install a filter

I don't know of a good answer. However, installing the filter
need not be specifically for one MN. You would do this to block a
malicious node from potentially affecting many MNs. You would
detect such a possibility however through at least one MN.

> (with which the ISP has a business relationship).

how about,

customer = an entity supporting HA/MN ? The customer has an ISP (or is an
ISP himself/herself) who interacts with another ISP. The same case above holds.
Correct me if I am missing something..

> But there isn't a business relationship between me and all CNs in the world.

You are a customer to some ISP and the CN is a customer to some other
(or same) ISP. Isn't this generally the case ?

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Mar 2002 09:43:59 +0100 (CET)

> ISP himself/herself) who interacts with another ISP. The same case above
> holds. Correct me if I am missing something..
> 
> >

Rajeev,

My point, which I don't seem to be able to communicate
clearly, is that during todays DoS and DDoS attacks the actions taken to
do manual traceback and filtering can follow the business relationships
one "hop" at a time.
Customer asks its ISP.
That ISP asks its upstream ISPs.
An ISP asks its transit provider.

I seem to be saying that there is a transitive closure of business
relationships and I agree that such a transitive closure exists and would
encompass mosts IP nodes in the Internet.
But I don't see how the transitive closure helps - each "hop" along the
path today requires people evaluating the legitimacy of requests to traceback
and/or filter before they pass it along to the next "hop" is the chain of
relationships.

Is that more clear?
If not perhaps we should talk about this on the phone.

  Erik