PIM DM

Use the above topology to test/verify PIM DM features:
PIM Neighbors
PIM Join / Prune
Prune override
Graft
Graft Ack
Assert
 

BGP Best Path Selection Flow Chart

Common TCP UDP Ports

Application	Port	Protocol	Notes
HTTP	80, 8080	TCP	Hyptertext Transfer Protocol. Used by web browsers such as Internet Explorer, Firefox and Opera.
HTTPS	443	TCP, UDP	Used for secure web browsing.
IMAP	143	TCP	Email applications including Outlook, Outlook Express, Eudora and Thunderbird.
FTP	20 to 21	TCP	File Transfer Protocol.
SSH	22	TCP	Secure Shell protocol. Provides a secure session when logging into a remote machine.
Telnet	23	TCP	Used for remote server administration.
DNS	53	TCP, UDP	Domain Name System protocol for converting domain names to IP addresses.
NNTP	119	TCP	Network News Transfer Protocol, used for internet discussion groups.
NETBIOS	137 to 139	TCP, UDP	NETBIOS is used for file transfers between Windows machines.
SNMP	161 to 162	UDP	Simple Network Management Protocol. Used by network administrators for remote statistics and information gathering.
LDAP	389	TCP, UDP	Lightwight Directory Services Protocol, used for accessing centralized databases of users and computers.
Microsoft SQL Server	1433 to 1434	TCP, UDP	Database application.
MySQL	3306	TCP, UDP	Database application.
Oracle SQL	1521, 1522, 1525, 1529	TCP	Database application.
Microsoft Terminal Server / Citrix ICA	1494, 1604	UDP	Remote desktop application.
ICQ	4000	UDP	Instant messenger.
Yahoo Messenger	5010	TCP	Instant messenger.
AOL Instant Messenger	5190	TCP, UDP	Instant messenger.
PCAnywhere	5632	TCP, UDP	Remote desktop application.
VNC	5800, 5900	TCP	Virtual Network Computer, allows remote desktop functionality.
Kerberos	88	TCP, UDP	Used for user authentication, mainly on Windows systems.
POP3	110	TCP	Post Office Protocool. For receiving email.
SMTP	25	TCP	Simple Mail Transfer Protocol, used for sending email.
RIP	520	UDP	Routing Information Protocol, part of the core internet infrastructure.
Microsoft PPTP	1723	TCP	Point-to-Point Tunneling Protocol, a VPN implementation.
Windows Media Streaming	1755, 7007	TCP, UDP
Age of Empires	2300 to 2400, 6073, 47624	TCP, UDP	Multiplayer game.
Call of Duty	20500, 20510, 28960	TCP, UDP	Multiplayer game.
Counter-Strike	1200, 27000 to 27015, 27020 to 27039	TCP, UDP	Multiplayer game.
Doom 3	27650, 27666	TCP, UDP	Multiplayer game.
Everquest	1024, 6000, 7000	TCP, UDP	Multiplayer game.
Far Cry	49001 to 49002, 49124	TCP, UDP	Multiplayer game.
FIFA	3658, 10400 to 10499	TCP, UDP	Multiplayer game.
Microsoft Flight Simulator	2300 to 2400, 6073, 23456, 47624	TCP, UDP	Multiplayer game.
Gamespy Arcade	3783, 6515, 6500, 6667, 13139, 27900, 28900, 29900, 29901	TCP, UDP	Game browser.
Gnutella	6346	TCP, UDP	P2P file sharing application.
GTA2	2300 to 2400, 47624	TCP, UDP	Multiplayer game.
Half Life 2	1200, 27000 to 27015, 27020 to 27039	TCP, UDP	Multiplayer game.
iTunes	3689	TCP, UDP	Music sharing application.
MSN Messenger	1863, 5190, 6891 to 6901	TCP, UDP	Instant messenger.
NBA Live	3658, 9570, 18699 to 28600	UDP	Multiplayer game.
Need For Speed	80, 1030, 3658, 3659, 9442, 13505, 18210, 18215, 30900 to 30999	TCP, UDP	Multiplayer game.
Net2Phone	6801	UDP	VoIP application.
NetFone	10200	TCP	VoIP application.
Neverwinter Nights	5120 to 5300, 6500, 6667, 27900, 28900	UDP	Multiplayer game.
NHL	3658, 10300, 13505	TCP, UDP	Multiplayer game.
No One Lives Forever	2300 to 2400, 7000 to 10000, 27888	TCP, UDP	Multiplayer game.
PhoneFree	1034 to 1035, 2644, 8000, 9900 to 9901	TCP, UDP	VoIP application.
Quake	27650, 27910, 27950, 27952, 27960, 27965	TCP, UDP	Multiplayer game.
Quicktime	6970 to 7000	TCP, UDP	Video streaming application.
Rainbow Six	80, 2346 to 2348, 6667, 7777 to 7787, 8777 to 8787, 40000 to 42999, 44000, 45000	TCP, UDP	Multiplayer game.
RealVNC	5900	TCP, UDP	Remote desktop application.
Remote Desktop	3389	TCP, UDP	Generic remote desktop protocol.
Shiva VPN	2233	TCP, UDP	Tunneling application.
Soldier of Fortune	28910 to 28915, 20100 to 20112	TCP, UDP	Multiplayer game.
Speak Freely	2074 to 2076	UDP	VoIP application.
Starcraft	6112	TCP, UDP	Multiplayer game.
TeamSpeak	8767, 14534, 51234	TCP, UDP	Online voice chat.
Tiger Woods PGA Tour	80, 443, 9570, 13505, 20803, 20809, 32768 to 65535	TCP, UDP	Multiplayer game.
Tight VNC	5800, 5500, 5900	TCP	Remote desktop application.
Tribes	28000, 28001	TCP, UDP	Multiplayer game.
Ultima Online	5001 to 5010, 7775 to 7777, 7875, 8800 to 8900, 9999	TCP	Multiplayer game.
Unreal Tournament	7777 to 7788, 8080, 8777, 9777, 27900, 42292	TCP, UDP	Multiplayer game.
Vonage	5061, 10000 to 20000	UDP	VoIP application.
VPhone	11675	TCP, UDP	VoIP application.
Warcraft	6112 to 6119	TCP, UDP	Multiplayer game.
WebcamXP	8080, 8090	TCP	Video sharing application.
Winamp Streaming	8000 to 8001	TCP	Audio streaming application.
Wingate VPN	809	TCP, UDP	Tunneling application.
World of Warcraft	3724, 6112, 6881 to 6999	TCP	Multiplayer game.
Worms Armageddon	80, 6667, 17010 to 17012	TCP	Multiplayer game.
XBox	80, 1900, 3390, 3074, 3776, 3932, 5555, 7777	TCP, UDP	Game appliance.
Azureus	6881 to 6889	TCP, UDP	P2P file sharing application.
DC++	411, 1025 to 32000	TCP, UDP	P2P file sharing application.
Limewire	6346 to 6347	TCP, UDP	P2P file sharing application.

