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

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf