Subject: [mobile-ip] A new proposal for handling Home Address destination options

From: Charlie Perkins <[email-masked]>
Date: Thu, 14 Feb 2002 18:50:40 -0800

Hello folks,

I would like to make the following proposal to enable use of
the Home Address option in certain cases even when there is no
current Binding Cache entry containing the care-of address.

==================================================================

The Home Address option allows a correspondent node to correctly
associate a mobile node's home address with ongoing protocol
operations in higher level protocols.  It is important, for
cases where a correspondent node should be able to receive packets
from a mobile node without going through a home agent.  The
current design team recommendation precludes the use of the
home address option except in cases where there is a valid
Binding Cache entry available at the correspondent node to
verify that the care-of address is valid.  This is too restrictive.
I suggest a mechanism by which packets from the correspondent node
are to be tagged with the presumed care-of address of the
mobile node.  This allows the home agent, without much additional
effort, to drop packets that have an invalid care-of address.

In order to make a good design, we must first distinguish between
a verifiable Home Address options (vHAO), and unverifiable Home
Address options (UnvHAO).  A vHAO is a home address option that
contains a care-of address that can be matched up to the care-of
address in a Binding Cache entry for a mobile node's home address.
UnvHAOss cannot be so verified, typically because the correspondent
node doesn't have any Binding Cache entry for the mobile node.
The design team recommendation for the vHAOs is good, and should
be incorporated into the specification.  For the rest of this
note, I only consider UnvHAOs.

For UnVCoAs, more care is needed.  We can make some simple
improvements to the way that correspondent nodes handle UnvHAOs
that will substantially reduce or eliminate any residual threat
of a viable reflector attack.  The first weapon in the arsenal
against these attacks is to tag outgoing packets with the
unverifiable care-of address.  These packets will then reach
the home agent.  The home agent has to look up its Binding
Cache entry for the mobile node.  If the care-of address does
not match the care-of address tagged by the correspondent node,
then the home agent can begin diagnostics or tracing for a
possible attacker, and then it would drop such packets.  If the
care-of address matches, then we are back to good, with much
better security.  Typically, along with tagging the packet,
the correspondent node would also take action to establish a
Binding Cache entry so that the care-of address would become
verifiable.

The other simple mechanisms which further reduce or eliminate
vulnerability to the reflector attack are simple rate and
capacity limitations at the correspondent node.  Any correspondent
node should only have a limited capacity for such UnvHOAs (perhaps
5 or so, but configurable and perhaps larger for big servers).
Similarly, most correspondent nodes should not make new entries into
this UnvHOA cache at a rate of more than one or two per second.
Some high-volume correspondent nodes could enlarge their
capacity, or their input acceptance rate.  Such measures
should at least rate-limit messages coming from particular
care-of addresses.  In any case, a limit of one unverified
care-of address per home address should be enforced.

There is a very simple firewall policy that will add a lot of
protection for general networks.  That is, a firewall can
drop packets that have the care-of address tag, if there is
no reasonable home agent which might tunnel such a packet to
a mobile node.  This will add further protection, in addition
to the traceability of the care-of address.

The additional effort to implement this procedure requires that
the correspondent node set up a flagged entry in its Binding
Cache for the mobile node.  This Binding Cache entry does not
yet allow the use of the care-of address for (e.g.) a Routing
Header, and it does require insertion of the tag containing the
care-of address.  It would have a short lifetime, on the order
of single digits of seconds.  I believe that at the time it
is created, we should also imagine that the process has been
started to create a "regular" Binding Cache entry, perhaps
by using Return Routability (RR).  Thus, this procedure
represents an initiation of a several step process, and in
this way enables much smoother and faster communications with
the mobile node.  This would be particularly important when
the mobile node has to supply timely data to the correspondent
node at a time when the Binding Cache entry does not yet exist.

=================================================================

I hope that this will be sufficient to persuade the design
team members to endorse continued operation of the Home Address
Option, and thus to maintain the improvements in performance
which would be lost if reverse tunneling were always required
until a Binding Cache entry could be established.  That process
could take hundreds of milliseconds, amounting to a quite
noticeable loss of responsivity.  Furthermore, if a correspondent
node loses its Binding Cache entry for any reason, then packets
from the mobile node would be black-holed.  This is intolerable,
especially because it is guaranteed that somewhere, sometime,
we will see correspondent nodes losing their cache entries.
My proposed mechanism will represent a much more robust way
to handle this problem.

Regards,
Charlie P.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 15 Feb 2002 15:58:38 +0200

Charlie,

IMHO, I think that you proposal has quite a lot of value,
thanks for working it out and posting it.  Furthermore,
I don't find any *big* security problems in it, per se.
OTOH, I still have to read Jean-Michel's analysis carefully
before I can say anything definitive about the security
aspects.

However, I think that there are fairly serious implementation
related problems.  We did discuss something fairly similar
at the DT, and there seems to be too many implementation problems
to solve; see below.  However, I would appreciate if you
liked to work more on this, and if the problems can indeed
be solved, at least I personally will be in favour of
something like what you propose.

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

> Binding Cache entry so that the care-of address would become

This far I agree, especially since you later note that the
tagging allows firewalls to filter them out whenever

> to the traceability of the care-of address.

