CCIE Security: Theory - Section 3

More notes, again I will probably add more to this, if you think anything should be added, then do so through the comments section.

3.0 Application and Infrastructure Security

3.1 HTTP

Port 80

Status codes

100 - Continue - client should continue with request
200 - OK - request succeeded
201 - Created - new resource should be created
202 - Accepted - request accepted but processing not completed
203 - Non-Authorative Information - metainformation gathered from local or third-party copy
204 - No Content
205 - Reset content
206 - Partial content
300 - Multiple choices
301 - Moved Permanently - new permanent URI
302 - Found
303 - See Other - response can be found under different URI and should use GET method on that resource
304 - Not Modified - if use conditional GET and document not modified then should give this
305 - Use Proxy - must be accessed through proxy given in Location Field
307 - Temporary Redirect
400 - Bad request - malformed syntax
401 - Unauthorized - requires authorization, response requires WWW-Authenticate Header
402 - Payment Required - reserved
403 - Forbidden - understood request by refused to fulfill
404 - Not Found
405 - Method Not Allowed
406 - Not Acceptable
407 - Proxy Authorization Required - similar to 401 - but client must authenticate with proxy first
408 - Request Timeout - client did not produce request quick enough
409 - Conflict - most likely to occur in PUT requests (i.e. versioning)
410 - Gone - response no longer available - not permanent - should use 404 instead
411 - Length Required - server required Content-Length
412 - Precondition failed - precondition tested false
413 - Request Entity Too Large
414 - Request-URI too Long - URI longer than one server willing to accept
415 - Unsupported Media Tytpe
416 - Requested Range Not Satisfiable
417 - Expectation Failed - request possibly not met by next-hop server
500 - Internal Server Error
501 - Not Implemented - server does not support functionality too fulfill request
502 - Bad Gateway - server acting as gateway or proxy received invalid response from upstream server
503 - Service Unavailable - temporary overloading or maintenance
504 - Gateway Timeout - server acting as gateway or proxy did not receive response from upstream server
505 - HTTP Version Not Supported - server does not support ot refused to support HTTP protocol version in Request

3.2 HTTPS

Port 443
AKA: HTTP over TLS, HTTP over SSL, HTTP Secure
Protects against MITM attacks, provides bidirectional encryption
Requires certificates

3.3 SMTP

Connection-oriented, text-based protocol
TCP port 25, port 587 for submission, SMTPS - port 465

MUA - Mail User Agent - User interface (like Outlook) used by end user connects to
MSA - Mail Submission Agent. MSA delivers mail to
MTA - Mail transfer Agent - Moves email from sending main server to recipient mail server. Uses DNS to find MX record for recipients domain. MX target accepts incoming message and passes it to
MDA - Mail delivery Agent - Moves email from MTA to user mailbox in recipient mail server, which waits for MUA to pick up using
POP/IMAP - protocol used to fetch email from recipient mail server mailbox to recipient MUA

3.4 DHCP

DORA - Discover, Offer, Request, Acknowledge

UDP/67 on server, UDP/68 on client
CIADDR - Client IP address
YIADDR - Your IP address
SIADDR - Server IP address
GIADDR - Gateway IP address
CHADDR - Client Hardware address

Options

3 - Router
4 - Timer server
5 - Name server
6 - DNS
12 - hostname
15 - Domain name
42 - NTP server
50 - Requested Ip address
51 - Lease time
52 - option overhead
53 - DHCP Discover
54 - Server Identifier
55 - Parameter request list
60 - Vendor Class identifier
61 - client Identifier
66 - TFTP Server name
67 - bootfile name

DHCP relay - point to DHCP server on different subnet

3.5 DNS

UDP/53

Opcodes 
0 - Query
1 - iQuery (obsolete)
2 - Status (server status request)
3 - Unassigned
4 - Notify
5 - Update
6 - 15 - Unassigned

RCodes
0 - NoError
1 - FormErr
2 - Servfail
3 - NXDomain (Non-Existent Domain)
4 - NotIm
5 - Refused

3.6 FTP and SFTP

Active or Passive, - Client creates TCP control connection to FTP port 21. Active - client starts listening for incoming data, sends FTP command PORT M to inform server what port it is listening on. Server initiates data channel from port 20. If client behind firewall (unable to accept incoming TCP connections) - use passive mode. In passive mode the client uses the control connection to send PASV command, receives server IP address and server port number. client then opens a data connection to server IP address and port number given.

