Ingress filtering: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
mNo edit summary
m (Text replacement - "[[" to "")
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{subpages}}
{{PropDel}}<br><br>{{subpages}}
'''Ingress filtering''' are a class of standard [[network security]] measures used in [[Internet Protocol]] networks. They are all based on the assumption that if  a packet attempts to enter the network, but the network has no ''reverse route'': a means to send a reply back to the source address in the packet header, the packet must be forged (i.e., an example of ''IP spoofing'') or in error. Packets with invalid addresses are sometimes called ''bogons''.
'''Ingress filtering''' are a class of standard network security measures used in Internet Protocol networks. They are all based on the assumption that if  a packet attempts to enter the network, but the network has no ''reverse route'': a means to send a reply back to the source address in the packet header, the packet must be forged (i.e., an example of ''IP spoofing'') or in error. Packets with invalid addresses are sometimes called ''bogons''.


When the idea was first standardized, it was generally implemented on a per-interface basis.<ref name=ingress-SH>{{citation
When the idea was first standardized, it was generally implemented on a per-interface basis.<ref name=ingress-SH>{{citation
Line 6: Line 6:
  | title = Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
  | title = Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
  | author = P. Ferguson & D. Senie
  | author = P. Ferguson & D. Senie
  | date = May 2000 | id = RFC 2827, IETF BCP (Best Current Practice) 34}}</ref> In early [[router]]s, this was done with explicit [[access control list]]s (ACL) on the interface, which was a benefit if the interface had some autonomous hardware that could filter. Filtering was often computationally expensive if done in a general-purpose interface processor, and improvements were sought.  One approach was the use of [[ternary content addressable memory]], which could do hardware-based ACLs, but TCAM was too expensive for large routing tables. Per-interface ACLs could also be labor-intensive to keep current.
  | date = May 2000 | id = RFC 2827, IETF BCP (Best Current Practice) 34}}</ref> In early routers, this was done with explicit access control lists (ACL) on the interface, which was a benefit if the interface had some autonomous hardware that could filter. Filtering was often computationally expensive if done in a general-purpose interface processor, and improvements were sought.  One approach was the use of ternary content addressable memory, which could do hardware-based ACLs, but TCAM was too expensive for large routing tables. Per-interface ACLs could also be labor-intensive to keep current.


A performance-boosting technique for routing was distributing the [[forwarding information base]] (FIB) to the forwarding cards. The technique of ''unicast reverse path filtering'' came into play when it was realized that the source, as well as the destination, address could be looked up in the FIB. If there were no route to the source address, the packet could be deemed a bogon and silently discarded.  <ref name=ingress-MH>{{citation
A performance-boosting technique for routing was distributing the forwarding information base (FIB) to the forwarding cards. The technique of ''unicast reverse path filtering'' came into play when it was realized that the source, as well as the destination, address could be looked up in the FIB. If there were no route to the source address, the packet could be deemed a bogon and silently discarded.  <ref name=ingress-MH>{{citation
  | url = http://www.ietf.org/rfc/rfc3704.txt
  | url = http://www.ietf.org/rfc/rfc3704.txt
  | title = Ingress Filtering for Multihomed Networks
  | title = Ingress Filtering for Multihomed Networks
Line 14: Line 14:
  | date = March 2004 | id = RFC 3704, IETF BCP (Best Current Practice) 84}}</ref> The FIB-based method is called ''reverse unicast path filtering (rUPF)''.
  | date = March 2004 | id = RFC 3704, IETF BCP (Best Current Practice) 84}}</ref> The FIB-based method is called ''reverse unicast path filtering (rUPF)''.
