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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

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

In your previous mail you wrote:

   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: "Jari Arkko" <[email-masked]>
Date: Sun, 6 Jan 2002 18:43:51 +0200

> (i.e. real world mobile IPv4).

This seems like a bad design tradeoff to me. We already have a
highly optimised mode of operation in MIPv6 (RO), and if you're
not using it you are falling back to something less efficient. Your
tradeoff improves the fallback solution a bit, but doesn't improve
the optimised solution. And the cost is extreme: we need a new
global infrastructure (though I admit some of it will be built anyway),
MIPv6 deployment is delayed, most if not all small sites and homes
will not be able to benefit from RO, etc.

Jari

---

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:03:44 +0100

This seems like a bad design tradeoff to me. We already have a
   highly optimised mode of operation in MIPv6 (RO),

=> no, we have not this until the security problem is solved,
i.e. it works but we may not deploy it...
 In fact (you sent this mail to the IPv6 WG mailing list only
so I can say that without being nuke in some minutes) if Mobile IPv6
is expensive for CNs and only at the benefit of MNs it is in a real trouble.
IMHO Routing Optimization has this problem, obviously not the
bidirectional tunneling and not the triangular routing *if*
the reply to the ingress filtering problem is not the burden of CNs.
I disagree with most of the IESG security concerns with MIPv6 but
the statement "This has negative implications for larger servers that
process many 100s of thousands of connections at a time" is true,
not only for AH/IPsec SAs.
I think we must put the responsability of using HAOs to senders!

   and if you're
   not using it you are falling back to something less efficient. Your
   tradeoff improves the fallback solution a bit, but doesn't improve
   the optimised solution. And the cost is extreme:

=> I disagree, and the cost of RO is really extreme for CNs so if
most of CNs just deny BUs we'll be happy to have a better fallback
solution.

   we need a new

=> first the implementation of smart ingress filtering and AAA is not
even a SHOULD (RFC 2827 is a BCP), it seems you believe it is a MUST.
Second the ingress filtering and HAOs is not a major security threat
(like unprotected BUs in an open network is).
 To summary your argument would be valid if ingress filtering was mandatory
and efficient, but today ingress filtering is not used by every ISPs
and unfortunately to know where are the attackers is not enough to
stop DDoS.

   MIPv6 deployment is delayed,

=> no, the only possible effect on deployment is another argument is
favor of a better/real AAA.

   most if not all small sites and homes
   will not be able to benefit from RO, etc.
   
=> I agree that to ask for a better network access control in general
stresses the trust/responsability problem.

Regards

PS: don't forget that the BCE check solution has many drawbacks:
 - it doesn't work with not-MIPv6 uses of HAOs
 - it doesn't work without routing optimization
 - it makes CNs processing more complex/expensive
 - BCEs should be hard state.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

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).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Jan 2002 11:18:11 -0800 (PST)

So here's a most-likely crazy idea: why can't we
treat the ingress filtering router like a CN which
must first be sent a BU which it verifies in
whatever manner the CN would? This already has a
requirement to not be bound to mythical PKI's,
etc. Given FMIP, the access routers are probably
going to end up having to process things like BU's
anyway.

Also: if we have ingress filtering taken care of
directly, is there any reason to preserve the HAO
at all? I thought its entire raison d'etre was to
provide a means of coexisting with ingress
filtering -- which we've already proven is just
shifting the problem around instead of providing
something useful.

		Mike

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 07 Jan 2002 22:06:15 +0200

> going to end up having to process things like BU's

I was drifting into this direction myself.  But how?
Introduce a new ICMP message saying: send me a BU
if you want to use HAO?

> shifting the problem around instead of providing

Now THAT sounds like the most reasonable thing that
I have heard about ingress filtering for a long time!

To me, it seems like combinding RR and CGA, the
ingress filtering router can fairly easily determine
that the MN really "owns" the home address, and
thereafter pass it.  As an immediate reaction, the
only problem seems to be that CGA requires fairly
heavy CPU load.  Could RR be enough in this case,
since the CoA and HoA are on the different sides
of the router?

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Jan 2002 22:22:44 +0200 (EET)

> since the CoA and HoA are on the different sides

Moreover, ingress filtering is usually performed at more than one router.

The network manager of the LAN might perform it.  The network manager of 
the site should perform it.  The network manager of the ISP should also 
perform it. Etc.

Therefore, this "notification" or "ingress filtering registration" would
have to operate a bit like path MTU discovery or a router alert option.  
Also, this would get more difficult in the case of multiple, changing
paths (multihoming).

Certainly an interesting idea, though.

-- 
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: Michael Thomas <[email-masked]>
Date: Mon, 7 Jan 2002 12:30:07 -0800 (PST)

> Certainly an interesting idea, though.

This entire question is being begged by
multihoming which RPF checks fail at pretty
miserably. And of course, asymmetric routes. We
need something better. Essentially, I think what
I'm proposing is something in lieu of RPF
checks. The open question is whether we can make
this pervasive too. If we can, we can safely turn
off RPF checks.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Jan 2002 12:34:46 -0800 (PST)

> Introduce a new ICMP message saying: send me a BU

   Sounds good to me. This also takes care of the
   case where somebody has RPF checks running farther
   into the network. I would expect that a MN
   would always send the BU to its access router.
   Making this a MUST implement for a v6 router 
   would probably be a good thing too.

 > I have heard about ingress filtering for a long 

   Heavens. Didn't mean to scare anybody :-)

 > since the CoA and HoA are on the different sides

   I think that if RR is viable for anything, it's
   probably fine for lifting RPF checks. 

		 Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 10:24:24 +0100

=> I suggest this in the smart anti-spoofing section (because
this is what we used and the alternative is based on remote network
access control or HA collaboration, i.e. something which needs
a protocol) but this has many drawbacks:
 - if there is more than one path, some coordination is needed
   between routers on these paths
 - this works if HAOs are not used before BUs (with standard mobility,
   this is true because of home registrations but this is a restriction)
 - this puts constraints on how BUs/BAs are protected (no ESP hiding
   some parameters like the home address)
 - as a special case of the previous point, it is fine to be able
   to check the status in BAs of home registrations
 - this is complex and expensive (this is not bound to the number
   of MNs inside the site, this argument doesn't apply for the
   anti-spoofing because HAs are in general statically configured
   and in case of a flood of home registrations HAs should be overloaded
   before firewalls).
So I believe this is a good complement but not a good candidate
for smart ingress filtering.

=> if I understand well your idea, you propose to disable traditional
ingress filtering (so HAOs are no more useful). I believe this depends
on the fraction of packets with HAOs, if it is high then I agree with you,
if it is low then I believe ingress filtering remains useful...

Regards

PS: I take advantage of this discussion to argue in favor of better
network access control. It seems that today DDoS bad guys no more use
random source address (i.e. ingress filtering is more efficient than
one can believe), they try source addresses in the same prefix (change
last bits in IPv4) in order to vary them (more harm for the target,
counter measure more difficult). Of course this is easier for IPv6
but with a good network access control (even passive, i.e. the maximum
number of boxes in a side is known) this can be detected and in many
cases be fixed.
(Thanks to Stanislav Shalunov who brought this point to my attention.
Even if the purpose is to save the HAO by a reply on the paper to
the traceback threat, it is fine to provide more applicable weapons
against DDoSs)
(Of course, a good network access control doesn't fit well with
RFC 3041 but we already know there are some tradeoffs between privacy
and access control :-)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 11:26:06 +0100

