IP Reassembly: If the
fragments are successfully reassembled then DPI analysis is done
on the reassembled packet.
Without TCP Proxy, fragmented
packets will go out on the other side. With TCP proxy, normal (non-fragmented)
IP packets will go out on the other side (which will not be similar
to the incoming fragmented packets).
With or without TCP
Proxy, if fragment reassembly was not successful, then all the fragments
will be dropped except under the case where received fragments were
sufficient enough to identify the 5-tuple TCP flow and the flow
had TCP Proxy disabled on it.
TCP OOO Processing:
Without TCP Proxy if it is configured to send the TCP OOO packets
out (as they come), without TCP proxy such packets were sent out.
With TCP Proxy, OOO packets coming from one side will go in-order
on the other side. For proxied flows TCP OOO expiry timer will not
be started and hence there will be no specific handling based on
any such timeouts. Also, TCP OOO packets will not be sent to other
side unless the packets are re-ordered.
In releases prior to
14.0, when TCP Out-of-Order (OOO) packets were received and when there
was any error in buffering those packets at ECS due to memory allocation
failure, these packets were marked as TCP error packets and the
rule matching was done accordingly. These packets were also marked
as TCP error packets when the reordering packet was not received before
the OOO timeout.
In 14.0 and later releases,
in the above mentioned scenarios, the packets are not considered as
TCP error and the TCP error flag is not set for OOO packets. So,
these packets will not match TCP error related ruledef but match
other appropriate ruledefs.
If the customer has
configured TCP error related rules, then OOO timeout failure packets and
memory allocation failure packets will not match these rules now.
It will match normal TCP rules.
TCP Checksum Validation:
Without TCP Proxy TCP Checksum validation is optional (configurable
through "transport-layer-checksum verify-during-packet-inspection
tcp" CLI command). With TCP Proxy TCP checksum is automatically
done irrespective of whether the CLI command is configured or not.
If the checksum validation fails, the packet is not processed further
and so it does not go for application layer analysis.
TCP Reset Packet Validation:
Without TCP Proxy TCP reset packet is not validated for Seq and
ACK number present in the segment and the flow is cleared immediately.
With TCP Proxy TCP Reset
packet validation is done. The flow will be cleared only if a valid
TCP Reset segment is arrived. This validation is not configurable.
TCP Timestamp (PAWS)
Validation: Without TCP Proxy timestamp verification is not performed
and even if there is any timestamp error, the packet is processed
normally and goes for further analysis and rule-matching.
With TCP Proxy if the
connection is in established state, timestamp validation for packets
is performed. If TCP timestamp is less than the previous timestamp,
the packet is marked TCP error packet and is dropped. The packet
is not analyzed further and not forwarded ahead. This packet should
match TCP error rule (if configured). This validation is not configurable.
TCP Error Packets: Without
TCP Proxy ECS being a passive entity, most of the errors (unless
configured otherwise) were ignored while parsing packets at TCP
analyzer and were allowed to pass through. With TCP Proxy TCP error
packets are dropped by Gi and Gn side TCP IP stack. However, since
the ECS processing is already done before giving the packet to the
stack, these packets are charged but not sent out by proxy on the
Policy Server Interaction
(Gx): With TCP Proxy, application of policy function occurs on two
separate TCP connections (non-proxy processed packets on Gn/Gi).
Only external packets (the ones received from Radio and Internet)
will be subject to policy enforcement at the box. This does not
have any functional impact.
Credit Control Interaction
(Gy): With TCP Proxy, application of Credit Control function occur
on two separate TCP connections (non-proxy processed packets on
Gn/Gi). Only external packets (the ones received from Radio
and Internet) will be subject to credit control at the box. This
does not have any functional impact.
DPI Analyzer: With TCP
Proxy, application of DPI analyzer occurs on two separate TCP connections
(non-proxy processed packets on Gn/Gi). Only external packets
(the ones received from Radio and Internet) will be subject to DPI
analyzer at the chassis. Any passive analyzer in the path would
be buffering packet using the existing ECS infrastructure.
With TCP Proxy, only incoming traffic is dropped based on bandwidth
calculation on ingress side packets. The BW calculation and dropping
of packet is be done before sending packet to ingress TCP IP Stack.
ToS and DSCP marking will be on flow level. The ToS and DSCP marking
can be done only once for whole flow and once the ToS is marked
for any packet either due to "ip tos" CLI command configured in
the charging action or due to ITC/BW control, it will remain
same for the whole flow.
Next Hop and VLAN-ID:
Without TCP Proxy nexthop feature is supported per packet, that
is nexthop address can be changed for each and every packet of the
flow depending on the configuration in the charging action. With
TCP Proxy only flow-level next-hop will be supported. So, once the
nexthop address is changed for any packet of the flow, it will remain
same for the complete flow. The same is the case for VLAN-ID.
TCP state based rules:
Without TCP Proxy there is only one TCP connection for a flow and
the TCP state based rules match to state of subscriber stack. With
TCP Proxy there are two separate connections when TCP proxy is enabled.
TCP state ("tcp state" and "tcp previous-state") based rules will
match to MS state on egress side. Two new rules (tcp proxy-state
and tcp proxy-prev-state) have been added to support the existing
cases (of TCP state based rules). "tcp proxy-state" and "tcp proxy-prev-state"
are the state of the embedded proxy server, that is the proxy ingress-side.
These rules will not be applicable if proxy is not enabled.
Using both "tcp state"
and "tcp proxy-state" in the same ruledef is allowed. If proxy is enabled,
they would map to Gi-side and Gn-side, respectively. If TCP Proxy
is not enabled, the "tcp proxy-state" and "tcp proxy-prev-state"
rules will not be matched because proxy-state will not be applicable.
Since TCP state and
previous-state rules are now matched based on state on Gi side connection,
ECS will not be able to support all the existing use-cases with
the existing configuration. New ruledefs based on the new rules
(tcp proxy-state and tcp proxy-prev-state) need to be configured
to support existing use cases. Note that even by configuring using
new rules; all use-cases may not be supported. For example, detection
of transition from TIME-WAIT to CLOSED state is not possible now.
TCP MSS: TCP IP Stack
always inserts MSS Field in the header. This causes difference in
MSS insertion behavior with and without TCP Proxy.
TCP CFG MSS limit-if-present:
If incoming SYN has MSS option present, in outgoing SYN and SYN-ACK
MSS value is limited to configured MSS value (CFG MSS)
TCP CFG MSS add-if-not-present:
If incoming SYN does not have MSS option present, in outgoing SYN
and SYN-ACK MSS configured MSS value is inserted (CFG MSS)
TCP CFG MSS limit-if-present
add-if-not-present: If incoming SYN has MSS option present, in outgoing
SYN and SYN-ACK MSS value is limited to configured MSS value (CFG
MSS), OR if incoming SYN does not have MSS option present, in outgoing SYN
and SYN-ACK MSS configured MSS value is inserted (CFG MSS).
Flow Discard: Flow discard
occurring on ingress/egress path of TCP Proxy would be relying
on TCP-based retransmissions. Any discard by payload domain applications
would result in data integrity issues as this might be charged already
and it may not be possible to exclude packet. So it is recommended
that applications in payload domain (like dynamic CF, CAE readdressing)
should not be configured to drop packets. For example, dynamic content
filtering should not be configured with drop action. If drop is
absolutely necessary, it is better to use terminate action.
Marking: Without TCP Proxy DSCP/IP TOS marking is supported
per packet, that is IP TOS can be changed for each and every packet
of the flow separately based on the configuration. With TCP Proxy
flow-level DSCP/IP TOS marking is supported. So, once the IP
TOS value is changed for any packet of the flow, it will remain
same for the complete flow.
Redundancy Support (Session
Recovery and ICSR): Without TCP Proxy after recovery, non-syn flows
are not reset. With TCP Proxy session recovery checkpointing is bypassing
any proxied flows (currently on NAT flows support recovery of flows).
If any flow is proxied for a subscriber, after recovery (session
recovery or ICSR), if any non-syn packet is received for that subscriber,
ECS sends a RESET to the sender. So, all the old flows will be RESET
Charging Function: Application
of charging function would occur on two separate TCP connections
(non proxy processed packets on Gn/Gi). Only external packets
(the ones received from Radio and Internet) shall be subject to
Policy enforcement at the box. Offline charging records generated
at charging function would pertain to different connections hence.