==unicast reverse path forwarding==
==unicast reverse path forwarding==
There are, however, legitimate network engineering techniques in which the ''router'' as a whole may have a reverse route, but the ''interface'' does not. One reason for not having a return path active on an ingress interface is that the nature of the application is such that it is known much more traffic will be returned to the source address, so an interface connected to a faster [[transmission medium]] might be used for the return path. A distinction, therefore, was made between ''strict rUPF'', where the return path must be on the FIB in the ingress card, and ''loose rUPF'', in which the packet is legitimate if some FIB contains the reverse route.   
There are, however, legitimate network engineering techniques in which the ''router'' as a whole may have a reverse route, but the ''interface'' does not. One reason for not having a return path active on an ingress interface is that the nature of the application is such that it is known much more traffic will be returned to the source address, so an interface connected to a faster transmission medium might be used for the return path. A distinction, therefore, was made between ''strict rUPF'', where the return path must be on the FIB in the ingress card, and ''loose rUPF'', in which the packet is legitimate if some FIB contains the reverse route.   


Loose uRPF can be quite complex to implement, if, for example, only traffic from certain source-destination address pairs are intended to take the asymmetrical reverse path. There also are various fault-tolerance schemes in which after the failure of a medium or interface that has the reverse route, another interface needs to be selected.  
Loose uRPF can be quite complex to implement, if, for example, only traffic from certain source-destination address pairs are intended to take the asymmetrical reverse path. There also are various fault-tolerance schemes in which after the failure of a medium or interface that has the reverse route, another interface needs to be selected.  
Line 20: Line 20:
Yet another variant is useful on routers that can forward faster to an internal null destination than they can drop packets. This may seem counterintuitive, but there are good reasons, in the detailed design of routers, when this may be the case.
Yet another variant is useful on routers that can forward faster to an internal null destination than they can drop packets. This may seem counterintuitive, but there are good reasons, in the detailed design of routers, when this may be the case.


Blackhole routing has applications besides rejecting bogons. If the network is under [[denial of service]] attack, and, for example, some hosted server address is the target, that server is effectively useless. It would be overwhelmed by the attack traffic, so unless the attack can be characterized and stopped, especially difficult in [[distributed denial of service]], network security monitoring software or personnel can create a ''blackhole route'' to the ''destination'', and use various mechanisms to distribute that route to the FIBs. Blackhole routing is a very fast way to throw away undesired packets.  
Blackhole routing has applications besides rejecting bogons. If the network is under denial of service attack, and, for example, some hosted server address is the target, that server is effectively useless. It would be overwhelmed by the attack traffic, so unless the attack can be characterized and stopped, especially difficult in distributed denial of service, network security monitoring software or personnel can create a ''blackhole route'' to the ''destination'', and use various mechanisms to distribute that route to the FIBs. Blackhole routing is a very fast way to throw away undesired packets.  


