Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3803] New: Support for HIP RR (RFC 5205)

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3803

           Summary: Support for HIP RR (RFC 5205)
           Product: Wireshark
           Version: 1.2.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: ivan_jr@xxxxxxxxx



Ivan Sy <ivan_jr@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3454|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=3454)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3454)
HIP DNS RR RFC5202 patch

Build Information:
wireshark 1.2.1

Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.16.1, with GLib 2.20.1, with libpcap 1.0.0, with libz
1.2.3, without POSIX capabilities, with libpcre 7.8, with SMI 0.4.7, without
c-ares, with ADNS, without Lua, with GnuTLS 2.6.4, with Gcrypt 1.4.4, without
Kerberos, with GeoIP, with PortAudio <= V18, without AirPcap.

Running on FreeBSD 7.2-RELEASE-p1, with libpcap version 1.0.0, GnuTLS 2.6.4,
Gcrypt 1.4.4.

Built using gcc 4.2.1 20070719  [FreeBSD].
--
Host Identity Protocol (HIP) Domain Name System (DNS) Extension

Note: The rendezvous servers are chopped using a while loop, to make it more
readable.

instead of "rvn.foo.com rvn.bar.com"

Rendezvous Server: rvn.foo.com
Rendezvous Server: rvn.bar.com

please see attached patch and packet-capture
fuzz done.

---------

To wireshark devs:

- would it be okay if I do some code basic clean-up and cosmetics improvements
to the DNS dissector?

- is there a function that can read/decode a base64 encoded data from a tvb and
that can be added to the tree as a text/string?

Thanks!

---------

5. HIP RR Storage Format


   The RDATA for a HIP RR consists of a public key algorithm type, the
   HIT length, a HIT, a public key, and optionally one or more
   rendezvous server(s).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  HIT length   | PK algorithm  |          PK length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           HIT                                 ~
   |                                                               |
   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     |                                         |
   +-+-+-+-+-+-+-+-+-+-+-+                                         +
   |                           Public Key                          |
   ~                                                               ~
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                       Rendezvous Servers                      ~
   |                                                               |
   +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             |
   +-+-+-+-+-+-+-+

   The HIT length, PK algorithm, PK length, HIT, and Public Key fields
   are REQUIRED.  The Rendezvous Servers field is OPTIONAL.

5.1. HIT Length Format


   The HIT length indicates the length in bytes of the HIT field.  This
   is an 8-bit unsigned integer.

5.2. PK Algorithm Format


   The PK algorithm field indicates the public key cryptographic
   algorithm and the implied public key field format.  This is an 8-bit
   unsigned integer.  This document reuses the values defined for the
   'algorithm type' of the IPSECKEY RR [RFC4025].

   Presently defined values are listed in Section 9 for reference.

5.3. PK Length Format


   The PK length indicates the length in bytes of the Public key field.
   This is a 16-bit unsigned integer in network byte order.

5.4. HIT Format


   The HIT is stored as a binary value in network byte order.

5.5. Public Key Format


   Both of the public key types defined in this document (RSA and DSA)
   reuse the public key formats defined for the IPSECKEY RR [RFC4025].

   The DSA key format is defined in RFC 2536 [RFC2536].

   The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
   size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
   specification.

5.6. Rendezvous Servers Format


   The Rendezvous Servers field indicates one or more variable length
   wire-encoded domain names of rendezvous server(s), as described in
   Section 3.3 of RFC 1035 [RFC1035].  The wire-encoded format is self-
   describing, so the length is implicit.  The domain names MUST NOT be
   compressed.  The rendezvous server(s) are listed in order of
   preference (i.e., first rendezvous server(s) are preferred), defining
   an implicit order amongst rendezvous servers of a single RR.  When
   multiple HIP RRs are present at the same owner name, this implicit
   order of rendezvous servers within an RR MUST NOT be used to infer a
   preference order between rendezvous servers stored in different RRs.

6. HIP RR Presentation Format


   This section specifies the representation of the HIP RR in a zone
   master file.

   The HIT length field is not represented, as it is implicitly known
   thanks to the HIT field representation.

   The PK algorithm field is represented as unsigned integers.

   The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
   hex or hexadecimal) of the HIT.  The encoding MUST NOT contain
   whitespaces to distinguish it from the public key field.

   The Public Key field is represented as the Base64 encoding [RFC4648]
   of the public key.  The encoding MUST NOT contain whitespace(s) to
   distinguish it from the Rendezvous Servers field.

   The PK length field is not represented, as it is implicitly known
   thanks to the Public key field representation containing no
   whitespaces.

   The Rendezvous Servers field is represented by one or more domain
   name(s) separated by whitespace(s).

   The complete representation of the HPIHI record is:

   IN  HIP   ( pk-algorithm
               base16-encoded-hit
               base64-encoded-public-key
               rendezvous-server[1]
                       ...
               rendezvous-server[n] )

   When no RVSs are present, the representation of the HPIHI record is:

   IN  HIP   ( pk-algorithm
               base16-encoded-hit
               base64-encoded-public-key )


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.