"Eric Vyncke (evyncke)" <evyn...@cisco.com> writes:
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.
The author is not upset at the delay, but rather the suggestion that the work be ripped apart, and delayed for probably years more, so that INT area can begin new work (heretofore unasked for by any users) based on the encapsulation to produce a generic IP tunneling protocol. Nothing is stopping INT area from starting this new work in parallel, but the author does object to to shutting down, and effectively killing, a needed, and in demand, security enhancement that has been worked on for many years now, for which there are waiting users. Thanks, Chris.
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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
