Hi Dan,
There are multiple good ways to indicate ESP-null traffic. We just chose one
option.
But (assuming you strongly dislike heuristics, which some of us do) the big
question is how to indicate *encrypted* ESP. Deprecating ESP-null is a
non-starter: it is "changing ESP" just like changing the header format, and
even more so, because it is a practically invisible change.
Thanks,
Yaron
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan
Harkins
Sent: Thursday, January 07, 2010 2:04
To: Grewal, Ken
Cc: ipsec@ietf.org; Paul Koning; Stephen Kent
Subject: Re: [IPsec] Traffic visibility - consensus call
Hi Ken,
No one responded to my suggestion so I'll suggest it again below.
On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote:
[snip]
> The bottom line is that in order for a network appliance (Trusted
> Intermediary) to offer critical network services (IDS/IPS/DPI/Access
> Control) in IPsec environments, it needs to know if a given IPsec packet
> is encrypted or not in a deterministic manner and this is within scope.
> WESP is offering this determination on a per packet basis.
That is a clear definition of the problem: a TI must be able to
determine whether a given IPsec packet is encrypted or not.
[snip]
> Some argue that we should use WESP for NULL traffic, mandating ESP for
> encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption
> within a given domain / environment. How does an intermediate device know
> that this policy is being enforced? What if ESP is still being used for
> ESP-NULL and encrypted traffic? If this is the case, we are back to where
> we were/are today - no way to tell if ESP payload is encrypted or not.
The intermediate device knows this because it is under the same
policy domain as the endpoints that have agreed to do WESP. If he's not
in the same policy domain then he has no assurance that the endpoints
will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL
cipher, so this box in the cloud is out-of-luck again and WESP doesn't
help. Unless, of course, WESP is really a trojan horse to deprecate ESP
and force everyone to use WESP always but you have said that's not the
case.
So now my suggestion again. If you're going to specify a new protocol
and require endpoints to implement it then why not just make a new
IPsec protocol that is a NAT-friendly way of doing per-packet integrity
protection? Don't try to "wrap" ESP packets. That way the middlebox knows
that when it sees this new protocol that it is not encrypted and when it
sees ESP it knows it is encrypted (it knows that ESP is not using NULL
encryption because policy has disallowed that). We could even think about
deprecating ESP-NULL in favor of this new protocol. This would be an
architecturally cleaner way of solving the problem you clearly described
above. IKE can negotiate the new protocol, in transport- or tunnel-mode,
negotiate an algorithm to use to provide integrity protection, and
establish an authenticated and shared key to use with the algorithm. So
what's the problem with this suggestion?
regards,
Dan.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