[In this message I don't address the rate limitation etc;
I just haven't had enough of time to consider it properly.]

Let's continue with your suggested implementation.

> node at a time when the Binding Cache entry does not yet exist.

Now, here I see, firstly, a potential and fairly serious,
security problem, and, secondly, fixing it seems to lead us
to a can of worms.  But, as I said, maybe this can of worms
can be worked out, and I'd appreciate anyone seriously and
rigoriously trying to do so.

But the security problem first: using the Binding Cache for storing
the UnVCoAs so that they can be tagged into outgoing packets
leads, together with the firewalling rules, to a serious DoS attack.
A concrete example illustrates nicely the problem.

A mobile node MN, currently at a CoA 3ff0:100:1 sends a packet
to a CN, with a HOA of 3ff0:200:2.  Upon receiving the packet,
the CN creates a flagged entry in the Binding Cache stating
that the MN of HoA 3ff0:200:2 is currently at 3ff0:100:1 but
this information has not been verified and therefore RO cannot
be used.  After that the CN removes the HAO and passes the
packet to an application, setting the Source Address to
HoA 3ff0:200:2.

The application processes the packet and sends back a reply
to the HoA 3ff0:200:2.  Now, when processing the outgoing
packet, the kernel consults the Binding Cache and finds the
flagged Binding Cache entry.  Since this entry exists, the
kernel knows that the packet must be tagged with the CoA,
goes ahead, and tags the packet with the CoA 3ff0:100:1.

So far so good.  Now consider that instead of there being
such an MN, a victim called Victor is communicating with
the CN using the address 3ff0:200:2.  Victor is a stationary
node and he doesn't care nor know about Home Agents.
Initially Victor's communication flows just fine.  However,
if Victor employs the firewalling method, i.e. if he drops
all packets tagged with a CoA tag, it is very easy to cause
Denial-of-Service.  Sending a single packet with an arbitrary
source address and a HAO with HoA of Victor's address does that.
That is, the attacker Mallory sends a single packet, perhaps
even from his own address, with a HOA that contains Victor's
address 3ff0:200:2 to the CN.  This causes the CN to create
the flagged BCE, as described above.  As a result, all future
packets that the CN sends to Victor will be tagged with the
CoA tag.  And this causes Victor's firewall to drop the packets.

To summarize and generalize, using the BCE method for storing
information about received HAOs and for tagging outgoing packets
is not a good idea.  It is too easy to enter bogus information
into the BCE, thereby causing bogus tagging of outgoing packets.
[A side note:  CGA might help here, but OTOH, using it
  without proper precautiosn would open up DoS vulnerabilities
  against the CN.  Security design is interesting. :-) ]

Let us now consider what looks like the right way of implementing
this.  IMHO, the right way would be to more rigoriously
associate requests containing the HAO and related replies
that need to be tagged.  For TCP and connected UDP sockets
this seems to be achieveable, since the information about
the received HAO and CoA can be stored in the socket.  The
unconnected UDP sockets are the problem, though.  There the
kernel does not create any state where the HAO or CoA could
be stored.  Consequently, the only reasonable option would be
to pass the information to the user level.  This, in turn,
would mean API changes.

One way to extend the API would be to include space into
sockaddr_in6 for the care-of-address. Unfortunately that would
increase the size of the struct, and as a result some applications
might break.  On the other hand, most applications these days
use sockaddr_storage anyway, so that doesn't matter so much.
One bit could be stolen from e.g. flowinfo or scope_id to indicate
whether the added space contains a CoA or some other information.

If adding extra space to the sockaddr_in6 would be considered too
big a change, there are hacks we could make.  For example, most
unconnected UDP sockets don't have _that_ many outstanding requests
anyway.  Thus, it _might_ be possible to use e.g. the scope_id
field to indicate that the packet was received with a HAO, and
cache the HAO in the kernel space for a few seconds.  However,
such solutions are hacks.

Thus, the best way seems to be adding more space to sockaddr_in6,
using that space to store CoA (if there is one), and stealing one
bit either from flowinfo or scope_id to indicate whether the CoA
field is used or not.  That would have the additional benefit that
also other system calls used to report peer addresses (e.g.
getpeername) would also report the CoA, if it exists.  Well, maybe
we would need to steal another bit, too.  That would indicate
whether the CoA is one just received in a HAO, or one authorized
through RR or RR+CGA.

Now, all these considerations led me earlier to some kind of
exhaustion, i.e., getting this all work just seemed like too
much work and too many details.  But if you, Charlie, or
if somebody else, feel otherwise, I'd be glad to see the results.

--Pekka Nikander

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 09:41:44 -0800

Pekka Nikander wrote:

> thanks for working it out and posting it.

Thanks!  My goal is to maintain the important functionality
which allows a mobile node to avoid reverse tunneling
in many cases not conveniently solvable by establishment
of a BSA.

This whole issue is actually part of the larger issue of teasing
out the dual roles of the IP address as locator vs. as identifier.
I hope you will agree with me that we should try to avoid
avenues of discourse that seem likely to fall irretrievably into
that design area.  I am hoping we can get a good solution that
doesn't require solving the larger problem.

... deleted description of concrete application of proposed tagging ...

> CoA tag.  And this causes Victor's firewall to drop the packets.

I understand the problem.

> into the BCE, thereby causing bogus tagging of outgoing packets.

I have a truly outlandish and perfect solution to this problem,
except that it may not be the most economical or parsimonious.
But it is so "different" that I think I will seek another approach
for now, in order to find the most economical solution.

I think the first noteworthy aspect is that it is a platform issue,
and may not require additional protocol.  Nevertheless, I agree
with you that we want to have protocol that is implementable,
so we need an existence proof.

> to pass the information to the user level.  This, in turn,

To the zeroth level, I would be satisfied with a solution that only
works for connected sockets.  I do not think it would be wise at
this point to require changes to user programs.  However, I would
have to go back and try to see what common UDP applications
do with their sockets.  What about DNS?

More to the point, if we agree that it is a platform issue, then
we can evolve the platform solution in time as we get more
experience.

> whether the added space contains a CoA or some other information.

I would militate against using a flowlabel bit unless there were not
any other mechanism.

> such solutions are hacks.

That's a pretty big hack!

> whether the CoA is one just received in a HAO, or one authorized

I'm O.K. with most of this discussion.  I just hope you can agree that
we can get most of the way there sooner, and let platforms evolve
as need be.

Do you like my staged evolution approach?  I believe it shows we can
get there, and in the near term before the final platform issues are
solved
we can still have Proposed Standard.

Regards,
Charlie P.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 15 Feb 2002 21:44:02 +0200

Charlie,

I completely agree that we need to avoid going too deep
into the address as locator vs. as identifier discourse.
IMHO, that venue should be taken separately.  OTOH, there
are situations where understanding the difference helps
us in deciding the right semantics and encoding.

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

> for now, in order to find the most economical solution.

Ok.

> so we need an existence proof.

I agree that the implementation is a platform issue, and can
even be approached in a piece wise manner.  That is, if the
rest of the WG would like to have triangular routing that works
only for TCP and a few UDP applications, but not all UDP
applications, that is certainly OK for me.

 From the security point of view, I think that most probably
we could adopt the solution without too much worries, since
the tagged packets can indeed be dropped on firewalls.  Thus,
even if we later find out that there are additional vulner-
abilities in the method, there is still hope that there exist
some immediate remedy to the situation, i.e. strictening
firewall rules or such.

However, I have one practical reservation:  We must be very
careful in the wording and details.  Firstly, we must make
sure that the RFC is completely inambiguous in making sure
that the tagged packets are exactly those that result of
receiving a packet with HOA and no else.  Secondly, to
get to that point we have to analyze a number of possible
border cases, such as TCP retransmissions, application level
UDP retransmissions etc.  Thirdly, there must be some text
like the following.

   Under all circumstances, the CN MUST NOT send
   untagged packets to HoA.  If the CN implementation
   is unable to positively assure this property,
   it MUST drop all incoming packets that contain the
   HAO _before_ passing them to TCP, application, or
   other mechanism that might send packets to the HoA.

Fourthly, we should work out a reasonable scheme (ICMP
or other) where the CN informs the MN that it is
dropping the packets because it is unable to process
unverified HAOs.

I also think that there is more work to be done on
the rate limitation, but I have to admit that I haven't
considered that too much.

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

> I would militate against using a flowlabel bit unless there were not

The flowinfo field in the struct sockaddr_in6 has extra bits
that are currently unused and that cannot fit in to the flowlabel.

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

> solved we can still have Proposed Standard.

As I stated above, the stage evolution is fine with me.
However, I am worried about getting the standard text
onto a level that we can be assured that there does not
exist any unambiguities that would allow an implementation
(or even a lazy implementor) to open up the reflection
threat.  That's quite an amount of work, and somebody
must work out the details quickly.  Unfortunately I don't
have the time, given the desired schedule.  OTOH, I
can certainly review whatever text is produced.

--Pekka Nikander

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 18:01:43 +0100

The Home Address option allows a correspondent node to correctly
   associate a mobile node's home address with ongoing protocol
   operations in higher level protocols.

=> this is the key point and even in the BT recommendation
alternative ways to the BCE check should be allowed.
For instance, assume the MN and the CN share a trust domain,
the MN can easily build an end-to-end IPsec SA pair with the CN
using its Home Address (H@) (don't forget the mobility is transparent
so for example IKE should see only the H@). With the MN->CN SA,
the CN is able to verify Home Address options.

   It is important, for cases where a correspondent node should be
   able to receive packets from a mobile node without going through
   a home agent.

=> I agree and I am not very satisfied by the choice of the design
team in the apparent security/performance lost tradeoff.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 19:08:44 +0100

related problems.

=> someone suggested to add an implementor in the DT...

=> the filtering out a bit dangerous, I believe a more clever
filtering in order to:
 - drop on the floor unrelated floods of tagged packets
 - avoid the vulnerability described by Pekka.
For connected or pseudo-connected transport protocols, to track
communications is easy using a cache. For other cases, rate
limitation should be enough (don't forget a DDoS attack can be
only based on brute force flooding and sophistication only makes
them harder).

=> this attack is against the firewall so it is enough to warn
firewall implementors against it IMHO.

   is not a good idea.

=> I strongly disagree.

   It is too easy to enter bogus information
   into the BCE, thereby causing bogus tagging of outgoing packets.

=> if there is no stupid action associated to tagged packets,
the only issue is the overhead of the tag itself.

=> to make AH mandatory won't even make IPsec folk happy (:-)!

   this.

=> this is no more difficult than the already nearly required binding
cache. Most of my questions in a previous message about the strange
idea of the DT this cannot be implemented in the kernel found their
answer in Charlie's proposal.

   IMHO, the right way would be to more rigoriously
   associate requests containing the HAO and related replies
   that need to be tagged.

=> this is not necessary (fortunately because this is hard).

   For TCP and connected UDP sockets
   this seems to be achieveable, since the information about
   the received HAO and CoA can be stored in the socket.

=> socket -> PCB (Process Control Block, something which is used
(usually with this name) by every implementations).

   The unconnected UDP sockets are the problem, though.  There the
   kernel does not create any state where the HAO or CoA could
   be stored.

=> so the kernel should create state... where is the problem?

   Consequently, the only reasonable option would be
   to pass the information to the user level.

=> this is the less reasonable option...

   This, in turn, would mean API changes.

=> typically something an implementor does *never* ask for!
   
   might break.

=> s/some/all/

   On the other hand, most applications these days
   use sockaddr_storage

=> the disillusion shall be bitter.

   anyway, so that doesn't matter so much.
   One bit could be stolen from e.g. flowinfo or scope_id to indicate
   whether the added space contains a CoA or some other information.

=> I agree, there are hacks. Not better than to add a field in
sockaddr_in6 structure to make unconnected UDP sockets answer
with the right source address (or this is a real problem and
should be addressed in the standardized API, or this is not
and a warning for careless programmers is enough).

   That would have the additional benefit that also other system calls
   used to report peer addresses (e.g.  getpeername) would also report
   the CoA, if it exists.

=> this is a real question but the experience shows the system call
which should be extended to report the CoA is getsockname (this
should not be a surprise, to talk to a mobile is transparent,
to be a mobile is not).

Be more serious, this should be handled by the kernel. There is
a good place to put the cache, the "Destination Cache" (RFC 2461 5.1)
(two reasons: this is a per destination cache, this solves MTU issues).
To come back to the kernel implementation considerations,
immediate issues were:
 - what kind of state? how long to keep it?
   (answer in proposal: cache (according to Mike Thomas' types of state)
    and for single digits of seconds)
 - what to do if only some packets have HAO?
   (no answer, there is an opportunity to detect attacks but a drastic
    action will give a DoS issue)
 - what to do if there is not enough memory to handle the state?
   (drop the packet, this raises another issue)
 - trivial performance attack with rogue packets (force the
   additional of an OAH to any packet for the victim)
   (no answer)
 - etc: what to do with two different UnvHOA for the same H@
   (answer, drop the second one)
I believe the proposal is a good answer to indirect DDoS but is subject
to DoS attacks against itself: this is easy to protect the CN (just refuse
new UnvHOAs) but this is easy too to disable processing of UnvHOAs (one
only needs to flood the CN by UnvHOAs until the CN cache is full).
There is a second order attack (i.e. against the MNs which want to use
the CNs) with a limited lifetime (cache will be flushed after a short delay).
Of course, the addresses of attackers will be known and with a good ingress
filtering their locations too.
Finally the "2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS"
alternative is perhaps feasible...

Thanks

PS: a detail: is it required/useful to add a tag to every packets?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 19:25:31 +0100

> so we need an existence proof.
   
=> ahah! Something for implementors (:-).

   receiving a packet with HOA and no else.

=> this is the point where we disagree.

=> some kind of unreachable for administrative reasons...
I'd like to get a different code for UnvHOA collisions and
for other no more memory, etc, cases.

=> I agree you have to apologize to forget rate limitation against
a DoS attack without multipliers.

=> the whole flowinfo field is unused in fact (this is not the
good API, Itojun's proposal is many times better).

   Unfortunately I don't have the time, given the desired schedule.

=> like everybody in this list...

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 17:02:18 +0100 (CET)

> unverifiable care-of address.

Charlie,

How would this tagging work in particular how would it work with
protocols on top of UDP without requiring modifications to the socket API?

Later you talk about a UnvHOA cache - is the assumption that
a packet received with an unverified HOA would cause an entry to be created
in this cache? (if a matching entry doesn't already exist)

If so how could the CN behave when this UnvHOA cache is full?

> to the traceability of the care-of address.

If I was implementing a MIPv6 MN taking the above into consideration
it would seem like the way to minimize the risk of firewalls dropping
packets destined to the MN the prudent thing would be to only
send packet with HOA when it is known that the CN has a BCE.

So it seems like the net result of allowing the behavior would be the
same as with the design team's recommendation, with substancial additional 
complexity in the specification.
If this need for relaxing HAO processing on the CN is needed it can be
added later as far as I can tell.

> noticeable loss of responsivity.

Why loss of connectivity?
Before the BCE is established the MN and CN can communicate using bidirectional
tunneling. Do you count that as "loss of connectivity"?

>  Furthermore, if a correspondent

The design team's recommendation was talking about using an error notification
mechanism to handle this case.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 18:07:52 +0100 (CET)

Charlie,

Most UDP applications do not use connected sockets,
and all of the server ends (as opposed to client end) of UDP applications
needs to have a non-connected socket in order to accept UDP packets from
any sender.
DNS is no exception - a DNS server has a non-connected UDP socket
receiving packets from anybody.
A DNS client/resolver might use connected UDP sockets in some cases -
I think the BIND source code has some support for this.

So what would it mean to have a solution that only works for connected sockets?
Would a UDP packet with an unverified HoA sent to a non-connected UDP socket
be silently dropped? Cause an error to be returned? Something else?

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Feb 2002 10:30:21 -0800

> PS: a detail: is it required/useful to add a tag to every packets?

Hello Francis,

Jari M and I have the attached text on tagging HAO. It addresses the issue that
Pekka Nikander brought up. Comments would be appreciated.

Regards,

-Rajeev

ps. the state machine comes out better in the attachment.

                     To Tag or Not to Tag ?

I. Tagging 

A CN, in the absence of a BCE, includes the source IP address in the
received packet on out-going packets to the Home Address. The source
IP address (CoA) and the HoA can be stored in a small buffer; the
mapping could also be part of destination cache (cf. Francis Dupont's
note to the mailing list). This process of including the CoA in the
absence of an authorized BCE is called tagging, and the CoA thus
included is called the tagged entry.

II. Tagging requirements

a) should allow a MN to use unverified HAO
b) should allow non-mobile Generic Node (GN) to operate with no added
harm 

III. Basic operation

- always tag (with an exception below in IV.b) in the presence of
unverified HAO and in absence of authorized BCE. However, 

- when there is no HAO, the CN does not create HoA <-> CoA entry. This
applies for communication with a GN and when a MN is at home.

So, the solution has to be able to distinguish between a MN away from
home and a malicious node attempting to create a bogus tagged entry at
the CN. For this, 

IV. Basic CN rules:

a) packets without HAO overide the tagged entry
b) transition from ``no-tagging'' to ``tagging'' state is slow when a
remote node is actively communicating without HAO; - at
least `n' consecutive packets with HAO containing a particular CoA
must arrive before that CoA is added to the unverified BCE. However,
if the CN is creating a fresh destination cache entry, it does not
apply this rule so that ``cold start'' packets contain tags. 
c) transition from ``tagging'' state to ``no-tagging'' state is
immediate; a single packet without HAO removes the tagged entry; - a
randomized timer disallows creating the CoA entry again until the timer
expires. Moreover, the lifetime of a tag is short; unless recently
refreshed with HAO, CN transitions to ``no-tagging'' state. [Note:
this rule assumes that an attacker cannot spoof the MN's current CoA]
d) In the ``no-tagging'' state, the CN drops packets with HAO.

The CN state machine can be described as below. 

                    ------
                    |    | longer
                    |    V
                  ---------- 
                  |   no   |
                  |tagging |
                  |        |
                  ----------
                    ^    |
             faster |    | slower (for active communication)
                    |    | 
                    |    V
                  ---------- 
                  |        |
                  |tagging |
                  |        |
                  ----------
                    ^    |
                    |    |  shorter (unless refreshed)
                    ------

With this,

V. GN operation

a) when a GN is not in active communication, an attacker can create an
unverified BCE tagging the GN's address with a genuine or bogus CoA. 
	- before the CN does anything, if the GN _initiates_ packets to CN,
	the tag disappears
	- if the CN transmitts packets to the GN,
	GN's response (e.g., TCP ack, RTCP packet) will remove the tag
	from unverified BCE
	- if the GN's site is configured to filter packets containing
	the tag, those packets will be dropped. Since the lifetime of
	unverified BCE is small, the entry will expire unless the
	attacker keeps on refreshing the entry. In any case, this is
	similar to DoS today; the tag provides the option to inspect
	the ``true source'' of the packet.  

b) the attacker attempts to tag an entry during active communication
between a CN and a GN with the hope that the GN's firewall will drop
packets 
	- any packet transmission from GN to CN will force it not to tag
	- only when the GN is a ``one-way'' listener, and its firewall
	drops all tagged packets the GN would notice 
	disruption. However, such sessions are rare in practice, since
	if a GN is interested at all in the packet stream from CN, it
	has to act when it does not receive packets (for an extended
	stretch). It is likely that rate limiting the tagged
	packets will facilitate faster repair of the CN's unverified
	BCE.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 10:48:42 -0800 (PST)

> Binding Cache entry so that the care-of address would become

   I haven't been following closely, but I hope that 
   somebody's pointed out that:

   1) The home agent may be either non-existant or
      under the control of the attacker
   2) That a CN's stack which accepted home address
      options from an unknown source address would be 
      subject to a spoofing attack which defeats 
      ingress filtering.

   In short, this doesn't seem to increase security.

      Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 11:22:47 -0800 (PST)

Pekka Nikander writes:
 > Mike,
 > 
 > Would you please clarify what you are thinking.  I just
 > don't follow.

   It seems that there's a general proposition in the
   proposal that the Home Agent can protect a correspondent
   node from misbehaving MN's, and that will provide an
   adequate defense against misuse. The problem is that
   the CN generally has no trust relationship with the
   HA, if indeed the HA exists at all. 

   This seems like a permutation on my HA cookies draft
   which says that HA's can potentially be used as
   optimizations for security, but their existence
   are not certain, and when they exist, their
   trustworthiness must be considered to be the
   same trustworthiness of the MN.

			Mike

 > 
 >   > Charlie Perkins writes:
 >   >  > For UnVCoAs, more care is needed. <snip>
 >   >  > ... to tag outgoing packets with the
 >   >  > unverifiable care-of address.  ...
 > 
 > Michael Thomas wrote:
 > At least for me, the only purpose of tagging is to make
 > sure that whenever a CN replies to the HoA instead of CoA,
 > the CoA address is carried in the reply.  That indeed
 > has the danger that the CN sends a reply to an address
 > where an attacker, assumedly located at the CoA (or close
 > thereof), cannot send packets directly to.  However, this
 > can be noted and acted upon since the replies contain the
 > tag.
 > 
 > Thus, the tag does increase security in two ways:
 > 
 >      - it prevents information about the CoA
 >        from being lost at CN, thereby making traceback
 >        etc. easier
 > 
 >      - it allows packets to be filtered based on the
 >        existense or contents of the tag.
 > 
 > IMHO, these seem good enough that HOAs could again
 > be used with triangular routing.  Provided, of course,
 > that the tagging can be performed correctly in the
 > first place.  The suggestion by Rajeev and Jari M.
 > seem to achieve that, but at least I need to think about
 > it more before I can form my opinion upon it.  There
 > may be nasty details that we are still missing; I just
 > don't know.
 > 
 > --Pekka Nikander
 > 
 > 
 >

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Feb 2002 21:12:25 +0200

Mike,

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 21 Feb 2002 14:33:40 +0200

Mike,

Thanks for the clarification.

 >    same trustworthiness of the MN.

First, it looks like the implementation proposal by
Rajeev and Jari M. takes care of the case when there
is no HA at all.  It aims at protecting innocent non-mobile
nodes from attacks where somebody tries to cause their
packets to be inappropriately tagget so that they get
dropped by some firewall.

What comes to the trustworthiness of an existing HA,
I don't immediately see how it is relevant here.
As far as I can see, unauthenticated HAOs are mainly
a threat against "the others" in the internet, not
the mobile nodes or home agents.  The basic threat is that
somebody sends HAOs that contain a bogus HoA, and the
basic consequences include DoS against the node at
the claimed CoA and DDoS against the network at the
claimed HoA.

--Pekka

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2002 11:38:21 -0800 (PST)

> the claimed CoA and DDoS against the network at the

   I fear we might not be communicating here. It's
   not just the DoS attack. Any IPv6 node can add
   any HAO they want to add. Right now, there's no
   ingress filtering which prevents that, and I
   remain pretty skeptical there will be any time
   soon. As such, if a "CN" accepts a HAO which
   hasn't had some sort of bogosity test applied
   (RR, CGA, etc), a random non-mobile node can 
   launch a source-spoofing attack against a 
   random host. As far as I can see, better
   Home Agent policing doesn't help that
   attack at all since you cannot assume that
   there's any HA around.

   Thus, if the gold standard here is "do no more
   harm than the non-mobile case", I think that
   opening up a source spoofing attack which
   cannot be countered by existing ingress
   filtering is certainly adding harm. Since it
   doesn't seem likely that it is fixable, it
   becomes permanent harm, and thus I don't see
   that there's any choice but to add soft state
   and testing somewhere (probably the CN) to meet
   our gold standard.

	    Mike

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 22 Feb 2002 10:25:35 +0200

Mike,

[Please include my address in to or cc if you want
  to have timely replies.  Otherwise I'll read your
  reply later when I browse through the mailing lists.]

I think this is an important issue to understand
thoroughly, since some people really really seem
to think that triangular routing is beneficial,
and we are trying to find out a secure way of
doing triangular routing.

>                                        .... It's
>    random host.

So far I agree, even though I am not quite sure
what you mean with the "source-spoofing attack".
If you mean that the CN is under an attack since
may create a socket that is bound to the claimed
HoA instead of the (assumedly rpf-filtered) CoA,
yes, you are right.  That is the whole function
of Mobile IP, to create sockets that are bound
to one address and communicate with another address.
If you take that path, you can argue that the whole
Mobile IP is a security mistake. (If you take
that position, you may tempt me to agree :-) :-)

But, in this case, the CN decides (because of the HAO)
that it is really communicating with the HoA
instead of CoA.  However, since the CN doesn't _know_
anything about the whereabouts of the HoA, it MUST
reply to the HoA.  From my point of view, so far so
good.  Somebody says that it wants to talk to me,
and I reply to that somebody.

I agree with you that the problem has its root in
the fact that the HAO doesn't carry any topological
information, i.e. it is not likely to be ingress
filtered in any way.  Thus, it may be completely
bogus.  But, if it is, the replies the CN sends
will go to the bogus address.  Presumedly, if there
is somebody at the bogus address, that somebody is
not prepared to receive those replies, and will
drop them or send back an error message.

I think this is the stage people came to long ago.

Now, the new realization here is that the HAO
can be used as a vehicle for DDoS attack, as
initially noted I think by Pekka Savola and
discussed several times.  And the method Charlie
proposed is to carry a tag in the replies the CN
sends.  That is, each reply that a CN sends as
a result of processing a packet containing a HAO
will contain a new DO (say OAH for symmetry sake)
that contains the CoA from the received HAO.

This has two effects.  Firstly, it allows all packets
that carry the OAH to be dropped by firewall if
there are no HAs behind the firewall.  This is fairly
effective measure against the basic DDoS threat.
Secondly, it allows more complex filtering in the
case there is a HA, as Charlie pointed out.

 >    As far as I can see, better

Not quite.  The existense of the tag (the OAH option)
allows you to very effectively filter out all replies
that carry it.  Thus, if there is no HA, you just
drop all packets that carry the OAH.

>    filtering is certainly adding harm. 

I still don't quite see what is the source spoofing
attack you are discussing about.  If you are concerned
about the CN, see my argument above about the whole
purpose of Mobile IP.  If you are concerned about the
reply packets sent by the CN, with Charlie's tagging
proposal they *do* carry the same information as the
HOA-containing request packets sent to the CN.  Thus,
I see no difference there.

Please feel free to continue, there may be something
that I am missing.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Feb 2002 23:39:24 +0100 (CET)

Rajeev,

I'm trying to understand the tag-or-not.txt and I see terms that I
don't understand and that I think are important for better understanding.

	"actively communicating"
Is this a statement about 
 - some minimum number of packets send and/or received per time unit?
 - a statement about there being connections/session at a higher protocol
   layer?
 - something else?

	"creating a fresh destination cache entry"
Does this apply independently of the history i.e. what if the
destination cache entry was deleted 1 microsecond earlier due to
some garbage collection even on the node?

	"GN _initiates_ packets to CN"
I don't know what it means to initiate packets.
Did you mean "sends packets" or "initiates connections"?

Also, what is the intended behavior when a unverified HAO arrives for
a new HoA and there is no room for creating more cache entries that 
track the tag/no tag bit for a peer? 

Thanks,
  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Feb 2002 17:40:04 -0800

Hello Erik,

thank you for reading the document.

>  - a statement about there being connections/session at a higher protocol

I meant packets have been received recently (from the Generic Node without
HAO).

> some garbage collection even on the node?

An implementation must preserve the active working set of entries in its
destination cache when doing garbage collection..If the entry was deleted
because of lifetime expiration, then the new entry will require tagging.

> Did you mean "sends packets" or "initiates connections"?

sends packets.

> track the tag/no tag bit for a peer?

Good point. When an unverified HAO arrives and there is no room in the
unverified BC,
the CN drops the packet. In addition (to what we described in the document),
it should send a Binding Request indicating that the MN should use either
RO or BDT (depending on what CN implements).

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Feb 2002 10:25:46 +0100 (CET)

> I meant packets have been received recently (from the Generic Node without

OK.

> because of lifetime expiration, then the new entry will require tagging.

Is this a new requirement in order for the scheme to work?
RFC 2461 doesn't require the destination cache to contain the working set
since most information in the destination cache can be rebuilt
without sending packets. (path MTU is one piece of information that can't
be rebuilt.)

> RO or BDT (depending on what CN implements).

If the CN doesn't allow the RO, then for how long time should the MN
switch to BDT before trying to use an unverified HAO again?
There seems to be a non-trivial performance tradeoff hiding in here.
If the time until it tries again is too long then the communication
might not see much of the claimed benefits of triagular, but if it
is too short and the lack of space in the cache persists then there
will be a packet lost for each time it tries to use an unverified HAO.

> a) packets without HAO overide the tagged entry
I don't understand this rule. Are you saying that the reception of a packet
without HAO should not effect the cache? That would conflict with c).
Or are you saying that this should have some effect on something else?

Rule c) seems to say that unless the HAOs arrive frequently enough the
cache entry will transition to no-tagging state, which will cause
some packets to be dropped due to unverified HAO.
This doesn't seem to be very robust against packet loss.
At a minimum this time after which the state transition happens
needs to be known by the MN so that e.g. if the MN knows that it
sent the last unvHAO packet 10 seconds ago and the CN goes to no-tagging
after 7 seconds, it should not send another unvHAO.
But packet loss makes this hard. Continue assuming the CN goes to
no-tagging after 7 seconds.
If the MN sent the last unvHAO 4 seconds ago it should be ok to send
another one, unless the first one was dropped by the network.
How about if the MN sent unvHAO 2 seconds, 4 seconds, and 6 seconds ago?
Then it is pretty sure that the CN hasn't transitioned to no-tagging
state - it would only do so if there all 3 packets were lost.
Sounds tricky - in a sense the unvHAO rules on the CN serve as a potential
amplificator of packet loss in the network - packet loss in the network
can cause additional packet loss/drops at the CN due to no-tagging state.

Rule b) and c) seems to imply that if the MN happens to send a single packet
without HAO to a CN then some number of packets will be dropped by the CN
due to it having transitioned to no-tagging.
This is rather constraining. For instance, a MN might wish to reverse-tunnel
certain multicast packets with a HoA source thus those might arrive at
the CN without a HAO. (This could be "fixed" by having the state on the CN
be identified by the source (HoA) as well the destination address.)
The 1a packet in the RR exchange (used to create and refresh RO) would
also be reverse tunneled through the HA hence arrive without HAO.
This would potentially cause a glitch when a MN wants to switch from
using tringular to RO:
	MN sends data to CN using HAO - ok
	MN initiates RR exchange - sends 1a/1b
	CN receives 1a - transitions to no-tagging and sends 2a
	MN continues to send data to CN using HAO - dropped due to unvHAO
	MN recives 2a and 2b - sends BU to CN
	CN receives BU - creates BCE
	MN continues to send data to CN using HAO - accepted due to BCE
Thus there is one round-trip during which the CN will drop packets.

Of course, this can be "fixed" by adding more complex rules to the MNs
use of HAO.
But the complexity is already quite high IMHO.

   Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 26 Feb 2002 14:57:23 -0800

Hello Erik,

good feedback. I will answer your concerns below. Before that, let me provide
some clarification.

- our intention (original anyway) was to provide a mechanism that did no harm for
Generic Nodes (GN) and worked for Mobile Nodes (ref Pekka Nikander's note to the
list). I am glad that we are now discussing performance aspects and complexity of
implementation. Good.

- we see triangular routing as an option that serves two purposes. First, it is
an alternative to BDT when there is no BCE. Second, it can be a stepping stone to
RO.  If a MN runs into performance issues (which BTW, depends on the
implementation as you seem to rightly imply below), it should consider RO!

- finally, we can specify exactly how tagging needs to work. One could argue that
details amount to complexity; however, latent complexity in the absence of
details is far worse (and perhaps dangerous).

Now, onto the comments..

> without sending packets. (path MTU is one piece of information that can't

It is a requirement. BTW, could you clarify what you mean wrt to RFC 2461 ?
I have the following paragraph from 2461 that seems to indicate that the active
working set needs to be preserved when garbage collecting. Also, how do you
re-build destination cache entries without running "next-hop determination" ?
Perhaps I am missing something..

Section 5.3 in 2461.

"To limit the storage needed for the Destination and Neighbor Caches,
   a node may need to garbage-collect old entries.  However, care must
   be taken to insure that sufficient space is always present to hold
   the working set of active entries.  A small cache may result in an
   excessive number of Neighbor Discovery messages if entries are
   discarded and rebuilt in quick succession.  Any LRU-based policy that
   only reclaims entries that have not been used in some time (e.g., ten
   minutes or more) should be adequate for garbage-collecting unused
   entries."

> will be a packet lost for each time it tries to use an unverified HAO.

IF the CN does not allow RO, then the MN should wait for a random period of time
before attempting unverified HAO again. Typically, random timeouts (or even
exponential backoff) help given the stochastic nature of the issue. Of course,
the MN may decide to simply continue with BDT. I think the packet loss issue here
is trivial.

> Or are you saying that this should have some effect on something else?

Sorry, I am saying when a CN receives packet without HAO, it removes the tagged
entry (i.e., the CoA). This means if an attacker created a tagged entry using a
GN's IP address, then receipt of a packet from the GN would "repair" the entry so
that outgoing packets will not be tagged.

> can cause additional packet loss/drops at the CN due to no-tagging state.

This really depends on how you set the lifetime of the tagged entry. We thought
having it small would work well for an average case when the MN has packets to
send. It could be redefined taking expected packet transmission rate into
consideration. I would like to note that the MN loses a packet when there is
infrequent packet transmission _and_ network congestion; sort of a "bad" case. In
any case, a simple extension may allow the CN to use history to not drop the
packet.

> be identified by the source (HoA) as well the destination address.)

I didn't quite follow the text in parenthesis. Could you clarify ?

> Thus there is one round-trip during which the CN will drop packets.

Here, you could include a bit in 1a that indicates to the CN that the MN is using
unverified HAO. The CN would then not transition to the no-tagging state, and
subsequently no packet losses.

> But the complexity is already quite high IMHO.

I see your concerns are regarding performance. I think we can start with an
implementation note and then better understand values for configurable
parameters, mostly the lifetime of unverified BCE.

Thanks,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Feb 2002 15:00:31 +0100 (CET)

> - our intention (original anyway) was to provide a mechanism that did no
> harm for Generic Nodes (GN) and worked for Mobile Nodes (ref Pekka
> Nikander's note to the list). I am glad that we are now discussing
> performance aspects and complexity of implementation. Good.

Just to clarify where I am at.
I'm first trying to understand how and whether it works.
Then look at the complexity of the *protocols* and *mechanisms* to see if
I personally think the complexity outweights the benefits or not.

> - we see triangular routing as an option that serves two purposes. First, it
> is an alternative to BDT when there is no BCE. Second, it can be a stepping
> stone to RO.  If a MN runs into performance issues (which BTW, depends on the

Yes, you'd like to take multiple steps to get to RO - I might prefer
a single step to get to that desired endpoint :-)

> - finally, we can specify exactly how tagging needs to work. One could argue
> that details amount to complexity; however, latent complexity in the absence
> of details is far worse (and perhaps dangerous).

Agreed. Understanding all aspects of tagging is important to guage
the added complexity.

> I have the following paragraph from 2461 that seems to indicate that the
> active working set needs to be preserved when garbage collecting. Also, how
> do you re-build destination cache entries without running "next-hop
> determination" ? Perhaps I am missing something..

You used the term "must" which is a lot stronger than RFC 2461
which talks about "care". And some of the language in that paragraph
is incorrect in that discarding destination cache entries does not
cause additional neighbor discovery messages - discarding *neighbor* cache
entries too early will cause that.
Next-hop determination is a local operation on the node.
Thus per RFC 2461 a node can made the tradeoff between the space consumed
by neighbor cache entries and the CPU time to recreate them by doing
next-hop determination again.
When doing so the node should take care to avoid discarding entries that
have a path MTU less than the interface MTU, but RFC 2461 doesn't talk about
that.

> IF the CN does not allow RO, then the MN should wait for a random period of
> time before attempting unverified HAO again. Typically, random timeouts (or
> even exponential backoff) help given the stochastic nature of the issue. Of
> course, the MN may decide to simply continue with BDT. I think the packet
> loss issue here is trivial.

I think the issue is important. The goal of using triangular is to get
some better performance without resorting to RO. If an MN that tries
to get this performance benefit in reality sees a performance degradation
because it needs to do random tries (causing packet loss) in order to
get a cache entry on the CN, then why would an MN try this at all?

So responding to comments about performance issues not being important
when the whole purpose of the scheme is a performance optimization
isn't productive IMHO.

> Sorry, I am saying when a CN receives packet without HAO, it removes the
> tagged entry (i.e., the CoA). This means if an attacker created a tagged
> entry using a GN's IP address, then receipt of a packet from the GN would
> "repair" the entry so that outgoing packets will not be tagged.

I now understand.

> This really depends on how you set the lifetime of the tagged entry.

How so? Replace the "7" above with any other number between zero and infinity 
and what is different?

> We
> thought having it small would work well for an average case when the MN has
> packets to send. It could be redefined taking expected packet transmission
> rate into consideration. I would like to note that the MN loses a packet
> when there is infrequent packet transmission _and_ network congestion; sort
> of a "bad" case.

I'm told wireless links cause packet loss unrelated to network congestion.

> In any case, a simple extension may allow the CN to use
> history to not drop the packet.

More complexity?

It seems like at a minimum the MN needs to know for how long it can assume
the CN will keep the cache entry. Do you agree?

> I didn't quite follow the text in parenthesis. Could you clarify ?

The writeup doesn't explain what is the unique key that is
used to identify a cache entry.
Is it the CoA? The HoA? Any of those combined with the destination (CN)
address?

> Here, you could include a bit in 1a that indicates to the CN that the MN is
> using unverified HAO. The CN would then not transition to the no-tagging
> state, and subsequently no packet losses.

Yep - adding that piece of complexity would take care of this special case.

> parameters, mostly the lifetime of unverified BCE.

I personally feel I need to get a more complete picture of what the proposal
actually is in more detail so that I can personally evaluate whether I think 
the benefits outweigh the complexity.

  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 27 Feb 2002 11:05:59 -0800

Hello Erik,

> when the whole purpose of the scheme is a performance optimization

Oops.. I didn't mean to imply that perfromance is not important. In this
particular case (i.e., the CN does not support RO), when the MN receives a
BR with request for BDT, I think the MN should continue using BDT for a
random period and try again. Just as there might be packet loss again, there
might not be any packet loss. In fact, I think using a random timeout helps.
Another thought: the CN could actually process this particular
packet (i.e., not drop it) _without_ creating an unverified BCE and then
generate a BR.

> How so? Replace the "7" above with any other number between zero and infinity

If you set the entry large enough, inspite of infrequent packet
transmission and packet losses, the CN would still be in tagging state.

> I'm told wireless links cause packet loss unrelated to network congestion.

Point taken. Even so, transport level retransmission would get the packet out to
CN.
Since bit errors are the predominant reason for packet loss in wireless, a scheme
such as udp-lite could greatly improve reliability even when there is no transport
level retransmission.

> > history to not drop the packet.

It depends on how you see it. Just as you keep the PMTU when you purge, you can
keep a flag associated with the tag indicating recent entry expiration.

> the CN will keep the cache entry. Do you agree?

It certainly helps if the MN knew about this. I don't know how best to convey this
to the MN..If it didn't, the protocol should still work with the caveat that a
packet would
be lost. But, if we can live with the CN not dropping it (e.g, because it has
history),
may be that's another option. I need to think this through further.

> Is it the CoA? The HoA? Any of those combined with the destination (CN)

HoA is the key. CoA is the tag.

> Yep - adding that piece of complexity would take care of this special case.

More generally, if non-HAO packets are due to mobility signaling, then we can
handle them in the above fashion.

> the benefits outweigh the complexity.

Ok. I will give the write-up a try. In the meanwhile, Charlie's original text
described the tagging proposal. I also have some other text (other than
tag-or-not.txt)
that I will include in the write-up.

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Feb 2002 10:22:12 +0100 (CET)

> packet (i.e., not drop it) _without_ creating an unverified BCE and then

I don't think that addresses the robustness problems I see.
Let's draw parallels between the unvHAO cache and the binding cache.
Both are going to be of finite size thus there will be cases when a new
entry can't be made.
In the BC case this will be signalled to the MN - the BU will receive a BAck
with a failure code. Thus the MN will actually know whether it has an entry
in the BC or not (subject to the CN not crashing or otherwise loosing all
state).

In the unvHAO case the MN seems to need to operate in pray and hope mode -
it sends a packet with a HAO and hopes that there is room for an unvHAO cache
entry.

I see two ways of making this more robust:
1. An explicit roundtrip between the MN and CN to create the unvHAO cache entry
   i.e. the MN will get an ack when the entry has been created. This
   means that no packets will be dropped by the CN (subject to the CN not 
   crashing or otherwise loosing all state).
2. An unvHAO arriving when there isn't room to create a cache entry results
   in an error going back to the MN.
   This means that one roundtrip worth of data packets can be dropped by the CN
   until the MN is notified to stop sending HAO packets.

> > How so? Replace the "7" above with any other number between zero and
infinity > > and what is different?
> transmission and packet losses, the CN would still be in tagging state.

That doesn't change any fundamentals - merely what frequence of communication
is subject to the loss propagation/expansion.
For instance if the unvHAO cache lifetime is one day then applications which
look for the news once per day would be subjected to this loss expansion.
And you've said the lifetime needs to be fairly short so I don't think
one day makes any sense - I believe we are talking about lifetimes that are
less than a few minutes, right?

> Point taken. Even so, transport level retransmission would get the packet
> out to CN.
> Since bit errors are the predominant reason for packet loss in wireless, a
> scheme such as udp-lite could greatly improve reliability even when there is
> no transport level retransmission.

I can't tell whether you agree with my point that the unvHAO logic
you've expressed is causing loss expansion in some cases where 
packet loss will cause the unvHAO cache entry to time out causing packets
to be dropped by the CN.

I also can't tell whether you agree with my point that the MN needs to know
how long its unvHAO will we kept by the CN in the absense of the CN 
receiving any matching packets.

> It certainly helps if the MN knew about this. I don't know how best to
> convey this to the MN..If it didn't, the protocol should still work with the
> caveat that a packet would
> history), may be that's another option. I need to think this through further.

Do you have a staw-man proposal for how the history would work?
How much information are we talking about? How is it maintained by the CN?

> HoA is the key. CoA is the tag.

In that case my point applies.

> handle them in the above fashion.

Yes, this could all be special cased.
But it doesn't address other cases of non-HAO packets.
My other example was a multicast packet sent by the MN that, for whatever
reasons, is reverse tunneled.
The MN doesn't even know that this particular CN is a member of the multicast
group. Yet the reception of that non-HAO packet causes the erasure of the
unvHAO cache which will cause packets with HAO to be dropped.

Special cases isn't necessarily the best path forward IMHO.

> tag-or-not.txt) that I will include in the write-up.

Great.
  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 28 Feb 2002 14:25:12 -0800

> in the BC or not (subject to the CN not crashing or otherwise loosing all

I mentioned that the CN sends a BR indicating to the MN to use RO or BDT.
May be it was not clear..

>    until the MN is notified to stop sending HAO packets.

This error message is what I meant by sending a BR. May be the same BR can also be

sent when the entry is created (1 above); on the other hand, that may not be
necessary.

> less than a few minutes, right?

Yes. It appears that we are looking at the issue from slightly different angles.
Since
packet loss when the MN sends HAO when there is no entry in the CN is the issue,
let me propose the following: the CN does not drop those packets. Instead, it does
not
tag the first few packets until it moves to tagging state. So, the downside is the
receiver
does not know the source for say 3 packets. What do you think ?

> packet loss will cause the unvHAO cache entry to time out causing packets

I agree. I might not agree with the rate of such occurrence. Also, if we can allow

the CN to not drop those packets (say the CN is in a standby state before it moves

to no-tagging state) then that might be a good compromise.

> receiving any matching packets.

I mentioned this is useful (see below).. What if the BR is sent when the entry is
created and it includes a lifetime field ?

> unvHAO cache which will cause packets with HAO to be dropped.

Actually, in the multicast case, the destination address is not the CN's address.
So the following rules will do when removing the unverified BC.

         if (srcIPaddr == HoA)
             if ((not a MIP packet) && (dstIPaddr=self))
                 remove tag

Regards,

-Rajeev