Subject: [mobile-ip] Re: IPv6 ingress filtering early access

From: Pekka Nikander <[email-masked]>
Date: Thu, 03 Jan 2002 11:32:05 +0200

Francis Dupont wrote:

> I have written a draft about IPv6 ingress filtering (with home address
> option considerations). It is not finished (some editing is needed) but
> I have put it for early access on (sorry for the long line):
> 
> ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt

The draft is quite nice, thanks for writing it.  There are a few problems,
though, that I see.  Firstly, I really do find it unrealistic to assume
that each and every site in the world would understand AAA, and change their
ingress filtering rules based on AAA information.  Thus, that leaves changing
the Binding Cache into hard state (instead of being cache) the only option, i.e.
requiring that the CNs check the HAO against the Binding information.

Secondly, such a the proposed practice would basically foil all of the
designed zero-configuration nature of IPv6.  That is, the reason for IPv6
stateless autoconfiguration is to allow hosts to be plugged in to a IPv6
network without any prior configuration.  IMHO, such a practice would be
very good in many environments, even in public access WLANs.  (I know that
some people disagree with me.)

Thirdly, if we consider most current DDoS attacks, the majority of hosts
used to launch those attacks seem to be badly administered PCs that belong
to home users, careless university labs, etc.  When we move to IPv6, there
will continue to be organizations with little administrative knowledge
(e.g. home users) or little money (e.g. some universities).  It is exactly
those kinds of organizations that are likely to continue having hosts that
can be broken in and used in DDoS attacks.  Now, the point is that those
are also exactly the organizations that are most _unlikely_ to use advanced
ingress filtering methods, or AAA at all.  Thus, relying on AAA and advanced
ingress filtering will most probably secure those parts of IPv6 internet that
already have relatively secure hosts (e.g. mobile handsets or PDAs), and
not those parts of the IPv6 internet that have insecure hosts.

--Pekka Nikander

---

From: Francis Dupont <[email-masked]>
Date: Fri, 04 Jan 2002 17:53:09 +0100

The draft is quite nice, thanks for writing it.  There are a few problems,
   though, that I see.  Firstly, I really do find it unrealistic to assume
   that each and every site in the world would understand AAA, and change their
   ingress filtering rules based on AAA information.

=> this is not exactly I propose, my idea is:
 - to do better ingress filtering based on AAA for sites where there are
   some mobile nodes (aka visited sites).
 - to do better anti-spoofing filtering for sites from where some mobile
   nodes are (aka home sites).
There is no constraint on sites where are the regular correspondent nodes
(aka correspondent domains) which should be the vast majority of sites.
I don't know how this is done everywhere but in many sites I can see
a special network for nomadic nodes with special network access control
and small priviledges just because by definition local network managers
have not the control of them, so IMHO this is not unrealistic to ask
to sites which welcome mobile nodes to have a responsible attitude towards
security.

   Thus, that leaves changing the Binding Cache into hard state
   (instead of being cache) the only option, i.e. requiring that the CNs
   check the HAO against the Binding information.
   
=> this is exactly what we don't like...

=> this is very unrealistic because this forgets the third letter of AAA.
And of course this doesn't go well with the responsible use of the network
principle.

   can be broken in and used in DDoS attacks.

=> note that the use of reflectors (i.e. iDDoS) makes the number of
primary attackers less important.

   Now, the point is that those are also exactly the organizations
   that are most _unlikely_ to use advanced ingress filtering methods,

=> the solution in this case is just to filter out HAO, i.e. to refuse
mobile nodes.

   or AAA at all.

=> in the case of home users AAA is used by ISPs.

   Thus, relying on AAA and advanced ingress filtering will most
   probably secure those parts of IPv6 internet that already have
   relatively secure hosts (e.g. mobile handsets or PDAs), and not those
   parts of the IPv6 internet that have insecure hosts.
   
=> this is more a DDoS vs ingress filtering topics... Don't forget
that my idea is not to fill the hole but to get back the previous
situation, i.e. to make ingress filtering a reply to the DDoS threat
again.

