Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis

The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.

On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:

> NULL may be useful to some, but should NOT be mandated (should rather than must).
> It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.
> 
> 
> Paul
> 
> ]-----Original Message-----
> ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael
> ]Richardson
> ]Sent: Tuesday, July 08, 2014 11:00 AM
> ]To: Stephen Farrell
> ]Cc: hipsec@ietf.org; saag@ietf.org
> ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
> ]
> ]
> ]Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> ]    > Generic: is it still considered a good plan to have null
> ]    > confidentiality suites such as these? Or for those to be
> ]    > Mandatory-To-Implement (MTI)? That clearly was the generic
> ]consensus as
> ]    > we have these in a number of protocols. The new reasons to move
> ]from
> ]    > that I think are: 1) we no longer need this for debugging purposes
> ]    > really since libraries and dev tools have moved on and are better
> ]now,
> ]    > and we specifically no longer need these for protocols that are no
> ]    > longer new, 2) BCP188 could be considered to argue against having
> ]these
> ]
> ]There are an incredible number of systems (Linux with stock-in-kernel
> ]NETKEY IPsec for instance), where it is impossible or very very
> ]difficult to get a packet capture of the traffic after decryption, but
> ]before it goes up the protocol stack.
> ]
> ]On such systems, if you have a problem in the field with a protocol that
> ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
> ]it works, and it appears to with without ESP, then the lack of debugging
> ]means that you turn off all security.
> ]
> ]ESP-authenticated-with-NULL-encryption is debuggable in the field.
> ]Not having it, means turning off ESP; and if the problem is in the link
> ]between the ESP layer and the upper layer, then...
> ]
> ]--
> ]Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
> ]IPv6 IoT consulting =-
> ]
> ]
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

Personal email.  hbhotz@oxy.edu