Re: [Last-Call] [Int-dir] Intdir telechat review of draft-ietf-ipsecme-iptfs-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you,

As you may have seen, I have referred to your review when balloting on this I-D.

Regards

-éric

On 19/08/2022, 00:49, "Int-dir on behalf of Tatuya Jinmei via Datatracker" <int-dir-bounces@xxxxxxxx on behalf of noreply@xxxxxxxx> wrote:

    Reviewer: Tatuya Jinmei
    Review result: Ready

    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.



    _______________________________________________
    Int-dir mailing list
    Int-dir@xxxxxxxx
    https://www.ietf.org/mailman/listinfo/int-dir

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux