# The IKE Scanner (ike-scan) is Copyright (C) 2003-2013 Roy Hills,
# NTA Monitor Ltd.
#
# This file is part of ike-scan.
#
# ike-scan is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# ike-scan is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with ike-scan.  If not, see <http://www.gnu.org/licenses/>.
#
# ike-backoff-patterns -- Backoff patterns file for ike-scan
#
# Author: Roy Hills <Roy.Hills@nta-monitor.com>
#
# Format:
# Implementation_Name<Tab>Backoff_Pattern
#
# Implementation_Name is a descriptive name for the IKE implementation
# (and version if applicable).  Backoff_Pattern is the observed IKE
# retransmission backoff pattern for this implementation.
#
# The backoff pattern is specified as a comma-separated list of backoff
# times in seconds.  The first number is always zero and represents the first
# packet received.  Subsequent numbers represent the expected delay in
# seconds after the previous packet.  For example, "0, 2, 2, 2" means that a
# total of four packets are sent with a delay of two seconds between each one.
#
# The numbers in the backoff pattern can be decimal numbers e.g. 1.5 for
# one and a half seconds.  You can specify up to a maximum of 6 digits
# after the decimal point (microsecond resolution), although anything
# beyond millisecond resolution is not really practical.  ike-scan uses
# a timeval struct to store the backoff pattern entries.
#
# You may also specify an per-pattern-entry "fuzz" value in milliseconds
# by appending /<fuzz> to the backoff time.  This will override the default
# fuzz for that time only.  The fuzz value specifies how close the specified
# time must be to the observed time for a match.  E.g. a fuzz of 0 means that
# the observed timing must match exactly and a fuzz of 1000 means that the
# times must be within one second of each other (1000ms = 1sec).  If no
# per-pattern-entry fuzz value is specified then a default fuzz value of 100ms
# (defined by DEFAULT_PATTERN_FUZZ in ike-scan.h) is applied.  This default
# value may be changed with the --fuzz option to ike-scan.
#
# Lines beginning with '#' and blank lines are ignored.
#
# The input format is quite strict.  In particular, the separator between
# the implementation name and the backoff pattern must be a single TAB and
# not a space, multiple tabs or spaces, or a mixture of tabs and spaces.
#
# If you have problems adding entries, run ike-scan as:
# ike-scan -v -v -v -o <any-target>
# To dump the backoff pattern table.
#
# There are examples and analysis of the backoff patterns returned by various
# implementations on the ike-scan wiki at
# http://www.royhills.co.uk/wiki/index.php/Ike-scan_Documentation
#
# You are encouraged to submit comments, improvements or suggestions
# at the github repository https://github.com/royhills/ike-scan
# In particular, I would like you to submit any new patterns that you
# discover.
#

# Discovered by: Roy Hills, November 2002
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 11.3(11b)T2
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.0(28c)
# Observed on: Cisco PIX 520 running 5.1(2)
# Observed on: Cisco PIX 520 running 5.2(9)
# Observed on: Cisco PIX 520 running 5.3(4)
# Observed on: Cisco PIX 520 running 6.0(4)
# Observed on: Cisco PIX 520 running 6.1(5)
# Observed on: Cisco PIX 520 running 6.2(4)
# Note: Cisco IOS 12.1, 12.2 and 12.3 (and possibly later versions as well)
#	have a different pattern: 0,10,10,10,10,10.  This is listed later
#	under a different name.
# Note: PIX OS 6.3 has a different pattern: 0, 5, 5, 5, 5, 5.  This is listed
#	under a different name.
# Note: IPsec was introduced in Cisco IOS 11.3.  Previous versions only
#	supported the Cisco proprietary CET encryption.
Cisco IOS 11.3 or 12.0 / PIX <= 6.2	0, 15, 15

# Discovered by: Tony Lloyd, May 2006
# Observed on: Cisco PIX 520 running PIXOS 6.3(5)
Cisco PIX 6.3	0, 5, 5, 5, 5, 5

# 1st Pattern Discovered by: Roy Hills, November 2002
# Observed on: Cisco VPN Concentrator 3005 running (unknown version)
# Observed on: VPN 3000 Concentrator Version 3.6.3.Rel Oct 04 2002 16:23:00
# Observed on: VPN 3005 Concentrator Version 4.7.2.L Jun 11 2007 14:07:29
# 2nd Pattern Discovered by: Guy Widloecher, March 2003
# Observed on: Cisco VPN 3005 Concentrator Version 3.5.2
# This second pattern may be due to the earlier software version, or it could
# be a missed packet.
# There are several models: 3005, 3015, 3020, 3030, 3060 and 3080, which are
# equivalent to the old Altiga C5, C15 Etc.  All models are believed to share
# the same backoff pattern.
# The first pattern is also generated by Cisco PIX 7.0
# Observed on: Cisco PIX 515E running PIX OS 7.0(7)
Cisco VPN Concentrator or PIX 7.0	0, 8, 8, 8
Cisco VPN Concentrator	0, 8, 8

