Skip to main content

Ingress Filtering for Multihomed Networks
RFC 3704

Revision differences

Document history

Date Rev. By Action
2015-10-14
03 (System) Notify list changed from <fred@cisco.com>, <pekkas@netcore.fi> to <pekkas@netcore.fi>
2012-08-22
03 (System) post-migration administrative database adjustment to the Yes position for Russ Housley
2004-03-23
03 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-03-19
03 (System) RFC published
2004-01-06
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-01-05
03 Amy Vezza IESG state changed to Approved-announcement sent
2004-01-05
03 Amy Vezza IESG has approved the document
2004-01-05
03 Amy Vezza Closed "Approve" ballot
2003-12-31
03 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2003-12-31
03 Bert Wijnen Revision 3:
  Discuss comments have been cleared.
  Other comments have been addressed.
2003-12-31
03 Bert Wijnen Status date has been changed to 2003-12-29 from 2003-12-11
2003-12-23
03 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley
2003-12-23
03 (System) New version available: draft-savola-bcp38-multihoming-update-03.txt
2003-12-22
03 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Yes from Undefined by Thomas Narten
2003-12-22
03 Thomas Narten
[Ballot comment]
Editorial:

>    There are at least five ways one can implement RFC 2827, with varying
>    impacts. These include:
> …
[Ballot comment]
Editorial:

>    There are at least five ways one can implement RFC 2827, with varying
>    impacts. These include:
>
>    o  Ingress Access Lists
>
>    o  Strict Reverse Path Forwarding
>
>    o  Feasible Path Reverse Path Forwarding
>
>    o  Loose Reverse Path Forwarding
>
>    o  Loose Reverse Path Forwarding ignoring default routes

Are these names in common usage, or are they defined by this document?
I ask because some of them don't make intuitive sense to me and better
names might be appropriate. More later...

>    An Ingress Access List is a filter that checks the source address of
>    every message received from a network against a list of acceptable
>    prefixes, dropping any packet that does not match the filter. While

s/from a network/ received on a network interface/? This check is per
interface, in essence, since a key part of the check is knowing what
interface the packet arrived on.

>    However, Ingress Access Lists must be kept up-to-date manually; for

"must be"? I can believe this is the case in practice, but this does
not seem an inherent requirement. later, the document talks about
tying this list into routing protocols.

Suggest:

s/must be .. manually/are typically maintained manually/

>    However, Ingress Access Lists must be kept up-to-date manually; for
>    example, forgetting to have the list updated at the ISPs when
>    starting to multihome might lead to discarding the packets if they do
>    not pass the ingress filter.

Also, I don't think its correct to assume that multihoming breaks
ingress filtering. What breaks it is a change in the list of legit
prefixes. That can happen not just because of multihoming. And
multihoming doesn't automatically cause this.

Better:

    example, forgetting to have the list updated at the ISPs if the
    set of prefixes changes (e.g., as a result of multihoming) might
    lead to discarding the packets if they do not pass the ingress
    filter.

>    filters and interface access-lists). The procedure is that the source
>    address is looked up in the Forwarding Information Base (FIB) - and
>    if the packet has come from the "expected direction", it passes the
>    check.

To be clear, is the check:

  "the packet is received on an interface
  other than the one it would send packets out on when forwarding
  traffic to the source of the packet?"

Might be good to say this.

>    It is critical to understand the context in which Feasible RPF
>    operates.  The mechanism relies on consistent route advertisements
>    (i.e., the same prefix(es), through all the paths) propagating to all
>    the destinations.  For example, this may not hold e.g. in the case

Is the above correct, or is it that the route must propage to all
routers doing the Feasible RPF checking?

> 2.4 Loose Reverse Path Forwarding

>    Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar
>    to strict RPF, but differs in that it checks only for the existence
>    of a route, not where the route points to.

It is not clear (to the reader) that default routes are included here
as "routes". It  would be good to make the clear here. (this becomes
more clear when one gets to the next section.)

Also, this isn't RPF, as RPF by defn. means checking the
direction. Change term perhaps? Call it "Route Presence Check"
perhaps?

> 2.5 Loose Reverse Path Forwarding Ignoring Default Routes

Call it "Explicite Route Presence Check" (or something)?

>    The fifth implementation technique may be characterized as Loose RPF
>    ignoring default routes. In this approach, the router looks up the
>    source address in the route table, and preserves the packet if a
>    route is found. However, in the lookup, default routes are excluded.
>    Therefore, the technique is mostly usable in scenarios where default
>    routes are used in addition to an extensive (or even full) list of
>    more specific routes.

Suggest replacing last sentence with something like:

    Therefore, the technique is mostly usable in scenarios where
    default routes are used only to catch traffic with bogus source
    addresses, with an extensive (or even full) list of explicit
    routes to cover legitimate traffic.

>    limitations of ingress filters for multihomed networks. Options
>    include:

Might be better to number these, since you later refer to them by "the
third", etc.

>    o  Ensure that edge networks only deliver traffic to their ISPs that
>      will in fact pass the ingress filter.

