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
Francis Dupont writes:
> In your previous mail you wrote:
>
> [Phil suggested I add mobileip back which was
> dropped somewhere along the way]
>
> 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
>
> => 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.
>
> 2) It sends a packet using its home address as the
> *source* address -- no HAO at all.
>
> => I propose that the packet is sent to the home agent (or something
> similar).
>
> 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
>
> => 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) MN sends AR a normal CN binding update
>
> => 4) is what I consider as a kind of network access control.
>
> 5) AR lifts the restriction for that source address
>
> => 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.
>
> 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.
>
> => i.e. active/reactive modes.
>
> 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).
>
> => in any case ICMP errors have to be sent when packets are dropped,
> I believe we can reach a consensus about this very quickly.
>
> 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.
>
> => 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).
>
> However, may I suggest that it's the AAA part that
>
> => 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.
>
> has become the lightning rod? And that maybe it
> shouldn't be quite so ambitious? :-)
>
> => 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
>
> [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]
--------------------------------------------------------------------