# Discovered by: Roy Hills, December 2002
# Observed on: Checkpoint Firewall-1 4.0 SP7 on Windows NT Workstation 4.0 SP6a
Firewall-1 4.0	0, 3, 3, 3, 3, 6, 6, 6, 6, 6, 6, 6

# Discovered by: Roy Hills, November 2002
# Observed on: Checkpoint Firewall-1 4.1 SP6 on Windows NT Server 4.0 SP6a
# Observed on: Checkpoint Firewall-1 NG base on Windows NT Server 4.0 SP6a
# Observed on: Checkpoint Firewall-1 NG FP2 on Windows NT Server 4.0 SP6a
# Observed on: Checkpoint Firewall-1 NGX R60 on Windows 2003 Server
Firewall-1 4.1/NG/NGX	0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4

# Discovered by: Roy Hills, December 2002
# Observed on: FreeS/WAN 1.9 on Debian Linux 2.2r7 (Potato) with 2.2.17 Kernel
# Observed on: strongSwan 4.0.5 on Debian Etch with 2.6.18 kernel
# Observed on: OpenSwan 2.2.0 on Debian Sarge with 2.6.16 kernel
Linux FreeS/WAN, OpenSwan, strongSwan	0, 10, 20

# Discovered by: Roy Hills, November 2002
# Additional fuzz on 1st retry suggested by Florent Trupheme, April 2005
# Observed on: Nortel Contivity 2500, OS version V4.06-120
# Observed on: Nortel Contivity 1600, OS version V3.60-45
Nortel Contivity	0, 16/600, 16, 16

# Discovered by: Roy Hills, December 2002
# Observed on: Watchguard Firebox 700 v6.1
# Observed on: Gnat Box (version unknown)
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.1(27a)
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.2(29)
# Observed on: Cisco 2621 running IP/FW/IDS Plus IPsec 3DES Basic 12.3(17a)
# Observed on: Cisco 1721 running Advanced Security 12.4(13a)
# Observed on: Cisco 7206 running Advanced Security 15.0(1)M
# Observed on: racoon 0.6.6 running on Debian Etch
# Note that the Gnat box has a much larger variance than the watchguard, but
# they are both essentially the same pattern.
Cisco IOS 12.1, 12.2, 12.3, 12.4 or 15.0 / Watchguard Firebox / Gnat Box / racoon	0, 10/1000, 10/1000, 10/1000, 10/1000, 10/1000

# Discovered by: Roy Hills, December 2002
# Observed on: Windows 2000 Server SP1
# Observed on: Windows XP Pro SP1
# Note: Backoff fingerprinting cannot distinguish between 2000, 2003 and XP,
#	but vendor IDs can.
Windows 2000, 2003 or XP	0, 1, 2, 4, 8, 16, 32

# 1st pattern Discovered by: Thomas Walpuski, Jan 2003
# Observed on: Various OpenBSD systems running isakmpd
# 2nd pattern discovered by: Marco Ivaldi <raptor@mediaservice.net>, Jan 2003
# Observed on: OpenBSD 3.2
# Observed on: FreeBSD 4.7-Stable with isakmpd-20021118 and OpenBSD 3.1
# Note: OpenBSD isakmpd is highly configurable, so it's difficult to get one
#       pattern which will match all possible backoff pattern.
#       Hakan Olsson has informed me that the actual algorithm used by isakmpd
#	is "5 + 2*<retrans#>" which can be found in transport.c, ca line 310.
#	Both patterns match this algorithm: the first with the default
#	retransmission limit of 3 and the second with retransmits set to 5.
#	It has also been pointed out that isakmpd can run on many platforms
#	other than FreeBSD and OpenBSD, so the inclusion of these OS names in
#	the pattern are misleading.  However, I'm leaving the names unchanged
#	in case someone relies on them in the program output.
FreeBSD/OpenBSD-isakmpd	0, 7, 9, 11
FreeBSD/OpenBSD-isakmpd	0, 7, 9, 11, 13, 15

# Discovered by: Paul van Maaren, January 2003
# 1st pattern observed Jan 2003 on: FreeBSD-4.7 STABLE with racoon-20021120a
# 2nd pattern observed Jun 2005 on: FreeBSD-5.3-RELEASE with racoon-20050510a
KAME/racoon-1	0, 20, 20, 20, 20, 20
KAME/racoon-2	0, 21.5, 21.5, 21.5, 21.5, 21.5

# Discovered by: Iain Lewis, February 2003
# Observed on: Netscreen 500
# Observed on: Netscreen 5GT running ScreenOS 5.1.0r1.0
Juniper-Netscreen	0, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4

# Discovered by: Doug Monroe, January 2003
# Observed on: Watchguard SOHO v5.1.7
# Note:	There is quite a bit of variation with this pattern, hence the
#	per-entry fuzz specifications.
watchguard-soho	0, 1/500, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000

# Discovered by: Christopher Harrington, February 2003
# Observed on: SonicWall Pro 200
# Note:	There is quite a bit of variation with this pattern, hence the
#	per-entry fuzz specifications.
sonicwall-pro	0, 6.5/1500, 9/1000, 13/2000, 22/3000

