Dan, As Yaron has already stated, there are multiple ways of detecting ESP-NULL packets and the WG chose one out of those. I remember an initial proposal (by Manav or Paul? not sure) where the author was using a reserved SPI value in the ESP to indicate all ESP-NULL packets. This was shot down by the WG citing extensibility reasons, and i agreed with them. I agreed, that if we do that then we will be able to differentiate between ESP-NULL and other ESP packets, but that'll be the end of the road, and there can be no further extensions done.
Then WESP came along, which was patently extensible and people happily lapped it up. Now, folks are getting cold feet, saying that its too extensible and probably we shouldnt be having such a loose protocol thats so easily extensible. Lets leave it at marking ESP-NULL only and lets not have this do anything else. Similarly, as Charlie says, you might be proposing AH-lite, but by the time it reaches IESG it would have morphed into something much more complex than the AH-lite that you have in your mind right now! :) YMMV but I dont see WESP as a hack at all, and i think its a very good solution to a problem that we're all trying very hard to fix. Jack On Fri, Jan 8, 2010 at 3:21 AM, Dan Harkins <dhark...@lounge.org> wrote: > > Hi Yaron, > > [wearing a baseball cap from the "Working Man's Triathlon"!] > > These same "unmanaged machines" will cause problems for this new > mutated form of WESP (wrapping both encrypted and unencrypted ESP). > There is no way to assure that they will use WESP. Maybe they'll > use ESP-null without WESP and then these middleboxes relying on > WESP wrapped ESP to do their job are out-of-luck. So yes, these > machines do pose a problem, but WESP doesn't fix that problem. > > Over time a larger and larger portion of the network will "play by > the rules", as you say, but those rules could be: 1) use WESP to wrap > all your ESP traffic, both encrypted and not encrypted; or 2) use > ESP for encrypted traffic and <NAT-friendly-AH-protocol> for your > unencrypted traffic. > > Aside from architectural cleanliness, another benefit of a NAT-friendly > AH would be that the temptation for extensions and the consequential > creep of new "requirements" (what WESP seems to be suffering from right > now) would go away. We had a problem and the solution has morphed and > succumed to temptation. That's the sign of a bad solution. > > Dan. > > On Thu, January 7, 2010 1:24 pm, Yaron Sheffer wrote: >> Hi Dan, >> >> [No hat. This is getting cold!] >> >> When I hear that "the network enforces a policy" I immediately think of >> the exceptions: unmanaged machines (in the enterprise sense of the word), >> machines with weird operating systems (that's "non Windows" to some of our >> participants), outdated versions, machines that failed to be provisioned >> etc. >> >> So it is difficult to assume that *all* ESP is encrypted in any given >> network. This may be OK, if you're willing to accept false positives (e.g. >> in a load balancer). Or it may not be OK, if you have security decisions >> that depend on this distinction. >> >> And this is why a smooth migration is so important. Over time you get a >> larger and larger portion of the network to play by the rules. >> >> Thanks, >> Yaron >> >> -----Original Message----- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Thursday, January 07, 2010 19:57 >> To: Yaron Sheffer >> Cc: ipsec@ietf.org >> Subject: RE: [IPsec] Traffic visibility - consensus call >> >> >> Hi Yaron, >> >> Yes, one way was chosen but it has morphed into something much more >> than simply indicating ESP-null traffic. What I'm suggesting is that if >> the goal is simply a good way to indicate ESP-null traffic then doing >> just that is possible with a NAT-friendly version of AH. It's much >> cleaner than WESP. >> >> How do I indicate encrypted ESP? Well, as I mentioned, it is the only >> traffic using ESP in the network for which traffic visibility is required. >> The middleboxes looking into these packets must be in the same policy >> domain as the end systems that are producing the protected traffic. That >> being the case you just disallow ESP-null _by policy_ on that network. >> Then any traffic on the network that is ESP is encrypted and the >> protected-but-inspectable traffic is the NAT-friendly version of AH. >> Voila! We can now distinguish between encrypted and non-encrypted traffic >> and we can inspect traffic that is merely integrity protected. >> >> Dan. >> >> P.S. ESP is a protocol which has the ability to use or not use any number >> of ciphers. I don't think deprecating a cipher (even the NULL cipher) is >> a "change" to ESP. It doesn't change the protocol the way changing a >> header format or redefining ICV calculations changes the protocol. But >> I'm not proposing deprecating ESP-null and that really has nothing to do >> with the topic of a NAT-friendly version of AH as a solution to the >> problem that WESP claims it is solving. >> >> On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote: >>> 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. >>> >> >> >> >> Scanned by Check Point Total Security Gateway. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
