Paul Wouters <p...@nohats.ca> wrote:
> On Sat, 13 Mar 2021, Michael Richardson wrote:
>> I'd *like* section 3 to enumerate the claims clearer (Maybe just new
>> paragraphs).
> You mean a textual change? like split out more, or bullet points?
Yes. I am imagine an argument between an operational person who wants to
authorization to upgrade/replace a gateway with the CFO. This document is
his ammunition, so we need to make the CFO consider that the risks of
not updating exceed the risk of change.
Fundamentally, the CFO is risk averse, and thinks that "it ain't broken"
> Systems that support IKEv1 but not IKEv2 are most likely also
> unsuitable candidates for continued operation.
> I know from vendors I've talked to that they froze their IKEv1
> stacks. I can't enumerate those in an RFC though. I think only the
agreed.
> IKEv1 systems can be abused for packet amplification attacks.
> This could be clarified, or reference CVE-2016-5361. CVE links aren't
> that stable over the years though.
That's okay, it's stable enough, and the form of the reference makes it clear
that there are issues.
>> I think that the third paragraph (labelled IPsec) should be a new
>> section 3.1.
> We can make PPK and Labeled IPsec their own sections, but I don't see
> why you would do labeled ipsec but not PPK. also, I guess Group IKE
> should be listed too as we have a draft and had support in IKEv1 but
> not in IKEv2.
I want labelled IPsec to be a separate section so that it will have an HTML
link, and can be referenced easily in the government RFP that justifies the
upgrade.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
