Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

2023-12-04 Thread Ben Schwartz
t protocol, but with sequence number subspaces it can be arranged with O(N) or even O(1) SAs. --Ben Schwartz From: IPsec on behalf of Pierre Pfister (ppfister) Sent: Monday, December 4, 2023 3:52 AM To: ipsec@ietf.org Subject: [IPsec] Why ipsecme-anti-replay

Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

2023-10-05 Thread Ben Schwartz
features (like a special set of keys) seems likely to make updates slower, not faster. --Ben Schwartz From: mohamed.boucad...@orange.com Sent: Thursday, October 5, 2023 9:36 AM To: Ben Schwartz ; Tommy Pauly ; Paul Wouters Cc: ipsec@ietf.org ; Valery Smyslov

Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

2023-10-05 Thread Ben Schwartz
directly from the SVCB RDATA. --Ben Schwartz [1] https://www.ietf.org/archive/id/draft-ietf-add-dnr-16.html#section-3.1.8 From: IPsec on behalf of mohamed.boucad...@orange.com Sent: Thursday, October 5, 2023 2:46 AM To: Tommy Pauly ; Paul Wouters Cc: ipsec

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

2023-07-31 Thread Ben Schwartz
se responses? Can I use ICMP ECHO inside the tunnel, or do we need draft-colitti-ipsecme-esp-ping? If we have path probes, why not just set DF=1 on the outer header for PMTUD? --Ben Schwartz From: Daniel Migault Sent: Monday, July 31, 2023 12:10 PM To: Ben Schw

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

2023-07-31 Thread Ben Schwartz
rdinary IP fragmentation and PMTUD. --Ben Schwartz From: Harold Liu Sent: Sunday, July 30, 2023 9:28 PM To: Ben Schwartz ; Daniel Migault Cc: ipsec@ietf.org Subject: RE: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification Ben, thanks for your comment. Yes at the beginning

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

2023-07-28 Thread Ben Schwartz
f ESP size limit is allowed, I think the best architecture would be to negotiate it up front (in IKEv2) since it is a static property of the endpoints, rather than discovering it in-band via error responses. --Ben Schwartz From: Daniel Migault Sent: Friday, July 2

Re: [IPsec] risav document at IPsec

2022-11-01 Thread Ben Schwartz
On Tue, Nov 1, 2022 at 5:53 AM Michael Richardson wrote: > > Ben Schwartz wrote: > > On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson < > mcr+i...@sandelman.ca> > > wrote: > ... > >> > Nit: RISAV in tunnel mode uses proto=

Re: [IPsec] risav document at IPsec

2022-10-31 Thread Ben Schwartz
On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson wrote: > > {some of my emails have written "ABSR" rather than "ASBR". Oops} > > Ben Schwartz wrote: > > On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson < > mcr+i...@sandelman.ca> >

Re: [IPsec] risav document at IPsec

2022-10-31 Thread Ben Schwartz
On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson wrote: > > Michael Richardson wrote: > > Based upon conversations on the list, this proposal might not even > be IPsec. > > At least, it's not proto=50(ESP)/51(AH), as they are asking for a new > > extension header type. > Nit:

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-24 Thread Ben Schwartz
On Mon, Oct 24, 2022 at 2:26 PM Michael Richardson wrote: > > Ben Schwartz wrote: > > ... > > >> Even assuming that you can insert an AH header (which I think you > can > >> legally > >> do in IPv4, but not in IPv6), then you have to u

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-24 Thread Ben Schwartz
On Sun, Oct 23, 2022 at 9:50 PM Michael Richardson wrote: > > Ben Schwartz wrote: > >> Ben Schwartz wrote: > >> > > > > >> > The real motivation to support AH in this draft comes down to MTU > >> > ove

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-23 Thread Ben Schwartz
On Sun, Oct 23, 2022 at 9:08 AM Michael Richardson wrote: > > Ben Schwartz wrote: > > > The real motivation to support AH in this draft comes down to MTU > > overhead. Going from 24 bytes of MTU loss to 73 bytes seems > > potentially significant, es

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-23 Thread Ben Schwartz
On Fri, Oct 21, 2022 at 11:50 PM Erik Kline wrote: > I suppose you could try to add a "we're exempt from 8200" paragraph and > see what happens. > > You could also just say that ASBRs are presumed to be communicating within > a well-managed environment, are often zero or one hops away from one >

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-21 Thread Ben Schwartz
On Fri, Oct 21, 2022 at 3:43 PM Michael Richardson wrote: > > Ben Schwartz wrote: > > We've just put out an extensively revised version of our RISAV > proposal > > (the I stands for IPsec). We'd like to start getting feedback from > the > > IPs

Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-20 Thread Ben Schwartz
ackets; for IPv6, inserting random headers along the path would violate > 8200. > > On Thu, Oct 20, 2022 at 7:23 AM Ben Schwartz 40google@dmarc.ietf.org> wrote: > >> Hello IPSEC, >> >> We've just put out an extensively revised version of our RISAV proposal >>

[IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

2022-10-20 Thread Ben Schwartz
questions (many of which are noted in the draft), but the core idea is simple: use RPKI to bootstrap an authenticated IPsec association between the source and destination ASes of Internet traffic, so that inauthentic packets can be discarded before they reach their destination. --Ben Schwartz