In the absolutely most generic case, yes. And heuristics absolutely have their place. However, my proposal clearly allows for eliminating all heuristics with policy constraints.
As you well know, you can eliminate the heuristics you describe by choosing the same algorithm so intermediaries don't need to guess ICV lengths. Hence in this scenario, all ESP traffic would be ESP-NULL of a known algorithm. This is possible since you just choose an algo that all the legacy clients also support. So my scenario gives a very real deployment that can eliminate the need for heuristics entirely during migration. So carrying encrypted traffic in WESP is very valuable (and in charter). bs -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Friday, January 08, 2010 3:58 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; Stephen Kent; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call [I finally managed to catch up all the tons of emails to the ipsec-list, so now I can finally reply to few of them.] Brian Swander writes: > In terms of your chart, that means that the only allowed > combinations (of this scenario) are: > > Case Nodes Flow S 1 S 2 > 1 N-N I EN EN > 3 W-W I W W > 4 W-W E EE W* > 5 W-N I EN EN > > Hence any (legitimate) ESP traffic that the intermediary sees must > be ESP-NULL, and the encypt flag is critical, as it is the mechanism > to enable encryption between uplevel machines. > > The main point of WESP is to remove heuristics from intermediary > processing. Hence we need to focus on the scenarios that actually > allow us to do that, and enable as many of them as possible. Note, that every time you have ESP-NULL traffic without WESP, you need heuristics. I.e. the cases 1 and 5 still need heuristics regardless whether you like that fact or not. If you try to inspect plain ESP-NULL traffic you need heuristics to find out the algorithm parameters for those ESP-NULL connections, i.e. what is the ICV length and whether there is IV (and its length). If you allow ESP traffic at all on the network you need to deal with it, meaning you either use heuristics to inspect it or you simply allow it go through or drop it (regradless whether it is encrypted ESP or ESP-NULL). If your use of ESP/WESP is such that it is beneficial for the users to use WESP instead of ESP-NULL then they will move to it (i.e. if WESP provides better QoS properties than ESP-NULL, then it will get used). If it is critical for security that all traffic is inspected then you cannot allow encrypted ESP at all (regardless whether it is marked in WESP or not). If it is "nice to have feature" (for example network statistics) to be able to see inside ESP-NULL packets (regardless whether they use WESP or ESP-NULL) then you either use heuristics for ESP-NULL packets, or just notice that the amount of ESP-NULL traffic is so small that it is no longer needed for network statistcs use (i.e. when WESP is widespread enough in your network, you can stop trying to inspect ESP packets to account that last 0.00001% of traffic still using ESP-NULL instead of WESP). I cannot really see any scenario above where it would really be needed to put encrypted packets inside WESP. -- kivi...@iki.fi _______________________________________________ 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
