Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9)

2018-12-11 Thread Paul Wouters
On Tue, 11 Dec 2018, Fernando Pereñíguez García wrote: These answers look fine. Thanks. Paul (the other emails will take a little more time :) Date: Tue, 11 Dec 2018 13:52:13 From: Fernando Pereñíguez García Cc: ynir.i...@gmail.com, i2...@ietf.org, ipsec@ietf.org, Rafa Marin Lopez ,

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9)

2018-12-11 Thread Fernando Pereñíguez García
Hi Paul, all, Next you can find our answers to your comments on sections 8 and 9. Section 8: Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required note to the RFC Editor to remove the entire section before publication as RFC.

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Nico Williams
On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote: > Nico Williams wrote: > > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > > > Paul Wouters wrote: > > > > > yes, typo, "not for road-warrior" > > > > > > > > I understood. I disagree with the “not”. Road

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Paul Wouters
On Tue, 11 Dec 2018, Nico Williams wrote: - you're not entirely sure that you don't have weak PSKs and would like to strengthen them I think that this is the major reason. OK, but you can always convert the real weak PSKs to either PK-{I,raw} or EAP depending on whether the "client" is

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Paul Wouters
On Tue, 11 Dec 2018, Valery Smyslov wrote: What I heard from the IPsecME record was that many in the room felt that this was where ther was a weakness. I see this as a social issue, not a technical one. We can't prevent administrators from being careless, either with PSKs or with passwords.

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Michael Richardson
Valery Smyslov wrote: > I think that using PAKE for road warriors is more important than for > site-to-site VPNs. In the latter case the SGWs are usually administered > by (presumably :-)) experienced administrators, who can select a high-entropy > PSK, and these PSKs need not to be memorable by

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Appendix A)

2018-12-11 Thread Rafa Marin-Lopez
Hi Paul, all: > > Appendix A: > > Why is it "eipsec" and not "ipsec” ? [Authors] We have fixed this now. > > Why is the organization not the IETF? Is this commonly done for yang models? [Authors] You're right. We will change this to: "IETF I2NSF (Interface to Network Security Functions)

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Valery Smyslov
> > I think that using PAKE for road warriors is more important than for > > site-to-site VPNs. In the latter case the SGWs are usually administered > > by (presumably :-)) experienced administrators, who can select a > > high-entropy > > PSK, and these PSKs need not to be memorable by users. So,

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Valery Smyslov
Hi Paul, I think that using PAKE for road warriors is more important than for site-to-site VPNs. In the latter case the SGWs are usually administered by (presumably :-)) experienced administrators, who can select a high-entropy PSK, and these PSKs need not to be memorable by users. So, generally

Re: [IPsec] replacing PSKs: CFRG and PAKE

2018-12-11 Thread Michael Richardson
Nico Williams wrote: > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > > Paul Wouters wrote: > > > > yes, typo, "not for road-warrior" > > > > > > I understood. I disagree with the “not”. Road warriors using group psk is > > > a > > > thing, sadly. > > > > But they aren't