Re: [nwcrg] IRSG review of draft-irtf-nwcrg-bats-03

Dear David, 

We just submitted a revised version based on comments. 
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/04/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/04/>

See the point-to-point response below. The security related issues took us some time to revise. 

Best, 

Shenghao

> On Jun 22, 2022, at 21:43, David R. Oran <daveoran@orandom.net> wrote:
> 
> I reviewed draft-irtf-nwcrg-bats-03 as designated reviewer for the IRSG. The document is in very good shape and the technical content sound. I have just a few minor comments and some grammar/typographic nits for the authors to consider prior to publication.
> 
> Minor Comments
> 
> In the introduction (paragraph 2), you should mention more than just interference as something that makes a wireless channel unreliable. There’s also fading, multipath, etc.
> 
> 
We mentioned fading and multiparty in the revision.
> 
> Discussion of multipath doesn’t show up until quite far along in the document, and in a few places the wording seems to restrict operation to a single receiver. There is in fact good discussion of multicast in the research questions section, so I suggest just a brief mention in the introduction that BATs is intended to work well in both unicast and multicast environments, possibly with a forward reference to the later discussion.
> 
> 
Multicast is mentioned in the introduction with referring to Sec 4. 
> On p7, the way the requirements on coded packets are laid out is bit difficult to follow. I suggest starting each set with something like a description list, with who the requirement applies to as the lead-in, for example:
> Encoder - the encoder DDP must deliver each coded packet with for following:
> 
> BID: batch ID
> Recoder - The DDP MUST deliver the following information to each recorder:
> 
> M: batch size
> q: recoding field size
> Decoder - The DDP MUST deliver the following information to each decoder:
> 
> M: batch size
> q: recoding field size
> K: the number of source packets
> T: the number of Octets in a source packet
> DD: the degree of distribution
The presentation style of this part is revised. 
> p9, beginning of section 2.2.4 says “A destination node needs the data transmitted by the source node”. Well, sure, but are you trying to say something beyond the obvious here? If so, it isn’t coming through.
> 
This paragraph is rewritten.
> In the various field descriptions and the equations, you use the letter “O” for “octets”. This slowed me down a bit as I had to think each time that you didn’t mean zero (“0”), despite the fact that the glyphs are in fact distinguishable in all three target renderings. It might be a pain to fix all of these, but I do think a better choice would either be “T” (which you use in the example above as a parameter for the decoder), or a two-letter variable name like “OC”.
> 
> 
O is changed to CO (the first two letters of coefficient). 
> 
> On p12 you say “A common primitive polynomial should be specified for all the finite field multiplications over GF(256). Is this actually a MUST for the operation of the code?
> 
“Should” is changed to “MUST"
> In the discussion of routing issues, on p18, you talk about the possibility of different batches being sent on different paths to achieve multipath gain. Is there a reason why batches can’t be similarly split and sent over different paths? If not, why not?
> 
We add the discussion about whether to transmit the packets of a batch on the same path or different paths for unicast and multicast. 
> Section 4.3 is titled “Application-related issues”, however most (perhaps all?) of the discussion isn’t actually about applications but about usage and deployment scenarios over different kinds of network technologies and topologies. Suggest renaming this “Usage Scenario Considerations” or something similar and if there are in fact application issues (e.g. multimedia, IoT, etc.) split those out in a separate section.
> 
The section title is changed to “Usage Scenario Considerations”.
> In section 6 on security considerations you address eavesdropping well, but don’t talk at all about traffic analysis. Are there interesting factors in BATs affecting the ability of traffic analysis to figure out what is happening with the application data flows, e.g. does BATs produce detectable timing or padding behavior that can be leveraged better than non-coded data, or perhaps conversely make things harder for an adversary?
> 
A new subsection is added to discuss traffic analysis. See 6.2.
> The discussion of attestation in section 6.2 left me feeling a bit un-satisfied, given that the protocol doesn’t actually provide provenance (i.e. the attestation of the chain of coders/recoders does not seem explicitly bound into the data streams). Simple origin authentication (e.g. using signatures) doesn’t seem to be adequate. Am I missing something here?
> 
The pollution attack part is rewritten. See 6.3.
> Nits
> 
> p7, s/DD[i] is the possibility/DD[i] is the probability/
> 
> p12, s/addition is an logical XOR/addition is a logical XOR/
> 
> p17, s/increasing too much end-to-end latency/increasing end-to-end latency too much/
> 
> p17, s/achieves the mulicast/achieves the multicast/
> 
> [End of review]
> 
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg