Loading...

Follow Katherine R McNamara - Networking fun Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

In this post, I’m going to be posting my deep-dive notes on ISE device profiling as well as what each probe does and what type of information to expect from the attributes.

CDP

Example of a CDP entry seen from a switch

CDP TLV Descriptions:

  • Address - Contains a list of device network-layer addresses. If a device uses Simple Network Management Protocol (SNMP), the first address is an address at which the device receives SNMP messages. The device may advertise all its addresses and may optionally advertise one or more loopback IP addresses.

  • Capabilities - Identifies the device type. The device type indicates the functional capability of the device, for example, a switch.

  • Device-ID - Name of the device

  • Platform - Describes the hardware platform of the device.

  • Version - Contains information about the software image version the device is running.

Enable CDP on the Switch
cdp run
!
interface g1/0/1
cdp enable


IOS Device Sensor for CDP
device-sensor filter-list cdp list TLV-CDP
tlv name device-name
tlv name address-type
tlv name capabilities-type
tlv name version-type
tlv name platform-type
device-sensor filter-spec cdp include list TLV-CDP
device-sensor accounting
device-sensor notify all-changes


Examples from ISE:

cdpCacheAddress: 254.128.0.0.0.0.0.0.178.170.119.255.254.151.119.92

cdpCacheCapabilities: T;B;I

cdpCacheDeviceId AP1

cdpCachePlatform: cisco AIR-AP3702I-UXK9

cdpCacheVersion: Cisco IOS Software, C3700 Software (AP3G2-K9W8-M), Version 15.3(3)JA12, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2017 by Cisco Systems, Inc. Compiled Fri 20-Oct-17 20:51 by prod_rel_team


cdpCacheAddress: 10.1.30.101

cdpCacheCapabilities: R;T;B;I

cdpCacheDeviceId: AP1

cdpCachePlatform: cisco AIR-CAP3602I-A-K9

cdpCacheVersion: Cisco IOS Software, C3600 Software (AP3G2-K9W8-M), Version 15.3(3)JD17, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2019 by Cisco Systems, Inc. Compiled Fri 12-Apr-19 03:21 by prod_rel_team


cdpCacheAddress: 10.1.100.109

cdpCacheCapabilities: H;P;M

cdpCacheDeviceId: SEP001A2F69DBEE

cdpCachePlatform: Cisco IP Phone 7961

cdpCacheVersion: SCCP41.9-4-2SR1-1S

cdpUndefined28: 00:02:00



LLDP

Example of an LLDP entry seen from a switch

ONE IMPORTANT NOTE: LLDP is turned off by default on most Cisco switches. Enable it globally using the lldp run command and then on the interfaces using lldp receive and lldp transmit commands. Unlike CDP, LLDP is an open standard and many IoT devices use it so I would recommend enabling this on your switches.

LLDP TLVs Descriptions:

  • Capabilities - Endpoints determine the types of capabilities that a connected device supports and which ones are enabled. 

  • Chassis ID - The Chassis ID is a mandatory TLV which identifies the chassis component

  • of the endpoint identifier associated with the transmitting LLDP agent. Usually I see this field being populated by either a MAC address or IP address

  • ManAddress - The Management Address is a mandatory TLV which identifies a network address associated with the local LLDP agent, which can be used to reach the agent on the port identified in the Port ID TLV.

  • Port Description - Provides a description of the port id in an alpha-numeric format. The value equals the ifDescr object

  • Port ID - The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the transmitting LLDP agent.

  • System Capabilities - Indicates the primary function(s) of the device and whether or not these functions are enabled in the device. The capabilities are indicated by two octects. Bits 0 through 7 indicate Other, Repeater, Bridge, WLAN AP, Router, Telephone, DOCSIS cable device and Station respectively. Bits 8 through 15 are reserved.

  • System Description - Provides a description of the network entity in an alpha-numeric format. This includes system's name and versions of hardware, operating system and networking software supported in the device. The value equals the sysDescr object, if the LAN device supports RFC 3418.

  • System Name - Provides the system's assigned name in an alpha-numeric format. The value equals the sysName object

  • Time To Live - Indicates how long (in seconds) the LAN device's information received in the LLDPDU is to be treated as valid information.

Enable LLDP on Switch
lldp run
!
interface g1/1/1
lldp receive
lldp transmit