Understanding IPSec VPN

SA and Key Management with the IKE Protocol

The IKE protocol version 1, defined in RFC 2409, provides an automated mechanism for the exchange of keying material and secure negotiation of IPSec SAs. It is also possible to manually configure keying material and SAs on IPSec peers. Manual configuration of keying material and SAs is practical only in very small-scale environments, however, so it is not discussed further in this section.
IKE is a hybrid protocol made up of elements of the following protocols:

• Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408)
• Oakley Key Determination Protocol (RFC 2412)
• Secure Key Exchange Mechanism for the Internet (SKEME)

NOTE

Additional elements are defined in RFC 2407 ("The Internet IP Security Domain of Interpretation for ISAKMP").

IKE operates in two phases and three modes:

• Phase 1— Main or aggressive mode negotiation is used in this phase to establish a single bidirectional IKE SA between IPSec peers. This IKE SA, in turn, provides a secure means by which IPSec SAs can be established via quick mode negotiation.
• Phase 2— Quick mode negotiation occurs during this phase.

Overall ISAKMP Message Format

As previously mentioned, one element of IKE is ISAKMP, which provides (among other things) a message format for IKE negotiation.
To understand IKE negotiation, it is important to have a basic understanding of the overall structure of the ISAKMP message, which is made up of a fixed header and a number of payloads. Figure 8-7 illustrates the relationship of the header to the payloads.

 

Figure 1 Overall ISAKMP Message Format

In Figure 1, the sample message consists of a header and four payloads. Each payload is indicated in the previous payload. For example, in the header, the Next Payload field indicates that the first payload in the chain is type X1. The Next Payload field in the X1 payload indicates that the second payload is of type X2, and so on. The final payload is indicated by the fact that the Next Payload field contains a value of 0.
Table 8-1 lists the payload types, together with their associated functions.

Table 8-1. Payload Types, Values, and Functions

Value	Payload Type	Description
0	NONE	This is the final payload
1	Security Association (SA)	Contains security attributes ([sub] payload types 2 and 3)
2	Proposal (P)	Contains information used during SA negotiation
3	Transform (T)	Contains information used for SA negotiation (for example, IKE policy information)
4	Key Exchange (KE)	Used for key exchange between peers
5	Identification (ID)	Used to exchange identification information between peers
6	Certificate (CERT)	Used to send certificates or certificate-related information
7	Certificate Request (CR)	Used to request certificates
8	Hash (HASH)	Used to exchange data generated by hash function
9	Signature (SIG)	Used to exchange data generated by digital signature function (for nonrepudiation)
10	Nonce (NONCE)	Contains random data used to indicate liveliness and to protect against replay attacks
11	Notification/Notify (N)	Used to send informational data such as error conditions
12	Delete	Used to communicate SPIs of deleted SAs to peer
13	Vendor ID (VID)	Constant value to identify a vendor; can be used to implement vendor-specific features
14–127	RESERVED	Must be set to 0
128–255	Private Use	Private use
For more information on ISAKMP message structures, see RFC 2408.

IKE Phase 1

As previously mentioned, the objective of IKE phase 1 is to establish a secure IKE SA and generate keys for IPSec. To this end, IPSec peers must agree on IKE parameters, exchange keying material, and authenticate each other.
These objectives are achieved using one of the following negotiation modes:

• Main mode negotiation
• Aggressive mode negotiation

NOTE

Before Cisco IOS Software Release 12.2(8)T, Cisco routers could not initiate aggressive mode negotiation.

Main Mode Negotiation

Main mode negotiation involves the exchange of six messages between IPSec peers. The precise form of these messages is dictated by the method of peer authentication used.
The three methods of authentication that can be used with IKE (in both main and aggressive modes) are:

• Preshared keys
• Rivest, Shamir, Adleman (RSA) signatures
• RSA encrypted nonces

NOTE

Because authentication using encrypted nonces is not widely used, this section concentrates on authentication using preshared keys and RSA signatures.

Main Mode with Preshared Key Authentication

As mentioned, main mode consists of the exchange of three pairs or six messages between IPSec peers. Each of these pairs of messages serves a particular purpose.
When a router or other system (called the initiator) wants to begin IKE negotiation, it sends a message to its peer. This message contains one or more IKE policy proposals (protection suites) containing parameters such as encryption algorithm, hash algorithm, authentication method, Diffie-Hellman group, and SA lifetime. These policy proposals are contained within an SA payload and its associated Proposal and Transform payloads. IKE policy is configured on Cisco routers using the crypto isakmp policy command.
The peer router (called the responder) examines the IKE policy information and attempts to find a match with its own locally configured IKE policies. Assuming the responder finds a matching IKE policy, it responds with a message indicating acceptance of one of the initiator's policies. Again, this proposal is contained with an SA payload. The peers have now negotiated an IKE policy.
The next two messages sent between the initiator and responder serve to exchange Diffie-Hellman public values, as well as nonces (random numbers). These values are exchanged in KE and NONCE payloads, respectively (see Table 8-1).
Diffie-Hellman is a public key algorithm that allows peers to exchange public key values over an insecure network, to combine the value received with their own private value, and through the wonders of modular exponentiation, to arrive independently at the same shared secret key.
The two nonce values (initiator's and responder's), together with the preshared key, are then used to generate the first of four session key values (SKEYID).
SKEYID is used, together with the shared secret key (from the Diffie-Hellman exchange) and other keying material, to derive three other session key values called SKEYID_d, SKEYID_a, and SKEYID_e. These session key values are used to derive keys for IPSec, authenticate further ISAKMP messages, and encrypt ISAKMP messages respectively.
At this stage, an IKE policy has been agreed upon (first two messages), keying material has been exchanged (second two messages), and session key values have been calculated.
All that now remains in phase 1 is for the two peers to exchange hash and identification values, contained in HASH and ID payloads. This is done during a third exchange of messages.
The peers then authenticate each other based on the hash values received. If the received hash value is the same as a hash value calculated locally, authentication succeeds. Note that the function of the ID payload is to identify the sender using, in this case, an IP address. The third exchange in phase 1 is encrypted (using SKEYID_e).
Figure 2 illustrates IKE phase 1 using preshared keys.

Main Mode with RSA Signature Authentication Using Digital Certificates

Main mode negotiation with RSA signature (digital certificate) authentication is very similar to main mode with preshared key authentication. The first two messages are again used to negotiate an IKE policy. The second two messages are again used to exchange keying material (Diffie-Hellman public values and nonces).
The difference is the third exchange of messages. IKE peers using RSA signature authentication exchange identification, certificates, and signature. These elements are carried in the ID, CERT, and SIG payloads respectively.
Note that the SIG (signature) payload contains a digital signature. This provides nonrepudiation, which means that the system that sent the message cannot deny that it sent the message. The ID payload can contain the system's IP address, a fully qualified domain name (FQDN), or an X.500 distinguished name, for example.
Figure 3 illustrates main mode with RSA signature authentication using digital certificates.

Aggressive Mode Negotiation

Aggressive mode is faster but slightly less secure than main mode negotiation. It is faster because negotiation consists of only three messages, and it is slightly less secure because the ID payload is exchanged unencrypted.

Aggressive Mode with Preshared Key Authentication

The first message sent by the initiator in aggressive mode consists of proposed IKE policies, its Diffie-Hellman public value, a nonce value, and identification. These are contained in the SA, KE, NONCE, and ID payloads, respectively. Note that all payloads exchanged during aggressive mode perform the same function as in main mode.
The responder now replies with a message containing the accepted IKE policy, its Diffie-Hellman public value, a nonce, a hash used by the initiator to authenticate the responder, and identification. These are contained in SA, KE, HASH, and ID payloads.
Finally, the initiator sends the third and final message in the exchange. This consists simply of a hash (used by the responder to authenticate the initiator). The hash is contained in a HASH payload.
Figure 4 illustrates aggressive mode using preshared key authentication.

Aggressive Mode with RSA Signature Authentication Using Digital Certificates

Aggressive mode with RSA signature (digital certificate) authentication follows a similar pattern to that for preshared keys, with three messages being exchanged.
The first message sent by the initiator contains policy proposals, its Diffie-Hellman public value, a nonce value, and identification. These are contained in SA, KE, NONCE, and ID payloads, respectively.
The responder replies with a message containing the accepted policy, its Diffie-Hellman public value, a nonce, identification, its certificate, and signature. These are contained in SA, KE, NONCE, ID, CERT, and SIG payloads.
Finally, the initiator sends a certificate and signature. These are contained in CERT and SIG payloads.
Figure 5 illustrates aggressive mode with RSA signature authentication using digital certificates.

IKE Phase 2

Once phase 1 is complete, and the IKE SA has been established, phase 2 can begin. The objective of phase 2 is to negotiate IPSec SAs.
There is only one mode of negotiation within phase 2, called quick mode. Note that quick mode negotiation is protected by the IKE SA established in phase 1 (using SKEYID_a and SKEYID_e). Quick mode negotiation consists of the exchange of three messages between the initiator and the responder.
The first message in the exchange contains a hash, IPSec proposals, a nonce, and optionally, another Diffie-Hellman public value, and identities. These elements are contained in HASH, SA, NONCE, KE, and ID payloads, respectively.
The hash is used to authenticate the message to the responder. The IPSec proposals are used to specify security parameters, such as the security protocol (AH or ESP), encryption algorithm, hash algorithm, and IPSec tunnel mode (transport or tunnel) to be used for the IPSec SA. These parameters are configured on Cisco routers using the crypto ipsec transform-set command.
The nonce is used to protect against replay attacks. It is also used as additional keying material. The Diffie-Hellman public value is included in the message only if the initiator is configured for Perfect Forward Secrecy (PFS). Normally, keys used with IPSec SA are derived from keying material generated during IKE phase 1. This means that IPSec keys generated using PFS are more secure. PFS is configured using the set pfs {group 1 | group 2} command (within the crypto map).
Phase 2 identities are used to exchange selector information. These identities describe the addresses, protocols, and ports for which this IPSec SA is being established. On Cisco routers, phase 2 identities are configured using a crypto access list.
The responder then replies with a message containing a hash (used by the initiator to authenticate the responder), an IPSec proposal acceptance, a nonce value, and optionally, a Diffie-Hellman public value (if the responder supports PFS), and identities. These elements are again contained in HASH, SA, NONCE, KE, and ID payloads. The payloads in the message sent by the responder serve the same purpose as those sent by the initiator.
The initiator now sends a third and final message. This contains a hash (HASH payload), and it serves to acknowledge the responder's message and to prove that the initiator is alive (that is, that the first message sent by the initiator was not just a message replayed by another source).
Figure 6 illustrates quick mode negotiation.