> On 25 Mar 2019, at 19:38, Hubert Kario wrote:
>
> On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
>>> On 25 Mar 2019, at 19:23, Hubert Kario wrote:
>>>
>>> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
Yeah, so this looks very much like the IKE mechanism (the draft even
On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> > On 25 Mar 2019, at 19:23, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> >> Yeah, so this looks very much like the IKE mechanism (the draft even says
> >> so)
> >>
> >> In IKE the reason for this is
> On 25 Mar 2019, at 19:23, Hubert Kario wrote:
>
> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
>> Yeah, so this looks very much like the IKE mechanism (the draft even says
>> so)
>>
>> In IKE the reason for this is to detect NAT because IPsec does not traverse
>> NAT. We need to
On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> Yeah, so this looks very much like the IKE mechanism (the draft even says
> so)
>
> In IKE the reason for this is to detect NAT because IPsec does not traverse
> NAT. We need to detect the NAT so as to choose an IPsec variant that
>
Yeah, so this looks very much like the IKE mechanism (the draft even says so)
In IKE the reason for this is to detect NAT because IPsec does not traverse
NAT. We need to detect the NAT so as to choose an IPsec variant that traverses
NAT. If the server (or IKE Responder) lies, you might use the
Hi Tommy, thanks for the presentation.
I do not think the draft succeeds at addressing its goals. The mechanism is
a fine way for the client to receive its public address (assuming the
server is honest) but I can't see anything useful the client can do with
that information.
1) Keepalives
