Subject: [mobile-ip] Home Address Option: design team recommendation

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Feb 2002 01:05:28 +0200

The MIPv6 security design team is trying to resolve the issues
around potential Denial-of-Service vulnerabilities regarding
the Home Address Option.

This note specifies the design team'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 each of our three
separate recommendations whether they AGREE, CAN TOLERATE, or
DISAGREE with them. In case of DISAGREE, please explain why.

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

The main problem with the Home Address Option (HAO) is its
potential to be used as a part of Denial-of-Service
attacks. More precisely, the Home Address Option helps
the attacker to conceal his or hers location.

1.1. BASIC ATTACK

The basic attack can be performed as follows:

1. Pick a victim host or network.

2. Pick any large set of other IPv6 nodes. There are no other
    requirements for the selection of these nodes beyond them
    having to be reachable from the Internet.

3. Send IPv6 packets with Src=attacker, Dst=reflector,
    HOA=victim. Here reflector is one of the chosen IPv6
    nodes, possibly a different one for every sent packet.
    The source address can be the attacker's own address.
    The attack can be launched from a single host, or
    be performed as a distributed attack.

4. Each reflector will process the IPv6 packet and respond.
    The responses would typically be ICMP errors, ICMP
    responses, UDP responses, or answers to TCP SYNs. Typically
    at most a single packet is sent as as a response. (In a
    variation of this attack, a reflector whose TCP sequence
    numbers can be guessed some amplification can be achieved.)

5. Since the MIPv6 rules require CNs to use the Home Address
    in return traffic towards the MN, the responses are sent to
    the victim's address. The victim sees packets that have
    Src=reflector, Dst=victim, and there is no indication of
    the original source address.

1.2. SERIOUSNESS OF THE ATTACK

The effect to the victim is that the hosts or the networks
Internet connection is filled with traffic. Since a reflector
is used, only replies can be sent and hence it may not be
possible to cause any much more trouble than the consumption
of communication resources. There is also no amplification
involved. On the other hand, the attacker can pick any
protocol to perform the attack, and the number of possible
reflectors is not limited to some special set of nodes such as
the DNS or web servers. In particular, the reflector nodes can
be private PCs and equipment without e.g. easy administrative
contacts, network monitoring, or logging of the used source
addresses.

The main problem, however, comes from our (in)ability to
prevent these attacks. The two basic approaches to dealing
with Denial-of-Service attacks include ingress filtering,
which prevents the use of wrong addresses, and tracing schemes
such as itrace that can be used in post-mortem analysis of the
attack. Ingress filtering is partially deployed in today's
IPv4 world, and this can be expected to continue in the IPv6
side. Tracing schemes are not yet deployed, at least not
widely.

Normal, stateless and filter-based ingress filtering can't
deal with these attacks. This is because by definition of the
HAO, its value can't be expected to be local to the network
where it is being sent from.

Tracing schemes as defined today can't deal with these attacks
either. Regular forward itrace, for instance, would only send
ICMP trace packets to the reflector on the first leg of the
path, and to the victim on the second leg of the path. But the
victim would not learn of the attacker's location due to the
existence of the reflector in between. A reverse itrace helps
trace back reflector attacks where the attacker has spoofed
the source address, but in this case this would not work as
the source field is not the victim.  A hypothetical extension
to itrace, "3-way itrace", could though be defined to send
ICMP trace packets to (a) destination, (b) claimed source, and
(d) claimed home address.

It seems therefore that ingress filtering is not sufficient
here, but a 3-way itrace might be. This is, however, just the
start of the hard part: allowing attacks that bypass ingress
filtering but are still caught with 3-way itrace could be
considered dangerous. Ingress filtering is by nature a
prevention mechanism while tracing is an analysis tool.
There's also three substantial differences between them:

- Ingress filtering is partially deployed while itrace is
   not.

- Victim needs to wait more in itrace to figure out what's
   going on.

- Most importantly, since itrace doesn't force you to use a
   specific IP address, it will not be possible for the victim
   to act quickly by e.g.  installing a filter in his network
   or his ISP's network to block the offending IP
   address. Instead, the victim must wait until the ISP or the
   policy on the other side of the globe acts and installs a
   filter on their site to block the attacker's link or
   computers. This could be time consuming.

