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 |