=> no, Michael's idea is to look at packets going through
access routers in order to find BUs (i.e. this is passive).
And if you'd like to use an active scheme, why not the
network access control?

   thereafter pass it.

=> I believe this is overkilling to ask for verification
of home addresses. To know bindings is enough to make
HAO spoofing not attractive.

   As an immediate reaction, the
   only problem seems to be that CGA requires fairly
   heavy CPU load.

=> both CPU load and IPR issue: enough to kill any good idea.

   Could RR be enough in this case,
   since the CoA and HoA are on the different sides
   of the router?
   
=> I don't know what is RR in this case (not only check that CoA is
inside and HoA is outside?). I suggest to look at BAs too, i.e.
at least home agents are far better equipped to verify BUs!
(note that I still believe this is overkilling)

Regards

PS: the main issue is this restricts the use of HAOs to mobility
(i.e. to use the network access control is better).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 11:28:26 +0100

=> as multi-homing is a place we could want to use home address options
this is a real issue...

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jan 2002 12:48:35 +0200 (EET)

> => as multi-homing is a place we could want to use home address options

I've always thought using Home Address option as a way of getting around
ingress filtering checks in multihoming is like "if words fail you,
mumble!" -approach.

Much more analysis is needed IMO before HAO is to be used outside of MIPv6 
context.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 11:40:05 +0100

=> the idea that RPF checks always fail with multihoming is a myth
(cf http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf).

Regards

PS: don't forget we don't need an absolute reply to source address
spoofing, in fact it seems that with the current deployment of
ingress filtering, random source address spoofing is enough unattractive.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 12:10:32 +0100

=> I agree if it is only a way of getting around ingress filtering checks
but there are some situations where to have more than one source address
is very fine. And don't forget the degenerate tunneling argument.

=> yes and to provide an independent and complete definition of HAO should
be very useful too.

Regards

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jan 2002 08:39:58 -0800 (PST)

> And if you'd like to use an active scheme, why not the

   No, actually, it was to have the MN send the
   BU's directly to the access router. On a router
   the BU just has an additional effect of removing
   any restrictions on source addresses it will 
   let through. Hence Pekka's question about use
   of ICMP was correct.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jan 2002 08:43:27 -0800 (PST)

> => as multi-homing is a place we could want to use home address options

   I think we need to take a step back here. If you
   could do route optimization effectively and use
   the "home address" you started a session with,
   there isn't any motivation for a separate
   identifier in the packet, right? CoA would
   always be a routing construct.

	     Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 18:39:44 +0100

let through.

=> I believed your proposal was BU snooping. But you can name it
as you'd like, the purpose is to provide the knowledge of bindings,
so there is no deep difference with my proposal (i.e. I can say
you use a non-standard network access control device, as I don't
specify one (I only give an example with AAA because it is the best
on the paper) I could argue your proposal is included in mine :-).

      Hence Pekka's question about use of ICMP was correct.

=> I am reluctant to define new ICMPs for anything. There is already
a format for BUs, why a new thing?

Another point: HAOs are inside packets, to look at them is legitimate
for my firewall but not for any router on the path, i.e. I'd like
to have the check done once and others to trust it (this idea is
exactly the network access control).

Regards

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jan 2002 10:20:25 -0800 (PST)

[Phil suggested I add mobileip back which was
 dropped somewhere along the way]

Francis,

I'm not sure we're communicating, so let me be a little
more explicit with what I had in mind:

1) MN arrives on new AR
2) It sends a packet using its home address as the 
   *source* address -- no HAO at all.
3) AR recognizes that the source address is not one of
   the subnets it subtends and sends an ICMP message
   to MN which explains the problem
4) MN sends AR a normal CN binding update
5) AR lifts the restriction for that source address
6) MN now sends packets as in (2), but unimpeded

If MN knows that there is likely to be a source
address check on AR, it can delete steps 2 and 3.
ICMP seems like a natural here because the router
really is reporting a network problem back to MN
(or not MN if a host were incorrectly configured,
etc).

If this is a subset of your proposal, fine. It
does seem that what I propose gets rid of the HAO
altogether which you don't seem to agree with.
However, may I suggest that it's the AAA part that
has become the lightning rod? And that maybe it
shouldn't be quite so ambitious? :-)

	 Mike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Jan 2002 11:33:32 +0100

1) MN arrives on new AR

=> many (academic or R&D) sites I know don't use firewalls
(they use a router for filtering) but have a passive management box
which detects new addresses and builds a database with MAC, IP,
name, location, etc, something very useful in case of problems.
So even if classical network access control is not performed on 1)
at the first packet, unusual behaviors are detected (i.e. there is
a passive and without automatic reaction kind of network access control).
 At the opposite I know some (commercial) ISPs which use the (traditional)
network access control to punch holes in the firewall for outbound
traffic, i.e. all source addresses are blocked by default and
network access control is used to open some of them (in AAA term
the authorized resource is the Internet access): this is ingress
filtering at the address level, usually it is done at the access
device (e.g. modem) level too.

=> I propose that the packet is sent to the home agent (or something
similar).

=> perhaps I should add a statement in the draft with a requirement
(modulo ICMP rate limitation) for ICMPs when a HAO is filtered out.
I believe a router should implement this by default but a detailed
text should help.
What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option),
as the router is not the destination of the packet the MN should
understand what's happened. Note that 1 (Destination Unreachable) -
1 (administratively prohibited) is too ambiguous.

=> 4) is what I consider as a kind of network access control.

=> the difference with my proposal is here, I propose to accept
corresponding HAOs, you propose to directly open the ingress filtering.
See more comments after.

=> i.e. active/reactive modes.

=> in any case ICMP errors have to be sent when packets are dropped,
I believe we can reach a consensus about this very quickly.

=> in order to get rid of the HAO your proposal has to be
supported on every ingress filtering devices where a packet
from the MN can go though. This is not in fact like path MTU
discovery (which is already difficult to get in the real world)
because your proposal uses a signaling with all the usual
problems of signaling (scalability, security, ...).
 Even if to get rid of the HAO would be very nice, I don't
believe this will work in practice. To summary this has the
same kind of problems (i.e. limitations) than micro-mobility
(i.e. mobility based on host routing).

=> I insist about AAA: AAA is not an essential part of
my proposal, it only brings extra goodies:
 - an instance of network access control which is well known
   and already has proposed extensions for (mobile) IPv6
 - remote network access control
 - a connection between local and remote access control.

=> too ambitious for a global deployment, and for local/special cases
I am afraid that micro-mobility is more attractive (it gets rid
of the routing header too).

Regards

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Jan 2002 11:27:43 -0800 (PST)