There are other concerns around IPPT, a new technique similar
to itrace and a soon to be WG in the IETF. IPPT works by
hashing each individual packet so that an authorized user
(e.g. the NOC or a customer calling the NOC) can ask questions
about a single recent packet.  The hash takes into account
such things as the TCP sequence numbers, the length of the
packet, etc. (but ttl is excluded since it changes in the
network). This means that any "transformation" needs
additional state. Example of transformations are IPv4
fragmentation by routers, encapsulation and decapsulation. The
entities that perform the transformations need to be part of
the IPPT system and collect this information to prevent
packets from disappearing. Thus a host processing a HAO and
then reflecting e.g. a TCP SYN would need to be part of the
IPPT in order to be able to use IPPT to traceback through that
reflector.  Of course, we don't do this for normal reflectors
but they are more predicable since they don't loose the IP
source address.

In conclusion, the crux of the matter is the impact on ingress
filtering. The design team would be hesitant to "bid down" our
ingress filtering protection and settle for itrace, even if
trace was deployed now. It also seems unlikely that HAO
support can be built for other methods such as IPPT. The
design team recognizes that ingress filtering is not fully
deployed and probably never will be. Still, we feel that the
possibility to use ingress filtering in an effective manner
should be retained even in IPv6 networks.

1.3. PRACTICAL EFFECT

The practical effect of the introduction of the HAO to the
Internet is that attackers can launch DoS attacks where the
victims have no practical ways to quickly disable the attack.
Even tracing of the attacker becomes hard; the tracing is
possible but can be slow and would require widespread
introduction of a technology which is just in its development
phase. Existing and future ingress filtering tools are
rendered largely useless, at least as far as protocol
responses are considered.

Compared to some other existing DoS attacks, the HAO
reflection attack compares as follows:

- This is a smaller problem than publicly open IP-in-IP
   tunneling, since through HAO we can only run responses.

- This is a bigger problem than regular source address
   spoofing attacks, because they can be prevented with
   ingress filtering (and are also detectable with current
   itrace mechanisms).

1.4. FURTHER BACKGROUND INFORMATION

Further background information on the security issues around
MIPv6's use of the Home Address Option can be found from
draft-savola-ipv6-rh-ha-security-01.txt, draft-dupont-ipv6-
ingress-filtering-00.txt, as well as in the mailing list
discussions. Reflection attacks in general are treated
extensively in

     http://www.aciri.org/vern/papers/reflectors.CCR.01

2. ALTERNATIVES
===============

The alternative decisions we can arrive at are the following:

(a) Decide that the threat is not significant.
(b) Apply infrastructure-based ingress filtering
(c) Apply infrastructure-less ingress filtering
(d) Allow HAOs only in conjunction of existing bindings (or
     IPsec SAs)
(e) Additional information copied to the reflected packet

2.1. THREAT IS NOT SIGNIFICANT

While the exact nature and seriousness of the threat may be
discussed, it seems that the "do no harm" principle is not
fulfilled. This is because the threat appears harder than the
one caused by regular source address spoofing.

2.2. INFRASTRUCTURE-BASED INGRESS FILTERING

Intermediate routers and firewalls could be made more
intelligent in order to still be able to continue to perform
the ingress filtering task. The question is how?

In infrastructure-based ingress filtering this is done this
with the help of a global infrastructure such as AAA. Upon
requesting access from a challenging router, a node
authenticates itself, the router uses the global
infrastructure to get the node's home organization to verify
the authentication. In doing so, the home network supplies
also a correct Home Address to the visited network.  This
information is used to open a "hole" to the ingress filtering
system at the visited network.

It may not be obvious why a global infrastructure is needed,
and to what extent. First, the global infrastructure is needed
in order for the authentication of the MN to be
verified. Otherwise, anybody could claim to be the rightful
owner of some legitimate Home Address somewhere else. Second,
both the visited and the home domains must be under the same
infrastructure. This implies a SOHO user could not get access
when he is visiting a big ISP, unless the SOHO user was also a
member of the roaming association of the ISPs. Obviously, the
SOHO user could be served by an ISP and perhaps the ISP
authentication procedures could be applied here. It turns out
that this isn't always possible. For instance, DSL providers
may rely on authentication procedures which require nodes to
be reachable at given fixed locations in their topology.  This
would preclude authentication of any node or user away from
its usual location. Providers may also have no authentication
at all.  With the advent of grass roots, self-organizing or
impromptu networking (typically using wireless LAN technology
to produce a patchwork of network connectivity), many users
will not be serviced by traditional ISP's. These users would
not be able to use such an infrastructure-based ingress
filtering.

As a result, only a subset of all users in the world would be
able to use this improved ingress filtering. What would be
done with the others? It seems that where ingress filtering is
deployed, it would be necessary to prevent the use of MIPv6
altogether for users who do not belong to the infrastructure.
This is because it may not be possible to differentiate between
the dangerous use of HAO and its safe use in conjunction with
Route Optimization (see 2.4).

Ingress filtering should also be as deployable as it is IPv4,
which means multiple places as well as higher up in the
hierarchy than a single Access Router or local firewall. This
sets additional requirements on the challenging router can
authentication the user; it may not be under the same
administration as the Access Router that gave access to the
MN.

The main benefit of this scheme is the level of control it
allows. The drawbacks include the introduction of a large
global infrastructure, the elimination of certain user groups
from being able to benefit from MIPv6, and the inability of
the global infrastructure to deal with e.g. RFC 3041
addresses.

2.3. INFRASTRUCTURE-LESS INGRESS FILTERING

A better way would be to come up with an ingress filtering
scheme that does not require a global infrastructure. We note
that such schemes appear to have to be based on similar
principles as the Route Optimization is based on. This is
because the infrastructure and the RR/CGA methods are the only
known ways to have some assurance of address ownership. While
rate limitation and other mechanisms can reduce the problems
associated with HAO reflection, they don't appear to be able
to solve them altogether. The hard problems in rate limiting
are determining what is reasonable rate a the location of the
limiter, and the attacker's ability to use a large number of
different reflectors.

Without going to the detailed signaling involved in the use of
RR or CGA to prove address ownership to a challenging router,
the basic scheme is as follows:

   1. Send a message to the CN
   2. The message is intercepted by the challenging router, and
      an authentication request is sent to the MN
   3. MN uses an RR or CGA method to prove ownership to the AR,
      just as if challenging router was a CN
   4. A filter is installed in the challenging router so that packets from
      the MN can not get past that router.
   5. The MN retransmits the packet that the challenging router
      dropped in Step 2.

Benefits of this scheme include keeping the current ingress
filtering model but extending it to do more. Theoretically,
this scheme would also allow the elimination of the HAO from
packets altogether (by simply using the HoA as the source, and
expecting routers to challenge this if necessary), which would
reduce the size of the packets in MIPv6.

The drawback of this scheme include the following.

- Deployment: it expects increased network support, which may
   delay introduction of MIPv6.

- Scaling: Instead of having a single ingress filter rule per
   prefix, the routers need to have per MN information to track
   which HAO each MN can use. New DoS attacks are opened
   against the routers because of this.

- Delay: There is delay due to the router's challenge.
   Multiple challenging routers in the path create additional
   delay. There might also be potential DoS issues around bogus
   challenges injected by random off-path nodes - the MN has no
   idea what nodes are routers on the path.

- Architectural: Should we select end-to-end or network
   centric approaches? Generally the network centric approaches
   do not scale as well as end-to-end mechanisms, and may be
   deployed slower.

2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS

If all CNs ensure first the validity of the Home Address claim
using e.g. RR techniques, HAOs can be accepted. The result of
this is that in order to send packets directly from a MN to a
CN the CN needs to have state about the MN. Thus in effect the
choices are either RO (packets in both direction take the
direct path between MN and CN) and bidirectional tunneling
(packets in both directions go through the HA). Thus it would
not be possible, without creating some authenticated state on
the CN, to send packets directly from the MN to the CN.

The benefit of this scheme is its zero need for network
support, and its end-to-end nature. The main drawbacks are the
elimination of triangular routing, and the change in the
nature of the BCE state (discussed below in 2.4.1).

A variation of this approach is that HAOs could additionally
be accepted also if there's an IPsec SA between the MN and the
CN. (In this case, however, the SA must be established using
traditional means such as local PKIs and newer research
results on self-signed certificates or opportunistic IPsec
would not suffice here.)

2.4.1. NATURE OF BCE STATE

The nature of the BCE changes a bit if alternative 2.4
is adopted. An expired BCE changes more than the routing
of the packets. In the current MIPv6 specifications, the
expiration forces the return packets to take the route
via the HA. But if alternative 2.4 is adopted, an expired
BCE causes any traffic with a HAO to be dropped upon
reception, causing packets to be blackholed until the
MN notices this condition.

A few observations of the effects can be made:

- The traffic does not get dropped if the MN and CN have the
   same understanding of the length of the expiration period.

- A CN that has to throw away BCE entries due to lack of
   memory or some other reason might cause this. Perhaps one
   could argue, though, that it would make more sense to
   allocate a fixed size memory pool for Route Optimization,
   making it possible for the CN to guarantee a BCE entry
   lifetime and refuse new RO requests. However, this would
   limit the ability of the CN to dynamically decide that a new
   BCE entry is more important than an existing one, and to
   throw away the existing before it has expired.

- However, a CN that reboots can still cause this. The effect
   is significant naturally only if the CN can get back to
   operational status soon enough to even be able to drop
   packets. (Note that RR protected BUs are expected to have
   lifetimes of at most few minutes, which limits the duration
   of the resulting condition.)

In conclusion it is necessary to deal with the situation in
some manner. There are different ways of dealing with this but
the design team proposes the following scheme.

A HAO with no matching BCE entry generates an ICMP error
message. The message is sent to the source of the packet,
i.e. the CoA. This guarantees that there will be no additional
reflection problems because of this.

It may be possible for attackers to spoof these messages from
the path, or possibly also off-path (it isn't clear that
implementations are expected or even can check for TCP
sequence numbers inside the ICMP packet).  This would have the
effect of forcing an unnecessary new RR exchange, or possibly
disabling RO altogether. Like all ICMP spoofing this requires
that the attackers can lie about their source addresses.
However, this attack does not appear to be any more severe
than MIPv6 offers in any case for RO. For instance, an a
spoofed ICMP Destination Unreachable would cause a CN to
revert back to using the HA path.

2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS

In this alternative, a traceback of the attacker is performed
by having the CN include additional information in the
reflected packets. In particular, the CN could include the
claimed source address of the original packet in the response,
e.g. in the "OAH Destination Option".

This approach is an easy one to provide within the MIPv6
specifications. A disadvantage is that it helps mainly for
traceback, and does not help as much prevention -- for
instance the victim's ISP could not filter the attacker's
packets using IP source address, but would have to look at the
option. (Prevention may still be possible, but could require
additional functionality in e.g. routers and filtering
firewalls.) A larger drawback of this scheme is that there are
IPv6 socket API implications, at least for UDP applications,
in order to ensure that the response sent due to a request
containing a HAO always contains a OAH option.

3. DISCUSSION
=============

The design team feels that the a great danger for MIPv6
deployment is that it is perceived as insecure. This is
particularly true after the widely known events that have
taken place in the IETF for MIPv6 since December 2000. Any
special conditions regarding what service providers need to
get in order to allow MIPv6 securely in their networks is
likely going to reduce the number of MIPv6 users. Therefore,
we feel that potential dangers in HAO should be considered.

The design team does not feel IFB solutions are acceptable as
a condition for MIPv6's use. MIPv6 will have the largest user
base if it doesn't require additional infrastructure in the
visited locations or in the home networks.

We'd also like the Internet to use end-to-end mechanisms
rather than network assistance, especially if there are
scalability concerns in the kind of assistance required. The
end-to-end principle isn't just an architectural rule, it will
also ensure that we can deploy our things without waiting for
providers to catch up.

4. RECOMMENDATION
=================

The design team notes that the resolution to this seemingly
small issue has major ramifications to the MIPv6 architecture.
It affects the topology of the routes the packets take; it has
a node vs. router functionality decision; it has an IFB
vs. IFL decision.

The design team recommends alternative d to be applied (R1).
We expect MIPv6 deployment to be soonest and largest if we
choose d.

The design team recognizes that moving non-RO traffic to
bidirectional tunneling has consequences. We do not believe
the technical consequences to delays etc. are significant. It
may be in fact be a cleaner approach to have a 2-level
solution and the RO deployment may grow because of
this. However, there are non-technical consequences. In
particular, the MIPv4 experience indicates that pure
bidirectional tunneling may result in leaving the Route
Optimization functionality behind in the standardization
process, and become less widely if at all implemented. Due to
these considerations, the design team additionally recommends
that (R2) MIPv6 bidir and RO parts be kept in the same RFC and
advanced at the same time, and (R3) RO should be required to
implement in all IPv6 nodes, as implied by RFC 1726.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Feb 2002 09:48:57 +0200 (EET)

> 1. INTRODUCTION

Note: this can also be used for spoofing attacks (e.g. exploits in
stateless protocols like UDP (unless TCP sequence numbers are guessed))
unless destination site implements a firewall policy that examines HAO of
the packet and rejects it if it belongs to the site provided that it isn't
a Home Address of a roaming local node.

I don't think all that many firewalls will implement checks like this.

> containing a HAO always contains a OAH option.

Note: this could be implemented in a similar fashion as routing header: 
"segments left" decremented and if it reaches 0, the option would no 
longer be processed.  However, as it seems ADA will be preferred over 
RH#1, these kind of semantics probably don't make sense.

-- 
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: [email-masked]
Date: Tue, 12 Feb 2002 17:02:40 +0100

Hello Jari,
isnt this a case where the "tool concept" way of designing things in the
internet
proves backsides. I mean, you cannot both have generic concepts and flexible
ways to compose and construct things and yet still think that it will be
secure,
especially for all possible kinds of attacks.
So isnt it possible that the basic way of design should be narrowed down for
the ways to create mobility.
Just a thought
BR Georg

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 23:03:14 +0100

1. INTRODUCTION
   ===============
   
   deal with these attacks.

=> (CLARIFICATION, DISAGREE) stateless and filter-based ingress
filtering is assumed up to the end of the introduction.
I understand that "ingress filtering" is already very long to type/read
but this should make clear or some next statements are at least
misleading.

=> (ISSUE) the attack against anti-spoofing filtering (i.e.
HAOs with the Home Address (H@) inside the site) is not addressed and
is a *real* security problem if such H@s are valid, i.e. there is
a Home Agent (HA) in the site.
   
   2. ALTERNATIVES
   ===============

=> (ISSUE) you make the assumption that the verification of
the H@ is critical:
 - there is no proof (no argument in fact) of this
 - unicast RPF check ingress filtering never requires the
  verification of source addresses, it just checks if
  source addresses are plausible (aka topologically correct)
 - (note: if you maintain this opinion, can I explicitely
    quote you in my to-write draft "RFC 3041 considered harmful"?)

   In infrastructure-based ingress filtering this is done this
   with the help of a global infrastructure such as AAA.

=> (CLARIFICATION) My draft tries to make clear that such
a global infrastructure is better but not necessary.
So this alternative doesn't reflect what I proposed.

   allows.

=> of course, a stronger hypothesis should give a stronger result (:-).

   known ways to have some assurance of address ownership.

=> (CLARIFICATION) this introduction shows clearly you think
the HAO solution must solve the address ownership problem too.

=> even the author of this proposal recognized it is unfeasible.

   A variation of this approach is that HAOs could additionally
   be accepted also if there's an IPsec SA between the MN and the CN.
   (In this case, however, the SA must be established using
   traditional means such as local PKIs and newer research
   results on self-signed certificates or opportunistic IPsec
   would not suffice here.)
   
=> (ISSUE) I disagree with this statement: if the SA uses the H@
(in fact it must because of the HAO with IPsec processing rule)
or the packet is fake and IPsec processing will reject it,
or the packet is not fake and IPsec processing will by side effect
prove the authenticity of the source. Of course (but this should
be a standard IPsec requirement) the IPsec transform should include
authentication.
The self-signed certificates & co stuff has nothing to do here,
if someone is ready to accept unsafe ways to establish IPsec SAs
he is ready to manage protected tunnels with unknown "road warriors"...
PROPOSAL: HAOs could be accepted as soon as the CN can verify
the validity of the H@:
 - using BCE (Co@ (in IPv6 header) and H@ (in HAO) match the BCE)
 - using IPsec SA which uses the H@ as the source address selector
  (the knowledge of the sharedsecret(s) of the SA proves the source
   of the packet, the source address in the IPv6 header does *not* matter)

The only possible problem with IPsec is DoS against the authentication
computing but this threat is already in IPsec with or without HAO
(reread RFC 2401 5.2.1 if you don't know why).

   
=> basically BCE state will become hard state.

=> (CLARIFICATION) I'd like to get the (obvious) consequences
for Binding Acknowledges (should be required) and
Binding Requests (still useful? the opposite (binding done?) more
interesting?).

   
=> (CLARIFICATION) This should be handled automatically, i.e.
by the kernel. So there are immediate issues:
 - what kind of state? how long to keep it?
 - what to do if only some packets have HAO?
 - what to do if there is not enough memory to handle the state?
 - trivial performance attack with rogue packets (force the
  additional of an OAH to any packet for the victim)
etc.

   A larger drawback of this scheme is that there are
   IPv6 socket API implications, at least for UDP applications,
   in order to ensure that the response sent due to a request
   containing a HAO always contains a OAH option.
   
=> (ISSUE) This is based on an incorrect assumption about
possible implementations. Of course this solution is unfeasible
if it is not transparent to applications...

   3. DISCUSSION
   =============
   
   4. RECOMMENDATION
   =================

=> CAN TOLERATE (R1)

   The design team recognizes that moving non-RO traffic to
   bidirectional tunneling has consequences. We do not believe
   the technical consequences to delays etc. are significant. It
   may be in fact be a cleaner approach to have a 2-level solution

=> (CLARIFICATION) you should exhibit a case where such a 2-level
solution for a security problem did work (good luck :-).

   Due to these considerations, the design team additionally recommends
   that (R2) MIPv6 bidir and RO parts be kept in the same RFC and
   advanced at the same time,

=> CAN TOLERATE (R2)

   and (R3) RO should be required to
   implement in all IPv6 nodes, as implied by RFC 1726.
   
=> DISAGREE (R3): this kind of requirement is *not* in the scope
of the mobile-ip WG. It is clearly the job of the IPv6 WG.
The only acceptable thing is a recommendation from the mobile-ip WG
to the IPv6 WG to consider such a requirement for all IPv6 nodes.
BTW it will be fine to exactly describe what is required and
what is not required, same for default configuration, etc.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 23:20:04 +0100

=> agree: this point was completely missed...

=> the proposed solution (R1) has to prove to be a solution of this
(I believe it is the case but this seems to be an argument against
CGAs without RR)

   longer be processed.

=> nice semantics but the packet is not forwarded, just responded to...

   However, as it seems ADA will be preferred over RH#1,

=> not yet done!

   these kind of semantics probably don't make sense.
   
=> your proposal saves one option type (waouh!) and makes detection
of reflection attacks very easy (reception of burnt HAO when the node
is not mobile)...

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Feb 2002 00:19:45 +0200

Francis, thanks again for your in-depth comments! Some quick

>    of the packet, the source address in the IPv6 header does *not* matter)

Does this mean that you propose HAOs to be accepted either because
there's an IPSec SA or because there's a BCE, and bidir tunneling
otherwise? I think I could AGREE with that.

> if it is not transparent to applications...

True, but you yourself listed some issues with the kernel
approach. We didn't see a way out so we didn't consider
it further. But it isn't certain that there's no way out.
Do you see answers to your questions above, and a technical
kernel solution? If yes, let's discuss it!

> to the IPv6 WG to consider such a requirement for all IPv6 nodes.

Yes, AGREE... I think this was roughly what we meant though the
text didn't exactly come out so.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 15:38:20 +0100 (CET)

> => basically BCE state will become hard state.

Per what definition of hard and soft state?

There is a definition of soft state in RFC 2205 which says:
   o    Soft state

        Control state in hosts and routers that will expire if not
        refreshed within a specified amount of time.

Since binding cache entries expire if not refreshed they seem to be
soft state per the above definition.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:43:23 +0100 (CET)

> to the IPv6 WG to consider such a requirement for all IPv6 nodes.

It would seem to be useful to determine whether we have rough concensus
in the MIP WG to mandate this *before* we ask the IPv6 WG
(as well as the rest of the IETF community) for their opinions.

I take it your DISAGREE in due to the procedural concerns.

Do you agree or disagree that the MIP WG should recommend to
the IPv6 WG that we think this should be mandatory in all IPv6 nodes?

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2002 15:44:01 -0800 (PST)

> soft state per the above definition.

   In fact, there are three different kinds of 
   state:

1) cached state
2) soft state
3) hard state

Route optimization was in class (1). Requiring
that HAO's not be accepted until there be a RR etc
test first pushes it into class (2). It was my
mistake at last IETF to claim that they were hard
state (3) such as TCP state, as Thomas Narten
correctly pointed out.

However, moving from (1) to (2) is still quite
a significant change.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 14 Feb 2002 16:42:35 -0800

Hello folks,

In a few minutes, I will send out a messgae describing how to
eliminate the vulnerability associated with the Home Address
destination option.  For the purposes of understanding my
responses to the recommendation, just imagine that it is
possible to eliminate the threat.

> DISAGREE with them. In case of DISAGREE, please explain why.

This is the threat that can be eliminated.

> 2. ALTERNATIVES

Can live with.

> (b) Apply infrastructure-based ingress filtering

Agree.

> (c) Apply infrastructure-less ingress filtering

Agree.

> (d) Allow HAOs only in conjunction of existing bindings (or

Disagree.

> (e) Additional information copied to the reflected packet

Agree.

> one caused by regular source address spoofing.

I think that the threat is significant, but not drastically significant.
I think that, even without remedy, no self-respecting Internet
wrecker would mess with it, since there are other better and
more effective ways to go about it.

> containing a HAO always contains a OAH option.

Please look at the note my other note on this subject.
I think it is better to design a good solution based on this,
rather than to eliminate useful functionality.

> 3. DISCUSSION

Agreed.  They have been considered.

> visited locations or in the home networks.

We don't have to require them, but we can show how they
might be useful.

> 4. RECOMMENDATION

This is the easiest choice except unless one wishes to preserve
functionality.    Thus, I disagree, and think we should make some
extra effort.  I'll suggest a good method in another note.

Regards,
Charlie P.

---

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

=> yes, the key point is something has to provide the home address
verification but IPsec can do that, not only BCE.

   it further.

=> I believe this is too new to become a real alternative...

=> so we agree about all points in your message.

Regards

PS: I've seen a new thread about this problem but roughly the current
recommendation is in "CAN LIVE WITH" scope for me.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 16:23:17 +0100

> => basically BCE state will become hard state.
   
=> should be more "harder" than "hard".

=> in the HAO/BCE case, the problem is the MN should have a good idea
of the state of its BCEs on its CNs. So the BU/BA has to be more robust
and there is a need for "will delete" messages from CNs to MNs.
Nothing hard (:-) but this should give a heavier protocol...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 16:35:06 +0100

=> I agree. The issue is in the wording.

=> exactly

=> I agree.

Thanks

---

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

> However, moving from (1) to (2) is still quite

Since I don't have the definition of the above types of
state I can't tell exactly what you are saying.

The difference with HOA verification against a BCE appears when the
BCE has been lost on the CN.
But if the BCE is merely stale (i.e. a binding update didn't reach the CN
when the MN moved from one CoA to another) then whether or not
the HOA is verified against the BCE doesn't appear to matter - if it
isn't packets towards the MN will go to the old CoA and presumably be dropped
on the floor.

  Erik

---

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

>  In your previous mail you wrote:
> 

Per what definition of "harder"?

> Nothing hard (:-) but this should give a heavier protocol...

I agree about the need for the MN to be able to know whether a CN has
a BCE for it, and how to "resynchronize" when the MN's knowledge doesn't
match the state at the CN.
This is an effect of making the BCE state matter when receiving packets
from the MN.
But attempts at assigning labels like "hard" or "harder" misses the actual
point IMHO.

Even when using the BCE state for packets sending to the MN it is 
critical to not have stale BCEs since they are likely to cause packets to
be dropped on the floor because they get sent to an old CoA.
So keeping the BCE state current is needed without the proposed HAO changes.

  Erik

---

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

> more effective ways to go about it.

Charlie,

Do you have specific examples of what better and more effective
ways will exist for the attackers?

Thanks,
  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Feb 2002 07:54:41 -0800

Hello Erik,

Yes, I do.  I do not want to discuss that on this mailing list.

Regards,
Charlie P.

---

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

> Yes, I do.  I do not want to discuss that on this mailing list.

Why not?

  Erik