On Tue, 26 May 2015, Kathleen Moriarty wrote:
I'm okay with that change. I thought that we discussed this last, there was an emphasis on the possibility to avoid logging unauthenticated sessions though?
We mostly talked about not using unauthenticated IDs and only use them for logging. Then Tero wanted it for additional debug and we loosened up to allow ID's other than ID_NULL for AUTH_NULL. We added text to ensure no security decisions are based on unauthenticated IDs in section 2.2. We never talked about completely not logging unauthenticated sessions. I'm sure everyone would like at least some logging of that. What we noticed in our deployment though is that logging failures is what really kills you - in our Opportunistic IPsec we clearly enounter 99.99 percent of "no IKE daemon, so incoming ICMP message", followed by a 0.01% chance we found an IKE server that was never meant to talk IKE to us, returning a NO_PROPOSAL_CHOSEN. On an open DNS resolver (yes we like real hammer tests) this filled up on 4GB log disk in 15 minutes. So we are making changes to minimize logging in the Opportunistic case. But these considerations are not specific to AUTH_NULL and should go into the (to be created) Opportunistic IPsec document.
I see there is wiggle room to allow for that still. Does the new text meet your needs and still allow for logging of authenticated sessions (my previous concern that was addressed).
As I read the new text, it makes no statement about authenticted IKE, only about things to do or not do when using unauthenticated IKE Paul
Thanks, Kathleen On Tue, May 26, 2015 at 10:20 AM, Paul Wouters <[email protected]> wrote: On Tue, 26 May 2015, Donald Eastlake wrote: Thanks for the review Donald, The Security Considerations section is quite thorough. I did notice one small thing: Section 3.1 is labeled "Audit trail and peer identification". But the content of that Security Considerations section is about not trusting identification when null authentication is used. It seems to me that a few words to the effect that some clear indication should be present in audit/log trails when a purported identity has not been authentication should be included, as I expected them to be from the section heading. The bulk of that section was moved into section 2.2i and 3.2. How about: OLD: With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Implementers that implement NULL Authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted" or "identifiable". NEW: With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Any logging of unproven ID payloads that were not authenticated should be clearly marked and treated as "untrusted", possibly accompanied by logging the remote IP address of the IKE session. Rate limiting of logging might be required to prevent excessive logging causing system damage. then move this bit: Implementers that implement NULL Authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted" or "identifiable". To just above the "While implementations should..." in section 3.2 Paul -- Best regards, Kathleen
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