# Discovered by: Florent Trupheme, April 2005
# Observed on Side Winder G2 Firewall
# Also observed on a separate Sidewinder G2 by Tim Ecott, July 2005
# Two different patterns have been observed: the 0,3,6,15,48 appears to be the
# more common one, but 0,3,4,12,36 has also been seen.
SideWinder G2 Firewall	0, 3, 6, 15, 48
SideWinder G2 Firewall	0, 3, 4, 12, 36

# Discovered by: Florent Trupheme, April 2005
# Observed on SonicWall unknown version
# Interestingly, this is different from the earlier sonicwall-pro entry.
Sonic Wall	0, 5, 8, 18

# Discovered by: RealRancor, September 2013
# DELL SonicWALL appliance (version unknown)
# There's quite a bit of variation in the timings, hence the per-entry fuzz
# settings.
# This may be the same patterm as "Sonic Wall" above, but we don't have
# enough data points to be sure.
DELL SonicWall	0, 5/1000, 10/2000, 20/3000

# Discovered by: Roy Hills, December 2003
# Observed on: Windows 2003 Server Enterprise Edition, Intel platform
# Note: The 2nd packet delay has been observed to vary between 0.5 and 1.5 sec.
#       Otherwise, this is the same pattern as Windows 2000.  Note that if the
#	Win-2003 server happens to pick a delay of around 1 sec for the 2nd
#	Packet, then ike-scan will mis-identify as Win-2000.  Vendor ID
#	payloads can distinguish Win-2003 from Win-2000 in any event, but
#	that's another story.
Windows-2003	0, 1/600, 2, 4, 8, 16, 32

# Discovered by: Bob Davies, March 2004
# Observed on Lynksys router, Unknown version
Lynksys	0, 15/500, 15, 15

# Discovered by: Tony Lloyd, January 2005
# Observed on: suspected bordermanager box
# July 2006: Observed on: BorderManager 3.8 on NetWare 6.5
Novell-BorderManager	0, 4.5/1000, 6.9, 9.8

# Discovered by: Tony Lloyd, April 2005
# Observed on: Draytek ADSL Routers (several different versions)
draytek	0, 3, 6

# Discovered by: Tony Lloyd, June 2005
# Observed on: Cyberguard Firewall (exact model and version unknown)
cyberguard	0, 3.5, 7, 10, 10

# Discovered by: Tony Lloyd, June 2005
# Observed on: Fortinet FortiGate Firewall (exact model and version unknown)
# Note: some FortiGate Firewalls appear to have a 0,10,20 pattern instead
FortiGate	0, 6, 12

# Discovered by: Tony Lloyd, August 2005
# Observed on: Avaya VSU 100R
# The backoffs have quite a bit of variance, but the delays always seem to be
# between 13.3 and 15.7 seconds.
Avaya VSU	0, 14.5/1200, 14.5/1200, 14.5/1200, 14.5/1200

# Discovered by: Tony Lloyd, September 2005
# Observed on: Stonegate V2.2.0 on Linux
Stonegate	0, 0.5, 1, 2, 4, 8, 16, 30, 30, 30, 30

# Discovered by Paul Askew, December 2005
# Observed on: Netgear FVS328 ProSafe VPN Firewall Version 1.0.15
# The time between the first and second packets has quite a bit of variance,
# but the delays between subsequent packets do not.
Netgear ProSafe	0, 4.5/1000, 5, 5, 5

# Discovered by Paul Askew, December 2005
# Observed on: Netgear DG834V2 ADSL Firewall Router Version 2.10.22
# Interestingly, the backoff pattern for this device differs from that for
# the Netgear FVS328 ProSafe VPN Firewall.
Netgear ADSL Firewall Router	0, 10, 20

# Discovered by Roy Hills, October 2006
# Observed on: Linksys Etherfast DSL/Cable VPN Router, Model BEFVP41 V2 s/w 1.01.04
# Not really a pattern as the Linksys doesn't retransmit at all.  However, this
# lack of retransmission is sufficiently unusual to be a pattern itself.
Linksys Etherfast	0

# Discovered by Roy Hills, November 2005
# Observed on: IBM RS/6000 running AIX 5L 5.3
# The AIX backoff is unusual because it goes on for a long time (about 19
# minutes) and it has a hiccup at one point where it sends two packets with
# the same backoff. With the standard ike-scan backoff timeout, you will only
# see the first three packets.  Longer timeouts let you see more packets.
# I have added multiple patterns to allow matching with any backoff timeout
# above 32 seconds.
IBM AIX	0, 16, 32
IBM AIX	0, 16, 32, 64
IBM AIX	0, 16, 32, 64, 128, 128
IBM AIX	0, 16, 32, 64, 128, 128, 256
IBM AIX	0, 16, 32, 64, 128, 128, 256, 512

# Discovered by Roy Hills, January 2007
# Observed on: Solaris 9/SPARC running on Ultra-5
# Observed on: Solaris 10/Intel running on VMware
#
# Sun's IPsec was introduced in Solaris 8, but this was manual keying only;
# IKE keying was not introduced until Solaris 9.
Sun Solaris	0, 0.5, 1, 2, 4, 8