Regards

[email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 04 Jan 2002 20:10:17 +0200

>    some mobile nodes (aka visited sites).

Why do you assume that AAA would be used everywhere where there are
mobile nodes?  For example, if I am visiting with my friends at their
place, why couldn't I just use their private WLAN to connect my wireless
PDA to the Internet?  If I could not use their private WLAN, I would
consider that as a flaw in the design if the Internet.  Similarily, our
local university campus provides open WLAN for anyone, for anyone to
connect to the Internet.

It is so much simpler to run these kinds of networks without any kinds
of authentication that they will continue to exist, even though many
current open WLAN networks may turn into requiring some kind of
authentication.  But even when they start to require authentication and/or
authorization, that authentication or authorization is more likely to be
based on 802.1x or PANA than AAA, and even if RADIUS/DIAMETER is used,
the non-ISP connectivity providers are unlikely to be part of the AAA
infrastruture.  For example, I run an open WLAN at my home, and even
though I may require some kind of authentication in the future, it is
very unlikely that I would run RADIUS or DIAMETER.

Thus, making your system to help at all, it would require that
EVERYBODY ELSE FORBIDS Home Address Option altogether.  It is not only
a mobile host that can send HAO, any host can send it.  If an intruder
can break into 10 million poorly protected home PCs, they can be converted
into MN looking devices that send fake HAOs.  Sure the ISP can drop all
packets containing HAO sent from their home customer sites, but that
would break the ability to use your PDA/other device through your
friend's WLAN while visiting at their place.

Do you see my point now?

>    nodes are (aka home sites).

I do not argue with that part.  You draft may well have some value
protecting the home sites of MNs.

> (aka correspondent domains) which should be the vast majority of sites.

As I said above, either you must assume that any site can host MNs
(in addition to CNs), ---or--- you must forbid sending HAO containing
packets from those sites that are assumed not tho host MNs.  My main
point is that forbidding HAOs to be sent from the majority of the
Internet would largely foil the purpose of Mobile IPv6.

> to sites which welcome mobile nodes to have a responsible attitude towards

My point is that almost every home will, in the future, be a potential
site hosting MNs.

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

> And of course this doesn't go well with the responsible use of the network

Most homes do not even know about responsible use of network principle.
It is just that since you can buy an Apple Airport (or whatever) from
your local shop, and set it up within minutes, that will happen.  Actually,
it is already happening in many places in the US and scandinavia.

Remember me setting up an WLAN access point at IPCN'2001 in Paris?

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

> => the solution in this case is just to filter out HAO, i.e. to refuse

... and what I am saying, such a practise is unreasonable and would severly
restrict our possibility to use the future Internet.  In other words,
madating that ingress filtering MUST refuse HAO (unless special means is
used to ensure that the Home Address is valid), besides being expensive
and unrealistic, would result in MIPv6 being used only be the telecom
vendors, not by the rest of us.

--Pekka Nikander

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 4 Jan 2002 20:56:48 +0200

> (aka correspondent domains) which should be the vast majority of sites.

I am concerned that this would be an obstacle to deploying MIPv6:
I couldn't put my node to network X because X will not get AAA within
five years.

> And of course this doesn't go well with the responsible use of the network

Uh... there are legitimate uses for accounting and AAA but I really don't
think we should impose configuration and AAA in all situations. There's
plenty of examples where there is no business or security need for complicated
configuration or even accounting. Such as closed company or free university
networks, or my access-paid-by-visa WLAN.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sun, 06 Jan 2002 17:20:42 +0100

mobile nodes?

=> this (to use AAA everywhere where there are mobile nodes) is the price
to pay to have an alternative to bidirectional tunnels with home agents,
i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling
(i.e. real world mobile IPv4).

   For example, if I am visiting with my friends at their
   place, why couldn't I just use their private WLAN to connect my wireless
   PDA to the Internet?

=> this is a problem of responsibility and trust between you, your friends
and their ISP(s). You already have it for network access, with my proposal
you only have a new "mobile node" option...

   If I could not use their private WLAN, I would consider that as a
   flaw in the design if the Internet.

=> there is a flaw in the laws of Economics: not everything is free for ever.

   Similarily, our local university campus provides open WLAN for
   anyone, for anyone to connect to the Internet.
   
=> same answer.

   authentication.

=> yes, there are still some bad guys in the world...

   But even when they start to require authentication and/or
   authorization, that authentication or authorization is more likely to be
   based on 802.1x or PANA than AAA,

=> I don't understand your argument: 802.1x or PANA are parts of an AAA
system.

   and even if RADIUS/DIAMETER is used, the non-ISP connectivity
   providers are unlikely to be part of the AAA infrastruture.

=> I believe your argument is that all AAA systems are not instances
of the AAA architecture. This is an AAA issue which is not in the scope
of IPv6 and mobile WGs.

   For example, I run an open WLAN at my home, and even
   though I may require some kind of authentication in the future, it is
   very unlikely that I would run RADIUS or DIAMETER.
   
=> again this is a problem of trust and responsability. If your neighbors
want to harm you, IMHO the wild Internet access provided by open WLAN
is enough. So one day you'll secure it (or your ISP will ask you to
secure it), this day the possibility to accommodate mobile nodes shall
become an option.

   Thus, making your system to help at all, it would require that
   EVERYBODY ELSE FORBIDS Home Address Option altogether.

