[IPsec] Re: The ESP Echo Protocol document for IPsecME

[Valery Smyslov]

Hi,

 

thank you for providing use cases in the new version of the draft.

I still have some questions about the intended use of the ESP Ping protocol.

 

I understand from the draft that one of the use cases is a manual check

for ESP connectivity by network operators. This use case is clear for me.

 

The unclear part is how the ESP Ping is intended to be used for IPsec SA 
establishment process.

Should it always be initiated before starting IKE? Should it be periodically 
initiated 

after the ESP SA is established to check for the network connectivity change?

What about MOBIKE – should it be initiated before MOBIKE starts changing IP 
addresses?

These all is not clear from the draft.

 

My another concern is that the draft seems to confirm my suspicions that 

the usefulness of this protocol is limited. After reading the draft it seems 
that

the algorithm for establishing IPsec SA is as follows:

 

1. Send ESP Echo Request

2. If ESP Echo Reply is received, start IKE

3. If no ESP Echo Reply is received start IKE (*) 

 

(*) possibly with UDP encapsulation, or without it.

 

So, the draft says that you SHOULD start creating ESP regardless of the result 
of ESP Ping.

Thus, why to delay SA establishment (you should wait for some time for the 
response) with ESP Ping?

 

Perhaps the better alternative would be to use mechanism described in 

draft-antony-ipsecme-encrypted-esp-ping in combination with ESP-in-UDP 
encapsulation. 

The peers can establish ESP with forced UDP encapsulation (regardless of the 
presence of NAT) 

and then immediately start encrypted ESP ping on the established ESP SA with no 
UDP encapsulation. 

If it succeeds, then the peers continue to use this ESP SA with no UDP 
encapsulation,

if not – with it. Note, that RFC 7296 requires that if UDP encapsulation is 
negotiated,

then peers are free to either use it or not (even on per-packet basis), unless 
NAT is detected.

 

Regards,

Valery.

 

 

 

 

From: Yoav Nir  
Sent: Tuesday, June 11, 2024 7:44 AM
To: ipsec 
Cc: Jen Linkova 
Subject: [IPsec] The ESP Echo Protocol document for IPsecME

 

Hi, folks

 

At IETF 119, Jen Likova presented [1] the ESP Echo Protocol draft [2].

 

The conversation in the room was lively, but did not look like the kind of 
consensus that we just confirm on the list.

 

So rather than starting an adoption call now, we’d like to encourage people to 
discuss it on the list, to see if we are approaching such a consensus.

 

Regards,

 

Yoav on behalf of the chairs

 

[1] https://youtu.be/n-yH3jtQmdQ?t=1205  (presentation starts at the 20:10 mark)

[2] https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query

[Fries, Steffen]

Hi Valery,

Thank you for the update. Is there any intention to provide an implementation?

Best regards
Steffen

From: Valery Smyslov 
Sent: Tuesday, July 16, 2024 9:51 AM
To: Fries, Steffen (T CST) ; ipsec@ietf.org
Subject: RE: [IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation 
availability query

Hi Steffen,

Hi Valery, hi Brian,

I just wanted to restate my question if you are aware of a potential 
implementation of G-IKEv2, which is publicly available and which we could use 
for further investigation regarding extendibility?
I found information about a minimal implementation in the WG slides of IETF-99  
(https://www.ietf.org/proceedings/99/slides/slides-99-ipsecme-minimal-g-ikev2-implementation-01.pdf)
 but could not find an associated project. There is one related project on 
gihub (https://github.com/krizki/Group-IKEv2), but the last change was 7 years 
ago, so it does not look like being maintained.

To my best knowledge there are no implementations of the current version of the 
draft.
 Your findings are concerned with the older versions.

 Regards,
 Valery.

Any hint in that respect is appreciated.

Best regards
Steffen

From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf 
Of Fries, Steffen
Sent: Friday, April 12, 2024 6:09 PM
To: ipsec@ietf.org
Subject: [IPsec] draft-ietf-ipsecme-g-ikev2, public implementation availability 
query

Hi Valery, hi Brian,

While looking at the latest version of draft-ietf-ipsecme-g-ikev2, I was 
wondering if a public implementation is available? It would be interesting to 
have a look at the implementation to get a better impression regarding the take 
over of enhancements done for GDOI into G-IKE-v2.

Bets regards
Steffen
--
Steffen Fries

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] RFC 9593 on Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 9593

Title:  Announcing Supported Authentication Methods in the
Internet Key Exchange Protocol Version 2 (IKEv2) 
Author: V. Smyslov
Status: Standards Track
Stream: IETF
Date:   July 2024
Mailbox:s...@elvis.ru
Pages:  13
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ipsecme-ikev2-auth-announce-10.txt

URL:https://www.rfc-editor.org/info/rfc9593

DOI:10.17487/RFC9593

This specification defines a mechanism that allows implementations of
the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the
list of supported authentication methods to their peers while
establishing IKEv2 Security Associations (SAs).  This mechanism
improves interoperability when IKEv2 partners are configured with
multiple credentials of different types for authenticating each
other.

This document is a product of the IP Security Maintenance and Extensions 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Milestones changed for ipsecme WG

[IETF Secretariat]

Changed milestone "Traffic Flow Confidentiality document to IESG", added
draft-ietf-ipsecme-iptfs to milestone, removed draft-hopps-ipsecme-iptfs from
milestone.

Changed milestone "Signature algorithm negotiation for IKEv2 to IESG",
resolved as "Done", added draft-ietf-ipsecme-ikev2-auth-announce to milestone.

URL: https://datatracker.ietf.org/wg/ipsecme/about/

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: New Version Notification for draft-antony-ipsecme-iekv2-beet-mode-02.txt

[Robert Moskowitz]

Antony and I discussed this in the hall this morning, and I will work 
with him on scoping a 7402-bis.


I will have to see what xml file I can find for this

Bob

On 7/8/24 09:28, Antony Antony wrote:

Hi,

The BEET mode work started around IETF 118. Since IETF 118, I have narrowed
the scope of the BEET mode ID to IKEv2 only, to obtain an IKEv2 Code Point
allocation. BEET mode itself is specified in the Appendix of RFC 7402.

However, if there is interest among the authors of RFC 7402, I would propose
writing a bis(revision) just for that Appendix.

This ID is simple now and could potentially proceed quickly.


On Mon, Jul 08, 2024 at 02:00:27 -0700, internet-dra...@ietf.org wrote:

A new version of Internet-Draft draft-antony-ipsecme-iekv2-beet-mode-02.txt
has been successfully submitted by Antony Antony and posted to the
IETF repository.

Name: draft-antony-ipsecme-iekv2-beet-mode
Revision: 02
Title:IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP
Date: 2024-07-08
Group:Individual Submission
Pages:8
URL:  
https://www.ietf.org/archive/id/draft-antony-ipsecme-iekv2-beet-mode-02.txt
Status:   https://datatracker.ietf.org/doc/draft-antony-ipsecme-iekv2-beet-mode/
HTML: 
https://www.ietf.org/archive/id/draft-antony-ipsecme-iekv2-beet-mode-02.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-antony-ipsecme-iekv2-beet-mode
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-antony-ipsecme-iekv2-beet-mode-02

Abstract:

This document specifies a new Notify Message Type Payload for the
Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec
ESP Bound End-to-End Tunnel (BEET) mode.  BEET mode combines the
benefits of tunnel mode with reduced overhead, making it suitable for
applications requiring minimalistic end-to-end tunnels, mobility
support, and multi-address multi-homing capabilities.  The
introduction of the USE_BEET_MODE Notify Message enables the
negotiation and establishment of BEET mode security associations.



The IETF Secretariat



regards,
-antony

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org


___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] draft-smyslov-ipsecme-ikev2-qr-alt update

[Paul Wouters]

Hi,

Valery and Vukasin worked on interop testing a few weeks ago
of draft-smyslov-ipsecme-ikev2-qr-alt-09 and after some code
fixes on both implementations we got successful interop on
the success and failure paths.

We believe this document is ready for WGLC

Paul

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: draft-smyslov-ipsecme-ikev2-qr-alt update

[Valery Smyslov]

Hi Paul,

as author I fully agree that the document is ready for WGLC. Actually,
that's what I said at the meeting.
Thank you for repeating this in the ML (it was too late for me to do it
myself yesterday).

Regards,
Valery.

> Hi,
> 
> Valery and Vukasin worked on interop testing a few weeks ago of draft-
> smyslov-ipsecme-ikev2-qr-alt-09 and after some code fixes on both
> implementations we got successful interop on the success and failure
paths.
> 
> We believe this document is ready for WGLC
> 
> Paul

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org