I finally managed to finish my G-IKEv2 review. Here are my comments:
--
2.3.4. GCKS Registration Operations
The GAP MAY also be
included to provide the ATD and/or DTD (Section 4
Valery Smyslov writes:
> The fixed 8 bytes were used for simplicity. The purpose of this field
> is only to avoid use of misconfigured PPKs, so it is believed
> that 2^-64 is an adequate chance for misusing PPK.
> In the worst case the SA won't be established with no clear
> reason in the log file
Valery Smyslov writes:
> The draft uses the method similar to RFC 8784:
>
> SK_d = prf+ (PPK, SK_d')
>
> with the replacement of SK_d with SKEYSEED.
>
> The rationale for using the current form:
> 1. This is the most straightforward and conservative use of prf,
> when the first argument (PP
Valery Smyslov writes:
> I have some comments on draft-pwouters-ipsecme-delete-info that I
> tried to express at IETF120, but due to lack of time they were not
> responded to.
>
> 1. I'm very much concerned with the "Delete Reason Text" field. My
> primary question - in what language this free tex
Christian Hopps writes:
> This example doesn't make sense to me, it seems contrived to make
> some point but it's not realistic.
>
> People aren't contacting random IPsec servers that are
> mis-configured for their users. If the user wouldn't understand the
> above language then the operator wou
> On Aug 10, 2024, at 20:30, Tero Kivinen wrote:
>
> Christian Hopps writes:
>> This example doesn't make sense to me, it seems contrived to make
>> some point but it's not realistic.
>>
>> People aren't contacting random IPsec servers that are
>> mis-configured for their users. If the user
Michael Richardson writes:
> If we are going to rely on the enum alone, then it needs to cover all sorts
> of cases that might be specific to some implementations, while other
> implementations would have a more general code.
Perhaps instead of reason text we have generic enumeration of close
reas
Tero Kivinen wrote:
> Michael Richardson writes:
>> If we are going to rely on the enum alone, then it needs to cover all
sorts
>> of cases that might be specific to some implementations, while other
>> implementations would have a more general code.
> Perhaps instead of rea