=> everybody else is better than everybody (:-).

   It is not only a mobile host that can send HAO, any host can send it.

=> this argument is mainly against BCE checks in CNs solution.

   If an intruder can break into 10 million poorly protected home PCs,
   they can be converted into MN looking devices that send fake HAOs.

=> our job is to make "they can be converted into MN looking devices"
a detail, i.e. this adds no new major security threat.

   Sure the ISP can drop all
   packets containing HAO sent from their home customer sites, but that
   would break the ability to use your PDA/other device through your
   friend's WLAN while visiting at their place.
   
=> again the same answer.

   Do you see my point now?
   
=> BTW I have a friend with a private WLAN (not an open one, he uses
WEP and a MAC address filter, i.e. common private WLAN security tools).
When I visit him I use my laptop with a secure bidir tunnel to my office
(I use SSH, in the best open WLAN example I know (IETF meetings) most of
us use SSH or IPsec (or both)). I don't use real mobility because I don't
know how to roam between private WLANs, i.e. this is a nomadic situation
where I use two identities, a remote one using a secure bidir tunnel and
a local one for short and/or local interactions like web browsing or
printing.
So if I understand the constraints with my proposal on private WLANs,
they are not a good example.

   
=> my concern is more sites that are not home sites (their anti-spoofing
filtering must be enhanced, fortunately this is very easy).

   As I said above, either you must assume that any site can host MNs
   (in addition to CNs), ---or--- you must forbid sending HAO containing
   packets from those sites that are assumed not tho host MNs.

=> I can't see a problem: they don't take the responsability, I don't
trust them... I stress this idea and its relationship with network
access control because the ingress filtering is not a reply to DDoS
but a reply to source address spoofing: DDoS is still possible but
sources can be traced back, i.e. know who has given the network access
to attacker nodes. RFC 2827 summary finishes by this statement:
   It is the responsibility of all network administrators to ensure they
   do not become the unwitting source of an attack of this nature.

   My main point is that forbidding HAOs to be sent from the majority of the
   Internet would largely foil the purpose of Mobile IPv6.
   
=> I don't believe that because I don't assume the same things about
mobile IPv6 applicability.

=> this is a point where we obviously disagree.

=> if they read the contract between them and their ISPs they should know.

=> I've already answered about private WLANs.

