| From: Paul Wouters
| On Tue, 3 Mar 2020, Paul Wouters wrote:
|
| > Current shunt handling cannot deal with this, as the second keyingtries
| > sometimes tries to install a second shunt, which sometimes “works” due to
| > not being widened. This is causing customer issues that at resolved by
|
On Thu, 5 Mar 2020, Antony Antony wrote:
it is OK to change the default and possibly change back when bug is fixed.
I don't think so. If a host on the internet has OE with keyingtries=0,
if it gets 1 (spoofed) packet from any random host, it will forever try
to send IKE packets to it. That is
On Tue, Mar 03, 2020 at 03:05:46PM -0500, Paul Wouters wrote:
> On Tue, 3 Mar 2020, Paul Wouters wrote:
>
> > Current shunt handling cannot deal with this, as the second keyingtries
> > sometimes tries to install a second shunt, which sometimes “works” due to
> > not being widened. This is causi
On Thu, 5 Mar 2020 at 12:50, Paul Wouters wrote:
>
> On Thu, 5 Mar 2020, Andrew Cagney wrote:
>
> > Reading the RFC, I can see CERT in:
> >
> > - the aggressive initial response
> > - the second aggressive request
> >
> > but not for the initial request (but pluto still tries to unpack it).
> > Ho
On Thu, 5 Mar 2020, Andrew Cagney wrote:
Reading the RFC, I can see CERT in:
- the aggressive initial response
- the second aggressive request
but not for the initial request (but pluto still tries to unpack it).
However, the state machine comments:
/* STATE_AGGR_R0:
* SMF_PSK_AUTH: HD
Reading the RFC, I can see CERT in:
- the aggressive initial response
- the second aggressive request
but not for the initial request (but pluto still tries to unpack it).
However, the state machine comments:
/* STATE_AGGR_R0:
* SMF_PSK_AUTH: HDR, SA, KE, Ni, IDii
* --> H
