[IPsec] Re: I-D Action: draft-cisco-skip-00.txt
This protocol is confusingly named for IPsec types. I thought that it was Cisco bringing the old Sun SKIP mechanism back to life. Maybe it is. If so I'm really unclear from browsing the document. If it is not doing that (and I see all sorts of HTTPAPI stuff), then maybe someone has a better TLA. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification
Tero Kivinen wrote: > Having lower 32-bits first will allow checking those bits even before > the upper bits are even received.. On the other hand I do not think > there is any difference in hardware as you most likely want to check > ICV first anyways before checking replay window, and that requires > receiving full packet anyways. Yes, and you can validate ICV, 32-bits against replay window, and confirm the upper 32-bits at the same time. For dataflow hardware, it matters little. But for CPUs with caches, the order can certainly matter. > For hardware I do not think order of 32-bit words makes any > difference. I do not think there is any difference in software either, > so this is should not affect performance, except you can perhaps use > the old hardware to check lower 32-bits of the sequence number if it > is in same location than before. Yes, that's true, and that's probably a win. You have to take hit on SPI# to find the SA, and until you load that, you don't even know if the upper 32-bits are present. But, the lower 32bits are in the same place. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification
Steffen Klassert wrote: > That said, if we want to transmit the 64-bit sequence number > in ESP, I'd prefer to transmit the upper 32-bits before > the lower 32-bits. That's easier on the imlementation side. My naive notions about cache-line optimizations, I'd think that one could start the replay-window check based upon the lower-32-bits, while waiting for the upper-32-bits to load, in order to validate the upper-32-bits are as expected. For that 1/2^32 situation where the upper-bits roll, then one takes a !unlikely(). I guess the bigger proceedural question is how do we get early feedback from hardware designers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info
Tero Kivinen wrote: > Michael Richardson writes: >> If we are going to rely on the enum alone, then it needs to cover all sorts >> of cases that might be specific to some implementations, while other >> implementations would have a more general code. > Perhaps instead of reason text we have generic enumeration of close > reasons like we have now, but in addition to that we have 32-bit > vendor specific reason code. The vendors could then use that vendor > specific code field to put in some internal error code or something It could even just be some unique slug that the gateway sending the message could put into it's log. I'm agnostic about including the text; include a language tag if we like. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated
Benjamin Kaduk wrote: > On Tue, Aug 06, 2024 at 12:31:21PM -0400, Michael Richardson wrote: >> >> Daniel Shiu wrote: >> > While working on cryptographic inventory tools, I noticed that the IKE >> > authentication methos AUTH_HMAC_SHA1_96 (SHA1-based HMAC truncated to >> > 96-bits) is permitted in IKEv2 per RFC 8247 (status MUST- according t >> >> Note, it's *HMAC* SHA1. >> >> > Have I missed the deprecation elsewhere, or is further action merited. >> >> HMAC consists of two passes of SHA1, and includes padding in such a way that >> means that pre-image attacks where the attack text is longer than the >> original does not work. >> >> So, I am not falling overmyself to deprecate HMAC-SHA1. >> I'm happy to leave things as they are until a revision to 8247 is done. >> Note that MUST- means that it is already on it's "way down" > The truncation to 96 bits is probably worth a bit of worry in this era > (though not an extreme amount of worry). Note that Kerberos for a long When we agreed to the truncation back in 1996-ish, an argument was that the lack of the full hash output meant that (brute-force) attackers had to attack each packet on their own. They couldn't be sure they had actually found the key based upon a single packet match. I think Hugo made this argument. So, the truncation was considered a feature. HMAC has been extremely powerful thing. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated
Daniel Shiu wrote: > While working on cryptographic inventory tools, I noticed that the IKE > authentication methos AUTH_HMAC_SHA1_96 (SHA1-based HMAC truncated to > 96-bits) is permitted in IKEv2 per RFC 8247 (status MUST- according t Note, it's *HMAC* SHA1. > Have I missed the deprecation elsewhere, or is further action merited. HMAC consists of two passes of SHA1, and includes padding in such a way that means that pre-image attacks where the attack text is longer than the original does not work. So, I am not falling overmyself to deprecate HMAC-SHA1. I'm happy to leave things as they are until a revision to 8247 is done. Note that MUST- means that it is already on it's "way down" -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info
Valery Smyslov wrote: > 2. The list of reasons looks to me both incomplete and excessive at the same > time. If we are going to rely on the enum alone, then it needs to cover all sorts of cases that might be specific to some implementations, while other implementations would have a more general code. So I expect it to be "excessive", but it being incomplete is certainly a problem. OTH, an enum that is more generic with text in UTF-8[well: precis!], that expounds upon the problem is also very useful. I am not concerned about attacks in this way. I'm more concerned that a VPN gets turned off, and the traffic goes in the clear because nobody can debug it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ 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-encrypted-esp-ping-01.txt
Antony Antony wrote: >> Antony Antony wrote: >> > We are proposing Encrypted ESP Ping, which will compliment/co-exist >> > with draft-colitti-ipsecme-esp-ping. We welcome feedback on this >> > proposal. Both authors will be present at the upcoming Vancouver IETF and >> > would love to chat about this ID and our implementation plans. Also, we are >> > planning a short presentation at IPsecME session there. >> >> This proposal allows the initiator to specify the SPI# in which the response >> will appear. I see the utility of this, particularily for multi-SA >> configurations. I'm not yet convinced this is safe, but I'm thinking about >> it. > Thanks for your feedback. > I am curious about your concerns. Could you share more details? > One concern I imagine is responding to a different peer would cause a DoS? > We specified more validations on the responder to address this problem. Assume a bunch of remote access (laptops) connected to a gateway machine. a) can peer A send traffic to another peer? b) can peer A use this to find out what SPI# are in use? c) can peer A find out where peer B is? I think that we want to prevent all of these things, and I don't think it's impossible to code. I think that we have to think about the error conditions carefully though. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ 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-encrypted-esp-ping-01.txt
Antony Antony wrote: > We are proposing Encrypted ESP Ping, which will compliment/co-exist > with draft-colitti-ipsecme-esp-ping. We welcome feedback on this > proposal. Both authors will be present at the upcoming Vancouver IETF and > would love to chat about this ID and our implementation plans. Also, we are > planning a short presentation at IPsecME session there. This proposal allows the initiator to specify the SPI# in which the response will appear. I see the utility of this, particularily for multi-SA configurations. I'm not yet convinced this is safe, but I'm thinking about it. Thank you for the document. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: The ESP Echo Protocol document for IPsecME
Yoav Nir wrote: > The conversation in the room was lively, but did not look like the kind > of consensus that we just confirm on the list. Here are a list of threads on the topic from the past 9 months that I could find. https://mailarchive.ietf.org/arch/msg/ipsec/Rd5B1Z_tj4LsjGHUiXClQCXS3WM/ 6 non-author contributions, 32 emails total. (Pretty much every regular contributor is on this thread. What more should they say?) https://mailarchive.ietf.org/arch/msg/ipsec/rHkfznUpgyYCkYuxLeIOY5rPRt4/ 2 authors discussing/disagreeing. https://mailarchive.ietf.org/arch/msg/ipsec/9_hkyF3P7Nq5oEOPc73v6i2gdLU/ 2 emails. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Panwei (William) wrote: > It seems to me that extending the traceroute by using an ESP packet can > be done right now and has no requirement for the ESP packet format. Any > ESP packets can work with this mechanism, and there is no need for the > designated SPIs. > The receiver will send back an ICMP response when it receives the ESP > packet with TTL=0, no matter what this ESP packet actually looks > like. The receiver can be the on-path firewalls or routers, and the > final IPsec peer. Yes, that's true up to the final hop. At the final hop, when the destination address is local, then one *might* receive an ICMP Parameter Problem because the SPI is not recognized. Maybe. If it does not, then the sender will send another packet with TTL one larger, and then when it gets no reply try again with two larger, etc. Receiving ESPping reply with SPI=8, would be a positive reply that the path was clear (in both directions!). One thing which the document does not say, and I'm not sure what to say, is what the TTL of the ESP reply ought to be. I was contemplating if it should copy the TTL of the incoming packet. That would weirdly let one traceroute in the reverse direction too, only the ICMPs would go to the receiving host, which is not the host doing the traceeroute, so not very useful actually. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Panwei (William) wrote: > If you want to do the traceroute to determine how far ESP actually > gets, you need to make sure every node supports the ESPping. No, only the final machine. Others would respond with ICMP unreachable when TTL=0 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Paul Wouters wrote: >> If you want to do the traceroute to determine how far ESP actually >> gets, you need to make sure every node supports the ESPping. > I think people meant to extend traceroute to use an ESP packet instead > of an ICMP or UDP packet. The machines in the middle do not need any > special support because any packet that hits TTL=0 should solicite > an ICMP response. That's right, and we yeah, we can do that immediately. Perhaps obviously: The responding server needs to implement this protocol in order to get a reply though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Panwei (William) wrote: >> I'm not sure I understand how you get this from the Problem >> Statement. >> Clearly, we need to clarify the purpose. >> It's not about detecting NAT, it's about determining if ESP will work or >> not. >> It's not about detecting or avoiding *NAT* per-se. >> We prefer not to have to encapsulate. > Please forgive my ignorance of the scenarios. My understanding is that > ESP failure is usually because of the existence of NAT. > Do you mean ESP may not work even if there is no NAT between the two IPsec peers? > If yes, I'd like to know more about how ESP failed and in what kind of > situations ESP will fail. usually, a bad firewall. One that allows UDP traffic (port 500/4500), but not proto=50. For IPv4, there will often be NAT, so the proto=50 firewall doesn't matter, as one has to UDP encap anyway. >> I think that you are over-estimating the competency of some operators: >> the experience with IPv6 is often not there. >> Even when it is, not all equipment vendors are equally competent at >> implementing/documenting things. > Is this problem, i.e., IKE works but ESP doesn't work, only exist in > the IPv6 network? Does IPv4 network have the same problem? Yes. It could exist in IPv4, and I've seen it, but NAT44 means you seldom notice. > Second, will UDP encapsulated ESP get through in these circumstances? Probably. >> The purpose of this protocol is to allow that debugging. >> The network operator people, who are not allowed into the billing >> system, can instead use an ESPping utility to send ESP traffic, adjusting >> their firewalls until they understand that UDP!=ESP. > 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 receiving a response? That there is a problem with proto=50... So: a) do UDP encap (maybe by manual config, if you are clueful) b) call network support and file a problem report. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Panwei (William) wrote:
> I feel that the problem of IPv6 ESP traverse failure, as described in
> the draft and presentation slides, is because of NAT. IKEv2 already
I'm not sure I understand how you get this from the Problem Statement.
Clearly, we need to clarify the purpose.
It's not about detecting NAT, it's about determining if ESP will work or not.
> supports the detection of NAT. After the detection of NAT, the peers
> can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use
> cases that this existing solution doesn't work and this draft tries to
> solve? Or, are there some use cases that IKEv2 fails in detecting the
> existence of NAT?
It's not about detecting or avoiding *NAT* per-se.
We prefer not to have to encapsulate.
I think that you are over-estimating the competency of some operators: the
experience with IPv6 is often not there. Even when it is, not all equipment
vendors are equally competent at implementing/documenting things.
Imagine a situation where IPsec will be used in a (sub)site to site
configuration. For instance, between a billing system and an outsourced
credit card processor. {Not replacing TLS, but in addition to}
The administrators of the billing system request "IPsec" from their (inhouse)
network operator, and the operator looks up their howto list, and enables UDP
port 500 and 4500, because that's what IPv4 wanted.
Now the billing system people wonder why the it seems to work, but in fact no
traffic gets through. It can be very hard to debug.
The purpose of this protocol is to allow that debugging.
The network operator people, who are not allowed into the billing system, can
instead use an ESPping utility to send ESP traffic, adjusting their firewalls
until they understand that UDP!=ESP.
We also realized that one can write/modify traceroute to use ESPping to
determine how far ESP actually gets.
There are also situations where there are ECMP routers in the way which
simply do not know what to do with ESP. A network operator could introduce
such a sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Panwei (William) wrote:
> Hi Michael,
>> > At yesterday's meeting, I think people basically understood and >
>> accepted the problem statement itself, but also raised different >
>> ideas regarding to the solutions. We'll try to do more analysis > and
>> comparison of possible solutions, including what you > suggested.
>>
>> I think that one thing that is unclear to me is whether the different
>> RANs can tolerate that all the different traffic share the same *IKE*
>> SA.
wei> [Wei (William) Pan] We did consider this before. Sharing the same IKE
wei> SA can partly release the pain, but not much. Assuming there are N
The reason I ask is if you can *NOT* share the IKE SA, then one solution is
to just give each base station a bunch of IP addresses. N of them.
Given RFC1918 this might be limiting. Given IPv6, a /64 per base station is
plenty. The advantage of that is that rather than having a VPNID, one has a
source/destination pair per RAN.
How are the base stations connected? Is it ethernet to the basestation?
Or do the base stations have direct fiber connections to each other? What
does the physical connectivity look like? I also wonder if there is a
metro-ethernet occuring, if the full mesh isn't overkill because the
metro-ethernet has other topological issues. {This question is mostly just
for my full understanding}
wei> the base station is deployed in a crowded area. We got from the
wei> customers that they want to double the number of operators sharing the
wei> RAN. Therefore, this solution isn't scalable enough for this need and
wei> future expansion.
What is the order of magnitude of N and M today?
2^4? 2^8? 2^16?
When you double, what is the starting order?
>> The next level is whether or not they can tolerate being in the same
>> CHILD SA. We could put the "VPN ID" at another layer (inside the
>> common tunnel), such as some kind of L3VPN, GRE, VXLAN.
wei> [Wei (William) Pan] Do you mean first encapsulating the original
wei> traffic into a tunnel that can carry the VPN info and then
wei> encapsulating the tunneled traffic into the IPsec tunnel? My initial
wei> feeling is that there may be operational and maintenance
wei> difficulties. We can have more thinking on this and reply later.
Yes, if you can tolerate the CHILD SA traffic being shared between all the
RANs, then having a new layer would let you scale without concern for IPsec.
You didn't answer that question: can they tolerate this?
Also, I think that this traffic is control plane traffic that allows for the
mobility of the devices attached to these base stations. I don't know the
3GPP protocol names for that.
But, does it also include encapsulated end-customer traffic?
I would assume that each base station has an SA to connect it to each of the
RAN's concentrators. L2TP or something like that.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Panwei \(William\) wrote: > At yesterday's meeting, I think people basically understood and > accepted the problem statement itself, but also raised different ideas > regarding to the solutions. We'll try to do more analysis and > comparison of possible solutions, including what you suggested. I think that one thing that is unclear to me is whether the different RANs can tolerate that all the different traffic share the same *IKE* SA. The next level is whether or not they can tolerate being in the same CHILD SA. We could put the "VPN ID" at another layer (inside the common tunnel), such as some kind of L3VPN, GRE, VXLAN. > we'd like to know more if it's OK. Switching to a new protocol is > still a reasonable solution for us, although it has pains. Developing > a new protocol in IETF will cost time, we'd like to adopt the new > protocol after it's standardized. But we need to solve our problem I don't think you need any new protocols, but maybe new ways to combine existing protocols. For instance, some IKEv2 support for configuring VXLAN. But, this depends upon the *security* and traffic isolation that you need. For instance, do you have issues of traffic accounting between the RANs that occurs on the outside (ESP) packets. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [furry13/ipsecme-esp-ping] Abandoning non-reserved SPIs (PR #6)
Jen Linkova wrote: > On Wed, Feb 28, 2024 at 7:12 AM Michael Richardson > wrote: >> In github issue: https://github.com/furry13/ipsecme-esp-ping/pull/6 >> >> I said: >I am not in favour of any link to IKE. >> >> I don't think it's useful to signal in IKE that the host/gateway >> supports SPI=7. I believe in many debug situations, the person doing >> the diagnostics won't have a credential that they can use in IKE, and >> the person that has that credential (it could be a physical token) >> won't know how to do the debugging. >> >> Consider a scenario where some branch office regularly has an external >> auditor physically present. Said auditor expects to operate their >> Remote Access VPN from their laptop, for which they got permission >> some years before. Central IT turns on IPv6, and everything is great, >> but they didn't think to enable ESP (because NAT44 rules, right?). >> Assume auditor's VPN hub supports IPv6. > [skip] > In your scenario announcing ESP Ping capability in IKE is useless but > harmless. I mostly agree. > You seem to assume that ESP ping is only used by humans > troubleshooting the network, but think about other case: a device (a > phone, for example) is going to establish an IPsec session to a VPN > server or, even better, a voice gateway (as WiFi Calling requires > IPSec). Sure. > Currently, if IKE succeeds but ESP fails, it's very hard for > the device to detect the issue. If the peer supports ESP ping and > announces it in IKE, the device can use ESP ping to find out > that..ooops, the corporate WiFi the device is connected to is having > issues with end2end ESP connectivity, and switch back to the mobile > network, instead of blackholing the data packets. If there is an IKE SA that works and is up, then we can easily negotiate the right TS to enable an appropriate ESP-encrypted ICMPv6 (echo request) PING to a target system. This is not spoofable or even detectable by an adversary. I would encourage someone to write a really short I-D that defines an IKEv2 NOTIFY that contained an IP address at which a gateway is willing to entertain ICMPv6 Echo Requests to. That would fit into the defined TSr. In many many environments, that would be the IPv6 address of the inside interface of the gateway. But, in some esoteric situations, it would need to be some other address. In such an I-D, we could argue whether or not the address has to fit into TSi/TSr. (There are arguments both ways) That wouldn't be an SPI=7 thing though, so I'd want it another document. > So I do not see any harm in advertising it in IKE but I do see some > benefits - but I clearly might be missing smth here. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [furry13/ipsecme-esp-ping] Abandoning non-reserved SPIs (PR #6)
In github issue: https://github.com/furry13/ipsecme-esp-ping/pull/6 I said: >I am not in favour of any link to IKE. I don't think it's useful to signal in IKE that the host/gateway supports SPI=7. I believe in many debug situations, the person doing the diagnostics won't have a credential that they can use in IKE, and the person that has that credential (it could be a physical token) won't know how to do the debugging. Consider a scenario where some branch office regularly has an external auditor physically present. Said auditor expects to operate their Remote Access VPN from their laptop, for which they got permission some years before. Central IT turns on IPv6, and everything is great, but they didn't think to enable ESP (because NAT44 rules, right?). Assume auditor's VPN hub supports IPv6. Auditor+Auditor's local host: "Hello, IT. The VPN that has works for *Auditor* since 2007 has suddendly stopped working. It was approved in ticket #87245 back in the day." IT: "Uh. When did it stop? When we enabled IPv6. Oh." ESP Ping means that the IT can effectively send ESP packets from some host *they* control at the branch office, aiming at the Auditor's VPN end-point. They don't even need ESP Responses to work, but it's sure nice if they do. Further, ESP Ping could be used in a *traceroute* like way using TTLs to determine how far the ESP Ping packet gets. traceroute --protocol=51 probably gets one 2/3 of the way there, but maybe not all the way. In the process, they discover some IPv6 firewall which thinks only TCP and UDP exist, and it gets fixed. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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. Either trust IKEv2 to detect the attacker, or don't :-) Meanwhile, a major goal here is to debug paths that have unintentional active on-path mis-configurations from screwing things up. > The RFC already says that even without negotiation, any IKEv2 peer may > decide to switch from ESP to ESPinUDP or ESPinTCP and back. And Linux > does not support any of this switching. okay, sure. It seems like a good thing. Maybe IKEv2 peers ought to be told if the kernel detects a change, and report that, and maybe even in a Notify. (I think, but I'm not certain, that an ESP can be turned into an ESPinUDP without affecting the crypto. Why would the network or attacker want to do that? I dunno.) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 > got stuck. > Let's say a device sends an ESP Echo request packet but no replies are received. > How can the sender differentiate between: > - there is a problem with e2e ESP connectivity > - the receiver doesn't support ESP Ping, so the packet with SPI=7 is > just silently discarded? They can't. That's okay. When they determine that they can't prove good connectivity, they will start investigating the source of the bad connectivity, and the next step would be to go to the receiver side and start ESP Ping Requests. Note that they do not necessarily have to do that from the IPsec gateway machine. They do discover whether it supports this feature, though, which helps them distinguish the case. Yes, often this involves walking some inexperienced person through some menus they didn't know about, and that has failure cases all of it's own. But, for the case where two semi-competent admins are debugging a site-to-site tunnel configuration, there is still a win. It is possible to send ESP Ping Requests (in IPv6 world) from any machine behind the gateway, assuming the gateway doesn't try to put them in a tunnel, *or* from any machine adjacent to the gateway. It's the plug my laptop in on the DMZ and debug stuff technique. > 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... No, let's not go there. I thought we had an ICMP Parameter Problem that was to be returned on unknown SPI. While perhaps something that many implementations would turn off, it would also allow one to distinguish the two. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 probably should be an ICMPv6 packet encapsulated into ESP. > Is there any reason we can't just use an existing SPI to send ICMPv6 packets? > Off-top of my head: > - what source/dst addresses to use, > - it could be a problem if the peer's configuration doesn't allow pings. The "more generic approach" is actually way way way more complex for the reasons cited above. Secondly, the "more generic approach" has really nothing in common with the ESP-ping mechanism, and there is really no overlap. I have no problem with developing a *second* approach, because I think that they solve different aspects of the diagnostic problem. The two points above (src/dst to use, whether or not policy allows) need to be solved with some amount of IKEv2 level negotiation and/or Notify. While the whole point of the SPI7/8 mechanism is that it can be operated completely without IKEv2 involved at all. I would prefer to adopt this document to solve the primitive diagnostic problem. There are a number of problems/challenges in the currenct solution which I think that the WG can address, once we agree on the problem we are trying to solve. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 actively attacked by network operators in > oppressive regimes. These regimes often will cause odd failures that > ensures the enduser keeps trying because if somewhat/sometimes works, > which stops those users from trying another protocol that the operator > cannot block yet. > I could see how those network operators would reply to these probes, > but still mess or block the real traffic. > I think the signal of "this network can transport this ESP" should come > from the endpoints and not be falsifiable. 1) I'm in favour of supporting this stronger assertion of communication. But, it requires that IKE be up, working, and able to negotiate. Sometimes that's just too much to figure out when working with unsophisticated end-users and/or administrators. 2) I still think that the reserved SPI concept is worth standardizing, because sometimes it's just really basic debugging one needs. Being able to puzzle through a series of nodes where one is screwing with ESP, and being able to "up-arrow-return" to try again is a good feature. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 > applications, would it work? How would ESP Ping responses correlate to > multiple instances sending ESP Ping from a sender? I feel the document > might need to define a specific payload format. This format would help > us correlate responses with their respective requests, the ESP ping ID > and sequnce number proposed in I think we should define something for SPI=7/8. (I'm not actually certain we should use two SPI numbers. There are pluses and minuses here) I think that the problem ESP PING for a negotiated SA is rather a different problem, and that while we might re-use the packet format, I think it's a significantly more complicated. (Because it does more) I think that something with proto=59 might be right, but there are other choices, and I think that it might turn out that we are actually defining some kind of ESP-dead-peer-detection mechanism. That we should simply have the kernel report receipt of PING/discard packets (on SA #1234) to the IKE daemon, and let it do the correlation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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. The goal is more: Is there something in the network that prevents us from speaking IPsec to x.x.x.x? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 an SPI value >> previously negotiated through IKE and set the Next Header value to 59 >> (No Next Header). The receiving IPsec peer, having established ESP >> through IKE, MAY issue an ESP Echo Response. When replying to an >> encrypted ESP Echo Request, the ESP Echo Response MUST be encrypted >> and utilize the corresponding negotiated SPI." > As I'm not really an IPsec expert, I'm not sure I understand how it > would work. Let's say a device A sends an ESP echo request packet > using an existing negotiated SPI. Then it receives an ESP packet back, > and that packet uses the negotiated SPI and has the next header set to > no next header. How would that device A differentiate between: - an It's just that the two negotiated SPIs have no relationship. Some systems know that they are related, but in general 4301 says that kind of thing belongs up in the key manager. My opinion (also as a new co-author) is that we should not attempt to support echo request/reply for existing SAs. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Yoav Nir wrote: > - Although it is implied, it should be stated explicitly that > TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As > some child SAs get deleted and perhaps not rekeyed if they’re idle, if > traffic picks up again, new child SAs with these TS can be created > until the peer again blocks you with a TS_MAX_QUEUE. Do you think it be better for each end to announce a maximum ahead of time? (At negotiation of the first child SA) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
I have read the draft. I think the draft could advance as it is. I have a few editorial comments, which authors may take with a grain of salt. On the implementation considerations: } This information } MAY be used by the peer to select the most optimal target CPU to } install the additional Child SA on. For example, if the trigger } packet was for a TCP destination to port 25 (SMTP), it might be able } to install the Child SA on the CPU that is also running the mail } server process. Trigger packet Traffic Selectors are documented in } [RFC7296] Section 2.9. It's not a bad example, but probably not very useful. I would say that many scalable gateways will use some kind of ECMP cache to direct flows of traffic to specific CPUs in order to keep packet re-orders to the minimum. The utility of that trigger packet is to be able to pull that flow out. section 3: } Upon installation, each resource-specific Child SA is associated with } an additional local selector, such as CPU or queue. These resource- } specific Child SAs MUST be negotiated with identical Child SA } properties that were negotiated for the initial Child SA. This } includes cryptographic algorithms, Traffic Selectors, Mode (e.g. } transport mode), compression usage, etc. However, each Child SA does Why is it a MUST that the new Child SAs need to use the same algorithm? It seems like that there could be situations where some CPUs are better at AES-GCM and others are better at ChaCha, and that would seem to be okay. Maybe SHOULD is enough? Is there a reason to reject a proposal because it didn't match the other SAs (but is otherwise within one's policy) > * Optional Payload Data. This value MAY be set to convey the local > identity of the resource. The value SHOULD be a unique identifier > and the peer SHOULD only use it for debugging purposes. If the presence of the payload is optional, and I always omit it, then it won't be unique, will it? Is that a problem? > And > bringing the deleted per-CPU Child SA up again immediately after > receiving the Delete Notify might cause an infinite loop between the > peers. I think this coud use an example. > Another issue Perhaps it's a new paragraph. > the first Child SA without ever activating any per-CPU Child SAs. It > is there for RECOMMENDED to implement per-CPU SADB_ACQUIRE messages. s/there for/therefore/ > intended CPUs is RECOMMENDED. An implementation MAY limit the number > of Child SAs only based on its resources - that is only limit these > based on regular denial of service protection. Although having too > many SAs may slow down per-packet SAD lookup. can an implementation that returns an TS_MAX_QUEUE at 13:05, then have more resources at 13:07? How long should one remember that one ran up against the maximum? > If this method is supported, >implementations must be careful to move both the inbound and outbound > SAs. what is the consequence if they don't do this? > For example, > using the CPU number itself as identier might give an attacker > knowledge which packets are handled by which CPU ID and it might > optimize a brute force attack against the system. An attacker that can see into your IKEv2 packets, can also do many other things. They are a peer. I think this is poor advice. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Daniel Migault wrote: > As far as I understand it, yes, the two end sites are managed by the > MNO. So they should be able to either coordinate DSCP values (use the same ones), or they should know how to translate them between sites (before entering tunnel and/or after exiting tunnel). -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Tero Kivinen wrote: > If we agree on the inner DSCP values, but map them differently that > does not actually matter as long as we never bypass some DSCP values > while mapping others, as every packet in the tunnel will have same > outer DSCP value thus will receive same processing in the internet. Are the two ends/sites in the same administrative domain? > I think the easiest way of doing that is to add DSCP Status Notify and > use it like this: I agree. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: >> > Or use IPTFS and set your own max packet size sufficiently low? >> >> I think that this is the killer app for IPTFS. >> > But of course this means either IPTFS should be able to auto-tune this, > or else we end up with hardcoded configs that might stop working or > cause future problems. I think that the ESPping mechanism is the right way to do "PLPMTUD" for IPTFS. (for the outer MTU) >> > I'm not convinced doing this between IPsec peers will solve any real >> > use cases. >> >> I am also skeptical, but I don't object to the work getting >> standardized. >> >> In particular, for networks where there are MTU constraints on the far >> side of the far gateway, telling the sending gateway about the MTU has >> a far higher chance of working than anything else. The sending >> gateway probably can send PTB ICMPs with better results. > There would need to be dynamic updating, kernel <-> userland > communications, etc. Just hardcoding this in an ikev2 configuration > would be pretty bad. yeah, I don't know exactly how to do the userland communication. How specific does it need to be is my question? How express that. Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow which has the MTU concern. It's mostly clear when it appears along with TSx that it applies to that traffic, but not for the other notifications. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Christian Hopps wrote: > You're confusing inner and outer traffic here. When your egress > endpoint decaps the tunnel traffic, and then that traffic won't fit on > it's egress red link on your egress endpoint is going to send an ICMP > too big message back to the ingress router *inside the tunnel*. This > has nothing to do with the routers that carry the tunnel traffic. Assuming that this ICMP "fits" inside the tunnel. For bog-standard site to site VPNs, that mostly means that the source IP of the ICMP has to be the red link's IP. That's hard to get right, and Linux certainly does it wrong in my experience, using the outside IP. For a gateway that is linking two subnets, which are NOT directly connected, then it's even harder to get that ICMP right. This is where I think some other signal would be better. >> We do have mid tunnel fragmentation (with IPv4 of course). DF=0 is >> also preferred over dropping packets which results in a blackholing >> situation. > Can I ask, who is providing this mid-tunnel fragmentation service for > you? Your upstream provider, or a DFZ transit network like AT&T? I'm > curious b/c it's surprising that anyone is providing this service > anymore given it's an attack vector on their network. :) Yeah, but it still happens in IPv4. PPPoE makes it happen; the only way that it works with the bazillion banks that have ICMP turned off (because cisco pix default configuration of 20 years ago) is because IPv4 home routers fix the MSS. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: >> Christian Hopps wrote: >> The ingress node >> encrypts this packet and adds the IPsec >> encapsulation, and this >> IPsec-processed packet is also larger than the >> Link MTU. The >> ingress node fragments this IPsec-processed packet and >> sends all >> the fragments to the egress node. >> >> > This should not happen. The ingress node should first fragment the > >> inner IP packet so that it fits in the tunnel (i.e., so that the ESP > >> packets it creates do not violate it's own MTU). >> >> You can't do that if DF=1, or IPv6. You can form big ESP packets and >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is >> good, until there is a firewall that cant cope with fragments. > Why does any of this even matter? The applications should use PLPMTUD / > DPLPMTUD ? 1) For TCP things. We also have RFC9268 now. 2) how can we get it turned on by default? I tried to make this case to Linux distros and kernel people, but there is a lack of evidence that it is safe, and the people who might have the evidence (at scale) don't want to do it. 3) the gateways really have no idea if PLPMTUD is being done, and sometimes it's better to just make things work. > Sprinkling bits to try to communicate with hops in between hasn't > worked for decades. Agreed. PMTUD is a fail. > Or use IPTFS and set your own max packet size sufficiently low? I think that this is the killer app for IPTFS. > I'm not convinced doing this between IPsec peers will solve any real > use cases. I am also skeptical, but I don't object to the work getting standardized. In particular, for networks where there are MTU constraints on the far side of the far gateway, telling the sending gateway about the MTU has a far higher chance of working than anything else. The sending gateway probably can send PTB ICMPs with better results. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Christian Hopps wrote: >> The ingress node encrypts this packet and adds the IPsec >> encapsulation, and this IPsec-processed packet is also larger than the >> Link MTU. The ingress node fragments this IPsec-processed packet and >> sends all the fragments to the egress node. > This should not happen. The ingress node should first fragment the > inner IP packet so that it fits in the tunnel (i.e., so that the ESP > packets it creates do not violate it's own MTU). You can't do that if DF=1, or IPv6. You can form big ESP packets and then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant cope with fragments. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 nice to be able to put enough padding to make packets at >> least 1280, ideally 2048 bytes in size. >> >> that would let us diagnose MTU issues better. > That (0-255 bytes) is leftover from the figure I copied from the > RFC4303, where it was part of the length of the padding field. In my > case I did assume that payload can be of any length, so I agree on your > fix... 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 suppose it would be good to have a value at the beginning of the packet (closer to what an ICMP PTB might successfully return upon failure) to say how big the packet was. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: > On Aug 1, 2023, at 12:56, Daniel Migault wrote: >> >> Hi Ben, Just trying to position our understanding of the position >> between the ICMP PTB and the IKE PTB. If an incoming Encrypted packet >> is larger than the Link MTU > How can than be? You mean you received an ESP or ESPinUDP that after > decrypting was too large for the link you need to send the decrypted > packet on? That seems really odd. Odd if you think it's all 1500 byte ethernet. And there are no further tunnels. Could come out of an ESP SA and try to go into an ESP-in-UDP SA, and it might not fit. Many people would like to use 9000 byte ethernet across VPN links. Such as the physical people. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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, ideally 2048 bytes in size. that would let us diagnose MTU issues better. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
DSCP is mutable enroute. The numbers are from a palette of actions. It is explicite in the DS architecture that ISPs may and SHOULD remark it across boundaries. (I recall the diffserv WG 23 some years ago.. and I've been an operator of b2b VoIP, and we had to make sure we did not allow packets to enter with marks we did not trust in order to protect our VoIP network against outside attack) The recent situation where certain DSCP values have become "constant" is peculiar. (the palette has ossified) I think that there are recent documents that may make this peculiar situation more permanent, but I can't speak for what's going on there. IPsec receivers MUST NOT check what's on the outside DSCP, and probably SHOULD NOT care whats on the inside, although remarking makes sense. I don't understand this part of the discussion... it is totally outside of what the document is about: Tero quotes RFC4301, and it's totally a concern that if packets in the same IPsec flow get marked (or remarked) differently then that could delay them, and replay windows might close. Tough... the network probably remarked them for a reason, and the alternative was probably dropping the packet. I have read through ipsecme-ts-dscp, twice, to be sure I got it. I understand that the problem is distinguishing between different DCSP values that will be allowed into a single IPsec SA. There is perceived to be a need to communicate this in the IKE negotiation for the SA. So, it doesn't matter if the gateways have twenty IPsec SAs for the twenty classes of services that they want to support, there could yet be more DSCP that do not fit into any SA (and that traffic should be dropped, or maybe should cause an ACQUIRE, or maybe not encrypted, or...). Each of the twenty SAs need to distinguish what goes into each SA. [What goes on the DSCP on the outside is entirely a different question. Copy DSCP is only one possible action, yes, with consequences noted in 4301] (The argument about limited number of SAs does not really ring that well for me, but I'll accept it in the scale of hundreds of thousands of tunnels. Prioritizing voip flows for remote users over HTTP downloads sounds reasonable, particularly for enterprises that insist all traffic go through HQ) Where I have a problem with this document is that in the remote-access situation, there is no value in the laptop system telling the gateway which kinds of DSCP it wants, because the laptop system has NO IDEA what the DSCP markings are at HQ. The gateway SHOULD just be configured correctly. In the case of gateway to gateway situations, it would assume that gateways are each in the same DSCP namespace. So it's a site to site VPN for a single enterprise, and so AGAIN, it can also be configured correctly. In the unlikely case that this is a VPN tunnel between two different enterprises (it does happen, but it's unfortunately rare, maybe Ben will fix that), then the DSCP code spaces are completely different, and it ALSO makes no sense to negotiate DSCP as a traffic selector. I see Joel Halpern as a co-author. Perhaps Joel can better articulate what real world problem this is really trying to solve. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
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 existing session until the > problem is detected and fixed with another migration. Oh, that's really sad to hear. In v6ops a point was made that ESP was the evidence that Extension Headers are already commonly in use. It was, even for me, a "oh yeah, that's right" > In many cases, I think a simple "pre-flight check" to see if ESP is > supported on a given network path could solve this problem. So after a > few conversations with folks here I put together this draft. It > provides the equivalent of an ESP ping packet. Comments and feedback > appreciated. This is a really good idea. PLEASE ADOPT already. Let me suggest that while a Header value of 59 is good, it would also be interesting to put IPv6-ICMP type/code ICMP Echo Request in. This would allow the size of the ESP packet to be made arbitrarily large, eliciting both ICMP Too Big fragments, but also RFC9268 processing to occur. I like that we could clearly write an "esping" command that would operate without any IKEv2, etc. Years ago I advocated for a situation like this during the interop tests, just to even be sure that we'd typed in the right peer IP. Two hours wasted as peer A kept trying to initiate to peer 4231 rather than 4321... If esp echo request is implemented in a kernel, then bullet point two: * An attacker can use ESP Echo Request packets to determine whether a particular destination address is an ESP endpoint. This is not a new attack because any endpoint that supports ESP must also reply to IKE INIT packets. might not be true. End points that aren't running IKE might also reply to ESP Echo Requests. This might be a feature. Or a bug. It might be that kernels ought to have a sysctl or ioctl against the IKE socket that would turn on ESP Echo Request processing. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RISAV proposal at SECDISPATCH
Benjamin Schwartz wrote: >> 3. How do ACSes communicate with ASBRs? > In my view, this is an "implementation detail" within a single AS, and is > out of scope for the draft. Personally, I imagine the ACS being an anycast > service implemented across all the ASBRs, using a distributed database. I agree. There will communities that will want to implement a standard so that they can buy commodity silicon for the ASBRs, but they don't need IETF. If they do want something, there is FORCES: (RFC3746 and friends). -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RISAV proposal at SECDISPATCH
Benjamin Schwartz wrote: >> Benjamin Schwartz wrote: > In Transport Mode, the >> thought is mainly to _avoid_ traffic > engineering, and instead be >> able to deploy RISAV with confidence that > your existing TE will not >> be altered. >> >> I thought you replaced the destination address with that of the ASBR? >> > In Tunnel Mode (ESP), the source and destination addresses are > replaced. (By default, they are "contact IPs", i.e. ACS addresses, but > ASBR addresses can be substituted using IKEv2 Active Session Redirect.) > In Transport Mode (AH), they are unmodified. > My understanding is that this is how ESP and AH are conventionally > used. Yes/no. If the destination address of the packet is still the real destination, and not the ASBR, then the packet isn't for the ASBR, and won't get processed by it. So, either your transport mode has to change the destination address on the packet, and recover/store the real one somewhere (much like SR6 does), or, it's really some kind of L2 function going on here, and not really IPsec at all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RISAV proposal at SECDISPATCH
Benjamin Schwartz wrote: > In Transport Mode, the thought is mainly to _avoid_ traffic > engineering, and instead be able to deploy RISAV with confidence that > your existing TE will not be altered. I thought you replaced the destination address with that of the ASBR? mcr> The other concern that I have with RISAV is that it seems unreasonable mcr> that mcr> an AS have only a single ACS. Maybe this can be accomplished via an mcr> anycast situation, > Yes, personally I imagine implementing the ACS as an anycast service. I think that the system would be better if that was explicit. >> I can imagine a situation where the ACS together, pick an appropriate >> pair of ASBRs to form a tunnel between them. >> >> Should a global ISP should be hairpinning traffic across the Pacific >> when it secures traffic between two AsiaPacific entities? >> > Obviously not, and RISAV intends to avoid that. ... > I like the idea of a new WG, especially since IPSECME seems quite busy. > However, I do think the various multi-SA/multi-sender drafts in IPSECME > (esp. [1][2]) should be in the same WG as RISAV, as it depends heavily > on that capability. We have to get simultaneous IPsec, 6man and BGP review. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] RISAV proposal at SECDISPATCH
TL;DR> Important work needing New WG in Routing Area. Hi, I thought I had read previous versions of RISAV... maybe under a different draft name. I find this version much better than I saw before. I have some specific technical comments about how to make this work simpler, but that's not a topic for SECDISPATCH. This document proposes to amend AH to distinguish it from other uses of AH, and I think that this is a very good idea. AH has essentially no deployment at this point, and so this is rather a good plan. The concerns that I have about this document is that the IPsec/AH parts of it are rather simple. The IPv6 header insertion and MTU parts of this document are, I think very controversial given the SR6 experience: SR6 was said to be always within an AS, and that any leaks would be a bug. But, the ENTIRE point of RISAV is to communicate between ASs. I also think that there is a lot of BGP-like TE that is missing from this proposal. Although I run a BGP AS with multiple uplinks, I don't know all the latest stuff about MED and how to deal with situations where two ISPs connect in multiple places. The other concern that I have with RISAV is that it seems unreasonable that an AS have only a single ACS. Maybe this can be accomplished via an anycast situation, which to me implies some kind of MOBIKE-like situation where the anycast IKEv2 respond answers with it's topologically useful IP. I can imagine a situation where the ACS together, pick an appropriate pair of ASBRs to form a tunnel between them. Should a global ISP should be hairpinning traffic across the Pacific when it secures traffic between two AsiaPacific entities? While this could be dispatched to IPSECME, I don't think that is the right choice. I think that we might need a new WG in the routing area with a SecAD owning it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Tero Kivinen wrote: > I mean what should other end do if the other end says he will not > do anti-replay checks? Not send unique relay values in the ESP. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07
Valery Smyslov wrote: >> > Thus, what do you want to see in the third column? "Defined in RFC >> > 7296"/"Defined in this document"? >> >> You could say, "STD79", and "Section X" if you like. > I prefer "RFC7296", as it's better known than "STD79" :-) Yet, it's incorrect. It fails to include the updates, and it goes stale. It also wastes all the effort we put into bringing it to Internet Standard. > The similarity between IKE_AUTH and GSA_AUTH is that both complete > authenticating peers and creating IKE SA. The difference is that > IKE_AUTH in addition creates unicast Child SA, so the set of payloads It does? >> > Note, that RFC 7296 includes a concept of one-way IKEv2 messages >> (for > error notification in case no IKE SA exists). >> >> Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY >> is not. > GSA_REKEY is "inside" a multicast rekey SA (which is different from > initial GM<->GCKS IKE SA). I think that this new SA needs to be introduced. I think that there need to be some diagrams. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07
Valery Smyslov wrote: > Thus, what do you want to see in the third column? "Defined in RFC > 7296"/"Defined in this document"? You could say, "STD79", and "Section X" if you like. >> I don't understand GSA_AUTH vs IKE_AUTH. I think that's an IKEv1-ism >> to split it. > Why? When you need to substantially modify the behavior of the exchange > you have two options - either indicate its purpose with some notify or > introduce a new dedicated exchange. GSA_AUTH substantially differs from > IKE_AUTH, so what's wrong with introducing a new exchange type for it? > After all, we did it before (IKE_SESSION_RESUME, IKE_FOLLOWUP_KE). I guess that I'm completely unable to understand what GSA_AUTH needs to do that's different. >> I'd consider leaving it out, or discouraging it. Obviously, one can >> just never compress, but it seems like it's been a PITA to implement. > IPcomp is optional, you don't need to implement it. It can be useful if > the traffic is compressible, especially taking into consideration that > multicast is always udp and IP fragmentation may be an issue. On the > other hand, if IPcomp is used for some group SA and later an GM is > joined which doesn't support it, then a sufficiently clever GCKS could > immediately rekey the SA with IPcomp off (taking a risk of IP > fragmentation). I'm saying, it adds complexity, which means additional test cases, and potential security holes. It seems unlikely to ever actually get used. > The GSA_REKEY is a pseudo-exchange, consisting of a one- way > IKEv2 message sent by the GCKS, where the rekey policy is delivered to > group members using IP multicast as a transport. This method is > valuable for large and dynamic groups, and where policy may change > frequently and a scalable rekeying method is required. Reasonable text, but with the clarification, I have many more questions :-) I think that it's conflating forwarding plane stuff with control plane stuff in a way that is really surprising.. >> propose some clarification text? >> >> It seems that GSA_RSAKEY is not an IKEv2 message at all then. > Why? It is a one-way IKEv2 message (but not an IKEv2 exchange!). It > follows the format for IKEv2 messages and it is processed very much as > usual, except that no response is sent. Does it travel from port 500 to port 500? I don't think so, but maybe I just don't understand. > Note, that RFC 7296 includes a concept of one-way IKEv2 messages (for > error notification in case no IKE SA exists). Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY is not. > I cannot speak for others, but I'm planning to implement it. And as > far as I know, draft 05 version of the IEEE Std 802.15.9 standard > (March 2021) specifies that G-IKEv2 is used for group key distribution > (but I'm not involved in this work). Almost nobody other that Tero has implemented 802.15.9/IKEv2. (That's a shame, and I wish it weren't so, but sometimes you have to respect the market choices) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07
value for > transform ID is added. We'll try to make the text more clear. > I'm not sure it is an update to 4301, since it requires no code change > for existing implementations. Is the KWK part of IKEv2 or is it part of ESP? >> I'm not sure if section 6.1 belongs here. > Why? It describes how PPK can be used (well, how complicated is to use > it :-)) with G-IKEv2 and also has some justification for alternative > way of using PPK (defined in drft-smyslov-ipsecme-ikev2-qr-alt). It seems like it belongs in smyslov-ipsecme-ikev2-qr-alt. I don't feel strongly. >> Who has implemented? > As far as I know early versions of the draft (incompatible with the > current one) were implemented by Cisco and by Tobias Heider and Tobias > Guggemos. The current version is partially implemented by myself. >> Or maybe I should instead ask: who cares? > I believe that there is some interest in this work. I cannot estimate > how strong it is :-) We shouldn't waste resources publishing documents that nobody plans to deploy. (We have enough to do...) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] comments on draft-ietf-ipsecme-g-ikev2-07
I started reading through this document during IETF115, but didn't finish until today. I don't think that I have ever read the IKEv1-G stuff. > G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because > they serve a similar function. They can use the same ports, just as > IKEv1 and IKEv2 can share port 500. The version number in the IKE > header distinguishes the G-IKEv2 protocol from GDOI protocol > [RFC6407]. G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which > would provide a better integration with IKEv2. G-IKEv2 MAY also use > TCP transport for registration (unicast) IKE SA, as defined in > [RFC8229]. Based upon this text, I would have no idea when/if I can send my G-IKEv2 packet to port 500 or 848. Section 2.2 recaps the payload acronyms. I suggest a third column telling us where they are defined. I think that GSA, KD, IDg, and SAg are new? Can I do unicast IKE_CHILD_SA echanges in the same PARENT_SA as I do G-IKEv2? I can imagine use cases where there is both multicast and unicast traffic that needs to be protected. I guess not, beacuse GSA_AUTH is not IKE_AUTH. Use of IPCOMP seems really difficult. I guess it can't be used until every receiver supports it. Is that common? Are the target use cases (probably video?) even compressible? section 2.4: GSA_REKEY The GSA_REKEY is a pseudo-exchange initiated by the GCKS, where the rekey policy is usually delivered to group members ... no response messages are sent so, does this violate the IKEv2 concept that all messages get acknowledged? I guess 2.4.1 answers that question. Maybe just leave the comment to 2.4.1. Are these IKEv2 messages sent in the normal port 500/848/4500 channel? Or? I don't understand this part at all. There are implications that it's multicast, but clearly, it can't be? "SID" is now rather overloaded in the IETF (CORE/YANG, SR6...), and perhaps another TLA could be considered :-) s/acieve/achieve/g in section 2.6. s/incement/increment/ s/thus making impossible/thus making it impossible/ I think that the end of section 2.6, aout reusing Extended Sequence Number should probably have more widespread review within the WG. This is not just a key mgmt issue, but an 4301 update I think. I think that KWK should be explained in the abstract in section 1. It seems a key architectural aspect of this document. I got lost in section 3. I am lacking architectural understanding. Perhaps there is some other background that I more strongly need to understand. I coudn't critically read Section 4, without higher level understanding. In general, I'd rather that this was an extension to IKEv2, rather than a new protocol. I think that IKEv1 was lacking enough orthogonality for that to have been practical before. I'm not sure if section 6.1 belongs here. Who has implemented? Or maybe I should instead ask: who cares? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)
Robert Wilton via Datatracker wrote: > I do wonder exactly how well understood "deprecated" is in the wider community. In the end, nobody really knows. The customers that read RFCs already knew IKEv1 was dead and replaced. The end customers that don't know, are still using their 2003 era equipment (maybe with 3DES). Often they have newer equipment (or firmware), but they lack the expertise to have enough confidence to adjust their configuration to do IKEv2. This document means that some more security auditors will now flag them for non-compliance, and that might free up resources to upgrade. > (i) the definition of deprecated in YANG (RFC 7950) is: > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. IKEv1 had this definition as soon as IKEv2 was published. Will this document move us beyond this definition yet? No. Devices will still ship with IKEv1 available (but maybe not default) because they still need to interop. But, at least we will get some more pressure to remove support from vendors. They can point at this document in their EOL announcements. > (ii) the definition in Java is: > A program element annotated @Deprecated is one that programmers are > discouraged from using, typically because it is dangerous, or because a > better alternative exists. Compilers warn when a deprecated program element > is used or overridden in non-deprecated code. > I think that the definition that security uses is presumably much closer to > (ii), or not even stronger in sentiment to move away from it? Yes, (ii) is way more about what we mean, but not having available protocol police, I don't think it really matters that much. > I tried to search and find a definition in IANA of exactly what deprecated > means, but with no luck. > Perhaps there is already a security definition of deprecated that could be > referenced, or if not, it might be helpful to: > - in Section 5, unambiguously specify what is meant by deprecated. > - in Section 7, bind the definition of the Status column back to Section 5. I'm not sure that a more precise definition will really help. Section 3 is also pretty clear: upgrade to IKEv2. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce
Valery Smyslov wrote: >> I am those that didn't read it during WGLC, or pay attention it before, but I scanned it. >> It seems to solve a problem that I don't think that I have. >> >> I do not object to publishing it. >> >> Given that Notify messages are available without a draft, it might be that >> what we have (an ID) is presently enough. >> (i.e. allocate it a Notify value, and just let it wait for some more people >> to implement it.) > the draft is also used in (now expired) draft-guthrie-ipsecme-ikev2-hybrid-auth. Yes, I'm not saying that the draft has no value. And since all it really does is allocate a Notify value (and document the structure for it), and *that* can be done without a draft (if you want a FSFC value). I'm saying that maybe just get the value allocated, keep the draft alive, and when (if?) draft-guthrie-ipsecme-ikev2-hybrid-auth finds some implementation, that it will all be ready. (by which point, many peple will have read auth-announce will many users) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce
I am those that didn't read it during WGLC, or pay attention it before, but I scanned it. It seems to solve a problem that I don't think that I have. I do not object to publishing it. Given that Notify messages are available without a draft, it might be that what we have (an ID) is presently enough. (i.e. allocate it a Notify value, and just let it wait for some more people to implement it.) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)
Paul Wouters via Datatracker wrote: > Also RFC 5723 states: ``` The keys and cryptographic protection > algorithms should be at least 128 bits in strength. ``` IF we live in > Grover universe, perhaps that should be 256 bits in strength? And since > we are making things quantum safe with this document, perhaps we should > then at least state session tickets should be 256 bits. Note if we do, > then this document must Update: RFC 5723. Perhaps this note on 5723 can > be added in the Security Considerations Section paragraph that talks > about Grover and Shor. My understanding of this document is that it tells us how to do multiple KE exchanges, as state in the abstrct: Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. It seems that if one wants a particular safety against a Grover universe, that we should update RFC8247, or create a companion document. I don't think that we should embed everything in this document. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual interim about re-designing ESP?
Paul Wouters wrote:
>> - How should the problems be solved?
>>
> Once we have a list, I think we can come up with plans to tweak ESP to
> tick off our list items.
> I do think we need some short presentations for an interim. Just having
> a free flow discussion will probably not be very useful.
We need a candidate list of items, then a slide / github issue per item, and
then we need to discuss enough such that all people have a deep understanding
of that item.
It could be that we have items which were duplicate, and it could also be
that we have goals which are really two goals.
{I think we are in complete agreement about how such a virtual interim should
go}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual interim about re-designing ESP?
I don't think that the constrained problems are really a good mix at all into a higher-performance ESP. We are talking about 10 to 12 orders of magnitude difference in network performance. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual interim about re-designing ESP?
Steffen Klassert wrote: > at the last working group meeting in London, it was quite some interest > to work on a re-design of ESP to make it fit to the multi-cpu case, QoS > classes, HW offloads etc. I agree with your idea in the subject, of a virtual interim on this. > https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt While there is a problem space section in this document, I found it a bit inadequate. I think that it is important to collect all of the challenges into a single set of goals. > The Google PSP Security Protocol (PSP) is another new 'ESP like' > protocol. There is some interest to standardize PSP, so the issues that > are solved there should also be considered when designing a new ESP > version. Most concepts that are used in PSP are taken from IPsec ESP, > so IMO this should be integrated into the IPsec protocol suite. It would be great to have the problems/challenges that this aims to solve, as well as the RAVSI concepts there too. > - What are the problems to solve? Let's get consensus on this aspect first. Maybe there are things that we might agree are out-of-scope, or are really implementation specific issues. That might mean a document be written, and the WG do a consensus call. > - How should the problems be solved? > Please let me know if there is interest, Thank you for bringing this up. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Adoption call for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
I have read draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt in it's various forms over the years, and again just now. I support adoption of the document and rapid publication. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance
Paul Wouters wrote: > I think this solution is such a small solution and already has running > code, that I would prefer the WG to quickly move this on, while also > beginning a separate discussion on how to do various different scaling I think that the multi-SA stuff should be really low impact to IKEv2, and we should just publish it. This would be the *interoperable* solution. > issues (and multi-cpu) in another way, eg by trying to work on an ESPv4 > version. But I would be sad if that work, which I expect will take some > time, would delay this draft. ESPv4 is a really good idea. It will require some experimentation... i.e running code. To that extent, we might need a WG document (not RFC) that explains how to do these experiments in a way that does not get in the way of an actual rough consensus. The experimental (non-interoperable) solutions might involve having actual hardware, so it may not as trivial as just changing a few lines of code. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] bid down to IKEv1
002 "dooku--ipv6" #14: Bid-down to IKEv1 attack detected, attempting to rekey connection with IKEv2 I've NEVER seen a real one of these in the field. I'm on a Eurostar train's wifi. Could it be some helpful NAT44? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] risav document at IPsec
Ben Schwartz wrote:
> 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>
>> > 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: RISAV in tunnel mode uses proto=50. Only transport mode
>> requests a
>> > new protocol number.
>>
>> And you'll add an outer IP header from ASBR to ASBR?
>>
> Not quite. The outer IP header is from ASBR to "contact IP". (There is
> only one "contact IP" per AS.)
So you propose to synchronize the SPI space across the entire AS?
How will replay windows and key management work?
> Here's one possibility:
> 1. The ASBR generates a 1524 byte packet.
> 2. It sends it (assuming the link MTU is big enough...)
> 3. Later, it receives a PTB reply.
> 4. It lowers its MTU estimate for this SA.
> 5. In transport mode, it strips the RISAV header off the ICMP echo payload
> and forwards the PTB to the original sender.
Yeah, so this basically doesn't work reliably in the remote access space, even
after
25 years of doing IPsec. ISPs that do this will lose customers.
>> If you think we need 1500 bytes of end-to-end MTU, I would be
>> interested to
>> > hear why.
>>
>> Because every single network/service/etc. that doesn't support that gets
>> into horrible MTU trouble.
>> I wish that wasn't true. I've pushed hard for PLPMTU to be turned on by
>> default, but it's not happening.
>>
> In 2014, a study from the QUIC team at Google found that 64% of Chrome
> users had a path MTU to Google of <1500 bytes (
> https://dl.acm.org/doi/pdf/10.1145/3098822.3098842, Figure 12). It sure
> seems like anything that assumes a 1500 byte MTU is already going to be
> broken frequently.
Yeah, yet, PMTU is still filtered by major banks and enterprises, and it's
still a disaster. Could google turn on PLPLMTU?
>> I don't see why you conclude this.
>> IP-TFS would be the tunnel between the ABSRs.
>> There would be one IKEv2 handshake per-pair of ABSRs, I think.
>>
> Yes. That means O(N^2) handshakes between each pair of ASes with N ASBRs,
> vs. just 1 (between the ACSes) for RISAV.
It's a nice idea, but I don't see how it's gonna work.
>> I guess your diagram has these ACS devices which are going to do IKEv2,
>> but I
>> don't really see how that's going to work at higher line speeds. One
chews
>> through keys very fast, as other drafts in the WG are trying to deal
with.
>>
> RISAV-AH doesn't have sequence numbers or replay protection, so you just
> repeat the handshake when you feel like it.
So, again, are you doing IPsec or not?
>> For the gain that you don't cause users TCP connections to fail.
>>
> I think you might be hinting at the fact that TCP generally relies on MSS
> clamping, not PMTUD. For RISAV, one approach would be to apply MSS
> clamping at the ASBR before RISAV is added, based on a path MTU estimate
> for this SA.
No, TCP has been forced by NAT44 already screwing with headers and PPPoE to
do MSS clamping to get around lack of working PMTUD.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] risav document at IPsec
{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
> 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: RISAV in tunnel mode uses proto=50. Only transport mode requests a
> new protocol number.
And you'll add an outer IP header from ASBR to ASBR?
Since transport mode will not fit into 1500 bytes, and will violate RFC8200,
why even bother? :-)
>> Even if you have the slimest possible pseudo-AH header, it will take at
>> least
>> a dozen bytes for the authentication data, which means at least 1520 byte
>> packets or so. None of them support >1500.
>>
> That's fine. We don't need 1500+24 bytes. We just need 1280+24 bytes,
(or
> 1280+73 in tunnel mode), so that the end-to-end MTU is IPv6-compliant.
Yes, but what if someone sends a 1500 byte packet?
> If you think we need 1500 bytes of end-to-end MTU, I would be interested
to
> hear why.
Because every single network/service/etc. that doesn't support that gets into
horrible MTU trouble.
I wish that wasn't true. I've pushed hard for PLPMTU to be turned on by
default, but it's not happening.
> I think I roughly understand the IP-TFS idea. I think that IP-TFS would
be
> preferable if it is easy to deploy, but I worry that it's not practical,
> for two reasons:
> 1. Scalability and efficiency. Compared to RISAV, IP-TFS would require
> * a much larger number of IKEv2 handshakes (one for each pair of
> communicating routers, vs. 1 for the whole AS pair)
I don't see why you conclude this.
IP-TFS would be the tunnel between the ABSRs.
There would be one IKEv2 handshake per-pair of ABSRs, I think.
I guess your diagram has these ACS devices which are going to do IKEv2, but I
don't really see how that's going to work at higher line speeds. One chews
through keys very fast, as other drafts in the WG are trying to deal with.
> * a larger amount of connection state (to hold all the different SAs)
> * a much larger amount of IP buffer memory (for fragment reassembly)
How many fragments you have to reassembly is somewhat configurable.
> * a somewhat larger amount of MTU overhead
For the gain that you don't cause users TCP connections to fail.
> 2. Routing interference and configuration
> RISAV-AH doesn't alter packet routing at all. The source and dest IPs are
> unchanged, so packets flow along exactly the same paths as they would
> without RISAV.
Yes, it does that by violating RFC8200.
Please ask for 6man time for this.
> RISAV in tunnel mode changes the destination IP to one IP for the whole
> receiving AS, but that IP can be anycast across all ASBRs, so routing
> should be similar to non-RISAV routing, and configuration is
> straightforward.
> IP-TFS requires each sending ASBR to pick a specific receiving ASBR. This
> creates a form of "source routing" that bypasses much of the usual BGP
> pathfinding.
I don't see how anything else is going to work, unless you create something
that isn't IPsec. I encourage you to do that.
> Recreating the baseline routing paths could be difficult or
> impossible, and might require O(N^2) active tunnels, for a pair of ASes
> with N ASBRs each. The simple RISAVAnnouncement that goes in the RPKI
> database would have to be replaced by a much larger configuration object
> that enumerates all the ASBRs and explains who should use which one.
> You mentioned earlier that this form of "source routing" might be
desirable
> in some use cases. That's an intriguing idea, but I would like for ASes
to
> be able to activate RISAV with a minimum of additional complexity,
> maintenance, and risk.
Geoff Houston has a presentation about this.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] risav document at IPsec
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. > The proposal would require allocation of a SPI for a destination address > which is not the receiving system of the SA. > It would be negotiated with IKEv2, but that part seems neither here nor > there. Ben, I asked on an (CDN) IX list if anyone supported >1500 byte packets. Even if you have the slimest possible pseudo-AH header, it will take at least a dozen bytes for the authentication data, which means at least 1520 byte packets or so. None of them support >1500. Now, private peering could certainly arrange 1600 byte packets, and I'll bet that many IXs could be persuaded to up their port limits, but this is a definite concern. ip-tfs lets you slice/dice packets so that they all fit into 1500, and maybe that would be a good option to consider. Different flows could have different treatments, all arranged by IKEv2. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
Tero Kivinen wrote: > My understanding is that this draft (which I have not yet properly > read) is solving the situation where the tunnel does not get ICMP PTB > messages as they are forwarding packets with DF bit set to 0, and then > the receiving end will see extra fragmentation happening for the > packets. Then the receiving end will simulate the ICMP PTB by sending > authenticated IKEv2 notification that tells the sending end that his > packets got fragmented. While I think that the authors think they are solving this problem, I think that what they have created is a protocol for dealing with fragmentation beyond the far gateway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
The other question is whether or not we can just leverage RFC9268 to do this. This is a recent 6man innovation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] risav document at IPsec
Yoav Nir wrote: > - also by Valery Inter-domain source address validation using RPKI and > IPsec (draft-xu-risav and draft-xu-erisav) - by Yangfei Guo 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. The proposal would require allocation of a SPI for a destination address which is not the receiving system of the SA. It would be negotiated with IKEv2, but that part seems neither here nor there. I don't object to discussing it in IPSECME. I think it's a good idea to do SOMETHING. I think that it's very SR6-ish, and since it is cross-AS, I can't see how 6man will approve. It might be appropriate to at least ask SECDISPATCH. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
Ben Schwartz wrote: >> Ben Schwartz 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, especially because: >> >> >> >> Where will you put the original src/dst IPs? >> >> 24 bytes is the AH overhead only. The v6 src/dst requires 32 bytes, >> >> at which point you might as well just have an IPIP header at 44 >> bytes. >> >> >> >> > They're in the outer IP header, unchanged, so it really is just 24 >> bytes. >> >> No, that's not legal or practical. >> > I'm not too worried about the "legalities". We write the rules! Yes, but we did write the rules, and if you want to change them, you might find that you will break the entire Internet. >> 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 use a SPI# allocated by >> destination ASBR, so you have to put the dstip= ASBR. >> > No, the SPI# is allocated by AS pair, so the SPI scope is unambiguous (to > the recipient) from the source IP. (There is no sequence number or replay > defense.) No, RFC4301 says that the SPI# is allocated by the host indicated by the IP dst. If you allocate something for a host in the middle, then you will break IPsec for all end-hosts. That's not going to fly. > ICMPs go to the source IP, which is what we want. The only trick is > that No, that's absolutely not what you want. The host that put inserted the AH has to get the ICMP errors about that AH. > It's IPsec, but not as we know it. It's a "transparent variant of IPsec > transport mode", or something like that. It's not IPsec at all. >> It's not that big deal, but I assume you'd like to use commodity off the >> shelf hardware. > I'm pretty sure this doesn't actually affect that. I think we would do > something like "ESP Key = HKDF(IKEv2 DH key, source IP)", and then ESP mode > would run pretty much as usual. My main question was how to negotiate this > in the IKEv2 handshake. You would be negotiating something new that's not ESP or AH. > In terms of performance, my bigger concern is that sending and receiving a > RISAV packet requires an IP->ASN mapping lookup. Hopefully ASBRs are good > at that... That's easy. That's just a routing lookup with nexthop=IPsec-SA#foo. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
Ben Schwartz 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, especially because: >> >> Where will you put the original src/dst IPs? >> 24 bytes is the AH overhead only. The v6 src/dst requires 32 bytes, >> at which point you might as well just have an IPIP header at 44 bytes. >> > They're in the outer IP header, unchanged, so it really is just 24 bytes. No, that's not legal or practical. 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 use a SPI# allocated by destination ASBR, so you have to put the dstip= ASBR. Really, you need to change the srcip= as well, because otherwise, ICMPs go to the wrong place. If you want do something else, then it's relly not IPsec. >> > I actually think RISAV uses RPKI for exactly the thing that RFC 9255 >> > wants: directing IP packets to the corresponding AS number. >> >> I'm not convinced it will fly. >> I agree with you, but I feel like I'm in the rough. >> > I think we can set this aside until we've ironed out the technical wrinkles. I actually think thta you need to do this up-front, otherwise, you are wasting your time. >> The draft notes some interesting questions about how sequence numbers >> > work in this situation. The best solution I came up with was to put >> > the source IP into the "Additional Data" of the AEAD (or equivalent), >> > but this seems like it would need a new IKEv2 extension. >> >> yes, that's an entirely new cipher mode. >> > How big a deal is a new cipher mode? It doesn't sound so bad. It's not that big deal, but I assume you'd like to use commodity off the shelf hardware. >> You have, btw, just re-invented SKIP. And maybe that's what you actually >> want, btw. >> > Oh, wow. SKIP (https://datatracker.ietf.org/doc/draft-ietf-ipsec-skip/ for > those following along) looks like exactly the "proposed extensions" > mentioned in Section 5.2 and Section 5.3 of RISAV, so it's definitely > relevant. Too bad it doesn't exist... I think that SKIP is probably the best direction to think about. Some ex-SUN people will buy you drinks until you die if you go that way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
Paul Wouters wrote: >> 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 another, and that this environment MUST accommodate the larger MTU >> for tunnel-mode IPsec encapsulation. > If it’s such a trusted one hop, why do you need IPsec to signal a traffic label? It's not one hop. It could transit multipls ASs. That's why they are so concerned about MTU, and why IPTFS might help make this deployable. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
turn it on, it should > work for them without any help from anyone else. Yes, if every single deployment has a direct ROI, the that supports the fax effect and more incremental deployment. Further, if I can do Traffic Engineering of my links by directing floes by AS to specific ACS which have specific tunnels, then we wind up with a kind of inter-AS MPLS/SR6/ATM solution. That would also be a major win for many. >> You really should create a tunnel with AH. >> > Wait, what's a tunnel with AH? I've heard of "ESP without encryption", > but I've never heard of "AH but it's a tunnel". tunnel: IP AH IP ULP. vs transport: IP AH ULP >> AH has the advantage that everyone knows it's AH, so skipping the >> outer header and the AH means you can find the inner IP and do >> auditing or flow analysis on it. Since you have to modify hardware to >> do something, you might as well do this. >> > I don't know what you're advising, but my main question is about the > MTU overhead. With ESP, you can't know what's inside the ESP. Even if it's ESP-NULL, nobody can count on that, so processing has to stop with the ESP. By fluke, back in the early 1990s, cisco routers uses the 5-tuple as part of a cache to speed up forwarding. This turned into netflow (aka openflow), and operator/ISPs since them have rejected any forwarding engine that can not produce the same kind of statistics. They really want to know how much traffic is port-80 vs port-25... Of course QUIC screws that all up. Many routing fabrics have internal mirror "ports" that actually do the 5-tuple accounting that is desired. Those devices can be told to skip the AH header to find the ULP in order to do the accounting. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
I haven't found in the draft an explanation of where the original source and destination address would go. IPsec SPI are seat specific, the ABSR can't just eat AH headers from packets that were not addressed to it. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt
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 > IPsec experts. We're also hoping to present this idea and solicit > feedback at IETF 115. Thanks. The question of what kind of tunnel or transport is a deep one, and whether or not to encapsulate the traffic within an IP header has significant architecture discussion. Despite the experience of SR6 pushing through, I'm not convinced that 6man will buy your use case. There are some interesting opportunities for privacy and defeating traffic analysis by adding an IP header. The IPTFS work (now in the RFC-editors Q https://www.rfc-editor.org/current_queue.php#draft-ietf-ipsecme-iptfs ) also offers some interesting opportunities. > This is an early stage proposal with a lot of open 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. But, what about: https://www.rfc-editor.org/rfc/rfc9255.html It seems like you are trying to use RPKI for something which the RPKI people don't want you do to. (I mostly disagree, btw) I see from the content in section 2.2 that you have an EE cert for the ACS. I'm a bit unclear about whether step 1 is already the RPKI, or some new process. It seems that one would want many ACS systems. If successful, all of the traffic between AS A and B would go through, and that could easily exceed the bandwidth of a single system (or a single cluster). Since AS A/B may interconnect in many places, on many continents, they need many tunnels. I think that this invokes the entire MED debate in BGP4, which I'm really out-to-date on, but AFAIK, isn't solved. Maybe adding IKEv2 provides opportunities to make better policy decisions. There are shades of RFC4322 in these ideas, but not the same. Also, if universally successful, does this suddenly change how the DFZ looks? Does it have to carry all of the routes to all of the places, or only the routes to the ACS/ASBR? Can you drop all IPv4 and just encapsulate to IPv6? Is there a win in simplifying silicon here? }4.1. Transport Mode } } To avoid conflict with other uses of IPsec, RISAV defines its own } variant of the IPsec Authentication Header (AH). The RISAV-AH header } format is shown in Figure 2. This is really dumb. Don't do this. There are only conflicts because you think you are insert the header. You can't and you shouldn't. You really should create a tunnel with AH. AH has the advantage that everyone knows it's AH, so skipping the outer header and the AH means you can find the inner IP and do auditing or flow analysis on it. Since you have to modify hardware to do something, you might as well do this. }7.3. MTU } } TODO: Figure out what to say about MTU, PMTUD, etc. Perhaps an } MTU probe is required after setup? Or on an ongoing basis? The answer is probably to do IPTFS, but that is in conflict with using AH. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
I think that the point is that even if there are n CPUs, that a sensibly designed system might well have n+1 SAs active. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
Valery Smyslov wrote: > My main problem with the draft is the concept of "Fallback SA". This SA > is treated specially in the draft, which I don't think is > necessary. For example, it must always be up so that the outgoing > packet can always be sent in case per-CPU SA does not exist. Why other > existing per-CPU SAs cannot be used for this purpose? Because the point of the per-CPU CAs is that they are local to the CPU and so they do not require locks to acces/update. I could guess that the fallback SA *does* require locks. > affinity). There also is some mechanism that deterministically > dispatches incoming ESP packets to CPUs based on some information from > the packets, most probably from the content of SPI. It needs to be deterministrically by SPI, or you get no locality. > With these kernel features in mind the following IPsec architecture > could be implied. The SPD is global for all CPUs, while SAD is split > into several copies, so that each CPU has its own SAD. We also need to > introduce a special entry in the SAD - "stub SA", that only constitutes > of a selector and has no associated SA. The read-only copy of the SPD can be replicated per-CPU, with the counters being updates by RCU. I don't understand your stub SA use. > This way the new SAs are created dynamically and treated equally - they > all live their own life - are re-keyed or even deleted if they are idle > for a long time. If there are SAs which are being used more than others, than there is something wrong. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt
Paul Wouters wrote: > I am a bit confused why the source address needs to be cryptographically > verified to make SAV based decisions. What would be the scenarios of > inter AS communication where the packet is maliciously modified between > the two ASes but in such a way that RPKI wouldn't already reject the > packet with a bad src/dst ? I'm also confused by this proposal. But, imagine if you will, that the RPKI is unable to transitively address all of the transit points. There are a lot of corner cases that the SAV WG(s) have been unable to come to consensus about. I think that a lot of them work out to that many solutions only work if all operators conform to specific network topology patterns. But, if the originating AS is able to sign the packet in such a way that a receiving AS is able to verify the traffic came from the originating AS. This would definitely be a win, right? How would this be possible to do, well. There are ways that I can imagine it might be made to work, but it seems very difficult to do at speed, in practice. One thought is that I wonder if there is some value if one could only verify some small percentage of packets... with some consequence if the check fails such that we probablistically catch violators and put them into some ACL. > I am not convinced a modified IPsec AH is the best choice. A new > protocol as this would be, would take quite some time to be widely > supported. With IPsec, there are already two failures in this space, > BEET (BTNS) and wrapped ESP (wESP). I know that the Linux IPsec wasn't it BEEP? BEEP is not really related to BTNS. BEEP mode is really related to HIP, but, yes, BTNS could benefit from it. wESP is, I agree, a total failure. > Additionally, AH works poorly over NAT. Would there be a chance that > the two AS'es have to communicate via a NAT? Probably not. BGP4 just doesn't do NAT44. but, if it were a problem... IPv6 would still benefit. If ASs can benefit from DDoS protection by agressively switching to IPv6, then that might be a win-win. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt
guoyang...@zgclab.edu.cn wrote: > The drafts' link are > 1. https://datatracker.ietf.org/doc/draft-xu-erisav/ } IPsec IKE negotiates the tag tagged in the packet. IKE also negotiates the } authentication algorithm, authentication key, and others specified by } SA. These will be stored in the SAD and SPD described in [RFC4301]. IPsec AH } [RFC4302] is the authentication header of the IPsec Security Architecture. It } authenticates the whole packet for integrity. However, source address } validation does not require such strong authentication. It just needs to } protect the source address from being spoofed. So it needs a new } authentication process. This new authentication process will only take a few } changeless fields as input. And the original tag will be seen as the } authentication key. The result of this process will produce a new label } called the packet signature that will be filled in the packet properly. And } this label or the SA MUST send to all the ASBR for communication. With what node does IKE negotiate? Where is the AH introduced? In IPv4, whether we can introduce new headers is up for debate. For IPv6, it is not. So I really don't know what to make of your proposal. If we could asymmetrically sign every packet with a new AH protocol that used an assymetric key, that would be awesome. I've wanted to do this forever, but it's just not affordable. What if we signed some small percentage (%0.01) of packets... would there be some way this could be useful for SAV? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-xu-erisav-00.txt and draft-xu-risav-00.txt
guoyang...@zgclab.edu.cn wrote: > IPsec is an important protocol family of the Internet. And we think it > may be more powerful just by adding a few changes to it. > Source Address Validation (SAV) is a problem that can be partially > solved by using IPsec or other approaches. However, IPsec AH needs to > hash the whole changeless fileds of the length-vairable packet and > IPsec ESP needs to encrypt the whole packet. Therefore the AH or ESP > are too costly and heavily to implement the source address > validation. We design a new tech mechanism that uses RPKI and IPsec to > solve the inter-domain SAV problem. It's not the AH/ESP that's costly, it's the key agreement protocol that takes time. > This new mechanism needs to define a new type of IPsec SA using > together with RPKI to validate the inter-domain layer source > address. As it only needs to choose a little fields to protect but not > the whole packet, this will dramaticaly decrease the computation cost > compared with the original IPsec AH or ESP. Thus it may be used > globally in the Internet. Yes, maybe. You may want to look at TF-ESP, which is a failed protocol. RFC5840. > Two drafts were submitted for that purpose. The one, ERISAV, describes > its motivation, main framework, and interactive process. And the other, > RISAV, describes detailed things about how to use RPKI, IKE, and IPsec > AH for source address validation. > The drafts' link are > 1. https://datatracker.ietf.org/doc/draft-xu-erisav/ > 2. https://datatracker.ietf.org/doc/draft-xu-risav/ > The above announcement is these drafts. We would like to work with the > community to improve and clarify these tech drafts. They aren't not yet mirrored to my laptop, but I'll read them as soon as I have Internet again. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Tero Kivinen wrote: > Murray S. Kucherawy writes: >> This posture worries me. I've no doubt that you're doing a fine job >> as the DE for the registries for which you're responsible, probably >> because you were around during IPSec's development. But what about >> your successor(s)? Will they have all of the context, background, and >> vision you have in order to continue where you eventually leave off? > Designated experts are called experts, not automation robots following > steps set in RFCs. My understanding has been that the reason we use > experts is that then we do not need to give them exact rules to > follow. Some of the RFCs gives so strict rules for experts to follow, > that there really is no point of having expert involved at all, IANA > could simply follow those same steps themselves. I very very strongly concur with Tero here. This trend to constraining experts is a problem. Either we/the IESG trusts the experts, or they don't. And, either way, if the WG is happy with the instructions, then the let the WG be. > We currently have two experts for the IPsec registries (another one was > added few years back). Also I would assume there is pool of about 5-10 > people in the IETF that could easily work as an expert on the IPsec > registries on the short notice (whether they would be willing or having > time is another issue :-) > On the other hand IPsec registries are easy, as we do have active group > of people still working on it, meaning we have active mailing list and > in case there are issues where experts are unsure, the experts can go > and verify the decisions on the mail list. Yes... if there is any doubt, the expert can come to the list with questions. I've seen other experts do this regularly. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
On Aug 25, 2022, at 00:52, Erik Kline wrote: > I think this document needs to request a protocol number from IANA. Erik, the WG had this debate at length two+ years ago. I feel that the WG, through our AD, asked the IESG and the IntArea and Transport Area this specific question in a number of different ways to be sure. We decided not to go that way because we felt that it was a waste of a very scarce resource. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] ipsecme-ikev2-mtu-dect
TL;DR> please adopt document now so that WG can work on it. I believe in early adoption of documents. Hi, I watched the IPsecME WG recording from IETF114 today as I had a conflict with ANIMA WG. I saw the conversation about MTU and getting early Transport Area review, and I then read the document. First, I think that the Introduction is a bit confused about how things work when there is an IPsec tunnel, and the history of when/how and why Packet Too Big messages are trusted/untrusted. The WG should not ask for Transport Area review until this part is fixed. Second, IPv6 is mentioned only once, and the case for IPv6 over ESP-IPv4 tunnel is common and likely to increase as demand for always on IPv6 rises. This document won't get anywhere without an IPv6 section. Third, I have actually spent a lot of time going back to 2003 on the fragmentation vs DF for IPsec tunnels. The situation is very different for traffic in the tunnel vs IKEv2 messages, btw, and not just because they might take different paths inside the network. In particular FreeS/WAN's KLIPS stack intentionally ignored the inner DF bit, put the result into a too-big ESP packet and then fragmented that. I.e. did not copy the DF bit from inside to outside. This was done for operational reasons, but the incidence of fragments being dropped has increased, and of course, IPv6 does not support this at all. One concern from transport people was that on 1Gb/s network (high speed at the time), the cycle time for fragment IDs was quite short, and it was quite possible to get an ESP packet stuck in the re-assembly queue, and then for another one with the same fragment ID to arrive and for it to be reassembled. If this were a bare TCP segment, then it could result in a bad TCP flow, and this situation had been observed in the field, which is why transport people really really wanted to avoid fragmentation. Now, we never did get 9000-byte ethernet reliably deployed, although most ethernet switches and adapters that we have support it, and one can up your MTU locally and get way better throughput within your enterprise. The lack of credible MTU estimation means that if you do this, you likely wind up failing all non-local connections. But, the discusion at the time was that the mis-assembled ESP was protected by the cryptographic integrity check (HMAC-FOO), and that was way way stronger than the TCP checksum, and so actually fragmenting ESP packets was not really that much of a risk. But, this activity breaks PLPMTU for that hop! I tried hard during RFC8200 and RFC8504 to get PLPMTU to be MTI and to be the default method, but there was push back. We don't have enough data, people said. I also tried to get it turned on for Linux distros, and for the Linux kernel to ship with it enabled by default, but "not enough data". I asked a few people at the BigTech companies if they had data or would do an experiment, but thanks to Transport Segment Offload (TSO), the last they EVER want is for a TCP segment to get rejected and they take a retransmit delay. The TXOPs were just too valuable, so they typically set their MTU (TCP MSS) to 1400 or so that they never experience this. There are two MTUs that actually matter. 1) the MTU of the links between the two gateways. 2) the MTU of the links behind the receiving gateway. It is easy to mis-program the ICMP PTB on the receiving gateway so that it turns out not to fit into the tunnel, and gets dropped. I don't know if that's still an issue with gateways, but it's a common mis-configuration with a Linux kernel. I think that having an option to enable a receiving gateway system to tell the sending gateway what is considered a too big packet is very useful. Even if we have IP-TFS to mitigate the effects of too big packets. It can be based up many things. As Tero observed, a receiving gateway could observe the size of the ESP fragments that it successfully receives, and could conclude that the link is *at least* that big. Of course, an intermediate fragmenter could split the packet into two even pieces rather than a bit and a small bit. There are other heuristics, and yes, we can use PLPMTU on our ESP flow. We can create probe packets that get bigger until we discover the true size. None of this requires new standards, but the MTU observed notify is useful. (And yes, we need to acknowledge it, because all IKEv2 messages need to be acknowledged, so it's just another notify, and I assumed that Daniel had simply omitted the ack on his slide) I would drop much of section 4.1. Section 4.2, should be aware of IPv6 minimum MTU is 1280, and IPv4 minimum reasonable MTU is typically cited as 576. I would remove "IP4_" from the notifications message names. I would remove all mention of PMTUD. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature __
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt
Robert Moskowitz wrote: > Here is the latest revision. > Should this draft be adopted by the workgroup for 'proper' document > advancing? adopt it, and WGLC it. It's done. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
Robert Moskowitz wrote: >> I think it should have public and an errata could be filed for 1-3 ? >> Or we can draft a separate draft for encoding algo 14 (digital >> signatures) that also fixes up these entries ? >> >> Or this draft could fix them ? Maybe the chairs or AD could give >> guidance here 😀 > I think I could have the IANA Considerations have a fix for 1 - 3 as > well as add 4. > I will work something up and share it here.. Couldn't the IESG just provide IANA some clarifying guidance here? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
Paul Wouters wrote: >> On Aug 10, 2022, at 10:30, Robert Moskowitz >> wrote: >> >> I will fix my example. Do you think I should have both examples: with >> and without gateway? > No. First because you are not tunneling and it doesn’t apply to you and > second because it can only be set for IPSECKEY records in the reverse > zones, not in any forward zones. Agreed! >> Per Paul's request I am coming up that for EdDSA I would ask the >> following be added: >> >> 4 An EdDSA Public key is present, in the format defined in [RFC8080] >> [This] >> >> >> Note the addition of "Public" >> >> So should 1 - 3 also have "Public" added? Should 4 NOT have "Public" >> Should text be added describing this registry to be for "Public" keys? > I think it should have public and an errata could be filed for 1-3 ? Or > we can draft a separate draft for encoding algo 14 (digital signatures) > that also fixes up these entries ? I supposed that the word public could be added all over the Registry. I think that RFC4025 has the word in enough places that it should be obvious that a private key does not go there. So this seems like printing "This bag is not a toy" on stuff, but I don't object to this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt
Robert Moskowitz wrote: > I do need this expedited, as I do need to reference in my draft which, > hopefully, is in final IESG review process. > One particular point of review. Paul requested that I specifically say > this is for EdDSA Public Keys, as in drip, it ends up in the DNS HIP > RR. We don't want the initiated to think this is a place for private > keys... I have read it and it looks good. I would ask that there be an example of a public key in an appendix, and that private key be included. Shouldn't you cite RFC4025 somewhere? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ESP Signally to higher layers
Robert Moskowitz wrote: > This is an item that goes back to the beginning of ESP work: > Minimally, how does the higher level 'learn' that it is secure: Are you asking how *TCP* learns of this, or how an application with an open socket(2) learns of this? > Encrypted/Authenticated/CrCed... ? > And as ESP has a seq#, how might it be convied to the higher layer? Do you mean replay counter here, or did you mean SPI? Preferably, never, because it will get rekeyed, so really, whatever you want to do really needs to be communicated abstracted to the key daemon, who will do the right thing, and keep track of updates to the SPI# > Case in point: MAVlink has a 1-byte seq# in its payload. How might > this be provided by ESP? Now I think maybe you really do mean sequence/replay counter. > https://mavlink.io/en/guide/message_signing.html > So I have been thinking about this vis-a-vis diet-esp. What is the > mechanism/trigger that can best work across a number of higher layers > to inform of operating environment and values available (seq#)? > Is this done anywhere now? Doubtful. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsec RFC Errata
Tero Kivinen wrote: > Actually some of those held for document update errata could also be > useful to be inlined... Especially for documents which are not yet > obsoleted ( RFC2104, RFC4301, RFC4302, and RFC4303). I think that having stuff inlined is always good. I read your list, and I agree with them all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Cost-efficient quantum-resistant DoS protection
Thank you for the summaries. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> This is the start of 2 week WG adoption call for this document, ending > 2021-11-22. Please send your reply about whether you support adopting > this document as WG document or not. I have browsed through the document. I don't know if the mechanism is correct or not. I think that Paul Wouters' email seems correct to me. I think that there is an interaction with provisioning domains (PvD) which is not spelled out. The remote access "VPN" is usually a provisioning domain these days. In general, I don't think that split-DNS is a good thing. I don't think that sending all traffic through the VPN is a good thing. Almost everyone that I know, that has any kind of VPN, has more than one potentially active at the same time. (but my friends are mostly consultants like me). So I object to the entire notion that we need to do anything at all: there are way better solutions than split-dns, and I think we should stop pandering to enterprises that live in the dark-ages of 1992 IPv4. Do any of them actually pay to upgrade/replace their VPN gateway boxes such that they'd actually get this new code? Are the split-dns or die enthusiasts running IKEv1 w/3DES+MD5? Having said this, I do not object to the WG doing this work, but I won't be taking time to review it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-rfc8229bis
Valery Smyslov wrote: >> I wonder about keeping more of the original authors on the new >> document, since it is substantively the same document. I can not >> judge what their contribution was to the original document, nor do I >> know if they were asked. If the design team has gone through this >> consideration, then that's enough for me. > All three original authors were asked to co-author the draft. Tommy > agreed, but no reply was received from Samy and Ravi. I cannot judge > their contribution to the original rfc, but I think that it's a good > idea to add them to acknowledgement section anyway. Will do this. Glad to hear you had that discussion. My issue is closed :-) Please consider using the xml-v3 contributor mechanism. If you are using Kramdown, then it's just like the author: section, but you say "contributor:" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Cost-efficient quantum-resistant DoS protection
Yoav Nir wrote: >>> Tero Kivinen wrote: >>>>> Even without surpassing the 64KB limit, this must be a concern. >>>>> IKEv2's cookie mechanism and puzzles try to increase the cost of the >>>>> attacker per each connection. Now, an attacker must still accept >>>>> these costs but can use one connection to trigger several key >>>>> exchanges, all significantly larger than what we had with DH, making >>>>> the trade-off way better for them compared to non-pqc IKEv2. >>> >>>> No it cannot. Attacker can use cookie only once, and will only get one >>>> exchange created by each cookie exchange, thus it needs to do puzzles >>>> and cookies again for every single attack packet it wants to send. >>> >>> I wonder if anyone has any stats on how often cookie challenge is used, how >>> often puzzles are invoked. >> >> I've implemented puzzles, but I'm not aware of any other implementation. >> >> What about cookies - in stress tests they are used very intensively. >> But I don't have any real life stats for them. >> >> Regards, >> Valery. > I also implemented puzzles. So that makes two of us. Did you ever interop? What is your criteria for enabling them? Do you do this automatically, or is it an operator configuation to demand them? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-rfc8229bis
I have reviewed the diff at: https://www.ietf.org/rfcdiff?url1=rfc8229&url2=draft-ietf-ipsecme-rfc8229bis-01 and the update seems like a good job to me. I wonder about keeping more of the original authors on the new document, since it is substantively the same document. I can not judge what their contribution was to the original document, nor do I know if they were asked. If the design team has gone through this consideration, then that's enough for me. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt
I've read the diff, and it looks good to me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] iptfs publication request
Tero Kivinen wrote: > Christian Hopps writes: >> Will you be able to provide the text changes that would cover the >> issue you have? Would really like to get this submitted to IESG >> before another IETF cycle completes. > How about following: works for me. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Cost-efficient quantum-resistant DoS protection
Tero Kivinen wrote: >> Even without surpassing the 64KB limit, this must be a concern. >> IKEv2's cookie mechanism and puzzles try to increase the cost of the >> attacker per each connection. Now, an attacker must still accept >> these costs but can use one connection to trigger several key >> exchanges, all significantly larger than what we had with DH, making >> the trade-off way better for them compared to non-pqc IKEv2. > No it cannot. Attacker can use cookie only once, and will only get one > exchange created by each cookie exchange, thus it needs to do puzzles > and cookies again for every single attack packet it wants to send. I wonder if anyone has any stats on how often cookie challenge is used, how often puzzles are invoked. > So I do not think DoS attack properties of the IKEv2 is at all > modified with addition to the multiple ke, or beyond 64k limit drafts. I agree. IKEv2 is not SSLv3. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic (fwd)
Paul Wouters wrote:
>> On 6/28/21 1:23 AM, Valery Smyslov wrote:
>>> - Is it OK that the intended status is Standards Track? Shouldn't it be
>>> BCP?
> I think because it contains IANA actions, it should be Standards Track.
Agreed.
(It would be funny for it to be Historic, but actually that's wrong)
> Listing the good new stuff does not really put the focus on the deployed
> old bad stuff. I believe it is better to focus on why IKEv1 is bad. But
> I have added a paragraph paraphrasing this text. I did not use a bullet
> list to make it more informal and not look like it is claiming a
> complete list of items.
Great.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] iptfs publication request
Christian Hopps wrote: > Will you be able to provide the text changes that would cover the issue > you have? Would really like to get this submitted to IESG before > another IETF cycle completes. I also would like to see exactly what the difference is. I also would like the document submitted to the IESG. (And the IESG has become even more active, so it could still take many revisions to get to publication) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] iptfs publication request
Christian Hopps wrote: > In particular why don’t we simply indicate that a lost packet can > induce a delay of the fixed packet interval times the window size - 1, > and so the widow size should be kept to a minimum, and leave it at > that. Agreed. >> We have approved text from the transport experts now (in addition to >> clearing WG LC). I do not want to open this draft back up for major >> modifications that start talking about new ways to handle packets and >> their affects on the drownstream network etc. This is not our area of >> expertise, and we have already received approval from the experts for >> the text that we have. Let’s stick with the approved text and make >> clarifying modifications only. I understand and agree. Maybe clearly pointing at what text is involved would help. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsecme not meeting @ IETF 111?
I think you'll all be happier with a virtual interim meeting with no conflicts. We can now use meetecho even. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic
Yoav Nir wrote: > Although this draft is really new, having been submitted in April of > this year, its predecessor draft has been under discussion since March > of 2019. Agreed. > This begins a 2-week WGLC. Please read the draft and post comments to > the list. Since this is rather new, short messages in the vein of > “Yeah, this is good. Ship it”, but substantive comments are, of course, > even more welcome. Re-read to be sure. Ship it. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard
Paul Wouters wrote: > On Sat, 13 Mar 2021, Michael Richardson wrote: >> I'd *like* section 3 to enumerate the claims clearer (Maybe just new >> paragraphs). > You mean a textual change? like split out more, or bullet points? Yes. I am imagine an argument between an operational person who wants to authorization to upgrade/replace a gateway with the CFO. This document is his ammunition, so we need to make the CFO consider that the risks of not updating exceed the risk of change. Fundamentally, the CFO is risk averse, and thinks that "it ain't broken" > Systems that support IKEv1 but not IKEv2 are most likely also > unsuitable candidates for continued operation. > I know from vendors I've talked to that they froze their IKEv1 > stacks. I can't enumerate those in an RFC though. I think only the agreed. > IKEv1 systems can be abused for packet amplification attacks. > This could be clarified, or reference CVE-2016-5361. CVE links aren't > that stable over the years though. That's okay, it's stable enough, and the form of the reference makes it clear that there are issues. >> I think that the third paragraph (labelled IPsec) should be a new >> section 3.1. > We can make PPK and Labeled IPsec their own sections, but I don't see > why you would do labeled ipsec but not PPK. also, I guess Group IKE > should be listed too as we have a draft and had support in IKEv1 but > not in IKEv2. I want labelled IPsec to be a separate section so that it will have an HTML link, and can be referenced easily in the government RFP that justifies the upgrade. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-fedyk-ipsecme-mib-iptfs
Paul Wouters wrote: > On Mon, 8 Mar 2021, Tero Kivinen wrote: >> Subject: [IPsec] WG Adoption call for draft-fedyk-ipsecme-mib-iptfs >> >> This is the start of 2 week WG adoption call for this document ending >> 2021-03-22. Please send your reply about whether you support adopting >> this document as WG document to this list. >> >> This is part of the Traffic Flow Confidentiality work in the charter. > I am fine with adoption. > I would use "Bytes" instead of "Octects" for the byte counters. The use of the word "octets" is traditional in MIB documents, going back to the 1980s, when ASN.1 originated. Some machines had 9-bit bytes and 36-bit words :-) I also support adoption. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard
Tero Kivinen wrote: > This is the start of 2 week WG adoption call for this document ending > 2021-03-22. Please send your reply about whether you support adopting > this document as WG document to this list. I support adoption. I am frustrated with the WG because we've been talking about this for at least two years (maybe four?): documents don't need to be perfect to be adopted. So, just do it already. Please plan to WGLC this before the next IETF. I'd *like* section 3 to enumerate the claims clearer (Maybe just new paragraphs). Pretty much each sentence is a claim, and I think that they should point to references. That will make it much more impactful a document in my opinion. But, I'd rather publish it if adding such references is hard. I think that the third paragraph (labelled IPsec) should be a new section 3.1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