Simple FTP (SFTP) - unsecured. Implicit SFTP - passive mode by default

3.7 TFTP

UDP port 69. No login etc.

3.8 NTP

UDP/123

Stratums
0 - Reference clocks
1 -> 15 - 1 is better, 15 lowest. Can be used.
16 - Unsynchronized

3.9 SNMP

UDP/161, udp/162 for traps and InformRequests

GetRequest
SetRequest
GetNextRequest
GetBulkRequest (added in SNMPv2)
Response
Trap
InformRequest (added in SNMPv2)
Report (added in SNMPv3)

SNMPv2 added performance, security, confidentiality, and manager to manager communications.
SNMPv3 Added confidentiality, integrity & authentication - user-based Security (NoAuthNoPriv, AuthNoPriv, AuthPriv), uses MD5 & SHA

3.10 syslog

Facilities 0 - 23.
Severity 0 - 7:
0 - Emergency
1 - Alert
2 - Critical
3 - Error
4 - Warning
5 - notice
6 - Informational
7 - Debug

3.11 Netlogon, NetBIOS, and SMB

Network Basic Input/Output system - session layer OSI. API. not usable on networks over 50 computers annoying if over 10. DNS is better.
UDP/137 & 138
TCP/137 & 139

SMB - Server Message Block AKA CIFS. Application-layer. Does network sharing. TCP port 445

3.12 RPCs

Remote Procedure Call - program causes procedure to execute in another address space.

3.13 RDP and VNC

Remote GUIs. RDP - TCCP/UDP port 3389. VNC platform independent. Server/client based. TCP port 5900+N

3.14 PCoIP

PC-over-IP - remote display protocol/ Licensed by VMWare & AWS. UDP based.

3.15 OWASP

Open Web Application Security Project - dedicated to web application security.

3.16 Manage unnecessary services

Turn them off!!!

no service tcp-small-servers (echo, chargen, discard, daytime)
no service udp-small-servers (echo, discard, chargen)

Echo - echos what you type through "telnet x.x.x.x echo"
Chargen - generates stream of ASCII "telnet x.x.x.x chargen"
Discard - Throws away whatever you type
Daytime - returns system date and time

no ip finger
no ip bootp server
no mop enabled - disables Maintenance Operation protocol
no ip domain-lookup
no service pad - disables Packet Assembler/Disassembler on X.25 networks
no ip http server
no ip http secure-server
no service config - disables looking to TFTP for config

CCIE Security: Theory - Section 2

This is basically just notes, I will probably add more from time to time, if there is anything that you think should be added, then please use the comment boxes below.

2.0 Security Protocols

2.1 RSA

One of the first public-key cryptosystems. Uses two keys, one is public (the encryption key), the other is private (the decryption key). This is asymmetric. User creates (and publishes) a public key. Relatively slow. Key sizes are from 1024 to 4096.

RFC 2409 restricts private key size to 2048 bits or less for RSA encryption. Recommended modulus value for CA (and clients) is 2048 bits.

4 steps - Key generation, key distribution, encryption and decryption.

RSA & PKI - 

PKI:

 - Certificate Authority - issues and verifies digital certificates
 - Registration Authority - verifies identify of users requesting information from CA - also called a subordinate CA, accepts requests for certificates and authenticates the requester.
 - Central Directory - secure location to store and index keys

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/xe-3s/sec-pki-xe-3s-book/sec-deploy-rsa-pki.html

RSA key pair (public & private) required before you can obtain a certificate for your router. End host must generate pair of RSA keys and exchange public key with the CA to obtain a certificate and enrol in PKI.

A CA (Certificate Authority), which is a trustpoint, manages certificate requests and issues certificates. CA generates its own public key pair and creates a self-signed CA cert, The CA can then sign certificates and begin peer enrolment for the PKI.

RSA key pairs may need to be removed if:

• During manual PKI operations and maintenance the old RSA keys can be removed and replaced with new keys
• Existing CA is replaced and the new CA requires newly generated keys - i.e key size may have changed from 1024 to 2048.
• Peer route's public keys can be deleted in order to debug signature verification problems in IKEv1 and IKEv2.

2.2 RC4

