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
Francis Dupont writes:
> In your previous mail you wrote:
>
> > => 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).
>
> 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
> global infrastructure (though I admit some of it will be built anyway),
>
> => 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
>
> [EMAIL PROTECTED]
>
> 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 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]
--------------------------------------------------------------------
