IM/P2P Status and Information

Hello, and thank you for participating in the Astaro 7.200 beta program!

In this thread, I will provide you with up-to-date information and status reports about the new

Instant Messaging / Peer-to-Peer sub-system
AKA "Astaro Flow Classifier (AFC)"

of the Astaro Security Gateway. There's quite a lot of text here, so maybe get some snacks first.

To ensure the best possible user experience in the final 7.200 release, this article will also provide suggestions on how to test this new functionality, as well as provide helpful instructions on reporting your results. The latter is especially important, because it ensures that we get enough information to fix any issues that you uncover.

[FONT="Arial Black"][SIZE="4"]IM/P2P: Changes between 7.191 and 7.192 (RC1)[/SIZE][/FONT]

• [FIX] If a protocol was configured to be blocked, but its category (e.g. IM or P2P) status set to "disabled", it would still be blocked when the protocol's traffic selector was used in an active QoS bandwidth pool.
  
• [FIX] When actively blocking Skype, certain HTTPS sites using SSL 3.0 would be blocked as well.
  
• [FIX] Under extreme conditions only, a library used by the classification daemon would exhaust all its available stack memory, causing it to crash.
  
• [FIX] It turned out that IM/P2P QoS interfered with "regular" QoS. This is no longer the case.
  
• [FIX] Other issues with QoS, which affected IM/P2P classification as well, have been found and fixed.
  
• [MISC] Support for detecting and blocking encrypted Bittorrent sessions has been greatly improved.
  
• [MISC] Further modifications have been made to improve the classification engine's chance to detect proxied IM/P2P traffic.
  
• [MISC] The "AFC" acronym has been removed from several places, as it turned out to be a constant cause of confusion. We'll just call it "IM/P2P classifier" from now on.
  
• [MISC] Changes to speed up the classification of large HTTP transfers have been made.
  
• [MISC] Support for the P2P protocols FastTrack, Soulseek, WinMX and XDCC has been removed from 7.200. Those protocols will come back in one of the next Up2Dates, but not the 7.200 GA release.
  

[FONT="Arial Black"][SIZE="4"]IM/P2P: Changes between 7.190 and 7.191[/SIZE][/FONT]

• [FIX] Remote desktop sessions (RDP) are no longer mis-detected as Winny.
  
• [FIX] Configuration changes no longer cause "forgetfulness" with regard to existing, previously detected IM/P2P connections.
  
• [FIX] An issue causing the afcd process to "spin" and use up 100% CPU has been fixed.
  
• [MISC] Various means to improve overall performance have been implemented.
  
• [NEW] The "Block file-transfer" feature is fully supported again.
  
• [NEW] Winnyp support.
  

[FONT="Arial Black"][SIZE="4"]IM/P2P: Changes between 7.185 and 7.190[/SIZE][/FONT]

• [FIX] Fix the futex() deadlock issue, for real now.
  
• [FIX] Do not send notices about OSPFd being restarted when it should have been about afcd.
  
• [FIX] Improved AFC Livelog viewer.
  

[FONT="Arial Black"][SIZE="4"]IM/P2P: Changes between 7.180 and 7.185[/SIZE][/FONT]

(Removed, to allow this post to remain within UBB limits.)

[FONT="Arial Black"][SIZE="4"]Testing[/SIZE][/FONT]

Here are some ideas on things to test:

[LIST=1]

• Get an overview:
  
  
  
  • Enable detection of all IM/P2P protocols in "Log" mode.
    
  • Check the IM/P2P inline report after 30 minutes to see which protocols are actively used on your network.
    
  
  
• Block IM/P2P applications:
  
  
  
• Enable detection of all IM/P2P protocols in "Block completely" mode.
  
• Expected result: None of the blocked IM/P2P clients started after the configuration change should be able to either establish a connection or function properly in some way.
  

• Look for false positives:
  
  
  
  • Enable logging or blocking for all protocols that are known to not exist on your network.
    
  • Expected results:
    
    
    
    • No IM/P2P policy violations should be detected.
      
    • No innocuous and permitted traffic (HTTP, HTTPS, DNS, NTP, ...) should be adversely affected by any blocking.
      
    
    
  
  
• Test IM/P2P exceptions:
  
  
  
• Configure two or more IM/P2P protocols that should be blocked.
  
• Configure an exception for a single host within the controlled network. Permit it to use one of the blocked IM/P2P protocols.
  
• Expected results:
  
  
  
  • IM/P2P traffic of regular hosts within the controlled network is still being blocked.
    
  • The client with the exception is able to use one of the blocked protocols (the one configured in the exception), but not the others.
    
  
  

• Test IM/P2P Quality of Service:
  Caveat: Only traffic included in the "IM/P2P >> Settings >> Controlled Networks" setting will be classified, which affects QoS for IM/P2P protocols. The same applies to the "Control skip-list".
  
  
  
  • Limit IM/P2P bandwidth:
    
    
    
    • Determine, which supported IM/P2P protocol requires an unacceptable amount of traffic on your network.
      
    • Configure a Bandwidth Pool using the appropriate "AFC" protocol's traffic selector, with a restrictive limit.
      
    • Expected result: IM/P2P clients using the restricted protocol should not be able to use significantly more bandwidth than configured.
      
    
    
  • Guarantee IM/P2P bandwidth:
    
    
    
  • Determine a supported IM/P2P protocol that has suffered from too little bandwidth in the past.
    
  • Configure a Bandwidth Pool using the "AFC" protocol's traffic selector that guarantees enough bandwidth.
    
  • Expected result: Usability of the IM/P2P clients using the protocol should improve noticeably.
    
  
  

[/LIST]

[FONT="Arial Black"][SIZE="4"]Reporting[/SIZE][/FONT]

Please continue to create new UBB threads for new issues, and don't report them in here. However, feel free to post generic questions about the Astaro Flow Classifier here.

When reporting an issue with the new IM/P2P sub-system, these three items are vital for us to reproduce and fix the problem:

[LIST=1]

• What version of the ASG beta release (or later on, which 7.2xx release) are you running?
  
• What IM/P2P client are you having issues with? Please include:
  
  
  
• Client name.
  
• Client version.
  
• Information about any non-standard configuration settings you use in the client.
  

•  How is your ASG configured? Only some configuration settings are relevant:
  
  
  
  • Proxy configuration (SOCKS and/or HTTP proxy.)
    
  • Packet filter rules that concern the IM/P2P client. For example, in the case of Skype, this might be all rules! Other, less "aggressive" clients may only be affected by rules about their application-specific ports.
    
  • Anything else you deem potentially relevant.
    
  
  [/LIST]
  
  Note that we really do read all of your report, even (and especially) if it is very verbose. Actually, a good problem report can never be too verbose!
  
  [FONT="Arial Black"][SIZE="4"]Glossary[/SIZE][/FONT]
  
  detection quality
  

  With something like the Astaro Flow Classifier, there are two main "qualities" when it comes to protocol detection:
  

  
  
  • There is no detection at all, hence there's nothing that can be called "quality."
    
  • Detection.
    At least one packet of every connection initiated by an IM/P2P client was discovered, which allows reliable logging.
    
  • Blocking.
    Enough (i.e. all) packets of every connection initiated by an IM/P2P client could be discovered, do effectively block (or render non-functional) the client. This quality is also a prerequisite for effective traffic shaping / QoS.
    
  
  
  
  
  false negative
  

  A false negative is when a protocol could not be detected properly. These are usually easy to detect by the user. For example, if you know that you are running client X and enabled logging or blocking of client X, but neither logging or blocking occurred, this is a false negative.
  

  
  
  false positive
  

  This is when an IM/P2P protocol was detected in packets that are NOT from any IM/P2P client. Unfortunately, these problems are often hard to detect, and even harder to debug. In the worst case, innocuous traffic, like HTTPS or even DNS, is mis-detected as a protocol that has been configured to be blocked.
  Validating a false positive as "real" and narrowing down the cause is often tied to time consuming research. Also, one should not underestimate a client's ability to use different IM/P2P protocols, seemingly causing a "false false positive".