[DNSOP]Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[perpass] close the perpass list

Hi! I observe that this list has seen almost no real posts in over 5 years. The list appears to have served its intended purpose and is no longer in use. My intent is to close it in 4 weeks. Closure of the list will mean that no new post will be permitted. However, the list archive will

Re: [Swan] Data sent in clear despite established tunnel

On Fri, 10 May 2024, Phil Nightowl wrote: This was the case up until the last change (see above) - which I can roll back right away - but that did not work for me. I ended up with the public IP as source address in the xfrm policy installed by libreswan anyway. What I can further try is

Re: [Swan] Data sent in clear despite established tunnel

On May 10, 2024, at 03:08, Phil Nightowl wrote: > >  >> >>> There already is a >>> >>>leftsubnet=0.0.0.0/0 >>>rightsubnet=srv.ii.nn.tt/32 >>> >>> in the roadwarrior's config. The config file of the server contains >>> >>>leftsubnet=srv.ii.nn.tt/32 >>>

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

On May 10, 2024, at 05:36, jab...@strandkip.nl wrote: > > I'm interested in where this guidance comes from. > > RFC 2782 to me is the grandfather of underscore labels, and it pretty much > goes out of its way to encourage a hierarchy of underscore labels to anchor > SRV records under, e.g.

Re: [Swan] Data sent in clear despite established tunnel

On Thu, 9 May 2024, Phil Nightowl wrote: Then be sure to have a leftsubnet= on your client or else it will try to use the pre-NAT IP and your remote peer would likely not accept that. There already is a leftsubnet=0.0.0.0/0 rightsubnet=srv.ii.nn.tt/32 in the roadwarrior's

Re: [Swan] Data sent in clear despite established tunnel

On Tue, 7 May 2024, Phil Nightowl wrote: If NATing, disable it for the IPsec ip ranges ? Unfortunately, this is not feasible due to ISP limitations. On the roadwarrior end, it is not possible at all. On the server end, I theoretically might try, but the odds are rather against me, I

Re: [Swan] Data sent in clear despite established tunnel

On May 7, 2024, at 04:21, Phil Nightowl wrote: > >  >> >> Can you share the "ipsec traffic" output after doing a few pings over >> the tunnel? I have a feeling you might not actually have a plaintext >> leak, you just think you do because of the way tcpdump hooks into >> the kernel

Re: [Swan] Data sent in clear despite established tunnel

On Mon, 6 May 2024, Phil Nightowl via Swan wrote: After giving it a second look, a brief response to my original message. The xfrm policies seem quite wrong after all: Can you share the "ipsec traffic" output after doing a few pings over the tunnel? I have a feeling you might not actually

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Thu, May 2, 2024 at 2:28 AM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > > I realize there's terminology imported from elsewhere, but it would be > helpful > (and cheap) to expand things like "SA" on first use anyway. > Done > In Section 6, "it is there for" should be "it

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Thu, May 2, 2024 at 7:29 AM Éric Vyncke via Datatracker wrote: > > # COMMENTS (non-blocking) > > ## Unbalanced ? > > It has been a long time since I worked with IPsec, but I have a small > concern > about this proposal: one peer will use its own selector/SADB to select a > child > SA and the

Re: [IPsec] Gunter Van de Velde's No Objection on draft-ietf-ipsecme-multi-sa-performance-06: (with COMMENT)

On Mon, Apr 22, 2024 at 9:23 AM Gunter Van de Velde via Datatracker < nore...@ietf.org> wrote: > > ###COMMENTS: > ##generic comments: > The abstract implies the possibility of utilizing various resources to > enhance > performance for the same traffic selector, yet the document consistently >

Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Wed, 1 May 2024, John Scudder via Datatracker wrote: Thanks for the document. Just one note: ### Section 1 I don't understand this sentence: When an IKEv2 peer is receiving additional Child SA's for a single set of Traffic Selectors than it is willing to create, it can return an

Re: [DNSOP] Questions before adopting must-not-sha1

On Tue, 30 Apr 2024, Paul Hoffman wrote: Until someone can show that a reduction in collision resistance can lead to a reduction in real-world security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason for this group to say to a zone operator who

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Tue, 30 Apr 2024, Paul Hoffman wrote: Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. Why not share the data if you have some? This is the list of TLDs affected: apple. brand TLD beats.

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Apr 30, 2024, at 18:42, Paul Hoffman wrote: > > This cull-because-of-low usage thread incorrectly assumes that the DNS is > flat instead of a hierarchy. The last I saw, there are 14 TLDs who use > RSASHA1. Advancing this draft as-is means that all of the zones under those > TLDs would be

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Tue, 30 Apr 2024, Philip Homburg wrote: - FIPS - PCI-DSS - BSI - OWASP - SOC2 - PKI-industry & CAB/Forum - TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. - All the cryptographers including CFRG The problem is that none if them did an impact analysis for this draft. I phrase it the other

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Wed, 1 May 2024, Mark Andrews wrote: One got servfail because validators where not aware that support was ripped away underneath it. Validators started to get errors that where totally unexpected. Performing runtime testing of algorithm support addressed that by allowing the validator to

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Tue, 30 Apr 2024, Philip Homburg wrote: So what happens instead is that software is patched to return insecure if SHA1 is not avaiable for signing and that is of course very risky. has been patched, yes. The problem arguably is that DNS moved WAY slower that the industry as a whole to get

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Tue, 30 Apr 2024, Mark Andrews wrote: They DO NOT disable SHA1. They disable RSASHA1. The distinction is important. NSEC3 works fine on them. There were issues with NSEC3's use of SHA1 as well. I am failing to find the reports on this now unfortunately. Paul

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Tue, 30 Apr 2024, Philip Homburg wrote: The advise is split between producing SHA1 signatures and consuming SHA1 signatures, and those timings do not have to be identical. That said, a number of OSes have already forced the issue by failing SHA1 as cryptographic operation (RHEL, CentOS,

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Mon, 29 Apr 2024, Paul Hoffman wrote: If the purpose of deprecating validation that involves SHA-1 is the decision by RedHat to make that entire section of the DNS insecure, the documents should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual useful attacks on

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Mon, 29 Apr 2024, Mahesh Jethanandani via Datatracker wrote: From an operational perspective, the shepherd write-up brought up the question of how this draft would be operationalized. In other words, is there an augment of the existing YANG model planned that would update the model to add

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Mon, 29 Apr 2024, Philip Homburg wrote: As far as I know there is no second pre-image attack on SHA1, and there will not be one in the foreseeable future. Correct. So if we deprecate SHA1 for validators, and assuming validators will follow this advice, and some platforms already stopped

[6lo] Paul Wouters' No Objection on draft-ietf-6lo-multicast-registration-18: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-6lo-multicast-registration-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

[Uta] Paul Wouters' Discuss on draft-ietf-uta-ciphersuites-in-sec-syslog-05: (with DISCUSS)

Paul Wouters has entered the following ballot position for draft-ietf-uta-ciphersuites-in-sec-syslog-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On Apr 27, 2024, at 20:39, Tim Wicinski wrote: > > M > > > This starts a Call for Adoption for: > draft-hardaker-dnsop-rfc8624-bis > draft-hardaker-dnsop-must-not-sha1 > draft-hardaker-dnsop-must-not-ecc-gost I support adoption for all three drafts. Willing to help with text and

Re: [Swan-dev] [Swan-commit] Changes to ref refs/heads/main

On Sat, 20 Apr 2024, Andrew Cagney via Swan-commit wrote: libipsecconf: rename internal enum AUTOSTART_ONDEMAND -> AUTOSTART_ROUTE This is wrong. The libipsecconf names match the _keywords_ used by auto= and auto=route has been long obsoleted for auto=ondemand. consistent with other

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes,

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

> Just a ping on this; thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > >> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote: >> Hi Paul, >> >>> On 4/12/24 22:36, Paul Wouters wrote: >>> However, I would urge the au

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

On Thu, 18 Apr 2024, Valery Smyslov wrote: -- COMMENT: -- The shepherd writeup says there are implementers, but no implementations. Is that right? Yes,

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

On Thu, 18 Apr 2024, Valery Smyslov wrote: OK, then how about (Section 3): CURRENT: The receiving party may take this information into consideration when selecting an algorithm for its authentication if several alternatives are available. NEW: The receiving party may take this

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

> On Apr 18, 2024, at 04:09, Valery Smyslov wrote: > >  >> >> Note that the IANA registry involved here was renamed since the latest draft >> was written :) >> >> Notify Message Type -> Notify Message Status Type >> >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message

[IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[Swan-commit] Changes to ref refs/heads/main

New commits: commit ca6cfbe2682dd18200672d05baf09daa75465d70 Author: Paul Wouters Date: Wed Apr 10 21:59:05 2024 -0400 security: add CVE-2024-3652.txt ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org

[Swan-commit] Changes to ref refs/heads/main

New commits: commit a9fd7976c1b2691a027edc73205595c76e0233ce Author: Paul Wouters Date: Mon Apr 15 12:40:02 2024 -0400 documentation: update CHANGES for v4.15 ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

On Fri, 12 Apr 2024, David Dong via RT wrote: Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG), As the designated experts for the Underscored and Globally Scoped DNS Node Names registry, can you review the proposed registration in draft-ietf-dnsop-dnssec-bootstrapping-08 for us

Re: [IPsec] [Last-Call] Tsvart last call review of draft-ietf-ipsecme-multi-sa-performance-06

On Wed, 10 Apr 2024, Marcus Ihlar via Datatracker wrote: Thanks for your review. Load balancing algorithms and policies are likely best left as implementation details but I do think a paragraph in the operational considerations section could be warranted. We had some Linux details in there

Re: [Ace] Using Problem Details (RFC 9290) in draft-ietf-ace-revoked-token-notification

On Apr 8, 2024, at 09:23, Marco Tiloca wrote: Hello Paul and ACE, In its current version -06, the document draft-ietf-ace-revoked-token-notification [0] uses a custom payload format for error responses. While addressing the received IETF

[OPSAWG] Paul Wouters' Abstain on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-acceptable-urls-11: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [Gen-art] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

I can live with that.PaulSent using a virtual keyboard on a phoneOn Apr 2, 2024, at 03:10, Valery Smyslov wrote:Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction:   Since IKEv2 doesn't allow to use multiple   

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

I can live with that.PaulSent using a virtual keyboard on a phoneOn Apr 2, 2024, at 03:10, Valery Smyslov wrote:Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction:   Since IKEv2 doesn't allow to use multiple   

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction: > >Since IKEv2 doesn't allow to use multiple >authentication methods and doesn't provide means for peers to >indicate to the other side which authentication methods they

Re: [Gen-art] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction: > >Since IKEv2 doesn't allow to use multiple >authentication methods and doesn't provide means for peers to >indicate to the other side which authentication methods they

Re: [Swan] Regarding: pluto error message in pcaket capture

On Mon, 1 Apr 2024, kumar priyankar via Swan wrote: Issue is that my log space suddenly started getting filled up on the server, when checked in syslog  and also in pcap, I saw only one message. pluto: ERROR: recvmsg(,, MSG_ERRQUEUE) on eth0 failed (noticed before read_packet) (attempt 9).

Re: [Swan] Libreswan 5.0rc2 cannot start on debian bullseye

Sent using a virtual keyboard on a phone > On Mar 28, 2024, at 17:24, antonio via Swan wrote: > > Hi, > > I’m trying to install libreswan 5.0rc2 on a debian bullseye but I got the > error when trying to start it: That seems a bug in unbound when compiled with nettle on Debian? Maybe dkg

Re: [Swan] Android 14 - IKEv2/IPSEC PSK

On Wed, 27 Mar 2024, antonio via Swan wrote: I’m trying to connect an android device using native vpn and libreswan version 5.0rc2,  it looks like a simple connection host - host/subnet but it doesn’t connect…  got the following log:  Note that the logs provided do not yet indicate a

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

On Wed, 27 Mar 2024, Panwei (William) wrote: Thanks for your clarification. I'm much clearer about the problems now. > > When you find out that the IKEv2 negotiation succeeds but ESP > > traffic can't get through, what more information will you get > > from sending the ESPping and not

Re: [IPsec] Artart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

> On Mar 23, 2024, at 13:00, Marc Blanchet via Datatracker > wrote: > > Comment 1) > The draft does not specify any fallback procedure or how to handle the > situation when no proper authentication method can be chosen by one of the > peers. Maybe it is specified elsewhere? Or maybe it is so

Re: [IPsec] Does I-D of extension of IPComp belongs to IPSec? FW: I-D Action: draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt

L > On Mar 21, 2024, at 14:44, Tero Kivinen wrote: > > Shihang(Vincent) writes: >> Hi Tero, >> We moved our draft of IPComp extension from 6man to IPSecMe because >> people told me that IPComp IANA registry is in the IPSec. However >> the extension itself is not related to encryption. I wonder

Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05

ssion removed from the > thread made sense for the future -06 that can go to IETF LC. > >> -Original Message- >> From: Paul Wouters >> Sent: Wednesday, March 20, 2024 12:26 AM >> To: Roman Danyliw >> Cc: ipsec@ietf.org >> Subject: Re: [IP

Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05

On Tue, 19 Mar 2024, Roman Danyliw wrote: I performed an AD review of draft-ietf-ipsecme-multi-sa-performance-05. I have a mostly editorial feedback below: ** Abstract. Editorial. s/crypto/cryptography/ Fixed. ** Section 1. Most IPsec implementations are currently limited to using

[nvo3] Paul Wouters' No Objection on draft-ietf-nvo3-encap-12: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-nvo3-encap-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt

On Mon, 18 Mar 2024, Tero Kivinen wrote: Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now This seems to cover my comments until section 5, but does not cover the changes for section 5.1, 6, and 9. Is there some issues with those comments? that was an operator error on

[Ace] AD review and IETF LC for draft-ietf-ace-revoked-token-notification

Hi, I've done my AD review of draft-ietf-ace-revoked-token-notification. The document looks good, I only have a minor question, which can be answered during the IETC LC process. Section 13.2 states: Issuing access tokens with not too long expiration time could help reduce the

Re: [IPsec] IPR confirmations for draft-ietf-ipsecme-multi-sa-performance

I am not aware of any IPR, willing to be listed as author. Paul Sent using a virtual keyboard on a phone > On Mar 15, 2024, at 03:55, Tero Kivinen wrote: > > Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or > anybody else) aware of any IPRs related to this draft? > > Are

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 38b5ca55c4e8f0265da8a98e91cfb9bcc55d89b4 Author: Paul Wouters Date: Mon Mar 11 22:09:05 2024 -0400 documentation: merge in v4.13/v4.14 CHANGES ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https

[COSE] AD review draft-ietf-cose-key-thumbprint-04

Thanks for the short clear document. I only have two comments, which can be addressed as part of the IETF LC. In the Security Considerations: To promote interoperability among implementations, the SHA-256 hash algorithm is mandatory to implement. This really belongs somewhere

[Swan-commit] Changes to ref refs/heads/main

New commits: commit e80ee435de583eebad690e91f3af4fd3e0f929c8 Author: Paul Wouters Date: Mon Mar 11 17:47:37 2024 -0400 Bump to 5.0rc2 ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 2546f2783560b4e19dbbfc595d47e7f72547fe49 Author: Paul Wouters Date: Sun Mar 10 19:25:41 2024 -0400 security: Added CVE-2024-2357.txt ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org

Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

On Mon, 11 Mar 2024, Panwei (William) wrote: Indeed, splitting the 32-bit SPI into two sub-fields, the VPN ID sub-field and SPI sub-field, may also be one option. This solution doesn't need to change the ESP packet format, but it also has some disadvantages. The first one is the scalable

Re: [IPsec] New Version Notification for draft-guo-ipsecme-ikev2-using-shangmi-00.txt

On Mon, 29 Jan 2024, Xialiang(Frank, IP Security Standard) wrote: We have submitted this new draft “Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)”, which defines a set of cryptographic transforms for using in the IKEv2 based on Chinese cryptographic standard algorithms

[Swan-commit] Changes to ref refs/heads/main

New commits: commit d834d7660569fc95731bfd8bc475bf8af0321559 Author: Paul Wouters Date: Sat Mar 9 18:10:06 2024 -0500 testing: clean some cruft comments ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org

[OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with DISCUSS and COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 98cdfe71c053dbd6f076bcccbbc998e4802826cf Author: Paul Wouters Date: Tue Mar 5 10:24:06 2024 -0500 documentation: fix man page for listen-tcp= default ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https

[Swan-dev] state numbers in enduser output?

On Tue, 5 Mar 2024, Andrew Cagney via Swan-commit wrote: Date: Mon Mar 4 20:15:11 2024 -0500 ikev2: drop and NOT sending notify it's redundant and confusing vis: "west-cuckold" #4: sent INFORMATIONAL request to delete IKE SA "west-cuckold" #5: ESP traffic information:

Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

Initial thought while having morning coffee. I can see how you want an extra SPD selector for the VPN ID - but maybe call it Namespace ID or something else as VPN ID is confusing. Your gateway that needs to support say 256 VPN IDs could split up its SPI range so it can detect which VPN to

[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-dns-error-reporting-08: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-dns-error-reporting-08: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [DNSOP] unrelated name server name recommendation

On Mar 4, 2024, at 14:04, Paul Vixie wrote: > >  > > this means a zone will always be reachable through at least one in-zone data > path (name server name and associated address records.) the result would be > that a full resolver would never have to pause its current lookup while >

Re: google-re2 pacakge update and facebook vs google python bindings ?

On Mon, 4 Mar 2024, Fabio Valentini wrote: Since this update was stuck and obviously broken, with no response from Paul in over a week (either here or on the bodhi update), I've used my provenpackager rights to revert the commits in dist-git and unpush the stuck update (it failed gating tests,

Re: [Swan] default config that works with recent android/win10/win11/macos/ios

> On Mar 4, 2024, at 05:24, Marc via Swan wrote: > > I think that is always such crappy excuse 'I do this for free ..'. If you are > at some store and you see the owner give your kids some sweet that you saw > previously fell on the floor. Would you accept his argument 'but it was for >

[IPsec] DELETE_REASON notify (draft-pwouters-ipsecme-delete-info)

At IETF-118 I presented the issue on reason of deletion. From the Introduction: The IKEv2 [RFC7296] protocol supports sending a Delete Notify message, but this message cannot convey the reason why a particular Child SA or IKE SA is being deleted. It can be useful

[IPsec] draft-pwouters-ipsecme-child-pfs-info

I agreed to write up a draft to discuss the issue regarding rekeying the initial Child SA and KE/PFS settings. Previous discussion/presentation at IETF118: https://datatracker.ietf.org/meeting/118/materials/slides-118-ipsecme-ikev2-dhke-interop-issues-00 Initial proposed draft:

Re: [Swan] default config that works with recent android/win10/win11/macos/ios

On Thu, 29 Feb 2024, Marc via Swan wrote: Where can I find a working and tested config, that offers vpn connectivity with the os default clients of android, win10, win11, macos and ios? (maybe put this on some wiki/example page) Not sure there is one as the variations in systems are almost

Re: [Swan] Possible to setup multiple connections, partly behind NAT?

On Fri, 1 Mar 2024, Phil Nightowl wrote: still could not get it fixed so far. Is there perhaps an overview of the testing configurations? Not a real overview, but there is a list. Each of the entries has its own description.txt file:

Re: [Swan-dev] Mac OS Sonoma IKEv2 issue

On Fri, 1 Mar 2024, Rolando Bermúdez Peña via Swan-dev wrote: I have libresawn version "ibreswan-3.25-4.8.amzn2.0.2.x86_64" for a vpn in a server. I am trying to connect using IKEv2 from Mac clients. From a Mac with Ventura it connects fine, from a Mac with Sonoma it does not connect. These 

Re: [DNSOP] [Ext] About key tags

On Feb 29, 2024, at 20:33, Arnold DECHAMPS wrote: > > > Is it still a concern enough that they justify continuing using those tags > instead of the full key? The full key is not there. There is only a key tag. Are you proposing a wire format change to DNSSEC that puts the full key there?

Re: [DNSOP] [Ext] About key tags

> On Feb 29, 2024, at 07:52, Edward Lewis wrote: > (If no action is taken, malicious activity might follow now that it is > described, but I have not heard of a historical case of it.) This attack was more or less described five year ago: https://essay.utwente.nl/78777/ They didn’t get to

[bess] Paul Wouters' Discuss on draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS)

Paul Wouters has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [DNSOP] [Ext] About key tags

On Feb 27, 2024, at 17:48, Mark Andrews wrote: > > If you forbid in the protocol But part of this is not “in” the protocol. Eg if two dns hosters happen to arrive at the same key tag for a single zone in concurrent offline ways. Or if that happens when KSK and ZSK are managed differently.

Re: [Swan] Possible to setup multiple connections, partly behind NAT?

On Tue, 27 Feb 2024, Phil Nightowl wrote: pluto[30425]: "remotesite"[1] 203.0.113.55 #2: responder established Child SA using #1; IPsec tunnel [192.168.1.253-192.168.1.253:0-65535 0] -> [203.0.113.55-203.0.113.55:0-65535 0] {ESPinUDP=>0x7522bc14 <0x80c5c828 xfrm=AES_GCM_16_256-NONE

Re: [Swan-dev] What does "missing v2CP reply" mean?

On Tue, 27 Feb 2024, Brady Johnson via Swan-dev wrote: We tried several changes to the client nmstate configuration. Setting "ipv4: dhcp: false" caused a configuration error in nmstate. We have created a bug for that and the nmstate team is working on it. Then, we tried with the same client

Re: [Emu] AD review draft-ietf-emu-rfc7170bis-14

On Mon, Feb 26, 2024 at 10:49 AM Alan DeKok wrote: [cut text where we agreed[ > Appendix C.4 should clarify the TLS version used (1.2). Should it be > > changed to use a TLS 1.3 example? > > I think so, yes. I'll have to dig into that. I don't think I can get > that updated today before the

[Emu] AD review draft-ietf-emu-rfc7170bis-14

Hi, I think in general this document is ready to go. I have some hopefully minor issues that would be good to resolve or clarify before starting IETF LC. As such, the PAC has been removed from this document. This reads a bit weird. Can it say PAC has been deprecated instead? This occurs

[Swan-commit] Changes to ref refs/heads/main

New commits: commit c040ce61a3899bc2df0fd8a18be8d6e4fb919696 Author: Paul Wouters Date: Fri Feb 23 16:31:24 2024 -0500 testing: ikev2-05-basic-psk add global secrets This re-uses the test to ensure the most specific secret is picked irrespective of the location of the global

Re: google-re2 pacakge update and facebook vs google python bindings ?

On Wed, 7 Feb 2024, Ben Beasley wrote: Subject: Re: google-re2 pacakge update and facebook vs google python bindings I haven't heard back from any of the maintainers. I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the first step towards getting python-google-re2 working.

[OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-9092-update-11: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-opsawg-9092-update-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

On Feb 22, 2024, at 17:36, Paul Kyzivat wrote: > > > But, if I am asked to do a telechat review of this document I will raise the > issue so that the IESG think about it. Then it will be their call. Note you don’t have to wait to be invited for that. During last-call, voice what you want to

[Swan-dev] NAT and intermediate exchange

On Thu, 22 Feb 2024, Andrew Cagney via Swan-commit wrote: New commits: commit 8f2151aab6084561bdeb8c49206ee238b508eecc Author: Andrew Cagney Date: Thu Feb 22 10:58:13 2024 -0500 ikev2: drop code checking for NAT during IKE_INTERMEDIATE exchange NAT happens during IKE_SA_INIT;

[Swan-commit] Changes to ref refs/heads/main

New commits: commit d2ccd5d58f491bef3253151faf4c4bf253965bd4 Author: Paul Wouters Date: Wed Feb 21 15:03:44 2024 -0500 testing: update forgotten west.console.txt for addconn-37-nic-offload ___ Swan-commit mailing list Swan-commit

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 6c8b02569f7270266bc1e51661b5c761c584c804 Author: Paul Wouters Date: Wed Feb 21 14:21:29 2024 -0500 testing: add test to addconn-37-nic-offload for encapsulation=yes commit b1957720206ff006c87b5471faa9c7a371432469 Author: Paul Wouters Date: Wed Feb 21 13:43:06 2024

Re: [Swan] Possible to setup multiple connections, partly behind NAT?

On Wed, 21 Feb 2024, Phil Nightowl wrote: Server conf: conn remotesite left=%defaultroute leftcert=server leftsubnet=192.168.1.253/32 right=%any rightaddresspool=192.0.2.0/24 auto=add ikev2=yes authby=rsasig leftid=%fromcert rightid=%fromcert

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 1cd6ead3160c5449201035b47360e8c36184ad7e Author: Paul Wouters Date: Wed Feb 21 13:28:26 2024 -0500 pluto: If connection is NAT'ed abort on nic-offload=packet No known hardware currently supports offloading with encapsulation. On initiator, we can abort

[Swan-commit] Changes to ref refs/heads/main

New commits: commit b8d327f911da6e1c672dea25c19c04da11209769 Author: Paul Wouters Date: Wed Feb 21 12:29:47 2024 -0500 documentation: minor update to libreswan(7) man page Resolves: https://github.com/libreswan/libreswan/issues/1469

[Swan-commit] Changes to ref refs/heads/main

New commits: commit 481c0eb7957d3ad8e1f744cb8f2434a1f596d5e1 Author: Paul Wouters Date: Wed Feb 21 11:55:11 2024 -0500 cleanup: remove configs/st which is a copy of portexcludes.conf.in ___ Swan-commit mailing list Swan-commit

Re: [Swan] Possible to setup multiple connections, partly behind NAT?

On Wed, 21 Feb 2024, hr...@inmail.cz wrote: Subject: Re: [Swan] Possible to setup multiple connections, partly behind NAT? If you have NAT, then you no longer have a host-to-host connection. What internal IPs should be used? Some end has to hand out an IP address for the other end to use.

[Swan-dev] labeled TS don't search for a connection ?

I see this commit: commit f198add4b08640d1b67aef19168998070b65b725 Author: Andrew Cagney Date: Tue Feb 20 20:25:33 2024 -0500 ikev2: when responding to labeled TS don't search for a connection only possible match is the IKE SAs (note that at this point the Child SA is sharing

Re: [Swan] Possible to setup multiple connections, partly behind NAT?

On Tue, 20 Feb 2024, Phil Nightowl wrote: Subject: Re: [Swan] Possible to setup multiple connections, partly behind NAT? Should I remove the leftsubnet/rightsubnet options altogether? Yes. After doing that, I tried to connect from remotehost1.privlan to server.privlan - which now should

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-03.txt

em to be a consensus for that at the moment. I'm sure other folks will chime in with their views. But I want to ping Paul Wouters specifically - since you are one of the expert reviewers for this registry and an author of domain-verification, could you express your opinion on the specific request related to ACME (

  1   2   3   4   5   6   7   8   9   10   >