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

[Tero Kivinen <[e-mail]>]

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]