<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Normalization Engine Signatures in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762915#M85824</link>
    <description>&lt;P&gt;When the IDSM-2 is in-line does it always perform IP/TCP normalization functions on all traffic (modify/drop/fragment re-assembly) even if I disable all of the normalization signatures?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Thomas&lt;/P&gt;</description>
    <pubDate>Sun, 10 Mar 2019 10:46:26 GMT</pubDate>
    <dc:creator>t.clark</dc:creator>
    <dc:date>2019-03-10T10:46:26Z</dc:date>
    <item>
      <title>Normalization Engine Signatures</title>
      <link>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762915#M85824</link>
      <description>&lt;P&gt;When the IDSM-2 is in-line does it always perform IP/TCP normalization functions on all traffic (modify/drop/fragment re-assembly) even if I disable all of the normalization signatures?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Thomas&lt;/P&gt;</description>
      <pubDate>Sun, 10 Mar 2019 10:46:26 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762915#M85824</guid>
      <dc:creator>t.clark</dc:creator>
      <dc:date>2019-03-10T10:46:26Z</dc:date>
    </item>
    <item>
      <title>Re: Normalization Engine Signatures</title>
      <link>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762916#M85826</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;You can configure the sensor to reassemble a datagram that has been fragmented over multiple packets. You can specify boundaries that the sensor uses to determine how many datagram fragments it reassembles and how long to wait for more fragments of a datagram. The goal is to ensure that the sensor does not allocate all its resources to datagrams that cannot be completely reassembled, either because the sensor missed some frame transmissions or because an attack has been launched that is based on generating random fragmented datagrams. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 05 Sep 2007 13:28:41 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762916#M85826</guid>
      <dc:creator>umedryk</dc:creator>
      <dc:date>2007-09-05T13:28:41Z</dc:date>
    </item>
    <item>
      <title>Re: Normalization Engine Signatures</title>
      <link>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762917#M85829</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks very much for your time, Ursula. &lt;/P&gt;&lt;P&gt;Do you know if the IDSM performs fragment reassembly and tcp normalization even if the signatures in the Normalizer Engine are disabled? In the IDM GUI under Signature Definition &amp;gt; Miscellaneous are "Fragment Reassembly" and "Stream Reassembly." Are these actions enabled at all times? Is there a way to disable those features?&lt;/P&gt;&lt;P&gt;I had put the IDSM-2 in-line and quite a number of users (not all) were unable to connect to our HTTPS websites. As soon as I moved the IDSM-2 back to promiscuous mode all of the affected users were able to connect again. I suspected that the normalization actions of the IDSM-2 were the culprit and I want to put the put the unit back in-line so I can at least have the benefit of in-line blocking/dropping.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 05 Sep 2007 14:01:44 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/normalization-engine-signatures/m-p/762917#M85829</guid>
      <dc:creator>t.clark</dc:creator>
      <dc:date>2007-09-05T14:01:44Z</dc:date>
    </item>
  </channel>
</rss>

