Technical Alerts

Unexpected Restart due to IPv6 URL

Technical Alerts ID:    TFA64
Version:    1.0
Status:    Published
Published date:    05/19/2011
 

Affected products and versions

All SGOS versions prior to 5.4.6.1,  5.5.4.1, 6.1.4.

Problem description

It is possible that a ProxySG  enabled for ICAP processing could restart spontaneously when encountering and attempting to process Literal Address IPv6 URLs.

This issue is a result of an error in parsing the bracketed format of the hostname part of an IPv6 URL.

The bracketed syntax is a valid syntax as stated in RFC: 2732.  In the section of the RFC entitled “Format for Literal IPv6 Addresses in URLs”, it is specified that “To use a literal IPv6 address in a URL, the literal address should be enclosed in "[" and "]" characters. 

This results in URLs with a format of http[s]://[host name or host ip]/path

When encountering this URL type and trying to access the file for ICAP transmission, the ProxySG will restart. The signature of the crash dump file (mini-context, context, or full) will be something of the following nature.

PF in HTTP SW BF1E5EC0 for BFB2BEC0" in "ce_admin.dll"

You can look at the crash dump signature in your sysinfo file, by looking at the URL https://<proxy name> or <proxy_ip>:8082/sysinfo.  Search for “Minicontext”.

It may not be immediately obvious that the data stream contains such a URL, since it is likely  served from a server within an HTML response. This also makes it difficult to locate the offending URL except via a packet trace or core dump analysis.

Increased use of IPv6 and of embedding literal IPV6 URLs in web pages will make this issue more likely to occur over time.

Status

Fixed in 5.4.6.1 and higher 5.4 versions.

Fixed in 5.5.4.1 and higher 5.5 versions.

Fixed in 6.1.4 and higher versions.

Workaround

Disabling ICAP will avoid the situation. This is seldom a viable alternative.

Disabling ICAP for the destination (if known) will avoid the problem, but also may not be viable.

If the destination is known, then a force deny on the destination in a Web Access Layer will avoid the ICAP process. Again, for the same reason as above, this may or may not be viable.

If there is a common part of in the returned URL, then a sub string match may work for a while. At least until the path name changes or another pathnames emerges.

Attempting to match on the brackets in policy will not work.

Resolution

 Upgrade to a  version that includes the fix.


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question