[Gen-art] Gen-ART review for draft-ietf-ipsecme-esp-null-heuristics-06.txt (was: Re: Gen-ART review for draft-ietf-ipsecme-esp-null-heuristics-05.txt)

["Spencer Dawkins" <[e-mail]>]

Hi, Tero,

Thank you for fixing my suggested text ("writing text is hard" :-)

Russ,

-06 addresses all of my review comments from -05. It's ready for
publication as an Informational RFC, from a Gen-ART perspective. I did spot
one "This heuristics" in new text that should be "This heuristic", but 
that's an RFC
Editor note, not a draft respin.

Thanks,

Spencer


> 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.
> -- 
> [e-mail]