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

[Pekka Savola <psavola@funet.fi>]

On Mon, 14 Jul 2003, Daniel Senie wrote:
> >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.)
>
> A few comments to this:
>
> There are no references in your document to documents defining RPF
> methodologies. Why?

Because we already discuss that to a certain degree (without formal
definitions and descriptions though), because the concepts are already
rather stable, and at least I aren't aware of any good references which do
that.

And, while the formal definitions and extensive descriptions are probably
useful in unifying the vendors' behaviour, they are not the really
critical for this update of BCP 38.

> They grew out of vendor implementations that were then
> copied. While the mechanisms and definitions may have reached "de facto"
> definition by now, this does not answer questions about whether they all
> work the same. We had that basic question with the many flavors of NAT, and
> so set about writing documents that provide a consistent definition.
> Perhaps this is needed here? In the case of NAT, there was much "common
> wisdom" about how the mechanism worked, yet there was little documentation
> that gave a consistent view.

Yes, I can agree that such a document could be useful, but I also think
that it is of a lower priority than getting this multihoming update out.

> It would make sense to more clearly define the functionality of RPF in a
> separate document, and include in that document the issue I have raised,
> and have the present document reference that document. This would
> necessarily mean delay in publishing this present document.

If such a document would be reasonably quickly written (e.g. 1-2 months or
the like), I wouldn't have objections.  My main worry, however, is that
such a document would be more controversial than this one -- and if the
reference is normative, it could end up holding the publication.

> >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.
>
> As previously stated, a document about RPF in general needs to be drafted.
> I would be happy to be involved in authoring such a document. It is my
> opinion that a document about only RIB-based RPF lookups  alone would fall
> short of what's needed.

I can agree with that, but defining semantics of RPF in general is
(understandably) a low priority item for me at least.  Of course, if you
see it as important, you should work on it.  I could probably even make
some cycles to give it some extensive review.

> >But such considerations don't seem to have a place in this
> >*operational* document.
>
> When we wrote 2267 and later revised it as 2827, there were questions about
> whether it was really something that could be implemented. I will never
> forget Mike O'Dell glaring down at me in the lobby of the hotel in Memphis
> explaining how the Cisco 7000 routers in the core of his network would melt
> if our document were implemented, and that because of this he didn't think
> the document had any merit.

Agree: I'm not saying that e.g. a RIB-based mechanism would be an
impossibility; it would seem to me a relatively simple extension to strict
RPF especially in the cases where it makes the most sense.

But this, the mechanism hasn't been thought out yet, and even if it were,
it would take time to deploy.  We thought, and still think, that it's
better to focus on what we have (and if we kickstart other efforts to
specify better RPF mechanisms, all the better).

> > > 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 claim, as I stated above, that only today's deployment matters, is
> insufficient grounds for arguing what should be in a BCP, in my opinion.
>
> To further this argument: RFC 2644 revised the settings for RFC 1812 on
> directed broadcast. While we all knew it was the right thing to do, not all
> router vendors were then shipping products with the ability to configure
> the setting of directed broadcasts. Did that mean we shouldn't publish the
> document?

Quite the different argument.  We're in the same situation, I think.  Not
all vendors implement strict RPF; even fewer implement loose RPF (or
different variations of it).  But it's deployed enough so the mechanisms
are credible.

However, e.g. RIB-based mechanisms haven't even been thought out yet (and
I fear there may be a gotcha or two waiting when thinking them out; I
recall I got bitten by them when I tried to write out my thoughts a few
months ago).

> Network operators pick and choose which BCPs they implement, just as
> vendors pick and choose among which standards-track RFCs to implement.
> Providing guidance regarding optimal solutions, even if they can't yet be
> fully achieved, is worthwhile. If it weren't, I doubt RFC 2827 would have
> been published as a BCP.

RIB-based mechanisms etc. are WAY too far from being even a solution yet.

Note that we don't Obsolete BCP 38; we just Update it.  There is no
problem coming back later, e.g. in a year, with more knowledge and a
fleshed out idea and updating it again.

Pekka