I have read draft-ietf-ipsecme-iptfs before it was adopted, and during the adoption call, but have been busy. So I have read it again today from beginning to end before tackling the long thread that has developed.
EXEC SUM: I think that the document is not ready.
There are a lot of MAYs and future work thoughts on the sender.
That's fine. But, in order for future senders to know what's legal and
what's not, what we really need is a clearly articulated Receiver State
Machine.
I suggest that this is pretty important.
===
The first sentence of the Abstract needs rework.
The words "security" and "confidentiality" are used, but really it's about
traffic analysis. So, if there is anything with increased confidentiality,
it's the pattern, right? Abstracts are really hard to write.
Ah, the problem is that "traffic flow security" is not the term,
it's traffic flow confidentiality, and it is not capitalized!
So, that would help, but... it's not defined yet.
I suggest the following terms be added to section 1.1.
- TFC
* I'm glad you recommend PLMTUD, I suggest PMTUD is dead.
How do use PLMTUD? Will you tell us later in the document, or is that new
work?
(does not look like you tell us)
* You are using "CamelCase" for variables, I found that jarring.
I wondered what rfc4303 used, but found nothing.
RFC7296 uses UPPER_CASE.
RFC7296 does not use _ for field names.
I might prefer snake_case, but whatever...
* I would prefer "If BlockOffset != 0" rather than
Conversely, if the "BlockOffset" value is non-zero it points to the
> The "BlockOffset" can point past the end of the "DataBlocks" data
> which indicates that the next data block occurs in a subsequent
> encapsulating packet.
I guess, it the actual value does not matter: it's not remembered.
As long it is bigger than the packet, it's good. So 0xffff probably works?
> 2.2.2. No Implicit End Padding Required
-- I think you are telling me that the IPv4/IPv6 length field is good enough
to find the end of the packet. If not, I didn't quite understand.
Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5'
I hope this will be acceptable :-)
I think it's a reasonable hack, and I don't see us wrapping around
IP versions within a hundred years, soooo...
And pad blocks are "IPv0"
> This possible interleaving of all-pad
> payloads allows the sender to always be able to send a tunnel packet,
> regardless of the encapsulation computational requirements.
I think that you are telling me that a sender can have some pad packets being
created regularly (perhaps on a CPU dedicated to this) and almost ready to
send, and the pad packet is just replaced by real data if it happens to be
ready.
Please split 2.2.5 up by flag type into subsubsubsection.
2.4.21: Maybe need to briefly explain circuit breakers to us
non-transport-types.
> If the SA back to the sender is a non-
> AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload
> (i.e., header only) is used to convey the information.
is this really worth supporting?
Please break up third paragraph.
=====
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
