Re: Last Call: Ingress Filtering for Multihomed Networks to BCP

[Pekka Savola <psavola@funet.fi>]

Hi,

Fred already answered, but I'll try to answer on my own because I was
almost finished writing this, and to give an operator's perspective.

On Mon, 14 Jul 2003, Daniel Senie wrote:
> >The IESG has received a request to consider Ingress Filtering
> >for Multihomed Networks <draft-savola-bcp38-multihoming-update-00.txt>
> >as a BCP.  This has been reviewed in the IETF but is not the product
> >of an IETF Working Group.
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action.  Please send any comments to the
> >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-8-6.
>
> Writing as an author of the to-be-updated document, I have some serious
> concerns about this document. The information provided is useful to an
> extent, but centers around issues specific to particular vendor or vendors
> methodologies of implementation (specifically strict and loose RPF).

The ways of implementing RPF are quite common, and are not specific to any
one implementation.  I fail to see why you couldn't use the names of
typical implementation methodologies if they're commonly used and
understood, and vendor-independent.  (For example, most of the routers in
our networks are not Ciscos -- to take one example -- and different
flavors of RPF are still there.)

> My concern is this: It is entirely possible (though with present
> architectures less optimal) to implement a source address check mechanism
> in a router that performs the lookups in the RIB, thereby finding whether
> the egress interface selected is VALID (not necessarily optimal for
> ingress) for the source IP address in question. That equipment vendors have
> not chosen to implement such checks is a separate issue. In my opinion a
> complete RPF implementation would provide such a RIB check.
>
> To be fair, the overhead to properly implement such a complete RPF check in
> some router vendors' architectures may be difficult. Nevertheless, the
> impression one gets reading this document is that the methods implemented
> to-date are as good as can be done.
>
> While this proposed update deals with operational issues, failing to
> discuss the possibility of RIB-based RPF also fails to raise a technology
> issue that implementors might find useful and interesting. If we were to
> explain this possibility, and the technical hurdles to achieving it, there
> is a chance network operators would enquire with their vendors about the
> costs to implement.

This is an operational document.  As a matter of fact, I discussed my
exact same idea of using RIB-based lookups (for "potentially best paths")
with Fred, and we got to the conclusion that it should be in the separate
document ("operational").

However, when I got down to start thinking of the details of RIB-based
mechanism, there were some issues I wasn't able get around, especially in
the case where you're using BGP Route Refresh (which would be basically
incompatible with the mechanism -- soft-reconfiguration (in Cisco/Juniper
speak) would be ~OK though.)

If you want to try to draft a memo on RIB-based lookups, I can certainly
co-author it (if you want), and try to help it go forward.

But such considerations don't seem to have a place in this
*operational* document.

> RFC 2267/2827 recommend the source IP address be verified as valid. Access
> lists are but one mechanism to achieve that. Automated RPF schemes are
> certainly of interest in that they leverage the routing system's tables to
> perform the work. With sufficient light on the issue, I believe network
> operators would prefer an automated system that checks the proper routing
> table.

See above; RPF is what people have now, so that's what our operational
document covers.  I certainly would like to have better system, but that
doesn't help in our network *today*.

> The acknoledgement section, though cute, is inappropriate.

I kind of agree; a trivial thing to change.

Pekka