In your previous mail you wrote:
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
=> for (b) I prefer network access control (AAA is only one way
to provide it).
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.
=> so it seems we have to wait for the face-to-face meeting.
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.
=> 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.
- 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.
=> HAO is not MIPv6 only (i.e. be prepared to relax it :-).
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.
=> I agree: (c) is unrealistic.
2. We will have a two-phased approach to the MIPv6 spec and
=> 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.
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.
=> 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.
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.
=> 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
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