As originally advertised, I am now convinced that
this was indeed a crazy idea -- a bit too good to
be true. Thanks for the link on the "loose" RPF
checking; I wasn't aware of that. Having to signal
many routers in the path would be a non-starter,
and ISP's certainly have incentive to perform the
loose RPF, therefore this is an insurmountable
obstacle.

Oh well.

	Mike

---

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: Jari Arkko <[email-masked]>
Date: Sun, 13 Jan 2002 19:20:23 +0200

Folks,

We've had a very long discussion on what to do with MIPv6 Home
Address Options and Ingress Filtering, basically centering around
(a) solutions restricting HAOs to nodes that employ Route Optimization,
(b) solutions employing AAA in firewalls, and (c) solutions that
discard HAOs altogether and use BU authentication procedures (e.g. RR)
from the access router to the MN.

I'm not sure we are near consensus yet -- though we could be,
it's hard to say on the list because just a handful of people
have participated the discussion.

In any case, I'm thinking about how to go forward in a practical manner.
We need a solution. And we don't have much time to redesign MIPv6, so I'd
really like to see a solution that doesn't need too much new work. But
how do we decide between a-c?

I have a proposal. But first, let me make some observations:

- Most people do seem to agree that HAO reflection is an
   issue that needs to be dealt with somehow.

- A restriction can be relaxed easier than tightened. User
   groups with better technology can run relaxed versions, or
   future standard versions can have relaxed rules if we see
   that the infrastructure around us allows it.

- As a general rule, I'd like the Internet to use end-to-end
   mechanisms more than network assistance. This isn't just
   an architectural principle, but it will also ensure that
   we can deploy our things without waiting for providers to
   catch up.

- The different solutions have different impacts on
   various use cases of MIPv6. Some benefit regular MNs,
   some those that use RO with a CN, for instance.

So, my proposal is as follows:

1. We will not use the alternative (c), because it is not
    an end-to-end mechanism, because multi-hop ingress
    filtering could generate delays, and because scalability
    of intermediate routers with ingress filtering feature
    might become a question mark if there's a lot of state to
    hold. As a tradeoff, we have to carry HAOs in our packets.

2. We will have a two-phased approach to the MIPv6 spec and
    its treatment of reflection attacks: the first phase uses
    method (a) and the second phase relaxes the rules to allow
    also (b). The first phase will be put to the MIPv6 RFC.
    When and if experience shows that we can have AAA-based
    filtering in access routers and firewalls, an extension
    can be defined to allow the more relaxed use of HAOs.

Comments or other proposals are welcome.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Jan 2002 10:59:33 +0100

=> for (b) I prefer network access control (AAA is only one way
to provide it).

   
=> so it seems we have to wait for the face-to-face meeting.

   
=> we have to deal with it but we don't need a stronger solution
than today ingress filtering which is a BCP, i.e. something like
a SHOULD.

   - A restriction can be relaxed easier than tightened...

=> this doesn't work in practice because this is a security issue.
In the functionality vs security tradeoff, networking people always
choose the security, especially when they get no direct benefit from
the functionality. There are only a few counter examples (ingress
filtering is one of them).
   
   - As a general rule, I'd like the Internet to use end-to-end
      mechanisms more than network assistance.

