On Wed, Nov 15, 2017 at 1:06 PM, Paul Wouters <paul@xxxxxxxxx> wrote: > On Tue, 14 Nov 2017, S Moonesamy wrote: > >> Sorry for not being clear. The draft states that "NULL Authentication >> with IPsec" has been implemented and deployed. Given that it is a practice, >> is it a good idea? > > > The deployments I'm aware of with mesh encryption using IPsec did try > to keep some kind of network based monitoring/filtering in place, but > in the end concluded enterprise wide mesh encryption is more important, > and the rules of the network monitoring/firewalls can be pushed to the > endnodes using the usual sync methods (puppet, ansible, new gold image > container, etc). > > I dont think the IETF should try to answer whether it is a good idea or > not. There was a need for this, and we enabled the protocol to perform > this optional function. > ... and the document isn't trying to make those sorts of judgement calls. I've heard some mumblings that people thought that this document was somehow recommending against encryption or that encryption is "bad" in some way. This really isn't the intent; rather documenting places where encryption impacts operators network management practices informs the operator so they can design new ways to manage the network, and also informs protocol designers so they are aware that removing certain information may negatively impact how well the network works (and so negatively impact their performance). An example of this is that some enterprises prioritize VoIP / video conference traffic (esp from remote offices) to provide better user experience. Having this data encrypted (e.g from a browser) is (note: personal judgement call here!) a good thing, but it does mean that the enterprise cannot use their existing methods to prioritize the traffic, and having them know this is useful - otherwise a: the quality gets sucky, and b: the enterprise may try block this. So, documenting the effects of encryption is NOT to discourage it, but rather try make it better deployed -- the authors are not anti-encryption, quite the opposite. One of the authors is a Security AD, the original sponsoring AD was another Security AD (Stephen). Much of the document came from contributions - earlier versions of the document hadn't fully scrubbed the tone to remove judgements - please note that it has had significant rewrites to scrub this; places where there may be implications that encryption is bad are not intentional and should be point out so they can be addressed (e.g the "ideally") W > Paul > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf