I'm going to asssume you are running a 3.0 release of the code.
The 6302 Loki signature is triggered by an imbalance in the number of echo replies to echo requests between a fixed src and destination. Additionally these replies must have the same sequence numbers as the associated request had, and at least one must have a different payload than the associated request.
This fits the mold of something that is using ICMP echo request/replies as a covert channel for communication. The standard implementation of ICMP would call for a one to one correlation between replies and requests and the payload in the replies should be the same as the request, hence the name Echo request/Echo reply.
Unfortunately several companies for various benign reasons have decided to use ICMP as a way of communicating. These appear to be covert channels and they are, however they are benign in this case.
The subsignature IDs are the ICMP sequence numbers of the traffic that we were following that caused the alert. This would allow you to sniff your ICMP traffic and match up the offending ICMP traffic to the alarm so that you could decide if the data being communicated in the channel was benign or if it was a potentailly compromised host.
Hope this helps to shed more light on this for you.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...