=> this was like IETF meetings: a typical nomadic environment, no need
of real mobility because there was no other network to move to keeping
connections. I believe the issue in in the *local* area, but with a
public WWAN associated ISPs should manage a proper network access
control, at least in order to implement the third A of AAA (:-).

   
=> the only scenario where this can harm is a roaming from a public WWAN
to a visited private LAN, do you agree?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 06 Jan 2002 17:43:49 +0100

=> don't forget you still can use a bidirectional tunnel with your home
agent, so this is a constraint for the standard mode of MIPv6,
not the anti-optimized but optionaly really secure mode ((secure) bidir
tunnel). We have already some problems with the (route) optimized mode,
I believe we shouldn't like to lost standard mode too.

   Uh... there are legitimate uses for accounting and AAA but I really don't
   think we should impose configuration and AAA in all situations. There's
   plenty of examples where there is no business or security need for complicated
   configuration or even accounting. Such as closed company

=> there should be no security issue in a closed company

   or free university networks,

=> there is a problem for them but I don't believe this is very different
than for the Internet access. A balance between the freedom and the
responsability in case of problems has to be found.

   or my access-paid-by-visa WLAN.
   
=> I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made
with WLANs). In this case the problem is very easy to use, even
statically (i.e. with a home address bound to the VISA account).
Of course I expect the mobile support will be in the offered service list,
something we all like to get but perhaps is not understood by operators...

Regards

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 6 Jan 2002 18:57:22 +0200

> I believe we shouldn't like to lost standard mode too.

AAA-based solution would allow you to keep the standard mode, but
at a cost which would propably prevent some good size fraction of
nodes from using the optimised mode. The BCE check solution allows
you to keep the optimised mode in wide usage, but does force you to
go back to bidirectional tunneling if you didn't do RO. Take your pick
what is the right tradeoff here, but my preference is the last one.

> something we all like to get but perhaps is not understood by operators...

Right. You expect the support to be there. So, instead of me turning on MIPv6
when my code supports it and your code supports it, we have to wait five
years before VISA deploys the technology for both of us. And for that, we
get to pay a montly service fee!

By the way, didn't we already decide that a global infrastructure linking
people to their home addresses was out of the question? I don't think
it matters whether the acronym for this infrastructure was PKI, DNS, or
AAA?

Jari

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 06 Jan 2002 20:41:05 +0200

Francis,

> => everybody else is better than everybody (:-).

I think the main reason for our disagreement is that you mostly seem to
think that MIPv6 will be employed by operators.  I don't.  If MIPv6
will ever become common, I certainly want to run my own MIPv6 Home
Agent, in the same way I am running my own DNS server, my own SMTP
server, etc.  That is, the only service that I buy is IP connectivity,
and I really really really want to have an Internet that allows you
to buy IP connectivity, and provide all of the rest of the
infrastructure yourself.  I don't want to be part of a global AAA.
[Personally, I would consider such a requirement fascist.]

Now, returning to the real issue.  I just want to second Jari Arkko's
statement:

   A.  We seem to agree that HAO may be dangerous since it potentially
       makes IP traceback more difficult.

   B.  There seems to be two possible solutions:

      B.1 Make the Binding Cache hard state instead of a cache.
          That is, mandate that CN accepts HAO if and only if there
          is a corresponding binding in the binding cache.  (Or,
          at minimum, that it keeps trace of received HAOs for
          traceback purposes.)

      B.2 Mandate that every ingress router everywhere in the Internet
          either checks that the HAO is legitimate, or drops it.

That is, my (possibly flawed) understanding of your ingress filtering
draft requires B.2.  If B.2 was mandated, the CN could accept HAO
and rely that it is authentic.  On the B.1 case, on the other hand,
it is the CN's responsibility to decide whether to rely on HAO or not.

As far as I can see, that is the difference.  As a practical result,
B.1 allows anybody to use MIPv6 security protocols (whatever it will be),
establish bindings, and use HAOs.  B.2, on the other hand, would restrict
where you can use BUs, and that your home agent must be part of the
still-not-existing global AAA infrastructure so that you could use HAO.
As a result, all the work that we have done with RR and CGA would be
unnecessary, since you would mandate AAA, and while you are mandating
it, you just could use it for basic MIPv6 security as well.

Francis, if you insist to keep your opinion that B.2 with all its
consequences is better, there is nothing I can do.  On the other hand,
if I have really misunderstood the practical consequences of your draft,
please enlighten me, and explain in detail how you expect it to work
so that MIPv6 route optimization could still be used by private persons
and small organizations that are not part of the alledged global AAA
infrastructure.

--Pekka Nikander

---

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Jan 2002 10:22:10 +0100

=> your argument is based on the bet that full CN function will be
implemented by everybody and enabled everywhere. IMHO this is a
very dangerous bet...

   > something we all like to get but perhaps is not understood by operators...
   
   Right. You expect the support to be there.

=> the "even statically" is only an example of what can be done.

   So, instead of me turning on MIPv6
   when my code supports it and your code supports it,

=> this (when your code supports it) is the real question...

   we have to wait five years before VISA deploys the technology for
   both of us.

=> not VISA, our ISPs (and far less than five years).

   And for that, we get to pay a montly service fee!
   
=> if it is VISA, we'll pay a monthly fee for no service (:-)!

   By the way, didn't we already decide that a global infrastructure linking
   people to their home addresses was out of the question?

=> not exactly, the key term is "rely on".

   I don't think it matters whether the acronym for this
   infrastructure was PKI, DNS, or AAA?
   
=> I agree but it is not forbidden to get advantages of it, only to rely
on it. As we don't rely on ingress filtering for defense against DDoS,
I can't see a problem to propose to use AAA in order to improve ingress
filtering.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Jan 2002 11:51:08 +0100

=> first the term requirement is too strong, second the recommendation
for AAA in home domains is for your protection because without
remote network access control if a bad guy tries to use an address
in your (home) prefix you can't just reply "no, this is mine".

   
=> we agree.

   
   
=> in both cases the term mandate is far too strong.

=> I agree, the whole issue is where to put the responsability (or
who trust to).

   where you can use BUs,

=> this is not a restriction: the responsability is put on senders,
so we trust (or filter out) senders. This is exactly the same for
the current ingress filtering: we trust source address because
ISPs say we can (they may use a tool which makes source address spoofing
impossible).

   and that your home agent must be part of the
   still-not-existing global AAA infrastructure so that you could use HAO.

=> as I've said, this *recommendation* is for your protection:
without remote network access control you can be a target...

=> no, I never propose to base MIPv6 security on AAA. If I believe
that AAA is a fine alternative for MN-HA security (I tried full IPsec,
this works but this is so heavy and inefficient than near everything else
should be better :-), but AAA for MN-CN security is possible only
in some very special cases.

=> first, kill the idea to use (or to rely on) AAA for the general
MN-CN case. Second, don't forget the target: we have a nasty attack,
DDoS with source address spoofing, and a reply, ingress filtering,
which is not used by every ISPs and is not very efficient against
DDoSs (just because it is a reply to source address spoofing, not DDoSs
themselves). HAO may be dangerous since it potentially makes IP
traceback (ingress filtering is the only deploied tool which provides
IP traceback) more difficult. The idea is to improve ingress filtering
in order to get back the previous situation (the one before HAO).
The obvious solution is to make the knowledge of bindings available
to ingress filtering devices. My proposal is to use the local network
access control in order to carry this knowledge from MNs to ingress
filtering devices, this assumes only that there is a local network access
control (of any kind) and ingress filtering devices are between the
Internet access and the site, and have enough capabilities (i.e.
the firewall(s) which already filter(s) inbound traffic).
 If there is a AAA infrastructure and if both the local and remote
