locked
SoH size limiation RRS feed

  • Question


  • Hi,
    During testing of our System Health Agent we noticed that when ever the size of our SoH
    exceeds 1024 bytes, we get the following errors -

    a) On Vista, WLAN-AutoConfig service logs "Explicit Eap failure
    received" event and

    b) On XP SP3 RC2, napagent logs "A Statement of Health Request with
    correlation ID {...} - 2008-02-23 01:41:16.890Z could not include
    the following System Health-Agents in the statement of Health: %2"
    (NAP_EVENT_OVERFLOWING_SHAS) event.

    According to MSDN documentation, the maximum Network SoH Size is
    4000 bytes.

    In addition to the above limit, is there a limit on the size of
    individual SHA's SoH? Could somebody help us with this?

    Thanks,
    Bhagya Prasad
    Software Engineer,
    Avenda Systems.
    http://www.avendasys.com


    Thursday, February 28, 2008 11:16 PM

Answers

  • Hi Bhagya Prasad,

     

    Please refer to [RFC3579], section 2.4 (Fragmentation). Essentially, the SoH being transmitted in an EAP-Message within a RADIUS message has to fit within the MTU of NAS-Peer link  (or the Framed-MTU indicated by the NAS). Thus EAP protocols need to support fragmentation and reassembly by themselves to overcome this limit. In your case, the MTU seems to be around 1K.
     
    PEAP [http://msdn2.microsoft.com/en-us/library/cc209011.aspx] does implement fragmentation in phase-1 to overcome the above limitation using the same schme of [RFC2716], so that certificate chains whose size is longer than MTU can be transmitted in multiple fragments. However, PEAP currently does not support fragmentation and reassembly of SoH; this will be addressed in future.
     
    If it is a switch configuration, please try to change the Framed-MTU configuration (usual value for Ethernet: 1500 bytes). If you have negotiated MTU between the peer and the NAS, try to change the corresponding configuration.
     
    Since SoH is ultimately delivered to the AAA server (NPS) over RADIUS, RADIUS (and EAP over RADIUS) limitations apply. The overall SoH (from all SHAs) thus cannot be larger than 4K (and in PEAP case, MTU limitation would apply). Individual SoHs have to fit within this size.

     

    Note that the 4KB limit is from a RADIUS perspective: RADIUS attribute overhead means the maximum payload of an EAP-Message contained SoH would be around 3900 bytes, without counting any other RADIUS attributes. However, there are usually other necessary RADIUS attributes such as User-Name (variable size), Message-Authenticator, etc., which will bring down the maximum limit to say, around 3800 bytes. This is not taking MTU limit on EAP-Messages into consideration.

    So, in practice, MTU is the restriction on the SoH size for PEAP. Inreasing MTU or using a compression scheme are two possibilities to work within the current PEAP restrictions.

     

    Thanks,

    Sreenivas

    Tuesday, March 4, 2008 6:48 PM

All replies

  • I can answer b) for you.

     

    While the maximum individual SHA SoH size limit is set to 4000 bytes, the maximum total SoH request size is also set to 4000 bytes.  This maximum total SoH request size includes all SHA SoHs and the system soh from NAP Agent.  By default, Windows SHA runs on your client, which gives us about 100 bytes for its SHA SoH.  You're getting the error NAP_EVENT_OVERFLOWING because very likely your client runs other SHAs as well.  And when you put all the SHA SoHs together, you have a total size of > 4000 bytes.

     

    Hope this helps your investigation.

     

     

    Friday, February 29, 2008 9:08 AM
  • ( Transitioned to use a new account )

    Friday, February 29, 2008 9:19 AM
  • Thanks for the response. I can confirm that we are not running more than 2 SHAs on the client [Window SHA + our SHA ].  Considering Windows SHA sends about 100 bytes, when our SHA sends data appx close to 1000 bytes we see the above problem.  So adding  up all the SoHs from 2 SHAs including System SoH I am sure it is not crossing 4000 bytes. 

    If we reduce the SoH data sent from our SHA to appx 700-800 bytes we dont hit the problem.  Looks like we are missing something on the hard limit.  Are there any tools which we can use on the NapAgent side to debug this in detail?

    thanks
    Bhagya Prasad
    Friday, February 29, 2008 7:30 PM
  • Hi Bhagya Prasad,

     

    Please refer to [RFC3579], section 2.4 (Fragmentation). Essentially, the SoH being transmitted in an EAP-Message within a RADIUS message has to fit within the MTU of NAS-Peer link  (or the Framed-MTU indicated by the NAS). Thus EAP protocols need to support fragmentation and reassembly by themselves to overcome this limit. In your case, the MTU seems to be around 1K.
     
    PEAP [http://msdn2.microsoft.com/en-us/library/cc209011.aspx] does implement fragmentation in phase-1 to overcome the above limitation using the same schme of [RFC2716], so that certificate chains whose size is longer than MTU can be transmitted in multiple fragments. However, PEAP currently does not support fragmentation and reassembly of SoH; this will be addressed in future.
     
    If it is a switch configuration, please try to change the Framed-MTU configuration (usual value for Ethernet: 1500 bytes). If you have negotiated MTU between the peer and the NAS, try to change the corresponding configuration.
     
    Since SoH is ultimately delivered to the AAA server (NPS) over RADIUS, RADIUS (and EAP over RADIUS) limitations apply. The overall SoH (from all SHAs) thus cannot be larger than 4K (and in PEAP case, MTU limitation would apply). Individual SoHs have to fit within this size.

     

    Note that the 4KB limit is from a RADIUS perspective: RADIUS attribute overhead means the maximum payload of an EAP-Message contained SoH would be around 3900 bytes, without counting any other RADIUS attributes. However, there are usually other necessary RADIUS attributes such as User-Name (variable size), Message-Authenticator, etc., which will bring down the maximum limit to say, around 3800 bytes. This is not taking MTU limit on EAP-Messages into consideration.

    So, in practice, MTU is the restriction on the SoH size for PEAP. Inreasing MTU or using a compression scheme are two possibilities to work within the current PEAP restrictions.

     

    Thanks,

    Sreenivas

    Tuesday, March 4, 2008 6:48 PM
  • Hi Sreenivas,
    Thanks for the response. This explains the behavior we are seeing in our application.
    -Bhagya Prasad.
    Wednesday, March 5, 2008 1:55 AM