Monthly Archives: May 2016

802.1X Authentication Using EAP

Leave a reply

Extensible Authentication Protocol

one-time passwords (OTP) per RFC 2289

  • Supplicant: The 802.1X driver that supplies a username/password prompt to the user and
    sends/receives the EAPoL messages
  • Authenticator: Translates between EAPoL and RADIUS messages in both directions, and
    enables/disables ports based on the success/failure of authentication
  • Authentication server: Stores usernames/passwords and verifies that the correct values were submitted before authenticating the user
Protocol over LAN (EAPOL), CDP and STP allowed before authenticated.

 

IPv6 First Hop Security

Leave a reply

IPv6 RA Guard rejects fake RA messages coming from host (non-router) ports (not sure whether it handles all possible IPv6 header fragmentation attacks). Interestingly, it can also validate the contents of RA messages (configuration flags, list of prefixes) received through router-facing ports, potentially giving you a safeguard against an attack of fat fingers.

DHCPv6 Guard blocks DHCPv6 messages coming from unauthorized DHCPv6 servers and relays. Like IPv6 RA Guard it also validates the DHCPv6 replies coming from authorized DHCPv6 servers, potentially providing protection against DHCPv6 server misconfiguration.

IPv6 Snooping and device tracking builds a IPv6 First-Hop Security Binding Table (nicer name for ND table) by monitoring DHCPv6 and ND messages as well as regular IPv6 traffic. The binding table can be used to stop ND spoofing (in IPv4 world we’d call this feature DHCP Snooping and Dynamic ARP Inspection).

IPv6 Source Guard uses the IPv6 First-Hop Security Binding Table to drop traffic from unknown sources or bogus IPv6 addresses not in the binding table. The switch also tries to recover from lost address information, querying DHCPv6 server or using IPv6 neighbor discovery to verify the source IPv6 address after dropping the offending packet(s).

IPv6 Prefix Guard is denies illegal off-subnet traffic. It uses information gleaned from RA messages and IA_PD option of DHCPv6 replies (delegated prefixes) to build the table of valid prefixes.

Configuration:

Access-lists

CAT2(config)# ipv6 access-list ACCESS_PORT
CAT2(config-ipv6-acl)# remark Block all traffic DHCP server -> client
CAT2(config-ipv6-acl)# deny udp any eq 547 any eq 546
CAT2(config-ipv6-acl)# remark Block Router Advertisements
CAT2(config-ipv6-acl)# deny icmp any any router-advertisement
CAT2(config-ipv6-acl)# permit any any
CAT2(config-ipv6-acl)# !
CAT2(config-ipv6-acl)# interface gigabitethernet 1/0/1
CAT2(config-if)# switchport
CAT2(config-if)# ipv6 traffic-filter ACCESS_PORT in

RA Guard

Switch(config)# ipv6 nd raguard policy POLICY-NAME
! Defines the RA Guard policy name
Switch(config-ra-guard)# device-role {host | router}
Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 nd raguard attach-policy POLICY-NAME

DHCPv6 Guard

CAT1(config)# ipv6 access-list acl1
CAT1(config-ipv6-acl)# permit host FE80::A8BB:CCFF:FE01:F700 any
CAT1(config-ipv6-acl)# ipv6 prefix-list abc permit 2001:0DB8::/64 le 128
CAT1(config-ipv6-acl)# ipv6 prefix-list abc permit 2001:0DB8::/64 le 128
CAT1(config)# ipv6 dhcp guard policy pol1
CAT1(config-dhcp-guard)# device-role server
CAT1(config-dhcp-guard)# match server access-list acl1
CAT1(config-dhcp-guard)# match reply prefix-list abc
CAT1(config-dhcp-guard)# preference min 0
CAT1(config-dhcp-guard)# preference max 255
CAT1(config-dhcp-guard)# trusted-port
CAT1(config-dhcp-guard)# interface GigabitEthernet 1/0/1
CAT1(config-if)# switchport
CAT1(config-if)# ipv6 dhcp guard attach-policy pol1 vlan add 1
CAT1# show ipv6 dhcp guard policy pol1

BGP

Leave a reply

Confederations

LPref, MED and next-hop are kept across sub-AS eBGP!

network 1.0.0.0/24 backup – set distance 200

MED, Local-pref, NLRI are sent as TLVs.

When an IGP (in this example OSPF) route is redistributed in to BGP it is considered locally generated by BGP and gets assigned a weight of 32768.

Best Path Selection

AIGP – optiona notransitive 8 octet. If AIGP is configured AND the bgp bestpath aigp ignore command is not configured, the decision process considers the AIGP metric.

An AS_SET counts as 1, no matter how many ASs are in the set.

AIGP after Local Preference. AIGP metric reflects IGP cost. Lowest wins.
BGP prefers the path with the AIGP attribute by default.

 

Timers
The default BGP ConnectRetry timer is 120 seconds. Only after this time passes does the BGP process check to see if the passive TCP session is established. If the passive TCP session is not established, then the BGP process starts a new active TCP attempt to connect to the remote BGP speaker. During this idle 120 seconds of the ConnectRetry timer, the remote BGP peer can establish a BGP session to it. Presently, the Cisco IOS ConnectRetry timer cannot be changed from its default of 120 seconds.

Communities
Internet == 0:0 == match all; no such community in RFC

Redistribute & MED
— If the injected BGP route, using the network or redistribute command, is
from an IGP, the BGP MED is derived from the IGP metric.
— If the injected BGP route (using the network or redistribute command) is
from a connected route, the BGP MED is set to 0.
— If the route is injected by the aggregate-address command, MED is not set.

BGP GR
Capability 64
For IPv4, the end-of-RIB marker is a BGP Update message with no reachable NLRI and
empty withdrawn NLRI. Additional address families indicate the end-of-RIB with a BGP
Update containing only the MP_UNREACH_NLRI attribute with no withdrawn routes for
that AFI/SAFI.
Restart Time indicates how long a peer of the restarting router should maintain prefix
information received from the restarting router. The restart time should be less than the holdtime for the BGP peer.
The reception of a BGP-GR capability with no AFI/SAFI information indicates that the sending peer supports the end-of-RIB marker and can support peers that can maintain forwarding state and that want to utilize BGP-GR. The reception of a BGP-GR capability with AFI/SAFI information indicates that the sending peer wants to perform BGP-GR for the included AFI/SAFIs.
Mark all prefixes as stale.
After restart:
The receiving BGP router sends the BGP-GR capability to the restarting BGP router, with
the Restart State set to 0, unless the receiving BGP router also is reset. The receiving BGP
router receives a BGP-GR capability from the restarting BGP router with a Restart State of 1.
This triggers the receiving BGP router to send the initial routing update, followed by the
end-of-RIB marker.