Telechat Review of draft-ietf-ipsecme-iptfs-13
review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18-00
Request | Review of | draft-ietf-ipsecme-iptfs |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | Telechat Review | |
Team | Internet Area Directorate (intdir) | |
Deadline | 2022-08-20 | |
Requested | 2022-08-10 | |
Requested by | Éric Vyncke | |
Authors | Christian Hopps | |
I-D last updated | 2022-08-18 | |
Completed reviews |
Tsvart Early review of -03
by Dr. Joseph D. Touch
(diff)
Tsvart Early review of -12 by Dr. Joseph D. Touch (diff) Opsdir Last Call review of -12 by Bo Wu (diff) Secdir Last Call review of -12 by Shawn M Emery (diff) Genart Last Call review of -12 by Peter E. Yee (diff) Secdir Telechat review of -13 by Shawn M Emery (diff) Opsdir Telechat review of -13 by Bo Wu (diff) Intdir Telechat review of -13 by Tatuya Jinmei (diff) |
|
Comments |
This draft contains a tunnelling mechanism and is using an IP protocol number, so having a tunnel person to review this document would be perfect. Thanks -éric |
|
Assignment | Reviewer | Tatuya Jinmei |
State | Completed | |
Request | Telechat review on draft-ietf-ipsecme-iptfs by Internet Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/int-dir/8FpfPxuW9mLhQDY8T5hVP3FX1h0 | |
Reviewed revision | 13 (document currently at 19) | |
Result | Ready | |
Completed | 2022-08-18 |
review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18-00
I've reviewed version 13 of draft-ietf-ipsecme-iptfs. I'm by no means an IPsec expert or very much familiar with ESP details, so it's quite possible I may miss something in its technical details. That said, I think it's very well written to understand the concept, and I've not found any obvious problems. So I'd say it's "ready". It looks like one underlying high level question is whether we should rather standardize a (single, unified) mechanism that does not necessarily depend on ESP. For that question, I think this response from the author is convincing: > We designed the encapsulation with IPsec/IP-TFS (IP traffic flow > security) in mind. This work defines sending fixed-sized packets at > a constant rate specifically decoupled from the user load to achieve > a high degree of traffic flow security. We might design a generic tunneling mechanism that parameterizes the sending rate or whether to use of padding or encryption, but unless we have a clear demand for such a mechanism today (which I actually don't know well but doesn't look likely) that seems to me to be over generalization. I have a couple of very minor comments on the draft content: - In Section 6, some integer fields are explicitly defined as "unsigned" while some others don't specify the sign. Maybe it's obvious (all seem to be unsigned anyway), but for consistency and by convention I'd suggest clarifying the sign for all integer fields. - Since the "BlockOffset" field is 16-bit, this mechanism can't support IPv6 jumbograms. I don't really think it a problem, and it may not even be worth mentioning, but I'm pointing it out just in case the author wants to clarify it.