IOS Device Sensor for LLDP
device-sensor filter-list lldp list TLV-LLDP
 tlv name port-id
 tlv name time-to-live
 tlv name port-description
 tlv name system-name
 tlv name system-description
 tlv name system-capabilities
 tlv name management-address
tlv name chassis-id
tlv name time-to-live
device-sensor filter-spec lldp include list TLV-LLDP
device-sensor accounting
device-sensor notify all-changes


Examples from ISE:

lldpCacheCapabilities: B

lldpCapabilitiesMapSupported: B

lldpChassisId: 04:b0:aa:77:b9:34:90

lldpPortDescription: GigabitEthernet0

lldpPortId: 05:47:69:30

lldpSystemName: AP1


lldpCacheCapabilities: B

lldpCapabilitiesMapSupported: B

lldpChassisId: 04:54:78:1a:65:ca:60

lldpManAddress: 05:01:0a:01:1e:65:03:00:00:00:00:00

lldpPortDescription: GigabitEthernet0

lldpPortId: 05:47:69:30

lldpSystemName: AP1.securitydemo.net


lldpCacheCapabilities: B;T

lldpCapabilitiesMapSupported: B;T

lldpChassisId: 05:01:00:00:00:00

lldpPortDescription: SW PORT

lldpPortId: 07:30:30:31:41:32:46:36:39:44:42:45:45:3a:50:31

lldpSystemDescription: Cisco IP Phone 7961G,V1, SCCP41.9-4-2SR1-1S

lldpSystemName: SEP001A2F69DBEE


DHCP

DHCP Option Descriptions:

  • boot-file – Option 67 - Bootfile name - This option is used to identify a bootfile when the 'file' field in the DHCP header has been used for DHCP options.

  • class-identifier – Option 60 - This option is used by DHCP clients to optionally identify the type and configuration of a DHCP client.  The information is a string of n octets, interpreted by servers.  Vendors and sites may choose to define specific class identifiers to convey particular configuration or other identification information about a client.  For example, the identifier may encode the client's hardware configuration.  Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported).

  • client-fqdn – Option 81 - To update the IP-address-to-FQDN mapping, a DHCP server needs to know the FQDN of the client to which the server leases the address.  To allow the client to convey its FQDN to the server, this document defines a new DHCP option, called "Client FQDN".  The Client FQDN option also contains Flags, which DHCP servers can use to convey information about DNS updates to clients, and two deprecated RCODEs. Clients MAY send the Client FQDN option, setting appropriate Flags values, in both their DHCPDISCOVER and DHCPREQUEST messages.  If a client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change.

  • client-identifier – Option 61 - This option is used by DHCP clients to specify their unique identifier.  DHCP servers use this value to index their database of address bindings.  This value is expected to be unique for all clients in an administrative domain. It is expected that this field will typically contain a hardware type and hardware address, but this is not required.  Current legal values for hardware types are defined in https://tools.ietf.org/html/rfc1340

  • domain-name – Option 15 - This option specifies the domain name that client should use when resolving hostnames via the Domain Name System.

  • host-name – Option 12 - Hostname for the client – using RFC 1035 character set

  • parameter-request-list – Option 55 - This option is used by a DHCP client to request values for specified configuration parameters.  The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document. The client MAY list the options in order of preference.  The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client.

  • pxe-client-arch – Option 93 - Octet "n" gives the number of octets containing "architecture types" (not including the code and len fields).  It MUST be an even number greater than zero.  Clients that support more than one architecture type MAY include a list of these types in their initial DHCP and PXE boot server packets.  The list of supported architecture types MAY be reduced in any packet exchange between the client and server(s). Octets "n1" and "n2" encode a 16-bit architecture type identifier that describes the pre-boot runtime environment(s) of the client machine.

  • pxe-client-machine-id – Option 97 - Octet "t" describes the type of the machine identifier in the remaining octets in this option. 0 (zero) is the only value defined  for this octet at the present time, and it describes the remaining octets as a 16-octet Globally Unique Identifier (GUID).  Octet "n" is 17 for type 0. 

  • pxe-client-network-id – Option 94 - Octet "t" encodes a network interface type.  For now the only supported value is 1 for Universal Network Device Interface (UNDI). Octets "M" and "m" describe the interface revision.  To encode the UNDI revision of 2.11, "M" would be set to 2, and "m" would be set to 11 (0x0B).

  • requested-address – Option 50 - This option is used in a client request (DHCPDISCOVER) to allow the client to request that a particular IP address be assigned

  • server-identifier – Option 54 - This option is used in DHCPOFFER and DHCPREQUEST messages, and may optionally be included in the DHCPACK and DHCPNAK messages.  DHCP servers include this option in the DHCPOFFER in order to allow the client to distinguish between lease offers.  DHCP clients indicate which of several lease offers is being accepted by including this option in a DHCPREQUEST message. The identifier is the IP address of the selected server.

  • user-class-id – Option 77 - DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about its user's preferences.  For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department.

  • vendor-class – Option 60 - A DHCP client may use this option to unambiguously identify the vendor that manufactured the hardware on which the client is running, the software in use, or an industry consortium to which the vendor belongs.  The information contained in the per-vendor data area of this option is contained in one or more opaque fields that may identify details of the hardware configuration.

IOS Device Sensor for DHCP
device-sensor filter-list dhcp list dhcp-list
option name boot-file        
option name class-identifier                                          
option name client-fqdn                              
option name client-identifier                        
option name domain-name                              
option name host-name                                
option name parameter-request-list                   
option name pxe-client-arch                          
option name pxe-client-machine-id                    
option name pxe-client-network-id                    
option name requested-address                        
option name server-identifier                        
option name user-class-id                            
option name v-i-vendor-class        
device-sensor filter-spec dhcp  include list dhcp-list
device-sensor accounting
device-sensor notify all-changes


DHCP Helper Instead of IOS Device Sensor
interface vlan 100
ip helper-address 10.1.100.21


Examples from ISE:

dhcp-class-identifier: Cisco AP c3600

dhcp-client-identifier: 01:6c:20:56:52:7e:b6

dhcp-parameter-request-list: 1, 6, 15, 44, 3, 7, 33, 150, 43

 

dhcp-class-identifier: Cisco AP c3600

dhcp-client-identifier: 01:6c:20:56:52:7e:b6

dhcp-parameter-request-list: 1, 6, 15, 44, 3, 7, 33, 150, 43

 

dhcp-class-identifier: Cisco Systems, Inc. IP Phone CP-7961G

dhcp-client-identifier: 01:00:1a:2f:69:db:ee

dhcp-message-type: DHCPREQUEST

dhcp-parameter-request-list: 1, 66, 6, 3, 15, 150, 35

dhcp-requested-address: 10.1.100.109


SNMP

The SNMP Trap notifies ISE of a linkup/linkdown which let’s ISE know that it should run an SNMP Query. However, the SNMP Trap may not be needed if RADIUS is configured since the RADIUS session will also trigger the SNMP Query.

Options available for SNMP in ISE’s profiler:

  • cafSessionAuthorizedBy - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the name of the feature which authorizes the authentication session.

  • cafSessionAuthUserName - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the name of the authenticated user for the authentication session.

  • cafSessionAuthVlan - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the authorized VLAN applied to the authentication session. Value zero indicates that no authorized VLAN has been applied, or it is not applicable.

  • cafSessionClientMacAddress - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the MAC address of the device associates with the authentication session.

  • cafSessionDomain - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the type of domain that the authentication session belongs to. othe: none of the below. data: indicates the data domain. voice: indicates the voice domain. 1-other, 2-data, 3-voice

  • cafSessionStatus - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the current status of the authentication session. 1-idle, 2-running, 3-noMethod, 4-authenticationSuccess, 5-authenticationFailed, 6-authorizationSuccess, 7-authorizationFailed

  • cLApIfMacAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the Ethernet MAC address of the AP.

  • cLApName - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the administrative name assigned to the AP by the user. If an AP is not configured, its factory default name will be ap: eg. ap:af:12:be.

  • cLApNameServerAddress - Part of the CISCO-LWAPP-AP-MIB Module - This represents the IP Address of the name server. This attribute can be configured only if the static IP option is turned on in the AP.

  • cLApNameServerAddressType - Part of the CISCO-LWAPP-AP-MIB Module - This represents the type of the IP address of the name server, made available through cLApNameServerAddress.

  • cLApSshEnable - Part of the CISCO-LWAPP-AP-MIB Module - This object specifies whether SSH session can be established to the AP.

  • cLApSysMacAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the radio MAC address common to the dot11 interfaces of the AP and uniquely identifies an entry in this table.

  • cLApTelnetEnable - Part of the CISCO-LWAPP-AP-MIB Module - This object specifies whether Telnet session can be established to the AP.

  • cLApTertiaryControllerAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the address of the tertiary controller that the APs will join.

  • cLApTertiaryControllerAddressType - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the type of the tertiary controller's address made available through cLApTertiaryControllerAddress.

  • cLApUpTime - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the time in hundredths of a second since the last time the..

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we're going to talk about Trustsec design, brownfield considerations, and how to scale Trustsec.

The document I referenced in this video: https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/trustsec/software-system-bulletin.pdf

1.58 -Trustsec: Design, Scale, and Brownfield Considerations - YouTube
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’ll be going over the configuration of Security Group ACLs and the Trustsec matrix. After we configure it, I’ll show you how it’s pushed down to the network access devices and enforce them.

1.57 - Trustsec: Configuring the Trustsec Matrix and SGACLs - YouTube

CONFIGURATION COMMANDS
cts role-based enforcement
cts role-based enforcement vlan-list <vlan-numbers>

USEFUL SHOW COMMANDS
show cts role-based sgt-map all 
show cts role-based permissions 

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’re going to walk through the configuration of SGT Exchange Protocol (SXP). We’ll first configure it between two switches that are separated by a non-Trustsec-capable device and then we’ll configure it between the switches and ISE.

1.56 - Trustsec Configuring SXP - YouTube


SWITCH CONFIGURATION
cts sxp enable
cts sxp default source-ip <local-source-IP-address>
cts sxp default password <password>
cts sxp connection peer <SXP-Peer-IP> password default mode local both 

or

cts sxp connection peer <SXP-Peer-IP> password default mode local both vrf <vrf-name>
Optional:
cts sxp log binding-changes

USEFUL SHOW COMMANDS
show cts sxp connection 
show cts sxp connection brief
show cts sxp sgt-map brief
show cts role-based sgt-map all
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’re going to configure our Trustsec domain between a couple switches and enforce Network Device Admission Control (NDAC)

1.55 - Configuring Network Device Admission Control NDAC - YouTube


Notes from this video:

  • Trustsec Domains

    • There’s an establishment of trust within this domain between network access devices

    • SGTs and SGACLs are downloaded to network devices from a trusted source

    • Using NDAC, network devices are authenticated and authorized into a Trustsec domain

    • By authenticating links, it extends that trust for the SGT inline propagation

  • So where does ISE come into this picture?

    • ISE is the central point of SGT definition, distribution, and provides dynamic classification

    • It’s the central repository for SGT-based egress policies & pushes the policy from ISE in the form of SGACLs

    • It’s the authentication server for endpoints and network device admission into a Trustsec domain

  • How does NDAC work?

    • It uses 802.1x port-based authentication and EAP-FAST to authenticate to the network and receive it’s PAC (protected access credential)

    • Some devices (like switches) support EAP-FAST while others (like ASA) don’t and you’ll have to manually download and provision those PACs

  • How does RADIUS EAP-FAST work?

    • The network device requests a PAC and the PAC is pushed to the network device from the RADIUS server (ISE)

    • Using that PAC, the network device builds a secure TLS tunnel to ISE

    • The network device is then authenticated to ISE

    • (Optionally) You may configure your Trustsec domain to perform layer 2 encryption and that’s negotiated during NDAC for 802.1AE encryption


CONFIGURATIONS SEED device CONFIGURATION
aaa new-model

radius server ise
address ipv4 10.1.100.21 auth-port 1812 acct-port 1813
pac key 0 ISEc0ld

aaa group server radius ise-group
 server name ise

aaa server radius dynamic-author
 client 10.1.100.21 server-key ISEc0ld
auth-type any

aaa authentication dot1x default group ise-group
aaa authorization exec vty local 
aaa authorization configuration default group ise-group
aaa authorization network default group ise-group 
aaa accounting dot1x default start-stop group ise-group
aaa accounting system default start-stop group ise-group
aaa accounting update newinfo periodic 2440
aaa authorization network cts-list group ise-group

dot1x system-auth-control

cts authorization list cts-list