A better transition to section 4.1 would help. For the above item, its
not clear to the reader that this will be discussed later in the
document (section 4.3), even though the text talks about the other
points.

>    Therefore, the use of Loose RPF cannot be recommended in this
>    scenario.

Which scenario is being referred to here? where asymetric routing is
in use? be explicit.

> 4.3 Send Traffic Using a Provider Prefix Only to That Provider

This is a funny definition of multihoming. What benefits do you
actually get from being multihomed in this scenario? Do people
actually do this? Or is a key point that the tunnel that gets created
gets routed via the other ISP, rather than internal to the site? (if
so, saying this would be good).

>    Ingress filtering is typically performed to ensure that traffic
>    arriving in one network legitimately comes from a computer in the
>    other network.

better:

  Ingress filtering is typically performed to ensure that traffic
  arriving on one network interface legitimately comes from a
  computer residing on a network reachable through that interface.

Nits:

>    problems of its own when e.g. multihoming. This document describes

s/when e.g./when, e.g.,/

(occurs elsewhere too)

>    filtering, by verifying that their prefix are not used in the source
>    addresses in packets received from the Internet. In other attacks,

s/prefix/prefixes/

  best route there, the alternative pajths (if any) have been added as

spelling

>    discarding any traffic they do not have a "real" route to ,and

s/,and/, and/

>    defence in depth.

spelling
2003-12-22
03 Thomas Narten [Ballot Position Update] New position, Undefined, has been recorded for  by Thomas Narten
2003-12-19
03 Alex Zinin [Ballot comment]
Good document
2003-12-19
03 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-12-18
03 Amy Vezza Removed from agenda for telechat - 2003-12-18 by Amy Vezza
2003-12-18
03 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2003-12-18
03 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-12-18
03 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-18
03 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for  by Harald Alvestrand
2003-12-18
03 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-12-17
03 Ted Hardie
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work
when you have both …
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work
when you have both paid upstream providers and peers.  It is now fairly common to have
folks engage in multihoming in order to get PI space, then engage in peering (sometimes
regional, sometimes "eyeball-to-content", or as a cost reduction measure when the
networks have co-located pops).  Peering relationships commonly require traffic
restrictions, often based on the announcements heard at each connection point.
Implementing these restrictions and also using access control lists is fairly easy; describing
how  to implement them alongside the RPF-like mechanism with minimum pain would
be a useful addition to the later work.
2003-12-17
03 Ted Hardie
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work
when you have both …
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work
when you have both paid upstream providers and peers.  It is now fairly common to have
folks engage in multihoming in order to get PI space, then engage in peering (sometimes
regional, sometimes "eyeball-to-content", or as a cost reduction measure when the
networks have co-located pops).  Peering relationships commonly require traffic
restrictions, often based on the announcements heard at each connection point.
Implementing these restrictions and access control lists is fairly easy; describing how
to implement them with the RPF-like mechanism with minimum pain would be a useful addition
to the later work.
2003-12-17
03 Ted Hardie
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work when you have both …
[Ballot comment]
As an item of further work, I think it would be valuable to look at how these mechanisms work when you have both paid upstream providers and peers.  It is now fairly common to have
folks engage in multihoming in order to get PI space, then engage in peering (sometimes
regional, sometimes "eyeball-to-content", or as a cost reduction measure when the
networks have co-located pops).  Peering relationships commonly require traffic
restrictions, often based on the announcements heard at each connection point.
Implementing these restrictions and access control lists is fairly easy; describing how
to implement them with the RPF-like mechanism with minimum pain would be a useful addition
to the later work.
2003-12-17
03 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for  by Ted Hardie
2003-12-17
03 Russ Housley
[Ballot discuss]
I really like this document, but I think a small amount of rearrangement
  will help the reader.  The text at beginning of …
[Ballot discuss]
I really like this document, but I think a small amount of rearrangement
  will help the reader.  The text at beginning of Section 5 is about
  security, and I think the reader would be better served if it were in
  the Security Considerations section.  The text that is in the Security
  Considerations section is much weaker than the material in Section 5.
 
  I suggest breaking the current Section 5 into two parts.  Rename the
  first part Security Considerations.  Sprinkle the text from the current
  Security Considerations section to taste.  Then, delete the current
  Section 6.  Call the second part of the current Section 5 'Conclusions
  and Future Work' and number it Section 6.