Stream cipher, simple and fast (about 10 times faster than DES for example), though insecure. Vulnerable when beginning of output stream is not discarded  - lead to inscure protocols such as WEP. RFC 7465 prohibits use of RC4 in TLS. Generates a pseudo-random stream of bits. Generates keystream through a permutation of all 256 possible bytes (which is a variable length key, typically between 40 and 256 bits), also uses two 8-bit index pointers.

2.3 MD5

Hashing function - replaces MD4, made by Ron Rivest who created RC4. Creates a digest of 128-bits. No longer recommended as vulnerable. Hashing functions take input data and return a hash function (called hash or digest). Input and message has one-to-one mapping. Hashes are one-way - can create a digest, but cannot create original data from a digest.

2.4 SHA

Multiple variants.
SHA-0 - 160-bit hash, not widely used
SHA-1 - 160-bit hash, correct issues with SHA-0. Widely used but not recommended as there are theoretical attacks
SHA-2 - creates hashes of 224, 256, 384 or 512 bits.
SHA-224, SHA-256, SHA-384, SHA-512, SHA-512.224 & SHA-512/256
SHA-512 used by TRueCrypt
SHA-256 used by DKIM signing
SHA-256 and SHA-512 recommended for DNSSEC
SHA-3

2.5 DES

Block cipher, considered insecure - small key-size of 56-bits

2.6 3DES

Applies DES algorithm three times, better practical security, 3 keys of 56-bits each.

2.7 AES

Block cipher, successor to DES. based on Rijndael cipher. Most CPUs include hardware AES support - making it fast. Supported by TrueCrypt & SSH

2.8 IPsec

Protocol suite authenticates and encrypts each IP packet. Uses Security Associations (SA) - a bundle of algorithms and parameters used to encrypt and authenticate a particular flow in one direction - in bi-directional traffic the flows a rescured by a pair of SAs.

Uses ISAKMP to establish the SAs.

IPSec adds an overhead to the packet - meaning packet may need to be fragmented. By default the router knows the IPSec overhead to add to the packet, it then performs a lookup to see if the packet will exceed the egress physical interface IP MTU after encryption has been applied. If this is the case it then fragments the packet before encrypting it, and separately encrypts the resulting IP fragments.

2.9 ISAKMP

RFC 2408. Establishes Security Associations. UDP port 500

2.10 IKE and IKEv2

Phase 1: Uses Diffie-Hellman key exchange to generate a shared secret to encrypt further IKE communications. Results in one single bi-directional ISAKMP SA. Can use pre-shared key, signatures of PKI. Operates in Main mode or Aggressive mode. Main protects identity of peers, aggressive does not.

Phase 2: IKE peers use secure channel to negotiate SAs on behalf of other services, like IPSec. Results in minimum of two unidirectional SAs (one inbound one outbound). Operates in Quick Mode only.

IKEv2 0 adds standard mobility support, NAT traversal (encapsulation of IKE and ESP in UDP port 4500, SCTP support (VoIP), reliability and state management, It is DoS resilience.

2.11 GDOI 

http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html
http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html
http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf

Group Domain of Interpretation - cryptographic protocol used for key management. RFC 6407. Based on ISAKMP and IKEv1.

It is run between group member(s) and group controller (key server). Uses IKEv1 Phase 1 SA for authenticating a GDOI member to a GDOI controller, protecting a new phase 2 exchange where a member pulls the group state from the controller.

Group key encrypts keys that decrypt application data. The group key is also called a key encrypting key (KEK). KEK is used for Rekey Security Association - once Rekey-SA is established the GDOI controller can push unsolicited updates to the group security association to members over multicast, broadcast or unicast. GDOI is referred to as a multicast key management system.

2.12 AH

AH - provides connectionless integrity and data origin authentication for IP datagrams - computed authentication data is sent to peer.
IPv4 - protects payload and all header fields (except mutable fields - those that might be altered in transit)
IPv6 - protects most of IPv6 base header, AH itself, non-mutable extension headers after the AH and the IP payload.

Uses IP protocol 51.

Packet format:
Next Header | Payload Len | Reserved protected.
Security Parameters Index (SPI)
Sequence Number
Integrity Check value (ICV)

Next header indicates what upper-layer protocol is
SPI identifies the Security Association of the receiving party
Sequence number is used for protection against anti-replay attacks, sequence numbers are never reused.

DH Does not provide data authentication

2.13 ESP

Provides confidentiality, data origin authentication, connectionless integrity and anti-replay.
2 modes: Transport mode (does not provide integrity and authentication for entire IP packet) & tunnel mode (does provide the above).

Uses IP protocol 50.

Packet format:
Security Parameters Index (SPI)
Sequence number
Payload data
Padding | padd length | next header
Integrity Check Value (ICV)

2.14 CEP

Certificate Enrollment Protocol. SCEP Simple Certificate Enrollment Protocol used for enrollment and other PKI operations. Based on HTTP, Only supports RSA-based cryptography.

Steps:

Obtain copy of CA cert and validate it
Generate CSR and send to CA
Poll SCEP server to check if cert gets signed
Re-enroll as necessary
Retrieve CRL

2.15 TLS and DTLS

Preferred over SSL. Uses private and public keys and certificates. Provides privacy and data integrity between two communicating applications, Private as uses symmetric cryptography. Keys are generated uniquely for each connection - based on a secret negotiation at the start of the session. Server and client negotiate details of encryption and cryptographic keys to use before first byte of data is transmitted. Identity of parties can be authenticated using public key cryptography. Uses Message Authentication Code (MAC) to ensure reliability.

1. Client connects to TLS enabled server, requesting a secure connection, presents a list of supported cipher suites.
2. Server picks a cipher and hash that it supports and notifies client of decision.
3. Server sends its digital certificate (server name, trusted CA and public encryption key)
4. Client may then contact issing CA confirming validity of certificate
5. Client then generates session keys - either through random number encryption with servers public key or uses Diffie-Hellman key exchange

TLS 1.0 - RFC 2246
TLS 1.1 - RFC 4346 - added protection against cipher-block chaining (CBC) attacks, support for IANA registration of parameters
TLS 1.2 - RFC 5246 - replaced MD5-SHA1 with SHA-256
TLS 1.3 - draft - removes weak elliptic curves, removes MD5 & SHA-224

DTLS - Datagram Transport Layer Security - allows datagram-based applications to be secure. Based on TLS. RFC 6347. Used by AnyConnect.

2.16 SSL

Now deprecated

2.17 SSH 

http://www.snailbook.com/faq/ssh-1-vs-2.auto.html

Encrypted network protocol for remote login. Uses public-private key pairs, and password. Can also just use manually created public-private key pair (no need for password)

SSHv1 / SSHv2:

Both require a server key to protect the session key

SSHv2 has different layers:

• Transport layer - RFC 4253 - handles initial key exchange, server authentication, encryption, compression and integrity validation. Exposes an interface for sending and receiving plaintext packets - also does key re-exchange afte 1GB or 1hour.
• User Authentication layer - RC 4252 - handles client authentication - provides a number of authentication methods, client driven - can use password, publickey, keyboard-interactive, GSSAIP
• Connection layer - RFC 4254 - can host multiple channels such as shell, direct-tcip (client-to-server), forwarded-tcpip (server-to-client)
• SSHFTP DNS record (RFC 4255) provides public host fingerprints to aid verification of authenticity of host.

2.18 RADIUS

Centralized AAA, uses UDP at application layer. Often backend choice for 802.1X. Can use PAP, CHAP or EAP as authentication, can also connect to SQL, Kerberos, LDAP or AD.

Access-Request
Access-Accept
(or Access-Reject or Access-Challenge)

Reject - user unconditionally denied access - user unknown or user inactive
Challenge - request additional information - such as secondary password, PIN, token or card
Accept - granted access.

Authorization attributes can be included (giving extra rights) - can request IP address, L2TP parameters or VLAN parameters or QoS params.

Uses RSA MD5 to hide passwords.

Attribute value Pairs (AVP) are string values.
RADIUS does not encrypt username, authorization,or accounting

2.19 TACACS+

Cisco proprietary. remote authentication and related services for network access control through centralized server. Uses TCP. Encrypts all information (unlike Radius)

2.20 LDAP

Vendor neutral protocol for accessing and maintaining distributed directory services over an IP network. latest version is 3 - RFC 4511.

Common usage is in SSO (Single Sign On). Based on X.500. Uses TCP/UDP 389 or 636 (LDAPS). Global catalog on port 3268 & 3269. LDAPv3 can use TLS.

2.21 EAP methods (for example, EAP-MD5, EAP-TLS, EAP-TTLS, EAP-FAST, PEAP, and LEAP)

Extensible Authentication Protocol - RFC 3748 (made RFC 2284 obsolete), updated by RFC 5247. Provides transport and usage of keying material and parameters generated by EAP methods.

LEAP (Lightweight EAP) - developed by Cisco. Uses modified version of MS-CHAP - not strongly protected easily compromised. Not recommended
EAP-TLS - RFC 5216  - Still considered secure, requires client-side X.509 certificate
EAP-MD5 - RFC 2284 - minimal security, vulnerable to dictionary attacks, does not support key generation. Unsuitable for use w/ dynamic WEP or WPA/WPA2 enterprise. Only provides authentication of EAP peer to EAP server, but not mutual authentication. Vulnerable to MITM attacks.
EAP-POTP - protected one-time password - RFC 4793 - uses OTP tokens, Can provide unilateral or mutual authentication. 2 factor.
EAP-PSK - RFC 4764 - used pre-shared key.
EAP-PWD - RFC 5931 - shared password
EAP-TTLS - Client can be authenticated via a CA-signed PKI certificate to the server. Server can then use a tunnel to authenticate the client.
EAP-IKEv2 - RFC 5106 - based on IKEv2 - mutual authentication and session key establishment.
EAP-FAST - RFC 4851 - replacement for LEAP. Uses Protected Access Credential (PAC) to establish TLS tunnel. 3 phases
0 - in-band provisioning - provide shared secret, uses authenticated Diffie-Hellman Protocol (ADHP)
1 - tunnel establishment - authenticates using PAC, establishes tunnel key
2 - authentication - authenticates peer
Use manual PAC provisioning as automatic is vulnerable to attacker intercepting the PAC. PAC is issues on per-user basis, new user = need to create new PAC first.

EAP only defines message formats - needs to use another way to encapsulate
802.1X - EAP over LANs (EAPOL) - can use TKIP or CCMP (based on AES)
PEAP - (Protected EAP) - encapsulates EAP within TLS.

2.22 PKI, PKIX, and PKCS

PKIX

Also known as X.509, ITU-T standard for PKI and PMI. Specifies standard formats for public key certificates, certificate revocation lists (CRL), attribute certificates, and a certification path validation algorithm.

CA issues certificate binding public key to a particular distinguished name, or to an alternative name. Root certificates can be distributed so that they trust the PKI system.

X.509 includes certificate revocation list. IEFT-approved is OCSP (Online Certificate status Protocol)

V3 digital certificate structure:
Certificate
Version number
Serial number
Serial Algorithm ID
Issuer name
Validity period
Not before
Not after
Subject name
Subject public key info
Public Key Algorithm
Subject Public Key
Issuer Unique Identifier (optional)
Subject Unique Identifier (optional)
Extensions (optional)
Certificate Signature algorithm
Certificate signature

Formats:
.pem - privacy-enhanced Electronic Mail - encoded DER cert
.cer, .crt, .der - usually in binary DER form - can also Base64-encode
.p7b, .p7c - PKCS#7 SignedData structure w/out data, just certs of CRLs
.p12 - PKCS#12 - may contain certificates, public and private keys (password protected)
.pfx - predecessor of PKCS#12

PKCS - RSA

Group of public-key cryptographic standards created by RSA Security Inc. - Designed to promote use of cryptographic techniques using RSA patents.Covers PKCS#1 - 15.

2.23 IEEE 802.1X

IEEE standard, port-based Network Access Control (PNAC). Provides authentication to devices connecting to LAN or WLAN. Uses EAP over 802 - EAP over LAN or EAPOL.

3 parties - supplicant, authenticator and authentication server.
Supplicant - client device - but also refers to the software used to connect to authenticator
Authenticator - network device (such as switch or AP)
Authentication server - RADIUS & EAP (like ISE)

Process:

Initialization - switch port is set to unauthorised state - only 802.1X traffic is allowed - other traffic, such as IP (including TCP & UDP) is dropped.
Initiation - authenticator transmits EAP-Request Identify frames. Supplicant listens, will respond with EAP-Response Identify frame, containing identifier (i.e. User ID). Authenticator encapsulates this in a RADIUS Access-Request and forwards on to the authentication server
Negotiation - Authentication Server sends a RADIUS Access-Challenge to the authenticator, containing EAP Request with EAP method. Authenticator encapsulates the EAP Request in EAPOL frame and transmits to supplicant. Supplicant can either use this, or NAK and respond with supports EAP methods to use.
Authentication - If authentication server & supplicant agree on an EAP method and authenticity is successful then the authenticator sets port to authorised and normal traffic is allowed.

MAB - MAC Authentication Bypass - used where device not 802.1X compatible - When configured port will first check to see if device is 802.1X compliant - if not will then try to authenticate to AAA server using connected devices MAC address as username and password.

2.24 WEP, WPA, and WPA2

WEP - Wired Equivalent Privacy - for 802.11 wireless networks. Now deprecated (as of 2004). Uses RC4 (confidentiality) and CRC-32 (integrity). 64-bit WEP uses 40-bit key and 24-bit IV

WPA - Wi-Fi Protected Access (and WPA2) - uses TKIP (Temporal Key Integrity Protocol) and supports CCMP - an AES-based encryption mode.

TKIP has a 64-bit Message Integrity Check (MIC) and uses a new 128-bit key for each packet. implements key mixing function - combines secret root key with the IV before passing it to RC4.

WPA-Personal - uses pre-shared key
WPA-Enterprise - requires RADIUS server

2.25 WCCP

Web Cache communication protocol - Cisco developed protocol for content-routing. Redirects traffic in real-time, built in load balancing, scaling, fault tolerance, and service-assurance. Can also be used for traffic localisation.

WCCPv1 - only single router services a cluster of systems, supports HTTP only, uses GRE, uses UDP/2048

WCCPv2 - can use 32 routers with 32 engines/accelerators, supports any IP protocol (including multicast), supports 255 service groups, adds MD5 shared secret security (authentication)

client sends “Here I am” every 10 seconds
Server acknowledges with “I See you”

2.26 SXP

Part of TrustSec - enables security through identity-based controls. “anyone, anywhere, anytime”. data integrity and confidentiality services, policy-based governance and generalised monitoring, troubleshooting and reporting.

Establishes domains of trusted networks, each device being authenticated by its peers. packets are classified by security groups (SGs). Classification maintained by tagging packets on ingress  - called Security Group Tag (SGT).

Uses SGT Exchange Protocol (SXP) to propagate SGts.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cts/configuration/xe-3s/sec-usr-cts-xe-3s-book/cts-sxp-ipv4.html

2.27 MACsec

802.1AE aka MACsec - connectionless data confidentiality and integrity for media access independent protocols. New frame type, includes new fields - Security tag and Message Authentication Code. default cipher suite of GMC-AES-128, and GMC-AES-256.

Allows authorised Lan connections to be identified and excluded from communication within the network. Can mitigate attacks on L2 protocols.

2.28 DNSSEC

Domain Name System Security Extensions - provides origin authentication of DNS data, denial of existence, and data integrity. Designed to protect against cache poisoning, uses digital signatures. New DNS record types:
RRSIG - record set
DNSKEY - contains public key that DNS resolver uses to verify DNSSEC in RRSIG-records
DS - name of delegated zone
NSEC - link to next record name
NSEC3 - links to next record name in hash
NSEC3PARAM - authoritative DNS servers

UNetLab Competition winner!

I recently ran a little competition to design a lab for UNetLab over on the forum. The idea behind it was to try and raise the profile of UNetLab, give it a bit more exposure in a different way and so that people could see it's potential.

We had three entries. Not the earth shattering 100's I was hoping for, but it certainly made the job of picking a winner much easier!

The cool thing is that each entrant picked a different level of ability:

Luis picked CCNA:

  Nikita chose CCNP:

Peter chose a CCIE level:

This made it much harder to choose a winner though.

Should the winner be chosen just because it is more complex? Not really, that would not be fair. Each should be judged on it's own merits.

Luis did a great job a VLSM, clearly a lot of thought went into that.

Nikita threw in some troubleshooting, which was a great idea!

Peter build an entire infrastructure and really pushed the boundary!

So with the variation of designs and different target audiences it's very hard to pick an outright winner. Clearly a lot of effort was made by each of you.
Therefore (because I am in a jolly mood) each of you will get all three volumes of the books. Each of you will have your labs added to the official UNetLab distribution. Each of you will get a T-shirt.

Peter's t-shirt will be changed though, to say "I won the #UNetLab challenge".

Send me a private message on the forum with your addresses and preferred t-shirt size and I will get the goodies ordered. I'll let you know when they have been sent, and supply tracking information, if possible.