> 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 s
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 to
> 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 det
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
> traverses
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
The
