Wireshark · Ethereal-dev: Re: [Ethereal-dev] Accessing low level protocol's info

[Hannes Gredler <hannes@xxxxxxxxxxx>]

On Wed, Aug 28, 2002 at 09:27:44PM +1000, Ronnie Sahlberg wrote:
| From: "Hannes Gredler"
| 
| 
| > | There is no general framework to allow an arbitrary dissector to get
| > | arbitrary information from arbitrary lower-level dissectors.
| >
| > bummer - i stumbled in the IS-IS dissector about this as well;
| > for example in IS-IS there is a checksum TLV (12);
| > however in order to verify the checksum
| > it needs to parse the entire packet, which would mean accessing data
| > from a higher level;
| 
| How horrible. Why on earth would one develop a protocol which has
| dependencies
| into lower layer protocols. Its bad enough that TCP and UDP do this, but
| that was a long time
| ago and people didnt know better then, but today...
| Do ethereal really need to verify that this checksum is correct?

IS-IS has got the protocol defect that only LSPs are checksummed
and IIHs [Hellos] and SNPs [link-state DB sync packets]
are no checksummed at all;
 [see the attached draft for details] - here a TLV is described
 that contains the checksum for teh entire packet;
 clearly a layering violation but it helps ;-)

/hannes



Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                                                 Bell Labs
                                                              1 Nov 1998


                       Optional Checksums in ISIS
                  <draft-ietf-isis-wg-snp-checksum-00.txt>


Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-przygienda-snp-checksum-00.txt in any standard internet drafts
   repository.  Internet Drafts are working documents of the Internet
   Engineering Task Force (IETF), its Areas, and its Working Groups.
   Note that other groups may also distribute working documents as
   Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.


Abstract
   This draft describes an optional extension to IS-IS [ISO90, Cal90a,
   Cal90b], used today by several ISPs for routing within their clouds.
   IS-IS is an interior gateway routing protocol developed originally
   by OSI and used with IP extensions as IGP. IS-IS originally doesn't
   provide CSNP adn PSNP checksums, relying on the underlying layers
   to verify the integrity of information provided.  Experience with
   the protocol shows that this precondition does not always hold and
   scenarios can be imagined that impact protocol functionality.  This
   document introduces a new optional TLV providing checksums.


1. Introduction
   IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty
   implementations of L2 hardware or lack of checksuming on a specific

   network technology.  As a particularly ugly case, corruption of





Przygienda et al.              Expires 1 May 1999               [Page 1]
^L
Internet Draft                 SNP Checksums                  1 Nov 1998


   length and/or TLV length fields may lead to generation of extensive
   numbers of "empty" LSPs in the receiving node.  Since we cannot rely
   on authentication as checksum mechanism, this document proposes an
   optional TLV to add checksums to the elements.


2. TLV Description
   The optional TLV MAY BE included in all CSNP, PSNP and IIH packets
   and an implementation that implements optional checksums MUST accept
   PDUs if they do NOT contain the optional checksum.  Implementations
   that receive optional checksum TLV and support it MUST discard the
   PDU if the checksum is incorrect.  An implementation that does NOT
   implement optional checksums MAY accept a PDU that contains the
   checksum TLV. An implementation that supports optional checksums and
   receives it within any other PDU than CSNP, PSNP or IIH MUST discard
   the PDU. Such an implementation MAY discard the PDU as well if more
   than one optional checksum TLVs are included within it.


3. Checksum Computation
   The checksum is a fletcher checksum computed according to iso 8473
   Annex C over the complete PDU.


4. Interaction with TLVs using PDU Data to Compute Signatures
   Since other TLVs could be introduced that use PDU data as input
   to a function that generates output to be included in the PDU,
   authentication being a straight-forward example thereof, it is
   important to specify the sequence at which the computation of
   different signatures takes place.  An implementation that implements
   optional checksums must generate the TLV and fill the TLV Checksum
   part with 0's.  After all other signatures have been computed, the
   checksum MUST BE filled in after all other signatures have been
   generated.  The implementation MAY choose to omit the optional
   checksum if it is aware that other signatures are included in the PDU
   that provide equivalent functionality.


5. TLV Format
                 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
                +-----------------+-----------------+
                | TLV Type = 12   |  TLV Length     |
                +-----------------+-----------------+



Przygienda et al.              Expires 1 May 1999               [Page 2]
^L
Internet Draft                 SNP Checksums                  1 Nov 1998


                |   TLV Checksum (32 bits)          |
                |                                   |
                +-----------------------------------+


6. Acknowledgments
   Tony Li mentioned the original problem.  Somehow related problems
   with purging on LSP checksum errors have been observed by others
   before.


7. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues as to the new element are known.



References
   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            Force, December 1990.

   [ISO90]  ISO.  Information Technology - Telecommunications and
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.


Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
prz@xxxxxxxxxxxxxxxxxx






Przygienda et al.              Expires 1 May 1999               [Page 3]