=> ingress filtering is network assistance and is enough.
If we try a strong solution we'll get more security (i.e. a reply
to a minor improvement to an attack) and we'll weaken the functionality
(i.e. we'll lose the triangular routing).

     This isn't just an architectural principle, but it will also
     ensure that we can deploy our things without waiting for
     providers to catch up.

=> clearly you don't believe in current ingress filtering.

=> HAO is not MIPv6 only (i.e. be prepared to relax it :-).

   
=> I agree: (c) is unrealistic.

=> no, a two phase approach won't work because we'll stay at
the first phase. And you put the burden on the wrong people:
this is an ingress filtering problem, not a MIPv6 one, so
the solution should be in an ingress filtering improvement,
not in a new restriction for MIPv6.

=> if there is a consensus to do that, I propose to split the
MIPv6 document into a basic one about bidirectional tunneling
with the home agent and a special one about routing optimization,
i.e. the lost of the triangular routing should not have only
drawbacks.

=> this won't have interest, as soon as the use of HAOs will be
marginal, it will no more be considered as a real world security
threat.

Today firewall people have the choice between to ignore HAOs
(easy way for them because they have nothing to do) and to filter
them out (easy too but they are reluctant to kill HAO). My proposal
is to give a third solution (how to do an intelligent filtering),
your solution is to kill the HAO for them (so they won't complain :-).
Of course your proposal is safe, but I believe the price is a bit
too high. Frankly MIPv6 has already enough problems...

Regards

---

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.

   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.

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

   just to keep things as they were before.
   
=> 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: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jan 2002 20:44:18 +0100 (CET)

>    we can deploy our things without waiting for providers to

I agree.
But I would personally make a stronger statement since I'm concerned with
the direction of piling more and more requirements and dependencies on
AAA. Thus I think the AAA approach is the wrong one - if we collectively
can make AAA/Diameter do the things needed to make Radius more usable
(reliabiliy, security, some extensibility) I think we've collectively
have been successful. Keep piling more stuff on the AAA system and it might
very well get too heavy to be able to fly...

Also, waiting for AAA solutions to be available (specified, implemeted,
and deployed) before MIPv6 can be used seems to be counter to our desire
to finish up MIPv6 soon.

>     can be defined to allow the more relaxed use of HAOs.

While I have concerns with using the AAA per above I think the phased approach
(where the AAA approach continues to be discussed and further understood) 
makes sense to me.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Jan 2002 10:59:09 +0200 (EET)

On Mon, 14 Jan 2002, Francis Dupont wrote:
[snip]
> the first phase.
[snip]

If we'd stay at the first phase, that'd probably mean that the 
stateful network access control mechanism wasn't attractive and 
wide-spread enough? -- Which is one of the points here.

If one would want to differentiate between "network access controlled (no 
checks in end-nodes)" and "in god we trust, others must be checked", 
perhaps Home Address Option sub-options could be used? (or identically 
defined another HAO.)

> And you put the burden on the wrong people:

(a bit tongue-in-cheek)

If QWERTY working group would define a new mechanism for storing effective
source address in a varying location of IP header chain, under some
destination option's freshly defined fourth option's third sub-option
(padded to 2n+x), would digging that out and just coping with it be
"ingress filtering problem" too?

If AZERTY working group would make new requirements (caused by said
working group's new proposal) for ingress filtering, so that it could not
be done in practise, would finding new ways to do ingress filtering befall
ingress filtering people too?

---

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Jan 2002 11:46:01 +0100

=> first I have submitted the draft, second I tried to make clear
that my proposal relies only on (any kind of) network access control
(i.e. anything more that just plug and play). AAA is an implementation
option which has extra benefits.

   I agree.

=> for my purpose Radius is enough (only a new attribute is needed
for the home address, a new version of RFC 3162 ?)

=> I agree but AAA is the only way to provide (one day) remote network
access control (*not* necessary but fine).

=> I never proposed to wait for AAA solutions (as I ask only for network
access control, not everywhere but enough to make HAO spoofing unattractive).

=> have you still concerns with using network access control in a BCP?

Regards

PS (for the IPv6 WG list): my draft is about HAO vs ingress filtering,
I assume there is a consensus about traditional ingress filtering, i.e.
RFC 2827 is applicable to IPv6 (i.e. we don't need another document and
we'll get tradition IPv6 ingress filtering (access lists and unicast RPF)
support in the next router software version (I apologize if this is
already available)).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Jan 2002 12:22:54 +0100

[snip]

=> no, you haven't understood. The problem is not technical,
it is psychological: you can't have this kind of two phase approach
for a security device, you won't be able to relax something,
in fact it will be hard to get the first phase not be hardened.
For instance RFC 2401 explains that in tunnel mode the outer source
address should not be checked, most implementers do the check just
because it seems a bit more secure...

=> I have no concern about "in god we trust"... This is already the case
for ingress filtering and this is effective, i.e. random source address
spoofing is no more heavily used in DDoS attacks. This follows the same
mechanism than vaccination against an epidemic.

   (a bit tongue-in-cheek)

=> I think so (this is why I prefer the firewall based part of ingress
filtering because firewalls have to be prepared to dig into packets
anyway).

   If AZERTY working group would make new requirements (caused by said
   working group's new proposal) for ingress filtering, so that it could not
   be done in practice, would finding new ways to do ingress filtering befall
   ingress filtering people too?
   
=> this depends on who gets the benefits: if there are mainly global
benefits (as for home address declarations in order to limit HAOs),
I believe this is a topic for ingress filtering people, if there are
mainly benefits for a particular population (as for HAO filtering using
remote network access control, i.e. certified/verified home addresses),
I believe this is not a topic for ingress filtering people (in my
example this is a topic for AAA people).
We can consider where are the difficulties too but in a well engineered
system both should be equivalent (this is a practical problem too,
if you get the difficulties and not the benefits nothing will happen,
this is my concern about correspondent node based features).

Regards

---

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

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

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jan 2002 11:32:33 +0100 (CET)

> access control, not everywhere but enough to make HAO spoofing unattractive).

Are you proposing to wait until network access control is available?
(specified, implemented, and deployed)

If not, what do you propose to do in the interim until network access control
for HAO is available?
Seems like this requires a two-phase approach: phase 1 before it is available
and phase 2 when/if it become available.

What am I missing?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jan 2002 14:35:48 +0100

=> we don't need to wait because mobile IPv6 is not yet fully specified.
IMHO the only thing we need is to be ready and the first step should
be to get (traditional) ingress filtering and firewalls with IPv6 support
(or do you suggest to stop IPv6 until they are implemented and deployed?)

   If not, what do you propose to do in the interim until network
   access control for HAO is available?

=> decide if we keep or kill the triangular routing. In parallel (because
even if the triangular routing is killed there are still similar mechanisms
based on tunnels with the same security issue) give this idea to
network access control people (both RADIUS/DIAMETER and firewall) in
order to know what concrete proposal we can/should do (for instance a
new RADIUS attribute for IPv6 inner source address declaration). IMHO
this second part is mainly not technical (i.e. out of the scope of IETF).

   Seems like this requires a two-phase approach: phase 1 before it is
   available and phase 2 when/if it become available.
   
=> you are acking what will happen after some kilometers in a deep fog:
today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress
filtering, IPv6 firewalls, ...

   What am I missing?
   
=> mobile IPv6 is not yet in last call, in fact we don't know if it will be
this year. So we only need a paper solution against the future and
potential minor security threat of HAO with ingress filtering.
But I agree we have to know where we are going or we could lose more
than our time in this kind of discussions (i.e. implementers don't like
to follow random moving specs).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jan 2002 16:32:46 +0200 (EET)

> (or do you suggest to stop IPv6 until they are implemented and deployed?)

Ingress filtering and firewalls exist already.
 
> filtering, IPv6 firewalls, ...

You know full well that e.g. ip6fw, ipf, iptables (all free) etc. support
IPv6 ingress filtering and firewalling rather nicely; they've had the
support for some time now.  They're still a bit raw, as is understandable,
but usable.

So why do you spread FUD?

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jan 2002 15:37:20 +0100 (CET)

> (or do you suggest to stop IPv6 until they are implemented and deployed?)

No, but the specification of MIPv6 should wait until the ingress filtering 
part is specified.

If we (the IETF) really care about security we need to make sure that we don't
create holes in the set of standards track RFCs we issue. That is
all the IETF need to worry about. (Others need to worry about complete
security of products and a third set of folks need to worry about the security
of their operational network using those products.)

For the IETF I think this means that we should not issue a proposed standard
(e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be
made  aware of HAO). If we want to go this path I think we need a community
supported ingress filtering RFC (BCP or standards track) that handles HAO no
later than when MIPv6 becomes Proposed Standard.

I don't think we should use the fact that 1) there are IPv6 products with
incomplete security and/or 2) existing IPv6 operational networks have
incomplete security as arguments that we can have an IPv6 story where the
standards have security holes. Even if we say "we'll fill that hole really
quickly by later producing an HAO aware ingress filtering RFC" or
something similar.

> this second part is mainly not technical (i.e. out of the scope of IETF).

It seems like the IETF pieces (RFCs) that need to be completed to
have complete (i.e. not security holes in the combination of specs)
specification for network access control is sizeable: some fireall spec
(perhaps informational), some radius and diameter extensions.
This sounds like more delay for MIPv6 to me.

The two-phase approach removes this delay.

> filtering, IPv6 firewalls, ...

You're confusing specifications, products, and deployed practise.
People can build ingress filtering and firewalls for IPv6 today without
waiting for a specification from the IETF.

That wouldn't be true if we issue a MIPv6 specification which, in order to
avoid ingress filtering, depends on some yet to be written RFCs that specify
network access control for HAO.

> potential minor security threat of HAO with ingress filtering.

But we don't want to delay MIPv6 any more than we need to.

  Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 17 Jan 2002 09:08:17 -0800

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
> create holes in the set of standards track RFCs we issue.

For some people, RFC means Request For Comment.

Surely you don't think an RFC means anything with respect to real-world,
operational deployment. It is easy to point to RFCs (especially IPv6 ones),
that are operationally dysfunctional. Anyone writing code and making systems
work sees that. Most of those people have no time or inclination to make
"comments" in response to your "requests". They are busy making real
networks work. RFCs do not make things work properly. They appear to
mostly be resume-builders and large ISOC archive messages. It does not
even appear that the people writing them have ever deployed any of the
technology they write about. Take a survey of your ICANN and ISOC
leaders. Most of them have never gotten near an IPv6 system. Many of
them rarely even use IPv4 systems. They also do not appear to respond
to your "requests" for "comments".

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Jan 2002 08:49:24 -0800

Hello folks,

I'm pretty far behind on reading these voluminous e-mails, but
I would at least like to express again my belief that we could
go forward with the HAO as it is.  If the downside is that then
there is vulnerability to (single!) packets being reflected back
to an unsuspecting home address, then:

- This is not a completely horrible problem

- It is amenable to solutions that can be deployed later,
  as IPv6 itself becomes more widely deployed

- Solutions involving use of security associations between
  mobile and correspondent will be developed more rapidly if
  there is motivation for use with Proposed Standard Mobile IPv6

- We can be done almost immediately, and begin to productively
  tackle the issues more effectively with experience.

I think there is a very real possibility that we are getting
stalled in worrying over a problem that is not going to happen.

A couple of other points:

> => we don't need to wait because mobile IPv6 is not yet fully specified.

That is purely a matter of opinion.  People have built it and tested it
and it works.  I think it would be far more proper to say that Mobile IPv6
is in fact fully specified, but we have identified more things to do.
Those things should be in new specifications.  I would compare your
statement to be the same as saying "IP was not fully specified until
we had CIDR".  That is manifestly absurd, unless you are willing to
also contend that IP and IPv6 both are not even yet fully specified.

In my opinion, we are not moving forward because we are being
required to boil the ocean before even being allowed to take a drink.

>    access control for HAO is available?

I'd say let's try it.  The likely access controls are not going to
affect the handling at the correspondent node anyway.  The downside
isn't very bad anyway.  If I were a malicious hacker, why would I mess
with that when there are so many other low-hanging fruits to spear?

> filtering, IPv6 firewalls, ...

Phase one is basically requiring reverse tunneling for virtually all
mobility, killing route optimization, and probably along with it any
hope of QoS for many years.  It means that nodes will typically not
receive packets containing the Home Address option, and thus the feature
will rust.

> this year.

Well, technically speaking, it was already in Last Call last year (and
the year before).  But I guess that is really a moot point.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2002 11:01:53 -0800 (PST)

Charles E. Perkins writes:
 > to an unsuspecting home address, then: []

   That is not the only downside. The primary downsides
   have been discussed here ad nauseum. 

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2002 11:06:58 -0800 (PST)

> later than when MIPv6 becomes Proposed Standard.

   I agree 100% with Erik here, and add this:
   security needs to be thought of in terms of
   layers. Ingress filtering is a useful, but
   incomplete layer. Ultimately hosts need a means
   to defend themselves too since we can't assume
   that anything will have complete coverage.

		 Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 17:11:21 +0100

=> for IPv6? I'd like this is true but can you say more
(which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists,
which commercial firewalls have IPv6 support?)

   > filtering, IPv6 firewalls, ...
   
   You know full well that e.g. ip6fw, ipf, iptables (all free) etc.

=> no, we talk about commercial firewalls even if I share my not-expressed
opinion about them.

=> I don't want to spread FUD, I just wanted to show what is FUD...

Regards

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 18 Jan 2002 08:22:05 -0800

>  >                                       If the downside is that then

I looked at a lot of stuff, but that's the only one I saw,
even though it can be dressed up in different ways.
What else is there?

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 18:40:10 +0200

> => no, we talk about commercial firewalls even if I share my not-expressed

Francis, I really don't want to define the word "exists" as equivalent
to "included in IOS". Nor do I equate it with "exists commercially".
So, like Pekka Savola noted, there's a open source OSes that deal
with both v6 packets as well as with v4 packets in their firewall and
filtering functions. I also know some leading firewall and VPN vendors
who are working on v6 versions of their products.

But perhaps you meant that ingress filtering isn't generally applied for
v6 yet. That might well be true. But I still don't want you take away my
possibility to go out tomorrow and buy a linux box/product and configure it to
do ingress filtering in my home!

Jari

---

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

> even though it can be dressed up in different ways.

I think you are right Charlie, that is the only downside.
(There's a bunch of other downsides related to fixing
with AAA the hole HAO leaves in ingress filtering, but
that's another issue.)

The primary danger of unconstrained HAO is having even a small
number of attackers spoof HAOs and use a large
number of CNs as reflectors to attack a specific
target even if your network has ingress filtering.
Basically, it voids ingress filtering.

2-way i-trace would still detect the source of these attacks, at least
in some cases. However, my concern is that i-trace isn't ready,
isn't deployed and frankly I don't really believe it being deployed
anytime soon. A hypothetical "Care of Address Option" for MIPv6
would have the same detection power. The trouble with both of
these as opposed to ingress filtering is that they act after the attack
is done or over, while ingress filtering prevents attacks.

In situations where you have no ingress filtering there's really
no difference whether we use HAOs or not.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 18:11:39 +0100

=> I don't see why? Or do you argue that the ingress filtering part
is impossible or very long to specify (obviously not)? The purpose
to move this thread to the IPv6 WG mailing-list is just to fix it
in parallel.

   If we (the IETF) really care about security we need to make sure
   that we don't create holes in the set of standards track RFCs we
   issue.

=> I agree but in this case the target is explicitely "not introduce
significant new vulnerabilities that are not present in IPv4 today".
The new vulnerability has not be proved to be significant and the
proposed reply is designed to get back to the IPv4 situation (where
the reply to the threat, I have to say it again, is a BCP).

   That is all the IETF need to worry about.

=> I disagree, the IETF need to worry about holes in the set of
standards track RFCs we have already issued (the RFCs) and missed (holes).
(this should not happen but we know it's happened)

   made aware of HAO).

=> I believe you'll have the same opinion about BU security too (i.e.
byebye RR :-).

   If we want to go this path I think we need a community supported

=> supported = saying this is the solution or
   supported = have implemented it or
   supported = have deployed it
First is fine, second is possible (MIPv6 people will put pressure on
firewall people, IMHO firewall people need to be more aware of IPv6
in general). The last one is out of the scope of the IETF.

   ingress filtering RFC (BCP or standards track) that handles HAO no
   later than when MIPv6 becomes Proposed Standard.

=> I never use the "we'll fill" argument. My idea is "we can fill/we know
how to fill" in order to not slow down MIPv6 specifications. To move
the thread to the IPv6 WG is for the same purpose.

=> we need only some radius extensions (diameter extensions already
exist (as an author of one of the diameter for MIPv6 drafts, I may
claim this), firewall specs are not really in the scope of the IETF).
Of course if diameter for MIPv6 becomes a real AAA WG activity
(this is in the charter of AAA, the AAA/mobility RFC is very well
written (it makes no difference between IPv4 and IPv6), but AAA
people believe MIPv6 will be ready in many months/years).

=> not if it is done in parallel.

=> by dropping in practice the second phase, no thanks!

   > => you are asking what will happen after some kilometers in a deep fog:
   
   You're confusing specifications, products, and deployed practice.

=> no, I just reject all arguments based on what will happen in the future
at the exception that we want to get IPv6 smart ingress filtering
deployed not after than mobile IPv6. The IETF has no control over
deployment, its control is only over document publication, so the
only thing we can ask is to provide smart ingress filtering documents
before MIPv6 (we can do a bit more because we can implement them too).

=. can I translate your argument in the network access control for HAO
documents should be available (or enough stable) before the MIPv6 one
in the same state? This is unrealistic for DIAMETER (because of the
AAA state), easy for RADIUS and out of the scope of the IETF for
firewalls (I am not a firewall expert, I only know that many commercial
firewalls have a network access control module... in fact the whole
idea is from a team with some firewall persons so I know the whole
thing was put in a commercial firewall more than two years ago but
the @#$... people don't believe there is a market, grr...).

=> my purpose was never to delay MIPv6 but we obviously disagree
about what kind of stuff can be removed safely (i.e. with the
possibility to put them back after) from MIPv6 in order to speed it up.

Regards

PS: we are losing time: keep or kill the triangular routing?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jan 2002 19:36:12 +0200 (EET)

[snip]

There is a downside: destination site's filtering ("spoofing protection" 
from the direction of the Internet) is nullified!

(This attack is especially nasty in "send an UDP exploit" scenarios -- not
necessarily DoS.)

This can be more or less partially repaired, by e.g. allow incoming HAO
with local Home Address only from local MN's, or local MN's that are known
to be outside, or even local MN's that match a specific binding and are
outside.

However, for security, that requires packet filters wanting to protect
from this must have the ability to go into extension headers and match
against HAO.. this is not yet implemented anywhere that I know of; 
requirinig this for security of HAO might be too much.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2002 09:41:09 -0800 (PST)

> from the direction of the Internet) is nullified!

   Thank you. That was exactly what my point was.
   It's not just the reflector attack; the HAO
   nullifies all of the ingress filtering present
   on the net right now. That is distinctly worse
   than the status quo.

	      Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Jan 2002 09:45:30 -0800

Hello Jari,

Thank you very much for this clarification.

> with AAA the hole HAO leaves in ingress filtering, but

AAA for IPv6 is, indeed, quite another problem domain, and
one for which we've hardly started considering the issues. 

> Basically, it voids ingress filtering.

Here, I disagree, although I clearly understand why you would say
that.  The reason I disagree, is that I can specify an augmented
ingress filtering router that will work with HAOs (and, actually,
have already begun to done so). I do understand that such a thing
is harder to build.  Furthermore, I am quite reluctant to get
embroiled in a design discussion about building ingress filtering
routers (notwithstanding (*) below), when what I really want to
do is to move the Mobile IPv6 specification forward.

> is done or over, while ingress filtering prevents attacks.

But the larger problem is that we are being fantastically careful
about avoiding a possible future problem that is:
1) solvable in a backwards compatible way
2) not so horrible,
3) delaying by years the specification, and consequently
4) causing other design dislocations in, e.g., 3G.

In an effort to be constructive, here are some further ideas about
how to limit the damage from the packet reflection which can be
caused by malicious use of unrestricted HAOs.

1) The correspondent node can strictly limit the number of
   care-of addresses available to any one home address (to,
   say, one or two).  It _could_ even do so for the number
   of care-of addresses assignable to home addresses on a
   particular subnet, if we wanted to go to the trouble of
   putting the prefix length back into the Binding Update.

2) The ingress filtering router can strictly limit the number
   of HAOs transmitted from any particular subnet prefix
   per unit time (*).

These are the first things that come to mind, and I believe
they are quite simple to implement.   (1) certainly is.
Plus, I believe that, for the purposes of handling HAOs,
we should begin to distinguish between home addresses that
have security associations established with the correspondent
node, and home addresses that do not.  It is the latter
variety that need to have the strict numerical limitations.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2002 09:48:01 -0800 (PST)

> the reply to the threat, I have to say it again, is a BCP).

   Positing AAA as the necessary band-aid is a non-starter.
   Positing the kind of fix I proposed as a "crazy idea"
   runs into problems with middle of the network RPF
   checking and will, in practice, sink any use of 
   route optimization. HAO's cannot defeat ingress 
   filtering. That is distinctly worse than the
   current net.

   I think we seriously need to consider whether
   we should sever route optimization from this
   draft. Sigh.

		Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Jan 2002 19:04:31 +0100

=> I agree but it seems there is the real point...

=> a two phase approach works never in the security domain or
the triangular routing needs HAO support everywhere to make sense.

=> I still believe the idea to send IPv6 questions to the IPv6 WG
is the correct one. In fact the decision of keeping or killing
the triangular routing is in the hands of IPv6 implementors
(they are supposed to read the IPv6 WG list from time to time).

=> to get stalled is the worst way to get a decision.

   
   > => we don't need to wait because mobile IPv6 is not yet fully specified.
   
   That is purely a matter of opinion.

=> or of what is the meaning of fully specified. It seems I am the author
of this statement so I meant "not yet ready for publication".

=> this one of the drawbacks of security issues...
I am not commenting other remarks because we agree.

=> is a new last call after important changes due to IESG concerns
required? It seems we'll get a new WG last call, and perhaps some
last calls about other (than the spec) MIPv6 documents.

Regards

PS: you are in favor of keeping the triangular routing, aren't you?

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 18 Jan 2002 20:38:47 +0200

> from the direction of the Internet) is nullified!

Yeah. Forgot that, sorry!

Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jan 2002 18:40:59 +0200 (EET)

> which commercial firewalls have IPv6 support?)

If one vendor does not please you, you can try another (not that others
would have better support for these, necessarily) or bug them and/or wait
:-)

RPF is not required for ingress filtering, but sure makes it much easier.

> => no, we talk about commercial firewalls even if I share my not-expressed

Why again we should care about commerical firewalls?  Apparently their 
interests lie elsewhere; IPv6 is not significant enough for them and no 
one wants to pay for the extra.  Therefore those that care use free 
products.

---

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

> that.

Fair enough. Reading on...

>  The reason I disagree, is that I can specify an augmented

Yes. Your approach is a good one, but I think the concern
people have is that they are doubtful whether a sufficiently
good solution exists. I simply don't believe in the AAA approach
to fix this problem, for instance (even if I'm a big fan of AAA for
other purposes and even partially behind the Diameter base spec).
So, if you were able to give some clue to the plan how what
you intend to achieve, perhaps we could go with this approach then.
However, for the moment as has appeared such a hard problem
to me that I really need to see a some convincing parts of the solution
at least before I'd believe this really can be done.

> caused by malicious use of unrestricted HAOs.

Excellent!

>    putting the prefix length back into the Binding Update.

Unfortunately I don't think this will work. One property of the
HAO reflection vulnerability is that the number of nodes offering
"reflection service" is roughly the size of the IPv6 Internet. So,
any rate limitation / address limitation etc will not help if the
attacker chooses another CN the next time.

>    of HAOs transmitted from any particular subnet prefix

This is better than the previous one. But I'm still not too
happy with it. How do we ensure that what seems like
a small bandwidth at the Nokia Research Group router
isn't going to feel like a catastrophy at my home link?
And what if everyone in the Nokia Research Group wanted
to use HAOs at the same time, would their traffic capacity
be cut down too much? What would the value be? What
will it require from the router, is state involved or can you
do it in stateless way?

Also, if the HAO reflection would be used to hide DDoS
attack clients in a number of places, rate limitation at
single router might not help.

> variety that need to have the strict numerical limitations.

I'll treat this as the third offered solution. Like I think Pekka
mentioned some time ago, there's ways of coming up with
SAs that don't necessarily live up to this standard, even if
such SAs would be useful for e.g. preventing passive wiretapping.
But given that Opportunistic IPsec is not deployed much yet, maybe
we could put that consideration aside. Perhaps we should then
consider a rule that forbids HAOs if there's no SA involved? That
would be a possibility. The downside is that you'd still have to
provide for bidir tunneling for cleartext communications. Then
I could also ask that if you bothered to do 2xRSA+1xD-H and
keep at least a few hundred bytes of state at both ends, why
couldn't you use RO at that time too?

In conclusion I like these ideas better than the AAA approach.
However, I still think we'd need something even better to
start considering this alternative for real.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Jan 2002 19:06:05 +0100

=> this is 4.1 section of my draft:
 - the vulnerability can exist *only* if there are some home agents
   inside the site (this is a strong constraint)
 - the defense is basically the same: the filtering devices have to
   know the bindings (the home registrations are enough) by the way
   you'd like (several work, the only implementation I know uses
   BU/BA snooping with success).

=> no, this can be fully repaired. And in most cases very easily:
no home agent = no binding = just apply the anti-spoofing to everything
that can be a source address.

   against HAO..

=> if your packet filter doesn't already do that, change it ASAP.

   this is not yet implemented anywhere that I know of; 

=> this was implemented 30 months ago somewhere I know of.
(I can ask for a testimony if you really want it)

   requiring this for security of HAO might be too much.
   
=> if I apply your argument to the routing header it should be forbidden...
I strongly disagree: stupid defects in some stupid firewalls should not
be admissible arguments against a protocol feature.

Regards

PS: the position of the HAO in packets was required by some firewall people,
so I believe there are at least two firewall expert teams which already
managed how to deal with HAOs...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Jan 2002 19:15:48 +0100

=> if "ingress filtering" is your message is anti-spoofing, I've answered
in a previous mail, so I consider this is the traditional ingress
filtering.
I believe you made a confusion between causes and effects. Ingress
filtering itself as no value, ingress filtering is a reply to
the source address spoofing threat which itself is only an option
to the DDoS threat. So the HAO problem is *only* the reflector attack
in this context (i.e. without anti-spoofing considerations).

Regards

PS: we do no progress. After Monday I'll answer only comments to
my draft and threads proposed by the mobile-ip WG chairs.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Jan 2002 21:51:57 +0200 (EET)

> => this is 4.1 section of my draft:

I know.

You're making assumptions here:

 - every packet filter in the internet can
   1) recognize HAO
   2) parse it, and
   3) match against the address in it

This does not hold *at all*.  I doubt very much even a half of IPv6 packet 
filters, router access-lists etc. would do this in a few years' time (look 
how long it has taken to e.g. get anycast implemented, and to what 
success..).

The easiest method, which *might* be deployable soonish would be a check 
whether HAO exists or not (1) above), and drop all packets with it.  
However, this would kill all the use for HAO too; not good enough.
  
Iff 3) above holds, every site which does not have mobile nodes of its own 
can be protected.  (If it has MN's, state/AAA or more lax security for the 
addresses is required.)

In my opinion, this is an unrealistic requirement.

> that can be a source address.

See above.
 
> => if your packet filter doesn't already do that, change it ASAP.

I don't know of any alternative.
 
> (I can ask for a testimony if you really want it)

I'm interested, sure.

But really, I'm not all that interested if it was implemented just 
somewhere and not integrated with any firewalling products.
 
> be admissible arguments against a protocol feature.

Perhaps, perhaps not.  But I was not advocating Routing Headers be 
filtered in firewalls; I was not advocating HAO be either (because both 
are difficult problems which I think will not be deployed in the real 
world very widely).

Instead, I was advocating stronger checks in the end-nodes, thus
eliminating the need for firewall security checks except for those 1% who 
really want to go and build the AAA system to get the extra control and 
security.  For routing headers, it appears this issue will be clarified.  
For HAO, this is still open as it would require bigger modifications.

> managed how to deal with HAOs...

Wrong assumption.  This means some firewall people have analyzed what it 
seems to be required to manage HAO at all: whether it can be checked under
every circumstance (e.g. IPSEC secured data) and where it is usually 
located (check for the existance of the header, not necessarily the 
content).  This speaks nothing for implementing parsing for it, or 
anything.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 14:54:47 +0100

=> Jari meant network access control, not full AAA with AAA infrastructure.

   Furthermore, I am quite reluctant to get
   embroiled in a design discussion about building ingress filtering
   routers (notwithstanding (*) below), when what I really want to
   do is to move the Mobile IPv6 specification forward.
   
=> I agree, the ingress filtering stuff should be dealt with in parallel.

   
=> I don't believe in defense at CNs with triangular routing,
I am afraid this will catch only buggy attacks.

=> this can be useful in order to detect abnormal situations
(i.e. attacks) but not to fix them (it is too hard to distinguish
between legitimate and fake HAOs so the system can be itself
the target of a DoS attack).
The best passive protection is BU/BA snooping (all interesting
parameters are in the exchange and BAs are easy to check) but
if it is effective when possible (no too much ciphered fields,
snooping devices in the path), I personnaly prefer more active
schemes (mainly because they give far better proofs in the legal
meaning... but I believe firewall people prefer snooping which is
more common in their context).
BTW I've interpreted your statement as the number of *different* HAOs
transmitted...

=> with current specs a MN must have a home registration with is
always acknowledged so BU/BA snooping is the next step of your idea.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 20 Jan 2002 16:21:11 +0100

=> every firewall

      1) recognize HAO
      2) parse it, and
   
   This does not hold *at all*.

=> this holds for every decent firewalls: they do URL filtering and you
are trying to say they don't know how to dig into a packet?

   I doubt very much even a half of IPv6 packet filters, router
   access-lists etc. would do this in a few years' time

=> I assume we'll get at least the same level of technology which is
used today near everywhere for IPv4.

=> I agree that today situation for HAO is "ignore all" and the next step
is "drop all". I expect a third step (I am optimistic (:-) and this
is a problem of balance between mobility industry and firewall industry).

   can be protected.

=> yes, to know there is no binding at all is a perfect knowledge of
current bindings (:-).

   (If it has MN's, state/AAA or more lax security for the 
   addresses is required.)
   
=> please use "network access control" in place of AAA because some FUD
is based on the confusion between network access control and AAA
infrastructure.

=> what is unrealistic is to believe firewalls are not commonly used...

   > anti-spoofing stuff...
   
   See above.
    
=> anti-spoofing is different because the simple case is "no HA" which
should be far more common than "no MN". The way to use firewalls is
more usual too and gives more freedom.

    
=> I know at least one but it is not yet commercially available
(I can privately give some pointers). I believe there are others
(ready but not available).

=> a network access control please, no the AAA system

   security.

=> this doesn't work: if we kill the triangular routing following your
suggestion there will be no exception at all.
   
   > managed how to deal with HAOs...
   
   Wrong assumption.

=> please let Charly Perkins (or these persons) answer.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 10:42:08 +0100 (CET)

> to move this thread to the IPv6 WG mailing-list is just to fix it

It's just that I haven't seen credible solution to distributed ingress
filtering of packets with HAO that doesn't resort to have a global AAA
infrastructure to solve the hard problem.
I personally think we need solutions that don't required additional
infrastcuture.

