A minor caveat: A TCP reset is used to ‘tell’ the endpoints to quit sending packets so in the case of a well behaved endpoint, they will presenting packets to
the firewall and lighten offered load to the network. A false ack is telling the endpoints that everything is OK even though the packets are not making it to the destination.
Having said that, we simply have the false ack and in the description can leave it to the vendor if they manifest it as a false ack or a tcp reset.
From: Everett, Alex D <alex.everett@unc.edu>
Sent: Thursday, August 30, 2018 9:31 AM
To: Trey Darley <trey@newcontext.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Cc: 'openc2-actuator@lists.oasis-open.org' <openc2-actuator@lists.oasis-open.org>
Subject: [Non-DoD Source] Re: [openc2-actuator] SLPF: Should we get rid of the false ACK option?
Joe et al:
Here is the current text I see:
|
complete
|
Optional
|
A command option defined in this specification. Traffic meeting the criteria of the target specifier(s) is dropped and receipt of the packet is sent to the source address, i.e.
a false acknowledgement
|
maybe it could be better stated as
|
complete
|
Optional
|
A command option defined in this specification. Traffic meeting the criteria of the target specifier(s) is dropped and receipt of the packet is sent to the source address and or
destination address, i.e. a false acknowledgement, TCP reset
|
A TippingPoint guide states:
Each “Block” action can optionally specify that a TCP Reset occur, which results in the TOE resetting the TCP connection for the source or destination IP address when the Block
action executes.
I can say that this works for a stateless tippingpoint device. So, no, a device does not have to maintain state to do this. It is more common to maintain state and do this, but it
is not required.
References:
https://www.commoncriteriaportal.org/files/epfiles/st_vid10435-st.pdf
HP TippingPoint Intrusion Prevention Systems Security Target Version 1.0 July 29, 2011 Prepared for: TippingPoint/Hewlett-Packard
Corporation
|
https://www.cisco.com/c/en/us/td/docs/security/ips/7-0/configuration/guide/cli/cliguide7/cli_event_action_rules.html
event action rules IPS CLI commands, configuring event action variables, configuring event action target value ratings,
configuring event action overrides, configuratin event action filters, configuring OS identifications, configuring denied attackers, monitoring events, target value ratings, event action overrides, event action filters
|
From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org>
on behalf of Trey Darley <trey@newcontext.com>
Sent: Thursday, August 30, 2018 4:11:28 AM
To: Brule, Joseph M
Cc: 'openc2-actuator@lists.oasis-open.org'
Subject: Re: [openc2-actuator] SLPF: Should we get rid of the false ACK option?
On 29.08.2018 17:01:17, Brule, Joseph M wrote:
>
> I do know that there are high speed filters that are deployed today
> with this capability. I do not know how widely false acks are used.
>
> Let me know what you think. I do not intend to dig my heels on this
> one but tend toward supporting current capabilities.
>
Your reasoning makes sense to me, Joe. +1
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"Just wait till time intervenes. The alchemy of time transforms
everything into comedy. Everything..." --Josef Škvorecký
|