3.1.1.1. Network Interface

A network interface (a logical IP routing interface) can be configured on a network-facing physical or logical port, and is used for connectivity purposes. Each network interface can have only one IP address. The connections are point-to-point; for example, a network port on an Ethernet interface cannot be connected to a LAN but must be connected to a network interface on another router.

Secondary IP address assignment, which is used to connect the same interface to more than one subnet, is not supported.

Network ports are used to transport Ethernet, ATM, and TDM services by means of pseudowires.

IP address assignment is not supported on access (customer-facing) ports except for services such as IES or VPRN.

On the 2-port 10GigE (Ethernet) Adapter card/module, the network interface can only be created on the v-port (not the ring ports).

The 7705 SAR can be used as an LER (label edge router) or LSR (label switch router).

OSPF, RIP, IS-IS, and BGP are supported as dynamic routing protocols, and static routes to next-hop addresses are also supported.

Some network Ethernet ports support network egress per-VLAN shapers on a per-network-interface basis. Refer to the “Per-VLAN Network Egress Shapers” section in the 7705 SAR Quality of Service Guide for details.

3.1.1.1.2. Dynamic ARP and Static MAC entry

The MAC address of the far end can be learned dynamically or be statically configured.

ARP is the common way to dynamically resolve the MAC address of next-hop IP hosts and is the primary way to resolve IP-to-MAC associations. ARP packets are sent as soon as a MAC address resolution is needed for a given IP address.

Static configuration of MAC addresses for next-hop routers is also supported. Static configuration provides a higher level of security against IP hijacking attacks.

Note: Because timeout is built into dynamic ARP, the MAC address of the remote peer needs to be renewed periodically. The flow of IP traffic resets the timers back to their maximum values. In the case of LDP ECMP, one link could be used for transporting user MPLS (pseudowire) traffic while the LDP session could be transported on another equal cost link. In ECMP for LDP and static LSP cases, it is important to ensure that the remote MAC address is learned and does not expire. Some of the equal cost links might only be transporting MPLS traffic, and in the absence of IP traffic, learned MAC addresses will eventually expire. Configuring static ARP entries or running continuous IP traffic ensures that the remote MAC address is always known. Running BFD for fast detection of Layer 2 faults or running any OAM tools with SAA ensures that the learned MAC addresses do not expire. For information on LDPs and static LSPs, refer to the 7705 SAR MPLS Guide.

3.1.1.1.3. Configurable ARP Retry Timer

A timer is available to configure a shorter retry interval when an ARP request fails. An ARP request may fail for a number of reasons, such as network connectivity issues. By default, the 7705 SAR waits 5000 ms before retrying an ARP request. The configurable retry timer makes it possible to shorten the retry interval to between 100 and 30 000 ms.

Note: The ARP retry default value of 5000 ms is intended to protect CPU cycles on the 7705 SAR, especially when it has a large number of interfaces. Configuring the ARP retry timer to a value shorter than the default should be done only on mission-critical links, such as uplinks or aggregate spoke SDPs transporting mobile traffic; otherwise, the retry interval should be left at the default value.

The configurable ARP retry timer is supported on VPRN and IES service interfaces, as well on the router interface.

3.1.1.1.4. Proxy ARP

Proxy ARP is a technique by which a router on one network responds to ARP requests intended for another node that is physically located on another network. The router effectively pretends to be the destination node by sending an ARP response to the originating node that associates the router’s MAC address with the destination node’s IP address (acts as a proxy for the destination node). The router then takes responsibility for routing traffic to the real destination.

Proxy ARP simplifies networking schemes because it enables nodes on a subnet to reach remote subnets without the need to configure routing or a default gateway.

The 7705 SAR supports both proxy ARP and local proxy ARP. Local proxy ARP is similar to proxy ARP except that it is used within a subnet; the router responds to all requests for IP addresses within the subnet and forwards all traffic between the hosts in the subnet. Local proxy ARP is used on subnets where hosts are prevented from communicating directly.

Typically, routers support proxy ARP only for directly attached networks. The 7705 SAR supports proxy ARP for all known networks in the routing instance where the virtual interface proxy ARP is configured.

Proxy ARP is supported on:

1. the global routing table
2. IES service interfaces
3. VPRN service interfaces

A typical application for proxy ARP is when hosts in a private subnet need to communicate to host/servers via the public Internet; for example, when using network address translation (NAT). Source NAT can be used for creating connections from inside (private network) to outside (public network). If an arriving IP packet on the 7705 SAR matches the NAT policy rules, an internal mapping is created between the private source IP address/source port and a public source IP address/source port. The public IP address and port are configured in the NAT pool policy.

Proxy ARP is therefore required for Source NAT when the NAT pool uses a range of IP public addresses. The NAT pool public IP address can either be in a different subnet than the public interface or in the same subnet as the public interface. Proxy ARP can be used to respond to ARP requests for an IP address in these NAT pools.

Note: Only remote proxy ARP is applicable for NAT.

In order to support NAT and other edge-like environments, proxy ARP supports policies that allow the provider to:

1. configure prefix lists that determine for which target networks proxy ARP will be attempted
2. configure prefix lists that determine for which source hosts proxy ARP will be attempted

As an example, when a source NAT pool is configured with a dynamic IP pool with the address range 1.1.1.2 to 1.1.1.254 on the public interface 1.1.1.1, proxy ARP can be used to resolve the ARP request of the NAT pool hosts with the local interface (1.1.1.1) MAC address (remote proxy ARP).

As another example, if a NAT pool of addresses in the range 2.2.2.1 to 2.2.2.100 is configured on the public Layer 3 interface 128.251.10.59, then by enabling remote proxy ARP, the 7705 SAR will respond to ARP requests from hosts 2.2.2.1 to 2.2.2.100. In addition, a route policy with a prefix list can be created and used as a proxy ARP policy for finer granularity of the IP range for which proxy ARP is being used.

For detailed information on NAT, see NAT Security.

3.1.1.2. System Interface

The system interface is associated with the node, not a specific interface. It is used during the configuration of the following entities:

The system interface is also referred to as the loopback interface. It is used as the router identifier if a router ID has not been explicitly configured. Additional loopback interfaces can be configured; however, the system interface is a special loopback interface.

The system interface is used to preserve connectivity (when alternate routes exist) and to decouple physical connectivity and reachability. If an interface carrying peering traffic fails, and there are alternative links to the same peer system interface, peering could be either unaffected or re-established over the alternate links. The system interface IP address is also used for MPLS and pseudowire/VLL signaling (via targeted LDP).

3.1.1.3. Unnumbered Interfaces

Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface.

The benefits of using unnumbered interfaces are:

Unnumbered interfaces are supported on:

Only IPv4 addresses are supported.

Unnumbered interfaces are supported for the IS-IS and OSPF routing protocols and for MPLS (RSVP-TE and LDP). Refer to the 7705 SAR Routing Protocols Guide, “Unnumbered Interfaces” in the OSPF and IS-IS sections, for more information on IS-IS and OSPF unnumbered interface support. Refer to the 7705 SAR MPLS Guide, “RSVP-TE Support for Unnumbered Interfaces” and “LDP Support for Unnumbered Interfaces”, for more information on MPLS unnumbered support.

This feature is supported via both dynamic and static ARP.

The following ports on the 7705 SAR adapter cards, modules, and fixed platforms support IP unnumbered interfaces:

Note: Unnumbered interfaces do not support PIM routing or IGMP listener capabilities.

3.1.1.4. Creating an IP Address Range

An IP address range can be reserved for IES or VPRN services by using the config>router>service-prefix command. When a service interface is configured, the IP address must be in the range specified in the service-prefix command. If the service-prefix command is not configured, then no limitation exists.

Addresses in the range of a defined service-prefix can be allocated to a network port unless the exclusive parameter is specified. Then, the address range is exclusively reserved for services.

When defining a range that is a superset of a previously defined service prefix, the new superset definition will replace the original configuration. For example, if a service prefix exists for 10.10.10.0/24, and a new service prefix is configured as 10.10.0.0/16, then the old address (10.10.10.0/24) will be replaced with the new address (10.10.0.0/16).

