locked
802.1x switch must support "tunnel attributes to specify a client VLAN" ? RRS feed

  • Question

  •  

    As document [802.1X_StepByStep.doc],

    "The 802.1x compliant switch used in this test lab must support the use of RADIUS tunnel attributes to specify a client VLAN"

     

    Question 1)

    I don't know whether my switch can support RADIUS tunnel attribute or not. how can I know this on my L2 switch.

    Actually, 802.1x is implemented in my switch. but I don't know the "RADIUS tunnel attribute".  In case of this(802.1x support case), Is it possible to not support  RADIUS tunnel attribute ?

     

    Question 2)

    If my switch could not support RADIUS tunnel attribute, how could I test this document ?

    must buy new one?

     

    Question3)

    if I were L2 switch developer and my L2 switch could not support RADIUS tunnel attribute, what do I develop for tunnel attribute on my L2 switch?

     

    Question 4)

    If RADIUS tunnel attribute is neccessary for NAP, what is the internal action of RADIUS tunnel attribute and L2 switch VLAN?

     

    Is there any website or reference for this ?

     

     

    Monday, June 18, 2007 10:04 AM

Answers

  • The Tunnel- attributes are used by the NPS to instruct the switch to place the client onto a specified vLAN.  If the switch supports some other attribute set that allows the same functionality, then those could be used instead.

     

    A1)

    Yes, it is possible for a switch to not support these standardized attributes, but to instead use some other set to accomplish similar functionality.  To find out whether your switch supports these attributes or some other attributes for doing the same thing, you'd need to consult your switch manufacturer's documentation or support center.

     

    A2)

    No, not if it can use some other attribute(s) to accomplish the same functionality, you would not have to buy a new one.  See A1.

     

    A3)

    Again, see A1.  Support for this specific attribute set is not 100% required; some switch vendors choose to use these attributes for this functionality, other vendors use other attributes.

     

    A4)

    Again, the internal functionality will depend on the switch maker.  The majority of the ones I've worked with use this attribute set to assign a port to a vLAN, but some don't.  Some use other attributes to accomplish the same behavior.

     

     

    -Chris

    Chris.Edson@online.microsoft.com *

    SDET, Network Access Protection

    * Remove the "online" make the address valid.

    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, June 18, 2007 4:40 PM
  • Hi, here are some answers to your recent questions.

     

    Q: Who moves client2 from compliant VLAN to noncompliant VLAN.

    A: The switch does this based on the RADIUS attributes that are sent by NPS. You might say that NPS is "in charge" of specifying the VLAN, but the switch is responsible for actually moving the client port to a different VLAN.

     

    Q: What is the algorithm?

    A: First, the connection attempt is authenticated. If the user is allowed to connect, the "health" of the client is evaluated next in NPS network policy. "Health" is a condition that you set in network policy by selecting a health policy that the client must match. The step by step guide has two possible choices for health policies: one that is compliant and one that is noncompliant. Compliant and noncompliant are determined by the settings in the system health validator. In this case, we have said that to be compliant, the client must have enabled Windows Firewall. Therefore, if the Windows Firewall is on, the client will match the compliant health state. This causes the client to match conditions in the compliant network policy and therefore the compliant "settings" are applied. These settings include RADIUS attributes that are sent to the switch to tell it which VLAN ID should be associated with the port that the client machine authenticated to with 802.1X. You could also send other RADIUS attributes to do different things, such as a Filter-ID attribute that tells the switch to use an access control list that you have provisioned on the switch.

     

    Q: Can L2 switch handle these attributes (Tunnel-Medium-Type, Tunnel-Type, Tunnel-Pvt-Group-ID)? What about other attributes?

    A: As Chris indicated, you should consult your vendor documentation or support center to determine whether or not your switch supports the same attributes used in the step by step guide. There may be another set of attributes that can be used, but this depends entirely on your switch. The attributes described in the step by step guide are common attributes used to specify the client VLAN ID. Note that there is another vendor specific attribute that is used as well - this is Tunnel-Tag. This is a special value that helps to group all attributes used in the policy together. Not all switches require Tunnel-Tag, but it can help to prevent errors understanding the attributes that were sent.

     

    Q: L2 switch must automatically change VLANs with an attribute, correct?

    A: There are two ways a switch can do things "automatically" - one is using RADIUS input and one is without any input from RADIUS. Manipulating VLANs without RADIUS input isn't required for NAP, but it can help. For example, NPS does not specify a VLAN for clients that fail to authenticate, but your switch might do this for you. If your switch does not have a method to automatically deal with clients that fail 802.1X authentication, they may simply end up on a blocked port. Because the switch doesn't recognize "heath" of a client computer, it needs NPS to evaluate this. NPS can send back attributes to the switch based on this evaluation, and the switch may then "automatically" apply properties to the switch port, such as a VLAN or an access list.

     

    I hope this helps.

     

    -Greg

    Tuesday, June 19, 2007 6:17 PM
  • The way I think of it, as far as the switch config and the relationship between it and NPS, is quite simple. You configure a bunch of VLANs on the switch. You set them up exactly how you want them, defining a bunch of IP ACLs, route tables, filter lists, etc. NPS really only tells the switch, based on the configured policy and comparing it with the health state of the client, which VLAN to send a particular port to. While we can pass a number of attributes back to the switch, we really aren't sending any config, but telling the switch which config to apply to a port. Make sense?

    NAP the WORLD in 2007,

    Jeff Sigman
    NAP Release Manager
    Jeff.Sigman@online.microsoft.com *
    http://blogs.technet.com/nap
    *Remove the "online" to actually email me.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 21, 2007 2:52 PM