Alternatively, some or all of the attack traffic may be given a [[sinkhole (computers)|sinkhole route]], which still diverts it away from the target but sends it to a security analysis center. <ref name=NANOG28-sink-tut>{{citation
Alternatively, some or all of the attack traffic may be given a sinkhole (computers)|sinkhole route, which still diverts it away from the target but sends it to a security analysis center. <ref name=NANOG28-sink-tut>{{citation
  | title = Tutorial: ISP Security: Deploying and Using Sinkholes
  | title = Tutorial: ISP Security: Deploying and Using Sinkholes
  |author = Barry Raveendren Greene & Danny McPherson
  |author = Barry Raveendren Greene & Danny McPherson
  | publisher = [[North American Network Operators Group]]
  | publisher = North American Network Operators Group
  | date = NANOG 28, June 2003  
  | date = NANOG 28, June 2003  
  | url = http://nanog.org/meetings/nanog2/abstracts.php?pt=NzIzJm5hbm9nMjg=&nm=nanog28}}</ref> Hardware and software at the sinkhole, or multiple sinkholes when the traffic demands it, may be able to characterize the attack and give better methods of stopping it. Routes to sinkholes often use [[anycasting]] as a form of balancing the load across multiple sinkholes.  
  | url = http://nanog.org/meetings/nanog2/abstracts.php?pt=NzIzJm5hbm9nMjg=&nm=nanog28}}</ref> Hardware and software at the sinkhole, or multiple sinkholes when the traffic demands it, may be able to characterize the attack and give better methods of stopping it. Routes to sinkholes often use anycasting as a form of balancing the load across multiple sinkholes.  
==References==
==References==
{{reflist|2}}
{{reflist|2}}

Latest revision as of 07:30, 18 March 2024

This article may be deleted soon.
To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions.

For the monthly nomination lists, see
Category:Articles for deletion.


This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Ingress filtering are a class of standard network security measures used in Internet Protocol networks. They are all based on the assumption that if a packet attempts to enter the network, but the network has no reverse route: a means to send a reply back to the source address in the packet header, the packet must be forged (i.e., an example of IP spoofing) or in error. Packets with invalid addresses are sometimes called bogons.

When the idea was first standardized, it was generally implemented on a per-interface basis.[1] In early routers, this was done with explicit access control lists (ACL) on the interface, which was a benefit if the interface had some autonomous hardware that could filter. Filtering was often computationally expensive if done in a general-purpose interface processor, and improvements were sought. One approach was the use of ternary content addressable memory, which could do hardware-based ACLs, but TCAM was too expensive for large routing tables. Per-interface ACLs could also be labor-intensive to keep current.

A performance-boosting technique for routing was distributing the forwarding information base (FIB) to the forwarding cards. The technique of unicast reverse path filtering came into play when it was realized that the source, as well as the destination, address could be looked up in the FIB. If there were no route to the source address, the packet could be deemed a bogon and silently discarded. [2] The FIB-based method is called reverse unicast path filtering (rUPF).

unicast reverse path forwarding

There are, however, legitimate network engineering techniques in which the router as a whole may have a reverse route, but the interface does not. One reason for not having a return path active on an ingress interface is that the nature of the application is such that it is known much more traffic will be returned to the source address, so an interface connected to a faster transmission medium might be used for the return path. A distinction, therefore, was made between strict rUPF, where the return path must be on the FIB in the ingress card, and loose rUPF, in which the packet is legitimate if some FIB contains the reverse route.

Loose uRPF can be quite complex to implement, if, for example, only traffic from certain source-destination address pairs are intended to take the asymmetrical reverse path. There also are various fault-tolerance schemes in which after the failure of a medium or interface that has the reverse route, another interface needs to be selected.

Blackhole routing

Yet another variant is useful on routers that can forward faster to an internal null destination than they can drop packets. This may seem counterintuitive, but there are good reasons, in the detailed design of routers, when this may be the case.

Blackhole routing has applications besides rejecting bogons. If the network is under denial of service attack, and, for example, some hosted server address is the target, that server is effectively useless. It would be overwhelmed by the attack traffic, so unless the attack can be characterized and stopped, especially difficult in distributed denial of service, network security monitoring software or personnel can create a blackhole route to the destination, and use various mechanisms to distribute that route to the FIBs. Blackhole routing is a very fast way to throw away undesired packets.

Alternatively, some or all of the attack traffic may be given a sinkhole (computers)|sinkhole route, which still diverts it away from the target but sends it to a security analysis center. [3] Hardware and software at the sinkhole, or multiple sinkholes when the traffic demands it, may be able to characterize the attack and give better methods of stopping it. Routes to sinkholes often use anycasting as a form of balancing the load across multiple sinkholes.

References

  1. P. Ferguson & D. Senie (May 2000), Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC 2827, IETF BCP (Best Current Practice) 34
  2. F. Baker & P. Savola (March 2004), Ingress Filtering for Multihomed Networks, RFC 3704, IETF BCP (Best Current Practice) 84
  3. Barry Raveendren Greene & Danny McPherson (NANOG 28, June 2003), Tutorial: ISP Security: Deploying and Using Sinkholes, North American Network Operators Group