Re: [tcpm] AccECN field order

[Yoshifumi Nishida <[e-mail]>]

On Fri, Feb 12, 2021 at 3:05 PM Bob Briscoe <[e-mail]> wrote:

> Yoshi,
>
> On 12/02/2021 17:49, Yoshifumi Nishida wrote:
>
>
> On Thu, Feb 11, 2021 at 1:33 PM Bob Briscoe <[e-mail]> wrote:
>
>>
>>
>> On 09/02/2021 17:56, Scharf, Michael wrote:
>> > Bob,
>> >
>> >> -----Original Message-----
>> >> From: Bob Briscoe <[e-mail]>
>> >> Sent: Tuesday, February 9, 2021 5:58 PM
>> >> To: Scheffenegger, Richard <[e-mail]>; Mirja
>> >> Kuehlewind <[e-mail]>; Scharf, Michael <Michael.Scharf@hs-
>> >> esslingen.de>
>> >> Cc: tcpm IETF list <[e-mail]>
>> >> Subject: Re: AW: [tcpm] AccECN field order
>> >>
>> >> Richard,
>> >>
>> >> I just noticed I missed the last para of the old email from you below.
>> >> Response inline, tagged [BB]...
>> >>
>> >> On 23/11/2020 12:42, Scheffenegger, Richard wrote:
>> >>> I am also in favor of using two distinct option codes.
>> >>>
>> >>> However,
>> >>>
>> >>>> Or I guess we could say that only one option should be used for a
>> >> connection.
>> >>> I am opposed to this - with two option codes, a sender should be free
>> to
>> >> choose whichever he prevers at any one point; For example, if the
>> sender a
>> >> segment (e.g. may be the receiver side)  has to update the EE1 couter,
>> but
>> >> also convey SACK information, it would be good to use the one, where
>> the
>> >> EE1 field is first, and omit all remaining fields;
>> >>> Later in the same connection, that very same host may choose to update
>> >> the CE field together with some SACK information, and use the other
>> >> codepoint in order to preserve as much TCP option space for the SACK
>> >> option...
>> >>
>> >> [BB] I agree with you here (and disagree with Mirja below). The nice
>> >> thing about 2 options kinds is they are self-describing, so they can be
>> >> stateless (for instance, consider the code you would have to otherwise
>> >> add for when a host switches to a different congestion control module -
>> >> a lot of complexity despite being unlikely to happen).
>> >>
>> >>>
>> >>> As for extensibility: I would want to avoid that topic, and just
>> specifiy the
>> >> three correct supported lengths here, and not mention (other than
>> ignoring
>> >> "odd" fractionals of the 3-byte wide counters) what happens with other
>> >> lengths...
>> >>
>> >> [BB] A protocol spec should surely say what to do with unexpected
>> >> inputs. Not specifying this is one of the main reasons we have such
>> >> trouble changing things later - because we discover some implementers
>> >> handled the unexpected in different ways to others (e.g. ignore, vs RST
>> >> the connection), and others only handled expected inputs and didn't
>> even
>> >> think to check for anything else.
>> >>
>> >> So, I believe we have to either say "reset the connection" or "ignore",
>> >> in response to an unexpected option length. I figure that, if there's
>> no
>> >> harm in ignoring something unexpected, then why not ("liberal in what
>> >> you receive" principle).
>> >>
>> >> Earlier in this thread, Michael Scharf pointed out that there is some
>> >> potential harm here (covert channel of up to 29B), but I pointed out
>> >> that TCP/IP has plenty of other ways of creating covert channels, so
>> >> we're not really adding to any problem here. But I did say that we
>> would
>> >> highlight the covert channel in the Security Considerations section, so
>> >> the Sec Area has a chance to object. If it raises as serious concern,
>> >> then we should switch from "ignore" to "reset", But I doubt it will.
>> > I think we first have to come to the conclusion *inside* TCPM whether
>> such a new covert channel is actually acceptable.
>> >
>> > Existing covert channels do not at all imply that a new covert channel
>> is a good idea (and, IMHO, 29B per packet is a lot). Network administrators
>> and operators know how to deal with the existing problems in TCP/IP. Adding
>> any new security issue needs careful reasoning.
>> >
>> > As individual contributor to TCPM, I believe that this covert channel
>> must just be removed from the next version of the draft. At least I don't
>> need other opinions to come to this personal conclusion.
>> >
>> > If this was less obvious others in the WG, TCPM could ask for an early
>> SECDIR review to get further guidance ASAP. Then this question can be
>> sorted out while we finish the protocol.
>> >
>> > If TCPM needs any external input on covert channels, I think an early
>> SECDIR review would be a much better approach compared to having a security
>> discussion during IETF last call. We are here discussing a standards track
>> extension of one of the core Internet protocols. In such a case, at least
>> in my view on IETF processes, other IETF areas can expect that TCPM ties to
>> deal with known open issues within the WG as far as possible, i.e., before
>> they see a "stable" specification in the IETF last call.
>> >
>> > In a nutshell:
>> >
>> > -1 on leaving this question open until IETF last call
>>
>> [BB] That's a perfectly reasonable process proposal.
>>
>> I just wanted to add that there are not just 2 choices: the WG (with
>> advice from SEC area if necessary) is free to limit the bandwidth of
>> this covert channel anywhere between 0 and 29B per packet by simply
>> limiting how much extensibility the protocol allows the option length
>> field to offer, with a 0B covert channel corresponding to no
>> extensibility.
>>
>
> OK. Michael.S abstains from the decision for SECDIR review, but other
> co-chairs think this is an important point to be checked.
> So, if there's no specific opposition, we would like to ask for SECDIR
> review before WGLC.
>
> Do authors want to update the draft beforehand to add some more
> clarifications or are there any other thoughts on this?
>
>
> [BB] The current draft could probably go to SECDIR review as it is.
> However, I have a few edits already done in my local copy, and a todo list
> of a few more, which I could try to get done in the next few days. Then
> I'll post a rev. So I guess it might as well wait a few days for those
> updates.
>
> Agree?
>

Yes, works for me.
Thank you so much!
--
Yoshi