In your previous mail you wrote:
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.]
=> 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".
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.
=> we agree.
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.
=> in both cases the term mandate is far too strong.
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.
=> I agree, the whole issue is where to put the responsability (or
who trust to).
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,
=> 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...
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.
=> 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.
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.
=> 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
[EMAIL PROTECTED]
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 PROTECTED]
--------------------------------------------------------------------
