Subject: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 13:34:39 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-dots-data-channel-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4.3

The processing requirements for the tcp flags bitmask is not at all clear.
Specifically how should an implementation use the values in the flags, operator
and the bitmask fields in the tcp subtree to figure out if a given packet
matches. An example here could be very helpful.

"Bitmask values can be encoded as a 1- or 2-byte bitmask."

How? The bitmask field is a uint16. How would a client indicate a 1 byte
bitmask?

[Also note that there are *nine* flags defined for TCP including the
experimental NS bit that occurs as bit 7 of Octet 12 and a 1 byte bitmask will
not catch them all]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

How does the flags field in the ipv4 match subtree interact with the bits in
the fragment side? I can easily see that someone can make a mistake due to this
redundancy and come up with something that is not coherent. e.g. bit "more"
under flags is set and bit "lf" under fragment-> type is also set .

---

From: <[email-masked]>
Date: Thu, 2 May 2019 06:09:13 +0000

Hi Suresh, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 1 mai 2019 22:35
> À : The IESG
> Cc : [email-masked]; Roman Danyliw; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Suresh Krishnan's Discuss on draft-ietf-dots-data-channel-28: (with
> DISCUSS and COMMENT)
> 

[Med] The behavior is identical to the one used in BGP Flowspec (RFC5575). 

> How? The bitmask field is a uint16. How would a client indicate a 1 byte

[Med] A match on values less than 2^8 means implicitly that the match will be on the 13 byte of the TCP header; otherwise this is done on the 12/13 bytes (with data offset being ignored).

We could use a more "explicit" encoding such as the following: 

     |              |     |     +--rw flags-bitmask
     |              |     |     |  +--rw operator?                  operator
     |              |     |     |  +--rw (bitmask)?
     |              |     |     |     +--:(bitmask-one-byte)
     |              |     |     |     |  +--rw bitmask-one-byte?    uint8
     |              |     |     |     +--:(bitmask-two-bytes)
     |              |     |     |        +--rw bitmask-two-bytes?   uint16

> experimental NS bit that occurs as bit 7 of Octet 12 and a 1 byte bitmask

[Med] Indeed, but we wanted to allow for the same functionality as in BGP Flowspec. We could provid draft-ietf-tcpm-rfc793bis as a pointer to the current flags, but that document is not stable.

[Med] This is part of the trivial validation checks. Please note that this is not specific to these two nodes but to other cases such as:
* indicate a protocol at l3 set to 17, but include a tcp l4 container.