When defining a range that is a subset of a previously defined service prefix, the subset will replace the existing superset providing that the addresses used by services are not affected. For example, if a service prefix exists for 10.10.0.0/16, and a new service prefix is configured as 10.10.10.0/24, then the 10.10.0.0/16 entry will be unreserved as long as there no services configured that are using the 10.10.x.x addresses other than 10.10.10.x.

3.1.3.1. IPv6 Address Format

IPv6 uses a 128-bit address, as opposed to the IPv4 32-bit address. Unlike IPv4 addresses, which use the dotted-decimal format, with each octet assigned a decimal value from 0 to 255, IPv6 addresses use the colon-hexadecimal format X:X:X:X:X:X:X:X, where each X is a 16-bit section of the 128-bit address. In its full notation, an IPv6 address appears as shown in the following example:

2001:0db8:0a0b:12f0:0000:0000:0000:0001

Note: On the 7705 SAR, any function that displays an IPv6 address or prefix reflects the rules specified in RFC 5952, A Recommendation for IPv6 Address Text Representation. Specifically, hexadecimal letters in IPv6 addresses are represented in lowercase, and the correct compression of all leading zeros is displayed.

As per RFC 5952, the above IPv6 address appears as:

2001:db8:a0b:12f0::1

Leading zeros must be omitted from each block in the address. A series of zeros can be replaced with a double colon. The double colon can only be used once in an address.

The IPv6 prefix is the part of the IPv6 address that represents the network identifier. The network identifier appears at the beginning of the IP address and is made up of the network address and subnet address. The IPv6 prefix length, which begins with a forward slash (/), specifies the number of bits in the network identifier; this is similar to the subnet mask in IPv4 addresses. For example, the address 1080:6809:8086:6502::1/64 means that the first 64 bits of the address represent the network identifier; the remaining 64 bits represent the node identifier.

The following adapter cards support the full IPv6 subnet range for IPv6 static routes and interface IP addresses:

For these cards, the supported route range for statically provisioned or dynamically learned routes is from /1 to /128. Supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces.

For all other cards, modules, and ports (including the v-port on the 2-port 10GigE (Ethernet) module), the supported range for statically provisioned or dynamically learned routes is from /1 to /64 or is /128 (indicating a host route). Supported interface IP address prefixes are from /4 to /64, and /128 on system or loopback interfaces.

3.1.3.2. IPv6 Headers

The IPv6 header format is shown in Figure 1. Table 2 describes the fields.

Figure 1:  IPv6 Header Format 

Note: Type 0 IPv6 routing headers have been deprecated on the 7705 SAR (per RFC 5095).

3.1.3.3. Neighbor Discovery

IPv6 provides autoconfiguration of addresses, where equipment connecting to an IPv6 network can autoconfigure a usable address. There are two types of address autoconfiguration: stateless and stateful. Stateless autoconfiguration requires no manual configuration of hosts, minimal configuration of routers, and no servers. The host generates its own addresses using locally available information and information advertised by routers, such as the 7705 SAR. Stateless autoconfiguration is a feature of the neighbor discovery protocol.

Stateful autoconfiguration involves hosts obtaining interface addresses and/or configuration information from a server. For more information on stateful configuration, see DHCP Relay and DHCPv6 Relay.

Stateless autoconfiguration uses two neighbor discovery messages: router solicitation and router advertisement. The host sends router solicitation messages to find routers, and the routers send router advertisement messages to indicate their presence. The host sends the router solicitation message to all routers, requesting the IPv6 prefix as well as the IPv6 address of the routers. Each router responds with a router advertisement message indicating their IPv6 prefix and IPv6 address.

Neighbor discovery performs Layer 2 neighbor address resolution similar to ARP in IPv4. In addition, the neighbor discovery protocol performs a neighbor reachability function, where a “stale” neighbor entry is probed for reachability using a unicast neighbor solicitation message. This function ensures that link-layer address changes will be discovered reliably in addition to confirming the presence of the IPv6 neighbor.

Neighbor discovery is implemented within ICMPv6.

3.1.6.1. DHCP Relay and DHCPv6 Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services and DHCPv6 Relay agent services for DHCP clients. DHCP is used for IPv4 network addresses and DHCPv6 is used for IPv6 network addresses. Both DHCP and DHCPv6 are known as stateful protocols because they use dedicated servers to maintain parameter information.

In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The server maintains a database that keeps track of which addresses have been assigned to which hosts.

The 7705 SAR supports DHCP Relay on the base router, and on access IP interfaces associated with IES and VPRN. Each DHCP instance supports up to 8 DHCP servers.

The 7705 SAR supports DHCPv6 Relay on access IP interfaces associated with IES and VPRN. Each DHCPv6 instance supports up to 8 DHCPv6 servers. For more information on DHCPv6 Relay, refer to the 7705 SAR Services Guide, “DHCPv6 Relay”.

3.1.6.2. Local DHCP and DHCPv6 Server

The 7705 SAR supports local DHCP server functionality on the base router and on access IP interfaces associated with VPRN, by dynamically assigning IPv4 or IPv6 addresses to access devices that request them. This standards-based, full DHCP server implementation allows a service provider the option to decentralize IP address management into the network. The 7705 SAR can support public and private addressing in the same router, including overlapped private addressing in the form of VPRNs in the same router.

The 7705 SAR acts as a DHCP server or a DHCPv6 server.

An administrator creates pools of addresses that are available for assigned hosts. Locally attached hosts can obtain an address directly from the server. Routed hosts receive addresses through a relay point in the customer’s network.

When a DHCP server receives a DHCP message from a DHCP Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 82 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-gi-address command, the server uses the gateway IP address (GIADDR) supplied by the Relay agent to find a matching subnet. If a subnet is found, an address from the subnet is offered to the client. If no pool or subnet is found, then no IP address is offered to the client.

When a DHCPv6 server receives a DHCP message from a DHCPv6 Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 17 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-link-address command, the server uses the address supplied by the Relay agent to find a matching subnet prefix. If a prefix is found, an address from the subnet is offered to the client. If no pool or prefix is found, then no IP address is offered to the client.

IPv4 and IPv6 address assignments are temporary and expire when the configured lease time is up. The server can reassign addresses after the lease expires.

If both the no use-pool-from-client command and the no use-gi-address command or no use-link-address command are specified, the server does not act.

3.1.8.1. Enabling ECMP

The ECMP decision is performed at the ingress point on the node; therefore, ECMP must always be enabled on the ingress interface.

To enable LDP and GRT IP ECMP, the config>router>ecmp command is used.

To enable IP ECMP on a per-IP, next-hop basis (far-end PE) under the IP-VPRN context, the config>service>vprn>ecmp command is used.

For LDP ECMP, the lsr-load-balancing command under the system context enables optional LSR load balancing for the node. The lsr-load-balancing command under the router interface context overrides the system configuration for the specified interface.

For IP ECMP, the l4-load-balancing command under the system context enables optional Layer 4 load balancing for the node. The l4-load-balancing command under the router interface context, IES service interface context, or VPRN service interface context overrides the system configuration for the specified interface.

For IP ECMP, the teid-load-balancing command can be configured under the router interface context, IES interface context, and VPRN interface context.

For both LDP and IP ECMP, the system-ip-load-balancing command can be configured under the system context.

For information on the load-balancing commands, see Router Interface Commands, the 7705 SAR Basic System Configuration Guide, “System Information and General Commands”, and the 7705 SAR Services Guide, “VLL Services Command Reference”, “VPLS Command Reference”, “IES Command Reference”, and “VPRN Services Command Reference”.

3.1.11.1. ECMP vs FRR

If ECMP is enabled, which provides multiple primary next hops for a prefix, IP FRR is not used. That is, the LFA next hops are not populated in the RTM and the ECMP paths are used instead.

3.1.11.2. IGP Shortcuts (RSVP-TE Tunnels)

IGP shortcuts are an MPLS functionality where LSPs are treated like physical links within IGPs; that is, LSPs can be used for next-hop reachability. If an RSVP-TE LSP is used as a shortcut by OSPF or IS-IS, it is included in the SPF calculation as a point-to-point link for both primary and LFA next hops. It can also be advertised to neighbors so that the neighboring nodes can also use the links to reach a destination via the advertised next hop.

IGP shortcuts can be used to simplify remote LFA support and simplify the number of LSPs required in a ring topology.

When both IGP shortcuts and LFA are enabled under OSPF or IS-IS, and IP FRR is also enabled, the following applies:

3.1.11.3. IP FRR Configuration

To configure IP FRR, LFA calculation by the SPF algorithm must first be enabled under the OSPF, OSPFv3, or IS-IS protocol level with the command:

config>router>ospf>loopfree-alternate

or

config>router>ospf3>loopfree-alternate

or

config>router>isis>loopfree-alternate

LFA can also be enabled on an OSPF or OSPFv3 instance within a VPRN service with the command:

config>service>vprn>ospf>loopfree-alternate

or

config>service>vprn>ospf3>loopfree-alternate

Next, IP FRR must be enabled to use the LFA next hop with the command config>router>ip-fast-reroute.

If IGP shortcuts are used, they must be enabled under the OSPF or IS-IS routing protocol. As well, they must be enabled under the MPLS LSP context, using the command config>router>mpls>lsp>igp-shortcut.

For information on LFA and IGP shortcut support for OSPF and IS-IS, refer to the 7705 SAR Routing Protocols Guide, “LDP and IP Fast Reroute for OSPF Prefixes” and “LDP and IP Fast Reroute for IS-IS Prefixes”.

The 7705 SAR supports both IP FRR and LDP FRR; for information on LDP FRR, refer to the 7705 SAR MPLS Guide, “LDP Fast Reroute (FRR)”.

3.2.3.1. Directionally Aware Security Behavior

A security session can be directionally aware. For example, a firewall security policy entry can be configured to allow packets with source IP address X and source port Y that are traveling from the private network to the public network to traverse the firewall. This means that any traffic arriving from the outside network on IP address X and port Y is denied entry to the inside network. However, a host in the private network can create a session from inside to outside for IP address X and port Y. Once this inside-to-outside session is created, traffic with IP address X and port Y traveling in the reverse direction (from outside to inside) is now allowed.

Similarly with NAT, a source NAT policy entry can be created to apply NAT on all arriving packets with source IP address X and source port Y to an outside source IP address A and source port B. When the first packet with IP address X and port Y arrives, NAT creates an inside-to-outside session and punches a hole through the firewall for that specific IP address and port number, thus allowing all packets to be transmitted from the inside network to the outside network.

3.2.3.2. TCP MSS Configuration and Adjustment

Typically, the MTU in a private LAN is larger than the MTU of a public network; the MTU of a private LAN is usually 1500 bytes whereas the MTU of a public network is usually less than 1500 bytes. In addition, packets destined to the public network may have an additional header, such as a transport tunnel, appended to the original packet. These two factors can cause the TCP/IP packet to become fragmented when entering the public network. Fragmentation is not desirable for TCP applications where the server needs a lot of processing power to reassemble the fragmented packets.

To avoid fragmentation, the maximum segment size (MSS) of application data in a TCP connection can be adjusted. Applications use the MSS to calculate the maximum number of data bytes (not including the header) that can be transmitted in a single packet. By lowering the MSS value, an outgoing packet's MTU can be made smaller than the public network MTU, ensuring that the packets entering the public network will not be fragmented.

The 7705 SAR supports TCP MSS adjustment. When acting as a CE router, the 7705 SAR can insert or modify the MSS value in the header of a TCP SYN or SYN-ACK packet. The sending and receiving CE routers set their MSS based on the outgoing interface MTU. The routers exchange TCP SYN or SYN-ACK packets during TCP session negotiation, engaging in a three-way handshake to compare and then select the lowest MSS value.

On the 7705 SAR, MSS configuration and adjustment is supported on the following cards and platforms:

When the tcp-mss command is configured, the 7705 SAR can adjust the MSS field in the TCP SYN packet or SYN-ACK packet, or insert the MSS field in the SYN packet if the field is not present.

The command is supported in the general router, VPRN service, and IES CLI contexts; Table 7 lists the supported interface types for each context. The tcp-mss command is not supported for TCP packets arriving on or leaving from MP-BGP tunnels in a VPRN.

