Chris,
Thanks for repeating in this thread your earlier reply.
While I understand that the author is not happy with an additional 2 weeks of
delay on the top of 3 years, additional reviews[1] by the IETF community can
only be beneficial to the document. As written below, the draft name/title does
not make it obvious for people to guess the content.
NB: else, I find this document quite useful.
Regards
-éric
[1] hoping that not everyone is on vacation mode as it is August...
On 10/08/2022, 20:03, "Int-area on behalf of Christian Hopps"
<int-area-boun...@ietf.org on behalf of cho...@chopps.org> wrote:
I'll paraphrase what I replied to on the ballot proposal deferment thread:
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.
To support fixed-sized packets we have Pad blocks, something that is not
required for a generic tunnel encapsulation.
We also are replacing the highly inefficient pad mechanism originally
defined with ESP. To that end we are able to maximize bandwidth by re-using
(and depending on) the existing ESP sequence number to do things such as
reordering the outer packet flow to reassemble the inner fragmented packets.
Other parts of this draft deal directly with other security issues such as
how and when to utilize inner packet IP header values (ECN, DSCP etc.)
If there is a need to have a generic tunneling protocol similar to what we
have, then the INT area is of course free to borrow from this document in
creating their own work. However, as noted above we have made specific design
choices to benefit the intended IPsec/IPTFS use which we have an immediate need
for, and we would *not* benefit from delaying this work, or making the
encapsulation more generic.
Thanks,
Chris.
"Eric Vyncke (evyncke)" <evyncke=40cisco....@dmarc.ietf.org> writes:
> Dear intarea/int-dir,
>
>
>
> I have a request for you about https://datatracker.ietf.org/doc/
> draft-ietf-ipsecme-iptfs/
>
>
>
> While the draft name looks like it is about IPsec, it appears to me
> as an “aggregation and fragmentation” tunneling mechanism [1], i.e.,
> it uses the ESP Next-header field (an IP protocol per section 2.6 of
> RFC 4303 == IPsec ESP) to indicate a next protocol. While the
> original intent is to prevent traffic analysis (based on packet size
> and rate of packets) by padding/aggregating/fragmenting packets, it
> is also a tunnel. This smart technique could be use above other
> protocols than ESP.
>
>
>
> I have just deferred the IESG evaluation of this document to allow
> the int-dir and intarea WG to review this document as it has most
> probably escaped your filter during the IETF Last Call.
>
>
>
> Thank you very much for your comments (please keep all lists in cc)
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> [1] vaguely related to draft-templin-intarea-parcels
>
>
>
> _______________________________________________
> IPsec mailing list
> ip...@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
