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

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

Hi, Tero,

Thanks for the quick response (so I can remember what I was thinking :-)...

Deleting everything that you and I are OK with, I'm looking at these 
questions.

Thanks,

Spencer

>>    inspection engine.  (IPsec Security Associations must be satisfactory
>>    to all communicating parties, so only one communicating peer needs to
>>    have a sufficiently narrow policy.)  Also, such a solution might
>>    require some kind of centralized policy management to make sure
>>    everybody in an administrative domain uses the same policy.
>>
>> Spencer (minor): Is it fair to point out that this type of heuristic will
>> make changing the common attribute value you're looking for more 
>> difficult?
>> If you decide to move away from HMAC-SHA-1-96, for instance...
>
> That is why you need centralized policy management... If you have that
> then changing the policy in the whole organization should be quite
> easy (or at least possible)...

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.

>>    There are several reasons why a single packet might not be enough to
>>    detect type of flow.  One of them is that the next header number was
>>    unknown, i.e. if heuristics do not know about the protocol for the
>>    packet, it cannot verify it has properly detected ESP-NULL
>>    parameters, even when the packet otherwise looks like ESP-NULL.  If
>>    the packet does not look like ESP-NULL at all, then encrypted ESP
>>    status can be returned quickly.  As ESP-NULL heuristics should know
>>    the same protocols as a deep inspection device, an unknown protocol
>>    should not be handled any differently than a cleartext instance of an
>>    unknown protocol if possible.
>>
>> Spencer (minor): Are you saying that it might not be possible to handle 
>> the
>> two things the same way? I don't understand why. Prohibited by policy, 
>> sure,
>> and there may be other reasons to treat them differently, but I don't
>> understand why this is "should" ...
>
> That is not "SHOULD" in RFC2119 sense (this document does not specify
> protocol so there is no need for 2119 language).
>
> The text is just trying to say that in normal case for deep inspection
> engine it does not matter whether the unknown protocol was with
> ESP-NULL or without it. There is no real reason to change policy based
> on that fact, so both of them can/will/should receive same handling.

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.

>> 8.3.1.  TCP checks
>>
>>    The most obvious field, TCP checksum, might not be usable, as it is
>>    possible that the packet has already transited a NAT box, thus the IP
>>    numbers used in the checksum are wrong, thus the checksum is wrong.
>>
>> Spencer (minor): this isn't something I'm smart about, but would you 
>> expect
>> to see NAT boxes changing IP addresses and not fixing-up transport
>> checksums? That's begging for the receiver of these packets to discard 
>> them
>> based on checksum mismatches, isn't it? I know a NAT could be doing
>> anything, but that that seems short-sighted.
>
> No, I do expect NAT boxes to fix checksums IF they see them. In
> transport mode ESP-NULL case the checksum is INSIDE the ESP, thus NAT
> boxes will not see it, and cannot fix it.
>
> In the transport mode NAT-T in IPsec, there is special processing
> rules for that in the responder, where they will fix the (decrypted)
> checksums before giving the packet forward (See 3.1.2 of RFC3948).
>
> So as NAT boxes assume that when they see ESP it means the packet is
> encrypted, they not even try to fix the checksum and when the deep
> engine device gets the NATed packet in the checksum is incorrect
> because of that.

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"

> The deep inspection engine could try to find out the NAT mapping and
> take that in to account when calculating the checksum, but it gets
> quite complicated thus I do not think it is worth while to do that
> here.
>
>>    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.
>>
>> Spencer (minor): is this true when you have a transmit window size 
>> greater
>> than one packet, so that more than one packet is outstanding? I agree 
>> with
>> the heuristic, but not with the statement that it's a "good method of
>> detection" - I don't think it will be triggered very often for web 
>> browsers,
>> or or TCP-based streaming media, or anything that's not stop-and-wait.
>>
>>    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.
>
> As I point or here the retransmission usually have same source and
> destination ports (this is true for both retransmissions, and multiple
> packets in the same transmission window), and then the sequence
> numbers will either be same (retransmission), or right after each
> other (next packet in the same tcp session).
>
> Also the packet that is usually caught by this is the TCP SYN packet,
> and for that there will not be next packets yet, only after the TCP
> SYN ACK is received from the other end, thus in that case there will
> be mostly just retransmissions.
>
> As I pointed out before the most difficult case is the start-up case
> where we do not yet have any state we can match against, and for that
> start-up case this retransmission checks is good.

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".

>> 9.  Security Considerations
>>
>>    Using ESP-NULL or especially forcing using of it everywhere inside
>>    the enterprise can have increased risk of sending confidential
>>    information where eavesdroppers can see it.
>>
>> Spencer (minor): I'm not arguing with this statement, I'm just confused 
>> by
>> it. "Increased risk" compared to what? Saying that forbidding encrypted 
>> ESP
>> makes it easier to eavesdrop doesn't seem profound - was that what you
>> meant?
>
> I meant that I do not belive that enterprices should be forbidding
> encrypted ESP, just to get accounting, logging, network monitoring,
> intrusion detection etc to work, as that makes eavesdroping so much
> easier, but still there are people who thinks that is the right
> solution.

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"