When the tcp-mss command is configured on an interface, TCP packets with a SYN or SYN-ACK flag will have the MSS value is adjusted or inserted, as follows.

The command can be configured on an ingress interface, an egress interface, or both. When configured on both interfaces, the smallest MSS value is used.

If the interface configured with tcp-mss is part of a firewall zone, the MSS packet extraction occurs as part of the firewall processing extraction. If the security session does not have a 5-tuple signature, the TCP SYN or SYN-ACK packets are extracted to the CSM via control queues. If the security session has a 5-tuple signature or if there is no security session configured for the interface, the TCP SYN or SYN-ACK packets are extracted to the CSM via datapath queues. The SYN and SYN-ACK packets that are extracted to the CSM are counted as control or datapath queue statistics.

Fragmented packets are not monitored for TCP MSS adjustment.

TCP MSS configuration and adjustment is supported for both IPv4 and IPv6 interfaces. Because the tcp-mss value is configured separately for each interface, it is possible to configure and enforce a different MSS value for IPv4 and IPv6.

3.2.7.1. Profile Timers

Timers are used to time out a NAT or firewall session and drop it. The 7705 SAR supports configurable timers for different connections. Timers can be idle or strict. Idle timers are activated by the lack of traffic. Strict timers are used for protocol state changes and are not affected by the presence of traffic. The supported timers are described in Table 8.

3.2.7.2. Application Assurance Parameters

The following application assurance parameters can be defined in a security profile:

3.2.7.2.2. ICMP

ICMP replay attacks can be prevented using two mechanisms:

1. limiting the number of ICMP requests and the number of replies to ICMP requests with the request-limit command
2. limiting the number of ICMP type 3 replies to ICMP or IP sessions with the limit-type3 command

For each ICMP request received, the 7705 SAR creates an ICMP session based on the ICMP packet identifier field and source and destination IP addresses. The 7705 SAR restricts the number of packets for that session based on the limit configured in the request-limit command. Any request received beyond the configured limit for that session is blocked. For example, if the ICMP request limit is set to 2, only two ping requests and replies can be transmitted from that ICMP session, while the ICMP session has not timed out. This ensures that an external attacker cannot replay the ICMP reply packet repeatedly to the source of the ICMP request.

Note: It is recommended that the ICMP session timeout be set to equal the latency or delay of the network so that the session times out very quickly, and also that the timer type be set to strict so that the ICMP session times out strictly within the timer value.

The 7705 SAR can limit the number of ICMP type 3 replies for ICMP and IP sessions. For every packet arriving at the firewall, the 7705 SAR creates a 6-tuple session. For regular IP packets, these sessions are uniquely identified using the 6-tuple. For ICMP packets, these sessions are identified using the source IP address, the destination IP address, and the ICMP identifier field. If these packets are discarded after traversing the firewall (for example, because the destination is unreachable or fragmentation is not allowed), an ICMP type 3 packet is generated and sent back to the originator.

The ICMP type 3 packet usually has at least the first 8 octets of the original datagram in the payload of its packet. When the ICMP type 3 packet arrives at the 7705 SAR, the 7705 SAR examines the packet and its payload to find the original packet that triggered the error and tries to find the corresponding session for that packet. If it does, it counts the ICMP type 3 packet against the session. The 7705 SAR allows only 15 ICMP type 3 packets through for each original packet. If the 7705 SAR does not find the session corresponding to the packet that triggered the error, it discards the ICMP type 3 packet.

3.2.7.3. Application Level Gateway

When a 7705 SAR security profile is configured with Application Level Gateway (ALG), the firewall/NAT engine intercepts all upstream traffic destined for TCP port 21 (the FTP control channel), UDP port 69 (the TFTP port), or some other destination port configured to support ALG. All traffic matching the policy is extracted to the CSM for examination.

If the examined traffic is found to be an FTP control channel, the corresponding data channel is programmed to the datapath. When an FTP client sends the port command in the FTP control channel, the firewall/NAT ALG intercepts this command, creates a new mapping in the firewall/NAT table, and opens the data port based on the client port command. Firewalls configured in either passive or active mode must have ALG configured in order to allow the FTP datapath through the firewall. A temporary match rule for the FTP data port is placed on top of the security policy, and TCP timer configuration is inherited from ALG policy control timers. In short, the temporary data session inherits all the control session policy/profile configuration.

Trivial File Transfer Protocol (TFTP) is a simple File Transfer Protocol, which is implemented on top of the UDP/IP protocol and uses port 69. TFTP was designed to be small and easy to implement; therefore, it does not have most of the advanced features offered by more robust file transfer protocols such as FTP. TFTP requests from a client are always destined for UDP port 69 on the server. The server responds by sending an ACK and/or the data on a random port. The 7705 SAR firewall and the ALG are able to detect this random port and create a temporary rule to open the UDP port in the firewall.

The ALG security profile parameter can be configured as auto, ftp, or tftp.

When the parameter is configured as auto (the default), FTP or TFTP ALG is enabled on TCP port 21 (the default port for FTP) or UDP port 69 (the default port for TFTP). The firewall will enforce use of the ALG on the FTP or TFTP session for port translation, if NAT is being used, and for pin-hole operations.

When the parameter is configured as ftp, FTP ALG is enabled on any TCP port being used for FTP. For example, if a security session has been configured for a DNAT mapping where the destination port is not TCP port 21, configuring the ALG security parameter as ftp allows the FTP ALG to be enabled on TCP ports or TCP port ranges so that the session can be treated as FTP and so that the ALG can perform the correct translation and pin-hole functions as required by FTP.

When the parameter is configured as tftp, TFTP ALG is enabled on any UDP port being used for TFTP.

Unlike auto ALG, where only the default FTP and TFTP ports are inspected for a potential ALG session, FTP ALG and TFTP ALG inspect all packets that match their policy’s matching criteria. It is recommended that a specific destination port or port range be matched so that entire port ranges are not left open for potential attackers.

The following example shows a recommended configuration for incoming (DNAT) and outgoing FTP control.

3.2.7.4. Fragmentation Handling

Security functionality on the 7705 SAR can process TCP/UDP packet fragments; however, the fragment containing the header must arrive first. If this condition is not met, the following actions occur.

On the 7705 SAR-8 and 7705 SAR-18, in addition to the condition requiring the fragment containing the header to arrive first, all fragments of a given packet must arrive on the same adapter card for processing.

If packets for an application such as DNS or ICMP are fragmented and the first fragment does not contain the information needed to make a firewall decision, the packet is discarded.

A security profile configured with strict TCP requires that all packets, including packet fragments, are extracted to the CSM for processing. The CSM checks for repeated packet fragments and discards them, and also checks the fragment offset to ensure that all fragments correspond to the correct offset.

3.2.12.1. NAT Zones

With source NAT, a traffic session can only be initiated from a private domain to a public domain. Unless a session is created, packets from the public domain cannot be forwarded to the private domain. All arriving packets from the private domain, which are routed towards a public interface, are checked to determine if they traverse a NAT zone. If so, the packets are examined against the NAT policy rules. If there is a match between the policy and the packet, NAT is applied to the packet. Source NAT changes the source IP address and the source port of the packet, based on the configured NAT pool.

Zones can be segmented as small as a single interface or as large as the maximum number of interfaces supported by the 7705 SAR. For example, in metrocell applications, all the SAPs on the access point used to aggregate the metrocell can be placed in a single zone (zone 2) and the uplink public interface can be placed in another zone (zone 1). All traffic routed between the two zones uses NAT rules based on the NAT policies created for zone 1 and zone 2.

An example of the above zone configuration is shown in Figure 6.

Note: Zone 1 or zone 2 can be omitted if no specific security policy match criteria are required on the zone. If a packet does not travel between any zones, then NAT policies are not applied.

Figure 6:  Zone Configuration in a Mobile Backhaul Network 

In Figure 6, the OAM traffic from the metrocell is not encrypted. The OAM traffic is aggregated into a single VPRN service and IPSec functionality encrypts the OAM traffic. The encrypted traffic enters IES 10 with an IPSec header that has a routable IP destination address (typically to a security gateway) in addition to the encrypted payload. The far-end destination IP address can be reached through IES uplink zone 1 or GRT uplink zone 1. Since the traffic from IES 10 to the uplink zone crosses a zone boundary, the zone policy is applied to the uplink interface, and NAT is applied to the packet. The source IP address in the packet is replaced with the IP address of the uplink interface.

Similarly, in Figure 6, traffic from the metrocell (indicated by the dashed line), is encrypted by the metrocell with a valid IP header that contains a destination IP address (typically to a security gateway). The far-end destination is reachable through IES uplink zone 1 or GRT uplink zone 1. The packet has NAT applied to it because the packet must cross a zone boundary. The source IP address of the metrocell packet that enters IES 2 is replaced with the source IP address of IES uplink zone 1 as it exits the 7705 SAR. In addition, the source UDP/TCP port may also be replaced depending on the NAT policy configured for the zone.

In both of the cases described above, NAT is applied to the IP traffic according to NAT zone policy rules configured for IES uplink zone 1 or GRT uplink zone 1.

When using NAT in conjunction with IPSec, all IPSec tunnels must be configured (enabled) with NAT traversal (NAT-T) functionality. Enabling NAT-T on IPSec causes an insertion of the UDP port below the IPSec IP header. This UDP port can be used by NAT to uniquely identify each IPSec tunnel.

With static destination NAT, when packets from a public domain arrive at a zone, their source and destination IP addresses are evaluated to determine from which interface within the zone the packet will egress.

3.2.12.2. Dynamic Source NAT

Source NAT can be used to create sessions from inside a private network to an outside (public) network. If an arriving IP packet on the 7705 SAR matches the NAT policy rules, an internal mapping is created between the inside (private) source IP address/source port and an outside (public) source IP address/source port. The public IP address and port are configured in the NAT pool policy.

NAT automatically creates a reverse mapping for arriving traffic from the public domain to the private domain for the same connection. This reverse mapping is based on an outside destination IP address and destination port to an inside destination IP address and destination port.

The configurable outside NAT pool for the source IP address and source port can be either a range of addresses and ports or a unique IP address and port.

The 7705 SAR also supports a single public IP address so that all inside source IP addresses can be mapped to a single outside IP address and a range of ports. In this case, the interface name can be assigned to the NAT pool configuration. For ease of configuration, any local interfaces on the 7705 SAR can be assigned to the NAT pool (for example, local Layer 3 interfaces, loopback interfaces).

By assigning the Layer 3 interface name, the NAT pool inherits the IP address of that specific interface. For a DHCP client, the NAT pool IP address can change based on the IP address assigned to the interface by the DHCP server. If the interface IP address changes, all associated NAT sessions are cleared and re-established.

3.2.12.3. Local Traffic and NAT

Source NAT does not support self-generated traffic such as OSPF, BGP, or LDP.

Only packets transiting the 7705 SAR node have NAT applied to them. Any packet arriving on the 7705 SAR with a local IP address will be checked against active NAT sessions on the datapath (6-tuple lookup), and if there is no match, the packet is sent to the CSM for processing as local traffic.

3.2.12.4. Port Forwarding (Static Destination NAT)

Port forwarding consists of mapping an outside destination port to an inside destination IP address and port. For example, a packet arriving from outside on port X and using a UDP protocol (from any IP address) is mapped to an inside destination port and destination IP address.

A typical use of port forwarding is shown in Figure 7. Each inside application is uniquely accessible via an outside port. For example, the surveillance camera behind the 7705 SAR can be reached via the UDP protocol and port 50. Any packet from any IP address arriving on destination port 50 is mapped to an internal destination IP address of 192.168.1.3 and destination port 50.

Caution: Using port forwarding for well-known ports can disrupt in-band local management traffic.

Figure 7:  Static Port Forwarding with NAT 

Static port forwarding can provide accessibility to applications behind a single IP address. Each application can be uniquely accessed via the public IP address and the destination port for that application.

Matching criteria for port forwarding includes local interface IP address, source IP address, and source UDP/TCP port.