2003-12-17
03 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for  by Russ Housley
2003-12-16
03 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for  by Allison Mankin
2003-12-16
03 Steven Bellovin [Ballot Position Update] New position, Yes, has been recorded for  by Steve Bellovin
2003-12-12
03 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-12-11
03 Bert Wijnen Telechat date was changed to 2003-12-18 from 2003-11-20 by Bert Wijnen
2003-12-11
03 Bert Wijnen State Changes to IESG Evaluation from AD Evaluation by Bert Wijnen
2003-12-11
03 Bert Wijnen Status date has been changed to 2003-12-11 from 2003-11-29
2003-12-11
03 Bert Wijnen Placed on agenda for telechat - 2003-11-20 by Bert Wijnen
2003-12-11
03 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2003-12-11
03 Bert Wijnen Ballot has been issued by Bert Wijnen
2003-12-11
03 Bert Wijnen Created "Approve" ballot
2003-12-11
03 (System) Ballot writeup text was added
2003-12-11
03 (System) Last call text was added
2003-12-11
03 (System) Ballot approval text was added
2003-11-29
03 Bert Wijnen State Changes to AD Evaluation from Publication Requested::Revised ID Needed by Bert Wijnen
2003-11-29
03 Bert Wijnen New revision received on Nov 19th, 2003.
Checking if new IETF Last Call is needed.
And reviewing myself (Bert)
2003-11-29
03 Bert Wijnen Shepherding AD has been changed to Bert Wijnen from Randy Bush
2003-11-29
03 Bert Wijnen Status date has been changed to 2003-11-29 from 2003-08-07
2003-11-19
02 (System) New version available: draft-savola-bcp38-multihoming-update-02.txt
2003-11-11
03 Randy Bush Removed from agenda for telechat - 2003-11-20 by Randy Bush
2003-11-07
03 Randy Bush
From: Randy Bush <randy@psg.com>
Date: Fri, 7 Nov 2003 08:08:23 -0800
To: Pekka Savola <pekkas@netcore.fi>
Cc: Fred Baker <fred@cisco.com>, …
From: Randy Bush <randy@psg.com>
Date: Fri, 7 Nov 2003 08:08:23 -0800
To: Pekka Savola <pekkas@netcore.fi>
Cc: Fred Baker <fred@cisco.com>,
    Daniel Senie <dts@senie.com>
Subject: Re: draft-savola-bcp38-multihoming-update-01.txt

> It seems there are about three different possibilities how to go on from
> here.
>
>  1) go for the IESG review on 20th Nov, as is currently, try to
> incorporate comments after the IESG review.  Drawback: IESG gets a
> non-final product.  Advantage: the authors get IESG feedback earlier.
>
>  2) postpone the IESG review to 4th Dec, to give time for revision (and
> incorporation of new comments, if any).
>
>  3) issue a new last call and postpone the IESG review, the earlier
> possibility would be 18th Dec but that probably won't exist, so I guess it
> would go over the holidays.
>
> >From my personal perspective..
>
> 1) seems preferable, 2) is also fine especially if we value the IESG's
> time (dunno how "final" the work arriving there should be -- but I'd
> really appreciate more eyes, with wider perspective (=IESG) on the draft
> sooner rather than later), 3) seems like an unreasonable overkill.

as daniel is the one asking for something different, it would be
helpful if he would comment.

randy
2003-11-05
03 Randy Bush
Daniel Senie felt that the document was significantly changed since IETF last call and asked that it be last called again.

Randy asked the authors …
Daniel Senie felt that the document was significantly changed since IETF last call and asked that it be last called again.

Randy asked the authors and Daniel to sort this out, decide the best forward path, and tell him.
2003-10-29
03 Randy Bush Placed on agenda for telechat - 2003-11-20 by Randy Bush
2003-10-23
01 (System) New version available: draft-savola-bcp38-multihoming-update-01.txt
2003-08-20
03 Randy Bush State Changes to Publication Requested::Revised ID Needed from IESG Evaluation by Randy Bush
2003-08-20
03 Randy Bush i did not ask this to be put on the agenda!!!
2003-08-20
03 Randy Bush Removed from agenda for telechat - 2003-08-21 by Randy Bush
2003-08-19
03 Amy Vezza Placed on agenda for telechat - 2003-08-21 by Amy Vezza
2003-08-19
03 Amy Vezza State Changes to IESG Evaluation from Publication Requested::Revised ID Needed by Amy Vezza
2003-08-16
03 Randy Bush State Changes to Publication Requested::Revised ID Needed from 0::Revised ID Needed by Randy Bush
2003-08-14
03 Randy Bush State Changes to 0::Revised ID Needed from In Last Call by Randy Bush
2003-08-14
03 Randy Bush
Date: Thu, 14 Aug 2003 13:10:04 -0700
To: Randy Bush <randy@psg.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: draft-savola-bcp38-multihoming-update-00.txt
Cc: <pekkas@netcore.fi …
Date: Thu, 14 Aug 2003 13:10:04 -0700
To: Randy Bush <randy@psg.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: draft-savola-bcp38-multihoming-update-00.txt
Cc: <pekkas@netcore.fi>

At 12:37 PM 8/14/2003 -0700, Randy Bush wrote:
>will this document be revised based on last call comments?

yes; Pekka is picking that up. Did you receive comments that we might not have?
2003-07-10
03 Randy Bush Status date has been changed to 2003-08-07 from
2003-07-10
03 Randy Bush State Changes to In Last Call from Last Call Requested by Bush, Randy
2003-07-09
03 (System) Last call sent
2003-07-08
03 Randy Bush FOUR WEEK IETF last call please
2003-07-08
03 Randy Bush Draft Added by Bush, Randy
2003-05-27
00 (System) New version available: draft-savola-bcp38-multihoming-update-00.txt