ip device tracking probe auto-source override
ip device tracking probe delay 10
ip radius source-interface Vlan100

access-session template monitor
access-session acl default passthrough
epm logging
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail
radius-server dead-criteria time 5 tries 3
radius-server deadtime 30
cts credentials id Sw01 password ISEc0ld
cts logging verbose
NON-SEED DEVICE CONFIGURATION
cts credentials id Sw021 password ISEc0ld
cts logging verbose
aaa new-model
aaa authentication dot1x default group radius 
aaa authorization network cts-list group radius
aaa accounting dot1x default start-stop group radius
cts authorization list cts-list
radius-server vsa send authentication 
radius-server vsa send accounting 
aaa server radius dynamic-author
client 10.1.100.21 server-key ISEc0ld
auth-type any
dot1x system-auth-control


Uplink interface configuration on both switches
interface g1/0/x
switchport mode trunk
cts dot1x
sap mode-list no-encap
propagate sgt
no shut


useful show commands
show cts server-list
show cts interface gig1/0/x
show cts environment-data
show cts pac
show cts credentials
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’re going to dig into Trustsec a little bit further by discussing some of the different IP-to-SGT bindings are done, how to configure various static bindings, how the network access device prioritizes different SGT binding types and why SXP is so important.

1.54- Digging into SGT Bindings, priority, and SXP - YouTube

Notes from this video:

  • Different SGT Classification Options:

    • Dynamic – Usually assigned at the time of the connection by ISE as part of the authorization policy

      • Best type of SGT assignment

      • Important: Make sure that IP device tracking is turned on the switch

      • ISE uses cisco-av-pair=cts:security-group-tag to deliver the tag with RADIUS

      • To view the bindings, you can use the show cts role-based sgt-map all command for more details

    • Static – Usually done for servers, topology-based policy, or brownfield sites that you haven’t converted over to use ISE for AAA yet. Best to use with hosts that aren’t changing IP addresses regularly.

      • Static tags can be assigned by:

        • IP address

        • Subnet

        • VLAN

        • Layer 2 interface

        • Layer 3 interface

        • Any of the above in their own separate VRFs

        • Statically defined in ISE and pushed out via SXP

  • How are bindings done?

    • VLAN – Snooped ARP packets on a VLAN that has the static sgt mapping configured

      • Command: cts role-based sgt-map vlan vlan-number sgt sgt-number

    • IP address – Static configuration from the command line

      • Command: cts role-based sgt-map ip-address sgt sgt-number

    • Subnet – Can define a whole subnet for static assignment

      • Command: cts role-base sgt-map subnet/mask sgt sgt-number

    • Layer 3 interface – Bindings added due to FIB entries that have a path through that interface

      • Command:
        interface g1/0/1
        cts role-based sgt-map sgt
        sgt-number

    • Layer 2 interface – This can be statically configured with the following command

      • Command:
        interface g1/0/1
        sgt manual
        policy static sgt
        sgt-number

    • SXP – Bindings are learned through SXP peers

    • IP_ARP – Bindings learned through tagging ARP packets received on a CTS capable link

    • LOCAL – This is for dynamic SGT assignment. Bindings of authenticated hosts are learned via IP device tracking. This type of binding includes hosts that are learned via ARP snooping on Layer 3 ports

  • What happens if a device is configured with conflicting static & dynamic mappings for an endpoint? What tag does it get then?

    • There is a SGT Classification Binding Source Priority - Order of operations:

      • Internal – Between locally configured IP address and the network device’s own SGT

      • Local – Authenticated hosts learned via EPM and device tracking. Also includes hosts learned via ARP snooping on layer 2

      • IP_ARP – Bindings learned when tagging ARP packets are received

      • SXP – Bindings from an SXP peer

      • Layer 3 interface – Bindings added from the FIB

      • Static IP address or subnet bindings configured in the CLI

      • VLAN bindings learned from snooped ARP packets when a VLAN sgt mapping has been configured

  • SGT Propagation:

    • Inline propagation:

      • Tagging done in hardware

      • Requires Trustsec-capable device

      • Tag continues to be passed along to the next device in the network path

      • When the packet gets to the enforcement point, that enforcement point compares the tag to the SG policy and makes decision on what to do with it

      • One thing to note: Trustsec goes against how we used to do ACL where we blocked closest to the source instead of the destination.

      • Since it’s using unused layer 2 space, it really doesn’t affect the frame size greatly – at most ~40 bytes. Since it’s only layer 2, it doesn’t require changing the IP MTU for layer 3 devices.

      • If a switch or device in the path doesn’t understand SGTs, they’ll drop the frame unless you strip the SGT first

      • So how do we enable our SGTs to work over pockets of non-Trustsec-capable devices or a layer 3 boundary? SXP!

    • SXP

      • Control plane protocol – passes IP to SGT map of authenticated hosts to different points in the network

      • TCP 64999 by default

      • Two roles with SXP:

        • Speaker (the initiator)

        • Listener (the receiver)

      • Some switches can do both roles

      • ISE can also communicate as a speaker and listener

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This is going to be the start of a small series on Trustsec. We’re going to go over some of the common terminology and components of Trustsec and give an overview of why we would use SGTs.