> (this should not happen but we know it's happened)

Sure, in addition to make sure that new stuff doesn't have holes we either
need to fix or deprecate existing stuff with security holes.
I don't think I said anything to the contrary.

> => I believe you'll have the same opinion about BU security too (i.e.

I don't understand the point and I don't understand the joke.
Could you be more explicit?

> in general). The last one is out of the scope of the IETF.

If youn read the whole sentence before interjecting the comments (it's below)
you'll see it was about an RFC. BCP and Proposed standards are not required
to be implemented and/or deployed in order to be publishes as such.

> in the same state? 

Yes, this is what I said several times now.
No PS for MIPv6 with a security hole in my personal opinion.
Means that a PS or BCP smart ingress filtering (set of) RFC need to exist
at that time as MIPv6 becomes PS.

> This is unrealistic for DIAMETER (because of the

Above you said it wouldn't delay MIPv6 to do this (because of it being done
in parallel) but now you seem to say it would delay it because of various
reaons. So you seem to agree with me about the delay? 

> PS: we are losing time: keep or kill the triangular routing?

I say: Remove the unauthenticated and unauthorized use of HAO which
has the effect that tringular routing isn't an option. The only options
are bidirectional tunneling through the HA and route optimization.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Jan 2002 12:34:24 +0100

=> so you'll be very happy when you'll read my draft which relies only
on *enough* of any kind of network access control (even passive one,
aka BU/BA snooping which can have the favour of firewall folk).

=> we agree.

   
=> your statement could suggest the IETF doesn't need to worry about holes
in already published standard track RFCs (we agree this is *not* the case).

   
=> RR is known to be a bit weak from a security point of view so
as a MITM vulnerability can be considered as a hole, your opinion should
be in disfavour of RR, isn't it? (smile again)

   
=> I apologize: I was afraid of overinterpretations of the term supported.

   > =< can I translate your argument in the network access control for HAO
   
   Yes, this is what I said several times now.
   No PS for MIPv6 with a security hole in my personal opinion.
   Means that a PS or BCP smart ingress filtering (set of) RFC needs to exist
   at that time as MIPv6 becomes PS.
   
=> thanks, now there is no possible ambiguities about your opinion.
BTW I fully agree with you about this point.

   reasons.

=> where are the reasons (in document publication, cf above) of delays?
This can only be about the connection between network access controls
and firewalls:
 - there is no IETF protocol about this
 - it seems the current consensus is this is not in the IETF scope
 - this exists, in general in the purpose to be applied to remote
   and/or mobile users, for instance
   http://www.evidian.com/accessmaster/netwall/features.htm#Broad
In many AAA and PANA drafts (including mine :-), there are references
about when the terminal is authentified the firewall is opened for it
(i.e. authorization is "to access to the Internet"). I can't find
details about how this is done, can some firewall folk help us?
(if you know some, can you forward this to them)

   So you seem to agree with me about the delay? 
   
=> one thing we agree is we don't want delay.

   
=> so we disagree only about the necessity to remove the unauthenticated
and unauthorized use of HAO (my argument is there is no such necessity
about source address themselves).

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 14:28:02 +0100 (CET)

> aka BU/BA snooping which can have the favour of firewall folk).

I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume
that the architecture only needs to support ingress at one place.
I think we need to allow ingress filtering to take place at multiple
"levels" such at each college dorm room router, between the college and
the ISP, between leaf ISPs and transits, etc.
I don't see any difference between saying 
 - we can trust the access network to do ingress filtering
 - we can trust the host to not use bogus source addresses
Fundamentally it is an issue about trust boundaries.
If an ISP doesn't do ingress filtering themselves the ISPs that provide
service to it might want to filter. The architecture should not prevent
such flexibility.

> be in disfavour of RR, isn't it? (smile again)

I'm answering the serious underlying question/assumption:

You seem to have not read the abstract in the BU3WAY document.
I never claimed it was the best approach.

In fact, if CGA was free (no IPR concerns and no performance concerns for
the PK operations) doing CGA (in combination with RR to deal with certain
DoS attacks) would be the obvious answer IMHO.

> (if you know some, can you forward this to them)

If we feel that we (the IETF) can't produce documents that say how firewalls
should behave then it would seem foolish for us to produce standards that
assume certain behavior in firewalls.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Jan 2002 19:37:22 +0100

=> this is a constraint: active network access control is usually done
at one place.

=> it seems you have a very bad feeling of your ISP (:-).

=> I fully agree: this is a trust/responsability issue so I am not
surprised when this can be described with AAA terms (for instance
this is about "the authorization to use this home address").

   The architecture should not prevent such flexibility.

=> what does prevent flexibility is the only current technical
concrete form of trust/responsability is network access control systems.   

=> IMHO BU3WAY is an attempt to get the faster/cheaper security
scheme for BUs (the opposite of IKE+AH).

=> so I've put again a smile.

=> if CGA was free we have a lot of better solutions to many problems
(including the HAO vs ingress filtering one) but it has both IPR and
performance concerns...
   
   If we feel that we (the IETF) can't produce documents that say
   how firewalls should behave

=> this is about details of communication between network access controls
and firewalls, not about firewall behavior. BTW my draft is essentially
a firewall behavior specification.

   then it would seem foolish for us to produce standards that
   assume certain behavior in firewalls.
   
=> firewall people were not enough (? :-) foolish to wait for us
to specify how network access controls and firewalls should communicate.
More seriously I've looked at what is available:
 - it seems a lot of firewalls support this kind of feature for
   remote/mobile access (all the commercial firewalls still in the market)
 - IPF (well known open source firewall) has the auth/preauth actions
   which do exactly what is needed (unfortunately the IPv6 support of IPF
   is questionable and has not (*yet*) HAO support.)

Regards

---

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

> => this is a constraint: active network access control is usually done

I wasn't talking about network access control - I was talking about ingress 
filtering. 
While e.g. an ISP/subscriber relationship might have some network access
control that isn't the only place ingress filtering might need to be done.

> => it seems you have a very bad feeling of your ISP (:-)

Yes I do, but I don't trust the whole edge around the whole Internet.
There probably exists at least one ISP on the planet that will
allow any source address in the packets sent by their subscribers.

Thus it needs to be possible to ingress filtering at other places than
just the ISP/subscriber boundary.

> concrete form of trust/responsability is network access control systems.   

Sorry, wrog subject. We were talking about ingress filtering and
not network access control I think :-)

  Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 21 Jan 2002 12:44:47 -0800

> allow any source address in the packets sent by their subscribers.

where...Internet =??? "toy, legacy, IPv4 Internet"

http://www.dot-biz.com/IPv8/Papers/

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 23:34:38 +0100 (CET)

Charlie,

> receive packets containing the Home Address option, and thus the feature

I don't understand the meaning you assign to "basically" above.

Phase 1 would allow either bidirectional tunneling or route optimization
(in both directions). The thing it wouldn't allow is the triangle when packets
from the MN go directly to the CN, but the other path is through the HA.

   Erik