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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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"
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]