Spencer Dawkins writes:
I don't feel strongly about this, but do suggest s/uses the same policy/uses
the same policy, and that changes to that single policy can be coordinated
throughout the administrative domain/, to capture what you said in your
response, which I found helpful.
Changed that sentence as you suggested and the full sentence is now:
Also, such a solution might require some kind of centralized
policy management to make sure everybody in an administrative
domain uses the same policy, and that changes to that single
policy can be coordinated throughout the administrative
domain.
I saw that this isn't a 2119 document, but it's hard for people who are
familiar with 2119 language to ignore the words when they are in lower case
:D
I really liked the explanation you gave in your response here. I suggest
picking one of "can/will/should", probably "can", and including your
response in the document.
The resulting text (with some additional edits) might look something like
"As ESP-NULL heuristics need to know the same protocols as a deep inspection
device, an ESP-NULL instance of an unknown protocol can be handled the same
way as a cleartext instance of the same unknown protocol.
Changed to the text you suggested.
OK, that's the part that was missing for me. I would suggest "the packet has
already transited a NAT box which changed the IP addresses but assumed any
ESP payload was encryped and did not recalculate the transport checksums
with the new IP addresses. Thus"
Made the changes you requested, but used "fix" instead "recalculate"
as most of the nats do not recalculate checksum, but do incremental
update on it. The whole text section is now:
The most obvious field, TCP checksum, might not be usable, as it
is possible that the packet has already transited a NAT box
which changed the IP addresses but assumed any ESP payload was
encrypted and did not fix the transport checksums with the new
IP addresses. Thus the IP numbers used in the checksum are
wrong, thus the checksum is wrong.
This explanation is helpful. I'd suggest adding "This hueristic is most
helpful when only one packet is outstanding. For example, if a TCP SYN
packet is lost, the next packet would always be a retransmission of the SYN
packet".
Changed (with minor edits) as you suggested. The full text is now:
One good method of detection is if a packet is dropped then the
next packet will most likely be a retransmission of the previous
packet. Thus if two packets are received with the same source,
and destination port numbers, and where sequence numbers are
either same or right after each other, then it's likely a TCP
packet has been correctly detected. This heuristics is most
helpful when only one packet is outstanding. For example, if a
TCP SYN packet is lost (or dropped because of policy), the next
packet would always be a retransmission of the same TCP SYN
packet.
Your explanation was very helpful. I'd suggest
"Forcing use of ESP-NULL everywhere inside the enterprise, so that
accounting, logging, network monitoring, and intrusion detection all work,
increases the risk of sending confidential information where eavesdroppers
can see it"
Changed to use your text.
I updated the draft and submitted 06 version which includes these
changes.
--
kivinen(_at_)iki(_dot_)fi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf