Re: [IPsec] comments on esp-null-heuristics-01

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
>     >> It is?  I'll bet 95% of actual transport mode IPsec has an L2TP
>     >> layer inside.
> 
>     Tero> Inside one enterprise? I do not think so. I guess most of the
>     Tero> IPsec traffic is VPN style tunnel mode, but as that is going
>     Tero> over untrusted networks (there is word private there :) they
>     Tero> are encrypted, thus outside the scope of this draft.
> 
>   I see the "inside one organization" part now.
>   I was thinking that much of the transport-mode traffic crossing an
> enterprises' border is likely on-site consultants, who are doing remote
> access back to their HQ.

Yes, but those consultants do use encryption when connecting to the
enterprise network.

Most likely their encrypted traffic is terminated on the security
gateway on the enterprise network border, and then it might go forward
without encryption (it might have end to end ESP-NULL inside the
encrypted tunnel mode ESP when it arrives to the sgw, and sgw might
strip encrypted tunnel mode ESP out and leave transport mode ESP-NULL
inside).

>     Tero> I added a note there saying:
> 
>     Tero>   Note, that most of the current uses of the IPsec are not
>     Tero> host to host traffic inside one organization, but for the
>     Tero> intended use cases for the heuristics this will most likely be
>     Tero> the case. Also tunnel mode case is much easier to solve than
>     Tero> transport mode as it is much easier to detect the IP header
>     Tero> inside the ESP-NULL packet.
> 
>   I think that's 5%, with 95% being above, but maybe I don't know why
> this stateful inspection device is "inside"

It is "inside" as I do not belive anybody belives they could leave
encryption off for traffic that goes outside of the enterprise...

Remember that all of this is always talking about ESP-NULL traffic
only.

> 
>     >> I agree with the analysis of section 3, in particular the
>     >> explanation of how hardware can be programmed to statefully match
>     >> the ESP-NULL flows.  It might be worth noting that NAT-T ESP-NULL
>     >> flows *ALREADY* have a 5-tuple (likely unique) marker, and that
>     >> if the inspector is also a NA(P)T, that it already is keeping the
>     >> right state.
> 
>     Tero> Do you have any exact wordings where to add what.
> 
>   I think that there is later on text about this, and maybe just a
> forward reference is enough. 
>         "As described in section 7, UDP encapsulated ESP traffic
>         may also have have NAPT applied to it, and so there is already
>         a 5-tuple state in the stateful inspection gateway

Ok, added that to the end of section 3. "

>     Tero>    Flow
>     Tero>       TCP/UDP or IPsec flow is a stream of packets part of the
>     Tero> same TCP/ UDP or IPsec stream, i.e.  TCP flow is a stream of
>     Tero> packets having same 5 tuple (source and destination ip and
>     Tero> port, and TCP protocol).
> 
>   okay, I would run this by the transport and Internet area folks,
> because I think this disagrees with their definition of flow.

How does that disagree in their definition of flow?

On the other hand it really does not matter whether it disagrees or
not, this is what we mean by flow in this document, so as we define it
there, it should be clear for people what we mean by flow.
-- 
[e-mail]