On Tue, Jan 30, 2024 at 5:42 PM Paul Wouters wrote:
> > Not necessarily. A VPN client might know for sure that the server it
> wants to talk to supports ESP ping. Before the IKE
> > handshake, it could send the ping, and if no response came back, it
> simply wouldn't bother with negotiating ESP o
Paul Wouters wrote:
> That would be a poor implementation. A man-in-the-middle could quickly
> reply with an ICMP message before the ESP ping reply would come back.
> It would be a handy way to disable IKEv2/IPsec entirely.
Intentional Active On-path attacker can drop everything.
Eit
On Tue, 30 Jan 2024, Lorenzo Colitti wrote:
Not necessarily. A VPN client might know for sure that the server it wants to
talk to supports ESP ping. Before the IKE
handshake, it could send the ping, and if no response came back, it simply
wouldn't bother with negotiating ESP or IPv6
at all and
On Mon, Jan 29, 2024 at 10:51 AM Jen Linkova wrote:
> It looks like the ESP ping capability needs to be negotiated.
> The question is: shall it be another IKEv2 Configuration attribute or smth
> else?
> Anyway it means that the proposed mechanism can not be completely
> uncoupled from IKE...
>
N
Jen Linkova wrote:
> On Tue, Jan 23, 2024 at 10:10 PM Michael Richardson
> wrote:
>> While the whole point of the SPI7/8 mechanism is that it can be operated
>> completely without IKEv2 involved at all.
> So I was working on the text which focuses on SPI7/8 case only, when I
On Jan 29, 2024, at 13:51, Jen Linkova wrote:
>
>
> It looks like the ESP ping capability needs to be negotiated.
It doesn’t need to be negotiated, just announced.
> The question is: shall it be another IKEv2 Configuration attribute or smth
> else?
Use a plain Notify payload.
Of course, it
First of all my apologies for letting -00 to expire, I'm working on
-01 but failed to submit in time...partially due to an issue described
below..
On Tue, Jan 23, 2024 at 10:10 PM Michael Richardson
wrote:
> While the whole point of the SPI7/8 mechanism is that it can be operated
> completely wit
Jen Linkova wrote:
>> However, following several discussions and [1] , there's interest in
>> developing a more generic approach. I am hopping the Internet Draft would
>> define a more detailed payload, similar to how ICMP defines packet
payload
>> in RFC 792.
> Then it pro
Hi Antony,
On Fri, Jan 12, 2024 at 3:57 PM Antony Antony wrote:
> I'm glad to seee this ID will be updatead soon, before it
> expire this month!
Let's see if I can make the deadline..
> > >"Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the
> > >viability of the path for
Paul Wouters wrote:
>> For a basic use case, any response would suffice. The essential
>> requirement is the ability to send a request and receive a response
>> from the IPsec peer, which is why I proposed the minimal solution to
>> begin with.
> I disagree. VPN protocols are
Antony Antony wrote:
>> In the original proposal it was clear, as the reserved SPI values were
>> used. Am I missing anything?
> For a minimal use case it may work; however, for more generic use
> cases, such as sending multiple requests simultaneously from multiple
> applic
On Fri, 12 Jan 2024, Antony Antony wrote:
For a basic use case, any response would suffice. The essential requirement is
the ability to send a request and receive a response from the IPsec peer,
which is why I proposed the minimal solution to begin with.
I disagree. VPN protocols are actively
On Wed, Jan 10, 2024 at 05:07:55PM +0100, Jen Linkova wrote:
> Hello,
>
> Jen here, a new co-author of this undoubtedly useful draft.
> I'm working on addressing comments received after -00 was submitted,
> and I have a question..
Thanks, Jen. I'm glad to seee this ID will be updatead soon, befor
24 11:08 AM
> > To: ipsec@ietf.org; ant...@phenome.org
> > Cc: Lorenzo Colitti ; Michael Richardson
> >
> > Subject: Re: [IPsec] Fwd: New Version Notification for
> > draft-colitti-ipsecme-
> > esp-ping-00.txt
> >
> > Hello,
> >
> > Jen h
Scott Fluhrer \(sfluhrer\) wrote:
> Well, I just glanced through the original draft, and I'm a bit confused
> about the objectives.
> Essentially, it's a way to ask "is there someone at IP address x.x.x.x
> that supports IPsec and is reachable"
No, that isn't really the goal.
Th
Jen Linkova wrote:
>> "Upon completing an IKE negotiation, an IPsec peer wishing to
>> ascertain the viability of the path for ESP packets MAY initiate an
>> ESP Echo Request packet to the other peer. The ESP Echo Request packet
>> MAY be encrypted. If encrypted, it SHOULD utilize
> Sent: Wednesday, January 10, 2024 11:08 AM
> To: ipsec@ietf.org; ant...@phenome.org
> Cc: Lorenzo Colitti ; Michael Richardson
>
> Subject: Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-
> esp-ping-00.txt
>
> Hello,
>
> Jen here, a new co-
Hello,
Jen here, a new co-author of this undoubtedly useful draft.
I'm working on addressing comments received after -00 was submitted,
and I have a question..
Antony Antony wrote:
>> If we want to implement Antony's suggestion of doing this ping on real ESP
>> sessions as well, then that would
On Wed, 6 Sep 2023, Valery Smyslov wrote:
I would change this to:
"After completing an IKE negotiation, an IPsec peer wishing to verify
the viability of the current network path for ESP packets MAY initiate
an ESP Echo Request"
As in, you can do it immediately after the IKE SA is established,
Hi Paul,
> On Wed, 6 Sep 2023, Antony Antony wrote:
>
> > Here is a proposed text for the I-D.
> >
> > "Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the
> > viability of the path for ESP packets MAY initiate an ESP Echo Request
>
> I would change this to:
>
> "After co
On Wed, 6 Sep 2023, Antony Antony wrote:
Here is a proposed text for the I-D.
"Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the
viability of the path for ESP packets MAY initiate an ESP Echo Request
I would change this to:
"After completing an IKE negotiation, an IP
On Fri, Jul 28, 2023 at 01:01:39PM -0700, Lorenzo Colitti wrote:
> On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen wrote:
>
> > Sequence number is just 32-bit sequence number (always present, can
> > be used when correlating request to response).
> >
>
> Antony yesterday suggested to me that some
On Fri, Jul 28, 2023 at 08:20:03PM +0200, Antony Antony wrote:
> On Tue, Jul 25, 2023 at 07:06:47PM -0700, Lorenzo Colitti wrote:
> > Dear ipsec WG,
> >
> > When working on a VPN implementation we found that it's very difficult to
> > rely on IPv6 ESP packets because many networks drop them, so ev
Michael Richardson writes:
> I'm not sure how we put more than 255 bytes in :-)
> I guess it doesn't really matter if we call it padding or not, so we can
> really just do whatever.
I was just assuming rest of the packet is "Payload data":
0 1 2
Tero Kivinen wrote:
>> Tero Kivinen wrote: > I think we should use normal
>> ESP format i.e. have ESP SPI using > following format:
>>
>> I mostly agree. But:
>>
>> > (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | |
>>
>> It would be
Michael Richardson writes:
>
> Tero Kivinen wrote:
> > I think we should use normal ESP format i.e. have ESP SPI using
> > following format:
>
> I mostly agree.
> But:
>
> > (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
>
> It would be nice to be able to p
Tero Kivinen wrote:
> I think we should use normal ESP format i.e. have ESP SPI using
> following format:
I mostly agree.
But:
> (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
It would be nice to be able to put enough padding to make packets at least
1280,
On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen wrote:
> Sequence number is just 32-bit sequence number (always present, can
> be used when correlating request to response).
>
Antony yesterday suggested to me that some stateful firewalls/middleboxes
might be happier if these numbers started from 1
Antony Antony writes:
> Thanks Lorenzo for this ID.
> I believe this is a great idea. Perhaps we could consider allowing a
> non-zero ESP payload size? This would facilitate correlating responses upon
> arrival at the sender. Then I would add an ESP message, format similar to
> ICMP message. For
On Tue, Jul 25, 2023 at 07:06:47PM -0700, Lorenzo Colitti wrote:
> Dear ipsec WG,
>
> When working on a VPN implementation we found that it's very difficult to
> rely on IPv6 ESP packets because many networks drop them, so even if IKE
> negotiation succeeds, the data plane might be broken. Worse,
Lorenzo Colitti wrote:
> When working on a VPN implementation we found that it's very difficult
> to rely on IPv6 ESP packets because many networks drop them, so even if
> IKE negotiation succeeds, the data plane might be broken. Worse, this
> can happen on migrate, blackholing an
Dear ipsec WG,
When working on a VPN implementation we found that it's very difficult to
rely on IPv6 ESP packets because many networks drop them, so even if IKE
negotiation succeeds, the data plane might be broken. Worse, this can
happen on migrate, blackholing an existing session until the probl
32 matches
Mail list logo