network access controls are connected to this infrastructure you have
two extra benefits: the remote network access control works locally
and ingress filtering devices can verify bindings: without an AAA
connection between local/visited and remote/home domain, ingress filtering
devices can only check HAOs against registered bindings (IMHO this is
enough to make spoofing based on HAOs unattractive). With an AAA
connection, bindings can be verifed when they are declared/registered.
This is a far stronger property, we'd like to get it in an ideal world
(a world where there are AAA infrastructures :-).
 In summary participation to a global AAA infrastructure is not needed,
it has just many new advantages (and should be discussed in the AAA WG
mailing list, not here).

Regards

PS: I'll add in the draft a statement against BCE checks (they work
only for mobility) and an extra space between the "network access control"
and the "AAA" paragraphs (showing there is no dependency).

---

From: Durga Prasad Pandey <[email-masked]>
Date: Mon, 7 Jan 2002 05:26:27 -0800 (PST)

Francis
Could you please direct me to some online begineer's
tutorial/other resaource on Mobile IP.
I will appreciate your kind effort.

Thanks
Durga

=====
Believe in yourself
I do.

Assistant Online Editor: ACM Crossroads Magazine www.acm.org/crossroads/

VISIT MY HOMEPAGE AT :  www.geocities.com/dpsmiles
VIEW MY pics AT: www.geocities.com/dpsmiles/dp1.jpg

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jan 2002 17:27:13 +0200

> I can't see a problem to propose to use AAA in order to improve ingress

Yes, it's no problem to improve something. However, improving ingress
filting with AAA is not the *whole* picture of what we are doing. You
have to remember that by introducing HAO our first step is punching a
mile wide hole to the ingress filtering system. And, in fact, you
are not improving things by having a smart treatment of the HAO -- you're
basically keeping the status quo that we already have with v4. So, in
some areas that have both ingress filtering and aaa, you may keep the current
status, if the aaa fix to ingress filtering is deployed fast enough.
However, on other areas you are nuking an existing security measure some
people are using. In this sense you are relying on AAA all over the place,
just to keep things as they were before.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jan 2002 18:22:47 +0200

> without remote network access control you can be a target...

Ah, but I think the issue is who the victims are. If *I* add
protection in my network, that does *not* guarantee I won't
be hit by reflection attacks from someone's network that only
has regular ingress filtering (without the stateful and AAA
patches).

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Jan 2002 11:06:02 +0100

=> there is *no* guarantee with ingress filtering: its purpose
is not to make source address spoofing impossible, it is to
make it enough unattractive.

=> you have forgotten the purpose of ingress filtering. To get
the level of security you seems to want, AH should be mandatory
(its use, not its implementation).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Jan 2002 11:16:43 +0100

> I can't see a problem to propose to use AAA in order to improve ingress
   
=> I should have added that there are two possible improvements to ingress
filtering: network access control and full AAA. The first one keeps the
status quo, the second gives more.

   basically keeping the status quo that we already have with v4.

=> this is about (any kind of) network access control.

   So, in some areas that have both ingress filtering and aaa,
   you may keep the current
   status, if the aaa fix to ingress filtering is deployed fast enough.
   However, on other areas you are nuking an existing security measure some
   people are using. In this sense you are relying on AAA all over the place,

=> please replace AAA by network access control.

=> I don't see a problem: we have *not* ingress filtering performed
everywhere today. We don't need an absolute solution, we need only to
make HAO spoofing enough unattractive as we did need to make source
address spoofing enough unattractive...

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2002 10:38:31 -0800

> has regular ingress filtering (without the stateful and AAA

you mean stateful or AAA patches, right?

Vijay

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 14 Jan 2002 20:49:16 +0200

> you mean stateful or AAA patches, right?

I believe the AAA-assisted ingress filtering has to be
stateful, or? Otherwise you'd be asking for the right home
address per packet.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2002 12:12:24 -0800

> stateful, or? Otherwise you'd be asking for the right home

Actually I was trying to say AAA or 'some kind of network 
access control'. ofcourse both are stateful. sorry about that.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Jan 2002 10:21:59 +0100

=> Jari meant stateful and network access control patches (the state
is the knowledge of active bindings, network access control patches
give this knowledge).

Regards