[bmwg] Fwd: Re: DISCUSS and COMMENT: draft-ietf-bmwg-hash-stuffing

[Al Morton <[e-mail]>]

Folks,

We've made some progress with the Hash and Stuffing Draft.
You can see a summary of the status and IESG interactions here:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12175&rfc_flag=0

A summary of changes to the draft (and some of the exchanges)
are attached below.  In addition, a version of our "standard" paragraphs
as implemented in this draft were very helpful
when resolving a DISCUSS from one of the Security ADs.
Any comments are welcome.

happy new year!

Al
bmwg co-chair

>X-VirusChecked: Checked
>X-Env-Sender: [e-mail]
>X-Msg-Ref: server-3.tower-146.messagelabs.com!1166380742!779157!1
>X-StarScan-Version: 5.5.10.7; banners=-,-,-
>X-Originating-IP: [207.181.8.130]
>X-SpamReason: No, hits=0.0 required=7.0 tests=
>X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
>         saronni.eng.networktest.com
>X-Spam-Level:
>X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
>         autolearn=ham version=3.1.0
>Date: Sun, 17 Dec 2006 10:39:03 -0800
>From: David Newman <[e-mail]>
>Organization: Network Test Inc.
>User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
>To: Brian E Carpenter <[e-mail]>
>Cc: Al Morton <[e-mail]>, [e-mail], [e-mail],
>         [e-mail]
>Subject: Re: DISCUSS and COMMENT: draft-ietf-bmwg-hash-stuffing
>X-Enigmail-Version: 0.94.1.0
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 12/12/06 7:46 AM, Brian E Carpenter wrote:
> > OK Al. If you can suggest OLD/NEW text fixes for
> > these points I'm sure we can clear my DISCUSS this week.
> >
> >     Brian
>
>Hi Brian,
>
>At Al Morton's request, we are sending these proposed fixes to
>draft-ietf-bmwg-hash-stuffing-07.txt.
>
>I've also attached a diff between draft 07 and a proposed draft 08.
>
>Section 4.2 on IEEE 802 MAC Addresses
>
>new text:
>
>    The bitwise ANDing of the high-order byte in the MAC address with
>    0xFC sets the low-order two bits of that byte to 0, guaranteeing a
>    non multicast address and a non locally administered address.  Note
>    that the resulting addresses may violate IEEE 802 standards by using
>    organizationally unique identifiers (OUIs) not assigned to the test
>    port manufacturer.  However, since these addresses will be used only
>    on isolated test networks there should be no possibility of mistaken
>    identity.
>
>
>Section 4.3 on MPLS Addresses
>
>new text:
>
>    Similar to L2 switches, multiprotocol label switching (MPLS) devices
>    make forwarding decisions based on a 20 bit MPLS label.  Unless
>    specific labels are required, it is RECOMMENDED that uniformly random
>    values between 16 and 1,048,575 be used for all labels assigned by
>    test equipment.  As per [RFC3032], this avoids using reserved MPLS
>    labels in the range of 0-15 inclusive.
>
>
>Section 4.5 on Transport-layer Addressing
>
>new text:
>
>    In addition, it may be desirable to pick pseudorandom values from a
>    selected pool of numbers.  Many services identify themselves through
>    use of reserved destination port numbers between 1 and 49151
>    inclusive.  Unless specific port numbers are required, it is
>    RECOMMENDED to pick randomly distributed destination port numbers
>    between these lower and upper boundaries.
>
>
>Informative References
>
>deleted informative references, which were bibliographic in nature
>
>
>Appendix A. Acknowledgements
>
>corrects the spelling of Dan Romascanu's name (sorry Dan!)
>
>
>Appendix C.  Explicit Calculation of Bit Stuffing Overhead for IPv4
>
>Text and figure now use addresses from 192.18.0.0/15 space assigned by
>IANA to bmwg (NOTE: Text for the entire appendix is included, but the
>only changes are minor differences in the math resulting from the
>address change):
>
>
>    Consider a scenario where a tester is transmitting IPv4 test packets
>    across a bit synchronous link.  The test traffic has the following
>    parameters (values are in decimal):
>
>            +-----------------------+---------------------------+
>            | Field                 |           Value           |
>            +-----------------------+---------------------------+
>            | IP Version            |             4             |
>            |                       |                           |
>            | IP Header Length      |             5             |
>            |                       |                           |
>            | Type of service (TOS) |             0             |
>            |                       |                           |
>            | Datagram Length       |            1028           |
>            |                       |                           |
>            | ID                    |             0             |
>            |                       |                           |
>            | Flags/Fragments       |             0             |
>            |                       |                           |
>            | Time to live (TTL)    |             64            |
>            |                       |                           |
>            | Protocol              |             17            |
>            |                       |                           |
>            | Source IP             | 192.18.13.1-192.18.13.254 |
>            |                       |                           |
>            | Destination IP        |        192.18.1.10        |
>            |                       |                           |
>            | Source UDP Port       |     pseudorandom port     |
>            |                       |                           |
>            | Destination UDP Port  |     pseudorandom port     |
>            |                       |                           |
>            | UDP Length            |            1008           |
>            |                       |                           |
>            | Payload               |  1000 pseudorandom bytes  |
>            +-----------------------+---------------------------+
>
>    We want to calculate the expected number of stuffs per packet, or
>    E[packet stuffs].
>
>    First, we observe that we have 254 different IP headers to consider,
>    and secondly, that the changing 4th octet in the IP source addresses
>    will produce occasional bit-stuffing events, so we must enumerate
>    these occurrences.  Additionally, we must take into account that the
>    3rd octet of the source IP and the first octet of the destination IP
>    will affect stuffing occurrences.
>
>    An exhaustive search shows that cycling through all 254 headers
>    produces 51 bit stuffs for the destination IP address.  This gives us
>    an expectation of 51/254 stuffs per packet due to the changing source
>    IP address.
>
>    For the IP CRC, we observe that the value will decrement as the
>    source IP is incremented.  A little calculation shows that the CRC
>    values for these headers will fall in the range of 0xE790 to 0xE88F.
>    Additionally, both the protocol and source IP address must be
>    considered, as they provide a source of extra leading and trailing
>    ones bits.
>
>    An exhaustive search shows that cycling through all 254 headers will
>    produce 102 bit stuffs for the CRC.  This gives us an expectation of
>    102/254 stuffs per packet due to the CRC.
>
>    Since our destination IP address is even and the UDP length is less
>    than 32768, the random source and destination ports provide 32 bits
>    of sequential random data without forcing us to consider the boundary
>    bits.  Additionally, we will assume that since our payload is
>    pseudorandom, our UDP CRC will be too.  The even UDP length field
>    again allows us to only consider the bits explicitly contained within
>    the CRC and data fields.  So, using the formula for the expected
>    number of stuffs in a finite string from section 5.2.2, we determine
>    that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16).  Now,
>    f(32)/2^32 is calculable without too much difficulty and is
>    approximately 0.465.  However, f(8016)/2^8016 is a little large to
>    calculate easily, so we will approximate this value by using the
>    probability value obtained in section 5.2.1.  Thus, E[UDP] ~ 0.465 +
>    8016/62 ~ 129.755.
>
>    Hence, E[packet stuffs] = 51/254 + 102/254 + 129.755 = 130.357.
>    However, since we cannot have a fractional stuff, we round down to
>    130.  Thus, we expect 130 stuffs per packet.
>
>    Finally, we can calculate bit-stuffing overhead by dividing the
>    expected number of stuff bits by the total number of bits in the IP
>    datagram.  So, this example traffic would generate 1.58% overhead.
>    If our payload had consisted exclusively of zero bits, our overhead
>    would have been 0.012%.  An all ones payload would produce 19.47%
>    overhead.
>
>
>Appendix D.  Explicit Calculation of Bit Stuffing Overhead for IPv6
>
>new text and figure use addresses from 2001:0DB8::/32 space assigned by
>IANA for documentation purposes (NOTE: Text for the entire appendix is
>included, but the only changes are minor differences in the math
>resulting from the address change):
>
>
>    Consider a scenario where a tester is transmitting IPv6 test packets
>    across a bit synchronous link.  The test traffic has the following
>    parameters (values are in decimal except for IPv6 addresses, which
>    are in hexadecimal):
>
>         +----------------------+----------------------------------+
>         | Field                |               Value              |
>         +----------------------+----------------------------------+
>         | IP Version           |                 6                |
>         |                      |                                  |
>         | Traffic Class        |                 0                |
>         |                      |                                  |
>         | Flow Label           |        pseudorandom label        |
>         |                      |                                  |
>         | Payload Length       |               1008               |
>         |                      |                                  |
>         | Next Header          |                17                |
>         |                      |                                  |
>         | Hop Limit            |                64                |
>         |                      |                                  |
>         | Source IP            | 2001:DB8:0:1::1-2001:DB8:0:1::FF |
>         |                      |                                  |
>         | Destination IP       |         2001:DB8:0:2::10         |
>         |                      |                                  |
>         | Source UDP Port      |         pseudorandom port        |
>         |                      |                                  |
>         | Destination UDP Port |         pseudorandom port        |
>         |                      |                                  |
>         | UDP Length           |               1008               |
>         |                      |                                  |
>         | Payload              |      1000 pseudorandom bytes     |
>         +----------------------+----------------------------------+
>
>    We want to calculate the expected number of stuffs per packet, or
>    E[packet stuffs].
>
>    First, we observe that we have 255 different IP headers to consider,
>    and secondly, that the changing 4th quad in the IP source addresses
>    will produce occasional bit-stuffing events, so we must enumerate
>    these occurrences.  Additionally, we also note that since the first
>    quad of the destination address has a leading zero bit, we do no have
>    to consider these adjacent bits when calculating the number of bit
>    stuffs in the source IP address.
>
>    An exhaustive search shows that cycling through all 255 headers
>    produces 20 bit stuffs for the source IP address.  This gives us an
>    expectation of 20/255 stuffs per packet due to the changing source IP
>    address.
>
>    We also have to consider our pseudorandomly generated flow label.
>    However, since our Traffic Class field is 0 and our Payload Length
>    field is less than 32768 (and thus the leading bit of the Payload
>    Length field is 0), we may consider the flow label as 20 bits of
>    random data.  Thus the expectation of a stuff in the flow label is
>    f(20)/2^20 ~ .272.
>
>    Similar to the flow label case above, the fourth quad of our
>    destination IP address is even and the UDP length field is less than
>    32768, so the random source and destination ports provide 32 bits of
>    sequential random data without forcing us to consider the boundary
>    bits.  Additionally, we will assume that since our payload is
>    pseudorandom, our UDP CRC will be too.  The even UDP length field
>    again allows us to only consider the bits explicitly contained within
>    the CRC and data fields.  So, using the formula for the expected
>    number of stuffs in a finite string from section 5.2.2, we determine
>    that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16).  Now,
>    f(32)/2^32 is calculable without too much difficulty and is
>    approximately 0.465.  However, f(8016)/2^8016 is a little large to
>    calculate easily, so we will approximate this value by using the
>    probability value obtained in section 5.2.1.  Thus, E[UDP stuffs] ~
>    0.465 + 8016/62 ~ 129.755.
>
>    Now we may explicitly calculate that E[packet stuffs] = 20/255 +
>    0.272 + 129.755 = 130.105.  However, since we cannot have a
>    fractional stuff, we round down to 130.  Thus, we expect 130 stuffs
>    per packet.
>
>    Finally, we can calculate bit-stuffing overhead by dividing the
>    expected number of stuff bits by the total number of bits in the IP
>    datagram.  So, this example traffic would generate 1.55% overhead.
>    If our payload had consisted exclusively of zero bits, our overhead
>    would have been 0.010%.  An all ones payload would produce 19.09%
>    overhead.
>
>
>If these changes are OK, we have a draft 08 ready to go. If not, please
>let us know of any further tweaks. Thanks.
>
>dn/tcp
>
>
>
> >
> > Al Morton wrote:
> >> At 08:25 AM 12/12/2006, Brian Carpenter wrote:
> >>
> >>> Discuss:
> >>> Hopefully these are easy to fix (from Gen-ART review by Joel Halpern):
> >>>
> >>> In the MPLS recommendation, it is recommended that labels be
> >>> uniformly distributed between 0 and 2^20.  Given that the labels
> >>> 0-15  are reserved for special function, and often have special
> >>> processing or discarding, it strikes me that test equipment may well
> >>> get unexpected results if it randomly attempts to use those for
> >>> normal operations.  I would recommend checking the the MPLS standards
> >>> as to the current reserved range, and making sure the random
> >>> assignment stays out of that.
> >>
> >>
> >> The reserved label range Joel refers to is described in RFC 3032
> >> http://www.rfc-editor.org/rfc/rfc3032.txt
> >> section 2.1.  I suggest to add a reference to RFC 3032, as well.
> >>
> >>
> >>> ...the IPv4 address used as samples in Appendix C are not RFC 3330
> >>> documentation values (192.0.2.0/24).  Similarly, the IPv6 example
> >>> does not use the IPv6 documentation block assigned by RFC 3849
> >>> (2001:DB8::/32)
> >>
> >>
> >> BMWG has an IPv4 address range assignment in RFC 3330:
> >>
> >>
> >>> 3. Summary Table
> >>>
> >>>    Address Block             Present Use                       Reference
> >>>    ---------------------------------------------------------------------
> >>>    0.0.0.0/8            "This" Network                 [RFC1700, page 4]
> >>>    ...
> >>>    192.168.0.0/16       Private-Use Networks                   [RFC1918]
> >>>    198.18.0.0/15        Network Interconnect
> >>>                            Device Benchmark Testing            [RFC2544]
> >>
> >>
> >> BMWG's IPv6 address space assignment request is work in progress, so the
> >> documentation addresses should suffice for now.
> >>
> >> Al
> >>
> >>
> >>
> >>> Comment:
> >>> Minor points from Gen-ART review by Joel Halpern:
> >>>
> >>>         In section 4.2, in describing how to create the MAC address,
> >>> the upper byte is anded with 0xFC to clear the global/local and
> >>> unicast/multicast bit so that the address will be a global
> >>> multicast.  there are two minor issues here:
> >>>     Using a global MAC address construct from a random number and a
> >>> port number is probably appropriate, but violates the standard.  It
> >>> would probably be a good idea to acknowledge this fact, and explain
> >>> why global (rather than local) addresses need to be used.
> >>>     The text refers to the two bits that are being controlled as the
> >>> "high order two bits of that byte."  While those are the first two
> >>> bits that will be clocked out over the ethernet, they are not the
> >>> "high order" bits in most peoples understanding of the term.
> >>
> >>
> >
>


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg