Wireshark-bugs: [Wireshark-bugs] [Bug 9690] DHCPv6 Packet dissector incorrectly handling FQDN in

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sun, 26 Jan 2014 17:20:36 +0000

changed bug 9690

What Removed Added
Status IN_PROGRESS INCOMPLETE

Comment # 5 on bug 9690 from 
OK: 

After some research I've come up with the following comments and questions
(based only on what I've read and not on any experience):
(Can you provide additional insight ?

1. 17.2170.n (PKT_CCC_...)  suboption DHCPV6 dissection

   Looking at CL-SP-CANN-DHCP-Reg-I10-130808[1] Paragraph 5.4.1:

   Suboptions 17.2170.1 and 17.2170.2 are the *only* ones described
   (Previous versions of this document are similar).

   So: should the code in packet-dhcpv6.c which claims to handle
       suboptions 17.2170.3 thru 17.2170.9 be removed ?
       that is: the code for PKT_CCC_IETF_PROV_SRV thru PKT_CCC_IETF_SEC_TKT ?

       If so, then we do not need to decide if that code is valid.
       (The dissection of the PKT_CCC_KRB_REALM FQDN certainly does
       seem wrong).

2. 17.2171.6 (PKT_CCCV6_KRB_REALM) suboption DHCPV6 dissection

      The real reason why dissection fails for "BASIC.1" is that the
      name validation done specifically for this
      sub-option considers numbers to be invalid. (The encoding *is* handled
      properly).

      (The message 
       "Expert Info (Warn/Protocol): Invalid at byte=6" is a bit confusing: 
       The "byte=6" actually means the 7th character in the string with the
       first character being at byte=0.
       I will improve the message).


       I don't know why various punctuation characters are allowed (*not*
       including '-') and not numbers.

       My understanding of valid characters for a FQDN would be:
       A thru Z, a thru z, 0 thru 9 and -

       Is this something about how a kerberos realm name can also
       be X.500 & etc ?

       As an aside, the DHCPV4 CableLabs KERBEROS_REALM suboption is
       dissected as a normal FQDN; the name is not validated.

       I also note that the FQDN dissected for option
       17.2171.3 (PKT_CCCV6_IETF_PROV_SRV) is not checked for
       valid characters.

So: Should the following be done ?

1. Remove code for dissecting 17.2170.3 thru 17.2170.9.

2. Allow '0'- '9', '-', (and 'a' - 'z' ?) when validating the 17.2171.6
   PKT_CCCV6_KRB_REALM  (or: just remove validation ?)



[1]  
http://www.cablelabs.com/wp-content/uploads/specdocs/CL-SP-CANN-DHCP-Reg-I10-130808.pdf

You are receiving this mail because:
  • You are watching all bug changes.