1.53 - Overview of Trustsec and Terminology - YouTube

Notes from the video:

  • What is Cisco Trustsec?

    • Short answer: Initially defined as as architecture comprising of several components but most of the time, people thing of Security Group Tags (SGTs) when they think of Trustsec

    • Long Answer: Several components including -

      • Centralized policy management, distributed policy enforcement and microsegmentation using Security Group Tags (SGTs)

      • Confidentiality and integrity using encryption based on IEEE 802.1AE (AES-GCM 128-bit)

        • Wire-rate hop-by-hop layer 2 encryption

        • Key management is based on 802.1n

      • Authenticated networking environment

        • Endpoints are authenticated via 802.1x, Easyconnect, MAB, WebAuth, etc

        • Network devices are authenticated and admitted into the Trustsec environment via 802.1x which creates a trusted networking environment

  • Terminology:

    • Security Group - Used for grouping users, endpoints, and resources that should have a similar access control policy

    • Security Group Tag (SGT) - Unique security group number that’s assigned to the security group

    • Trustsec-Capable Device - Network access device that’s capable hardware- and software-wise of understanding security group tags

    • Trustsec Seed Device - Network access device that authenticates directly against ISE and acts as both the authenticator and supplicant for other network access devices

    • Network Device Admission Control (NDAC) - In a Trustsec cloud, network devices are verified with credentials by the peer device:

      • 802.1x

      • EAP-FAST

      • Upon authentication and authorization, network devices negotiate for IEEE 802.1AE encryption

    • Protected Access Credential (PAC) - Unique shared credential used to mutually authenticate client and server

    • Endpoint Authentication Control - Devices authenticated to the Trustsec cloud via 802.1x, Easyconnect, MAB, Webauth, etc

    • Security Group Access Control List (SGACL) - Used for access and permissions based on SGTs, not IP addresses or subnets. Simplifies the security policy.

    • Security Exchange Protocol (SXP) - A service that’s used to propagate IP-to-SGT bindings across network devices that don’t support SGTs. Think of it like BGP propagating routes across a provider’s MPLS.

    • Environment Data Download - Download from ISE to the Network Access Device when it joins the trusted network. When it does this, it downloads the following:

      • ISE RADIUS server list it can use for future RADIUS authentications and authorizations

      • Device SGT - SGT for the network access device itself

      • Expiry Timeout - How often the network access device should download or refresh the environment data

    • Identity to port mapping - Switch defining the identity on a port and using this identity to look up a particular SGT value from ISE

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we're going to walk through the FTD Advanced Troubleshooting menu. If you've worked with ASA or ASDM in the past, some of the tools on this screen will be familiar to you.

1.52 - FTD Advanced Troubleshooting Menu - YouTube
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’re going to walk through the configuring of FQDN ACLs on Firepower 6.3. This was a feature that was just added in this latest release. The goal of this configuration is the block source or destination based on FQDN. In this case, I’m blocking a single host FQDN from accessing another host (my proxy) based on it’s FQDN.

1.51 - Configuring FQDN ACLs on Firepower 6 3 - YouTube
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this video, we’ll be exploring FTD device copy, backup and restore. Device copy is used to easily copy configurations and policies from a pre-configured device to a completely different device while device copy copies the configurations, logs, events, etc and restore them to the same device.

1.50 - Copying, Backing Up, and Restoring FTD Device Configuration - YouTube

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview