[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 10:06 AM 7/14/2003, Pekka Savola wrote:

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.)
A few comments to this:

There are no references in your document to documents defining RPF methodologies. Why? 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.

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.


> 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.
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.


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.


> 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?

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.


> The acknoledgement section, though cute, is inappropriate.

I kind of agree; a trivial thing to change.

Pekka