All replies

  • The Tunnel- attributes are used by the NPS to instruct the switch to place the client onto a specified vLAN.  If the switch supports some other attribute set that allows the same functionality, then those could be used instead.

     

    A1)

    Yes, it is possible for a switch to not support these standardized attributes, but to instead use some other set to accomplish similar functionality.  To find out whether your switch supports these attributes or some other attributes for doing the same thing, you'd need to consult your switch manufacturer's documentation or support center.

     

    A2)

    No, not if it can use some other attribute(s) to accomplish the same functionality, you would not have to buy a new one.  See A1.

     

    A3)

    Again, see A1.  Support for this specific attribute set is not 100% required; some switch vendors choose to use these attributes for this functionality, other vendors use other attributes.

     

    A4)

    Again, the internal functionality will depend on the switch maker.  The majority of the ones I've worked with use this attribute set to assign a port to a vLAN, but some don't.  Some use other attributes to accomplish the same behavior.

     

     

    -Chris

    Chris.Edson@online.microsoft.com *

    SDET, Network Access Protection

    * Remove the "online" make the address valid.

    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, June 18, 2007 4:40 PM
  •  

    As document "802.1X_StepByStep.doc", part [Demonstrate CLIENT1 to CLIENT2 connectivity ]

    "When the firewall is turned off on CLIENT2, Windows Security Health Agent will specify a new health state for the computer that matches the noncompliant network policy on NPS1. As a result, CLIENT2 will be moved to the noncompliant VLAN. "

     

    Actually My Question is "Who" move Client2 from compliant VLAN to no compliant VLAN.

    Does L2 switch have to move Client 2 ?? or Does Client 2 Change the vlan by itself ?

     

    Question 1) "Who" is in charge of this "move" ????

     

    Question2 ) if L2 switch is in charge of this "move", How can move Client2 to the noncompliant ???? what is the "move" algorithm ???

     

    Question3)  As this document, Tunnel-Medium-Type, Tunnel-Type , Tunnel-Pvt-Group-ID, are used. If this attributes are important , I think, L2 switch could handle this attribute. Is it right?  If not what is other attribute?

     

     

      Question4) I read below post

    "

    It's not a matter of 'includes' or 'has a' relationships.

    A switch supports a certain set of functionality.

    If it has enough functionality support, it can support NAP.

    That minimum bar is:

    must support 802.1x EAP authentication pass-thru to a RADIUS server (NPS, in this case)
    and one of the following:

    must support assignment of port vLAN based on attributes passed back by the RADIUS server (NPS, in this case)
    or

    some other method of isolation (port ACLs, port filters) based on attributes passed back by the RADIUS server (again, NPS)
     

    In addition, some switch functionality can make roll-out easier.

    The ability for the switch to assign a vLAN (or filters, etc) to a client that fails authentication.  (Helps deal with some guest scenarios)
    The ability for the switch to assign a vLAN (or filters, etc) to a client that is unable to do 802.1x/EAP.  (Helps deal with some guest cases, or cases where clients do not support 802.1x)
     

    1. must support 802.1x EAP authentication pass-thru to a RADIUS server (NPS, in this case)

     -> Yes It's working

    2.must support assignment of port vLAN based on attributes passed back by the RADIUS server (NPS, in this case)

    -> some L2 switch cannot suport assignment for port vlan automatically based on attribute of RADIUS. In case of this L2 switch "must" implement automatically change based on "RADIUS" is it right ?

    L2 switch can support port based VLAN. but not change automatically.

    3.some other method of isolation (port ACLs, port filters) based on attributes passed back by the RADIUS server (again, NPS)

    -> Yes It's working . base on 802.1 auth, port could enable or disable

    4.The ability for the switch to assign a vLAN (or filters, etc) to a client that fails authentication.  (Helps deal with some guest scenarios)

    -> switch can assign a vLan , but not chang automatically

    5.The ability for the switch to assign a vLAN (or filters, etc) to a client that is unable to do 802.1x/EAP.  (Helps deal with some guest cases, or cases where clients do not support 802.1x)

    -> same, switch can assign a vlan, but not change automatically

     

    based on all of this question, L2 switch must be implemented "automatically change vlan by some attribute " Is that right ???




     

     

    Monday, June 18, 2007 11:52 PM
  • Hi, here are some answers to your recent questions.

     

    Q: Who moves client2 from compliant VLAN to noncompliant VLAN.

    A: The switch does this based on the RADIUS attributes that are sent by NPS. You might say that NPS is "in charge" of specifying the VLAN, but the switch is responsible for actually moving the client port to a different VLAN.

     

    Q: What is the algorithm?

    A: First, the connection attempt is authenticated. If the user is allowed to connect, the "health" of the client is evaluated next in NPS network policy. "Health" is a condition that you set in network policy by selecting a health policy that the client must match. The step by step guide has two possible choices for health policies: one that is compliant and one that is noncompliant. Compliant and noncompliant are determined by the settings in the system health validator. In this case, we have said that to be compliant, the client must have enabled Windows Firewall. Therefore, if the Windows Firewall is on, the client will match the compliant health state. This causes the client to match conditions in the compliant network policy and therefore the compliant "settings" are applied. These settings include RADIUS attributes that are sent to the switch to tell it which VLAN ID should be associated with the port that the client machine authenticated to with 802.1X. You could also send other RADIUS attributes to do different things, such as a Filter-ID attribute that tells the switch to use an access control list that you have provisioned on the switch.

     

    Q: Can L2 switch handle these attributes (Tunnel-Medium-Type, Tunnel-Type, Tunnel-Pvt-Group-ID)? What about other attributes?

    A: As Chris indicated, you should consult your vendor documentation or support center to determine whether or not your switch supports the same attributes used in the step by step guide. There may be another set of attributes that can be used, but this depends entirely on your switch. The attributes described in the step by step guide are common attributes used to specify the client VLAN ID. Note that there is another vendor specific attribute that is used as well - this is Tunnel-Tag. This is a special value that helps to group all attributes used in the policy together. Not all switches require Tunnel-Tag, but it can help to prevent errors understanding the attributes that were sent.

     

    Q: L2 switch must automatically change VLANs with an attribute, correct?

    A: There are two ways a switch can do things "automatically" - one is using RADIUS input and one is without any input from RADIUS. Manipulating VLANs without RADIUS input isn't required for NAP, but it can help. For example, NPS does not specify a VLAN for clients that fail to authenticate, but your switch might do this for you. If your switch does not have a method to automatically deal with clients that fail 802.1X authentication, they may simply end up on a blocked port. Because the switch doesn't recognize "heath" of a client computer, it needs NPS to evaluate this. NPS can send back attributes to the switch based on this evaluation, and the switch may then "automatically" apply properties to the switch port, such as a VLAN or an access list.

     

    I hope this helps.

     

    -Greg

    Tuesday, June 19, 2007 6:17 PM
  •  

    thank you for your answer.

     

    Q1)"they may simply end up on a blocked port " :

     Depends on 802.1x authentication. L2 switch port could be disabled/ enabled

     if then, test(step by step document) is possible?

     

    Q2)NPS can send back attributes to the switch based on this evaluation

    I wondering underline part."automatically apply"

     "the switch may then "automatically" apply properties to the switch port, such as a VLAN or an access list."

     

     Is there any standard or specification of "automatically apply properties" on L2 switch ?

     if there isn't any standard , how can you are confirmed that all L2 switch may "automatically apply properties" ? 

     

     our switch only works port enable/disable depends on 802.1x authentication.

     port based vlan support, and ACL support.

     but switch support center engineer does not know about any attribute or any properties.

     

     so my question is about "internal L2 switch algorithm with NPS attribute"

     if switch get that attribute, how can use that information?  

     

      if (attribute == not success )

     Change VLAN port?

     

     or

     

     if (attribute == special value)

     disable port ?

     

     how ????

    Thursday, June 21, 2007 11:32 AM
  • The way I think of it, as far as the switch config and the relationship between it and NPS, is quite simple. You configure a bunch of VLANs on the switch. You set them up exactly how you want them, defining a bunch of IP ACLs, route tables, filter lists, etc. NPS really only tells the switch, based on the configured policy and comparing it with the health state of the client, which VLAN to send a particular port to. While we can pass a number of attributes back to the switch, we really aren't sending any config, but telling the switch which config to apply to a port. Make sense?

    NAP the WORLD in 2007,

    Jeff Sigman
    NAP Release Manager
    Jeff.Sigman@online.microsoft.com *
    http://blogs.technet.com/nap
    *Remove the "online" to actually email me.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 21, 2007 2:52 PM
  • Hi,

     

    You must enable 802.1X on the switch port in order to use NAP with 802.1X enforcement. However, you could still do another enforcement method, such as DHCP.

     

    The attributes that I am referring to are discussed in RFC 2868: http://www.ietf.org/rfc/rfc2868.txt

    The RFC may help you to understand what these attributes are, but it doesn't discuss how they work with switches. This is usually found in the switch documentation. What model of switch are you using?

     

    -Greg

     

    P.S. I just saw Jeff's answer above. He brings up a good point that these attributes use a configuration that is already available on your switch. If you don't have "VLAN X" configured on the switch, then the attribute will be unable to move a port to this VLAN.

    Thursday, June 21, 2007 3:00 PM