Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[to...@strayalpha.com]

On Oct 31, 2022, at 11:07 AM, Daniel Migault  wrote:
> 
>>  - the tunnel has two DIFFERENT relevant MTUs
>>  the egress reassembly MTU (EMTU_R), which is the only thing 
>> that should drive the “tunnel MTU”
>> 
>>  the tunnel MTU, which the ingress needs to know for source 
>> fragmentation, but is NOT relevant to the
>>  origin MTU upstream of the ingress
>> 
> Will read the draft - but we believe that is better to generate one IPsec 
> packet for every inner IP packet as opposed to two. This is why we are 
> proposing to adjust the MTU so the outer packet matches the limit of the 
> EMTU_R - and fragmentation be avoided.

That doc explains why this is effort isn’t useful. As I noted to Tero, there’s 
no ICMP message that says “bigger than I’d like”. PTB means “packets larger 
than this will be dropped”. That’s not what’s going on here, so it’s the wrong 
message to support.

There is no message that supports what you’re trying to do - perhaps because 
there can’t and shouldn’t be.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[to...@strayalpha.com]

> On Oct 31, 2022, at 1:23 PM, Tero Kivinen  wrote:
> 
> to...@strayalpha.com writes:
>> 
>> What SHOULD happen in IPsec is that the SPI should have an MTU
>> (being a link) and the *router* where packets are forwarded into the
>> tunnel should determine when packets that want to enter that link
>> are too big - at which point, per RFC 1812, the *router* should be
>> sending the ICMP.
> 
> This is what the RFC4301 describes if I understood your description
> correctly. ...
> 
> So I think IPsec is still doing everything correctly.

For PTBs received along the path, then yes.

There are a few different cases here:
- the reassembled tunnel packet is decrypted, decapsulated, and inside 
is an IPv4 DF=1 that exceeds the next-hop MTU
at which point the IPsec tunnel egress router sends ICMP PTB 
based on that decapsulated (origin) packet (or not)

- the tunnel hops generated a PTB to the IPsec ingress, which changes 
its MTU
and the router at that ingress router sends PTBs back on 
subsequent packets if they receive IPv4 DF=1 that exceed that MTU

- the egress reassembly fails because tunnel packet exceeds EMTU_R at 
the egress
there’s no ICMP for this message, however

The PTBs of the tunnel (middle case) change the fragment size emitted from the 
ingress  (EMTU_S) accordingly, but it would not cause the tunnel to fail.

But note that the tunnel MTU is not its path MTU; it is the EMTU_R of the 
tunnel. Other packets CAN traverse it. So the only MTU the IPsec ingress should 
ever send back in a PTB would be EMTU_R of the tunnel.

This document tries to get around the fact that ICMP has no “packet bigger than 
I’d like” signal.

(Yes, I realize this means tunnels need to do frag/reassemly and this is 
expensive; the reason is explained in intarea-tunnels. If you’re talking about 
tunnels then reading that doc is a prerequisite - at least to my further 
involvement)

Until that signal exists, calculating it and relaying it is not useful. Even 
then, using ICMP to do this makes no sense, esp. given the entire mechanism 
assumes ICMP doesn’t work over the tunnel path.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] risav document at IPsec

[Ben Schwartz]

On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson 
wrote:

>
> {some of my emails have written "ABSR" rather than "ASBR". Oops}
>
> Ben Schwartz  wrote:
> > On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson <
> mcr+i...@sandelman.ca>
> > 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.)

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?


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.

> 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.

> 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.
>

Yes.  That means O(N^2) handshakes between each pair of ASes with N ASBRs,
vs. just 1 (between the ACSes) for RISAV.


> 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.

This is more interesting in RISAV tunnel mode, which might have some
strange interactions with Extended Sequence Numbers.  I do wish we had an
ESP with 8-byte sequence numbers...

> * 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.
>

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.

> 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.
>

It looks like 6man has a full agenda already (
https://datatracker.ietf.org/meeting/115/materials/agenda-115-6man-03.html)
but perhaps we can ask the 6man list for advice.

...


smime.p7s
Description: S/MIME Cryptographic 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]

to...@strayalpha.com writes:
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but only knows the SPI of the
> > Child SA, not who was the original sender. So it keeps track that for
> > this SPI the ESP packets cannot be larger than xxx bytes.
> > 
> > Next time it receives a packet from the source and when it is
> > encrypting it, it will verify that it will fit the size set for that
> > Child SA, and if it is too big, it will generate ICMP PTB for that
> > specific packet.
> > 
> > IPsec gateways have been doing that for years, and this has been
> > described in the RFC4301 section 8.2.1.
> 
> That would happen because the tunnel packet caused PTB. This case is
> described in intarea-tunnels 4.3.2. The way in which IPsec gets it
> wrong (IMO) is described in Section 4.3.1 and is related to RFC
> 3884, e.g., by subsuming the functions of a router inside the IPsec
> mechanism, rather than operating strictly as a tunnel, which should
> be represented as a link - and *links do not send ICMP messages.
> 
> What SHOULD happen in IPsec is that the SPI should have an MTU
> (being a link) and the *router* where packets are forwarded into the
> tunnel should determine when packets that want to enter that link
> are too big - at which point, per RFC 1812, the *router* should be
> sending the ICMP.

This is what the RFC4301 describes if I understood your description
correctly. I.e., when SGW A (IPsec security gateway routing clear text
packets to encrypted tunnel) sends packets out having DF=1 and gets
ICMP PTB back from the route, it does not know which packet triggered
this event, as the ICMP PTB might not have enough data in it to
identify that. It should get the SPI and destination address, so it
should be able to associate that ICMP PTB to some Child SA.

Now it will store that information to that Child SA, and wait for next
packet to arrive, i.e., effectively setting the MTU of the link to
whatever ICMP PTB said (and taking in to account the overhead caused
by the IPsec). When packet that is too big for that tunnel it will
generate ICMP PTB just like router should. The difference there is
that this cannot happen on the first packet only for later packets.

So I think IPsec is still doing everything correctly.

This case is not about that it is when the incoming packets that does
not have DF set, and in that case the router can fragment them before
or after sending them to the tunnel. Quite typically they encrypt the
whole packet, and then fragment the resulting ESP packets, as that
makes it easier for the receiving end to the exit tunnel checks.

If the incoming frame was 1500 bytes and we added around 50 bytes of
IPsec overhead the resulting packet is 1550 bytes which gets fragment
to one 1500 byte fragment and one 50 byte fragment.

> > 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.
> 
> The only reason the packet would have been too big at the receiver
> is if it were to exceed the receiver’s reassembly buffer. That’s not
> what’s happening here.

Now if in the middle of the path there some other MTU in use, lets say
there is another IPsec tunnel there (tunnel in tunnel), and that
getway is fragmenting the incoming packet before sending it to the
tunnel (it could fragment it before putting it to tunnel, as the
packet was already fragmented so fragmenting it again does not matter,
or perhaps there some link between it and its destination which does
not support IP fragments). So it takes the 1500 byte fragment and
refragments that to 1420 byte and 80 byte fragments, and adds IPsec
overhead. Then when that tunnel is decapsulated away we have 3
fragments ending to the receiving node.

One is 1420 bytes, another is 80, and the last one is 50 bytes.

When the receiving SGW B will see this it most likely can know that
this was not original SGW A actually used, thus could report back to
the SGW A saying that SGW A should use MTU of 1420 bytes instead of
1500 when sending ESP packets over this route.

This is not really a PTB event as everything still works regardless
what SGW A and B do, but this is still not optimal behavior of the
tunnels, and it would be useful to detect and fix this situation. 

> It seems like there’s confusion about the fact that the source can
> somehow avoid fragmentation of the tunneled packets. That can’t
> happen - see intarea-tunnels Sec 3.6.3. Source fragmentation can 

Re: [IPsec] risav document at IPsec

[Michael Richardson]

{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] Scheduling for London

[Paul Ponchon (pponchon)]

Hi,
We’d like to request 5-10 min to present IPsec anti-replay subspaces 
(draft-ponchon-ipsecme-anti-replay-subspaces) if time allows.
Regards,
Paul

On Sun, Oct 30, 2022 Yoav Nir mailto:ynir.i...@gmail.com>> 
wrote:

Hi, folks.

As you know, we have a 90-minute session on Wednesday, November 9th at 15:00.

In addition to all the document status and solemn recitation of the Note Well, 
we have so far received 4 requests for agenda time:


1.   From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a 
proposed extension to IPComp
2.   New IKEv2 payload format - by Valery
3.   Revised Cookie processing (draft-smyslov-ipsecme-ikev2-cookie-revised) 
- also by Valery
4.   Inter-domain source address validation using RPKI and IPsec 
(draft-xu-risav and draft-xu-erisav) - by Yangfei Guo

If anyone else needs an agenda slot, now is the time to speak.

Thanks


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Daniel Migault]

Hi,

see below some clarifications.
On Mon, Oct 31, 2022 at 12:18 PM to...@strayalpha.com 
wrote:

> See below in-line.
>
> On Oct 31, 2022, at 8:53 AM, Daniel Migault  wrote:
>
>
>
> On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com <
> to...@strayalpha.com> wrote:
>
>> HI, Tero, et al,,
>>
>> Thanks for the clarification; I now understand that what you really are
>> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a
>> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>>
>> My understanding is that IPv6 performs fragmentation at the source, in
> which case, the receiving gateway does not need to defragment.
>
>
> Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for
> tunnels (see intarea-tunnels).
>
> There are two sources (please review intarea-tunnels); please explain more
> clearly which one you mean.
>
> The original source of the packet (outside the tunnel) does source
> fragmentation. This doesn’t impact the IPsec egress (please - not
> “receiving gateway” - that could refer to ANY router on the path, either
> outside the tunnel or inside the tunnel; note that it does NOT actually
> refer to the IPsec egress because IPsec could be implemented as “bump in
> the wire” and its endpoints might not be gateways at all).
>
> But *so does the IPsec ingress*. It fragments the tunnel packets (again,
> see intarea-tunnels). It is THOSE packets the IPsec egress reassembles.
>
> Our problem is only happening with IPv4 when an on-path router fragments
> and the receiving security gateway needs to re-fragment.
>
>
> You should already stop using on-path *TUNNEL* hop refragmentation (again,
> router here is ambiguous).
>
> The “receiving gateway” is the IPsec egress of this traffic. Why do you
> keep saying it needs to refragment? It *reassembles* the tunnel fragments
> (but it has to - source fragmentation is always possible and will always
> need to be supported).
>
> I agree we are not concerned by source fragmentation but by on-path
*TUNNEL* hop refragmentation. We know these should nor be used, but it is
used and we have to deal with it. This is the scope of our document.

> We explicitly mention in the introduction that what we have is not a
> PLPMTUD for IPsec.
>
>
> Understood. But here’s the issue:
>
> - the end-to-end path can and should be using PLPMTUD
> having your system find a way for IPsec ingresses to generate *more* ICMP
> PTBs is not a solution,
> as you already note (because they’re untrusted, dropped, or not generated
> in the first place)
>
> - the tunnel has two DIFFERENT relevant MTUs
> the egress reassembly MTU (EMTU_R), which is the only thing that should
> drive the “tunnel MTU”
>
> the tunnel MTU, which the ingress needs to know for source fragmentation,
> but is NOT relevant to the
> origin MTU upstream of the ingress
>
> Will read the draft - but we believe that is better to generate one IPsec
packet for every inner IP packet as opposed to two. This is why we are
proposing to adjust the MTU so the outer packet matches the limit of the
EMTU_R - and fragmentation be avoided.

Tunnels fragment and reassemble. There is no way to avoid that or to tune
> to that, *if you implement your tunnel properly, that fact is and needs to
> be invisible* to the endpoints.
>
> Or do you want your endpoints sending 48B payloads when you transit ATM
> links too (they do still exist)?
>
> Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe
> a PLPMTUD can be built on top of it, but we would like to avoid taking that
> path for now.
>
>
> Please review intarea-tunnels. Signals inside the tunnel are not always
> appropriate to relay outside the tunnel.
>
> But the really confusing part here is that you admit that ICMP doesn’t
> work, but you’re designing a system to detect (the wrong) info to send in
> ICMPs.
>

What we are saying is that ICMP does not work because the message and its
information is *not* received - that is it is not generated, discarded and
in the best case not trusted. Using the IKEv2 channel achieves this.

The other part of the discussion is what to do once the gateway has that
information. We do list source fragmentation, which requires no interaction
with the peers sending the to-become-inner packet. On the other hand, we
believe - and maybe we are wrong - that it would be better to avoid the
fragmentation and ask the source of the inner packet to adjust its MTU and
send smaller packets. To do so we suggest using ICMP - which is the
trusted network. As the ICMP is coming from the IKEv2 gateway, it is
plausible that this packet reaches the source of the inner packet.






>
> Joe
>
>

-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] risav document at IPsec

[Ben Schwartz]

On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson 
wrote:

>
> Michael Richardson  wrote:
> > Based upon conversations on the list, this proposal might not even
> be IPsec.
> > At least, it's not proto=50(ESP)/51(AH), as they are asking for a new
> > extension header type.
>

Nit: RISAV in tunnel mode uses proto=50.  Only transport mode requests a
new protocol number.


> > 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.
>

Thanks!


> 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.

If you think we need 1500 bytes of end-to-end MTU, I would be interested to
hear why.

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.
>

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)
* a larger amount of connection state (to hold all the different SAs)
* a much larger amount of IP buffer memory (for fragment reassembly)
* a somewhat larger amount of MTU overhead

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.

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.  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.


smime.p7s
Description: S/MIME Cryptographic 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

[to...@strayalpha.com]

See below in-line.

> On Oct 31, 2022, at 8:53 AM, Daniel Migault  wrote:
> 
> 
> 
> On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com 
>   > wrote:
>> HI, Tero, et al,,
>> 
>> Thanks for the clarification; I now understand that what you really are 
>> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a 
>> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>> 
> My understanding is that IPv6 performs fragmentation at the source, in which 
> case, the receiving gateway does not need to defragment. 

Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for 
tunnels (see intarea-tunnels).

There are two sources (please review intarea-tunnels); please explain more 
clearly which one you mean.

The original source of the packet (outside the tunnel) does source 
fragmentation. This doesn’t impact the IPsec egress (please - not “receiving 
gateway” - that could refer to ANY router on the path, either outside the 
tunnel or inside the tunnel; note that it does NOT actually refer to the IPsec 
egress because IPsec could be implemented as “bump in the wire” and its 
endpoints might not be gateways at all).

But *so does the IPsec ingress*. It fragments the tunnel packets (again, see 
intarea-tunnels). It is THOSE packets the IPsec egress reassembles. 

> Our problem is only happening with IPv4 when an on-path router fragments and 
> the receiving security gateway needs to re-fragment.

You should already stop using on-path *TUNNEL* hop refragmentation (again, 
router here is ambiguous).

The “receiving gateway” is the IPsec egress of this traffic. Why do you keep 
saying it needs to refragment? It *reassembles* the tunnel fragments (but it 
has to - source fragmentation is always possible and will always need to be 
supported).

> We explicitly mention in the introduction that what we have is not a  PLPMTUD 
> for IPsec.

Understood. But here’s the issue:

- the end-to-end path can and should be using PLPMTUD
having your system find a way for IPsec ingresses to generate 
*more* ICMP PTBs is not a solution,
as you already note (because they’re untrusted, dropped, or not 
generated in the first place)

- the tunnel has two DIFFERENT relevant MTUs
the egress reassembly MTU (EMTU_R), which is the only thing 
that should drive the “tunnel MTU”

the tunnel MTU, which the ingress needs to know for source 
fragmentation, but is NOT relevant to the
origin MTU upstream of the ingress

Tunnels fragment and reassemble. There is no way to avoid that or to tune to 
that, *if you implement your tunnel properly, that fact is and needs to be 
invisible* to the endpoints.

Or do you want your endpoints sending 48B payloads when you transit ATM links 
too (they do still exist)?

> Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe a 
> PLPMTUD can be built on top of it, but we would like to avoid taking that 
> path for now. 

Please review intarea-tunnels. Signals inside the tunnel are not always 
appropriate to relay outside the tunnel.

But the really confusing part here is that you admit that ICMP doesn’t work, 
but you’re designing a system to detect (the wrong) info to send in ICMPs.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Daniel Migault]

So to clarify, the draft is mostly carrying the necessary information so
the gateway can deal with fragmentation in its network using whatever means
is needed.
The use of ICMP PTB was only a suggestion, other mechanisms may be used.
The definition of such a mechanism is outside of ipsec and the draft.
Our understanding is that unless there is no such mechanism the draft has
some value.

Yours,
Daniel


On Mon, Oct 31, 2022 at 11:59 AM Joe Touch  wrote:

> +1
>
> > On Oct 31, 2022, at 8:37 AM, Michael Richardson 
> wrote:
> >
> > 
> > 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 =-
> >
> >
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Daniel Migault]

I think Michael is correct. The problem comes from the fragmentation of the
outer IPv4 packet. The inner packet might be IPv4 or IPv6 and the
security gateway may use any possible means to ask the nodes to adjust
their MTU. Currently we suggest using ICMP PTB, but if  RFC9268 also
provides some means to do it, we do not want to prevent using it. We
currently believe that this may be up to the gateway to decide what to do,
so we do not necessarily require any use mechanism to be normative - but
that point may evolve depending on what the WG decides.

Yours,
Daniel

On Mon, Oct 31, 2022 at 11:37 AM Michael Richardson 
wrote:

>
> 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 =-
>
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Joe Touch]

+1

> On Oct 31, 2022, at 8:37 AM, Michael Richardson  wrote:
> 
> 
> 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 =-
> 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Daniel Migault]

On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com 
wrote:

> HI, Tero, et al,,
>
> Thanks for the clarification; I now understand that what you really are
> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a
> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>
> My understanding is that IPv6 performs fragmentation at the source, in
which case, the receiving gateway does not need to defragment.  Our problem
is only happening with IPv4 when an on-path router fragments and the
receiving security gateway needs to re-fragment.

We explicitly mention in the introduction that what we have is not a
PLPMTUD for IPsec. Our understanding is that we are closer to ICMP-like
than a PLPMTUD. Maybe a PLPMTUD can be built on top of it, but we would
like to avoid taking that path for now.


> To the authors, again please see intarea-tunnels. The terms used here are
> ambiguous - “downstream” of a tunnel means traffic as it leaves the egress,
> but “downstream’ of the ingress could mean either that or the tunnel path
> itself (both are downstream).
>
> > On Oct 31, 2022, at 4:18 AM, Tero Kivinen  wrote:
> >
> > to...@strayalpha.com writes:
> >>In the best case scenario, the security gateway informs the source
> node to
> >>reduce the size of the inner packet with an ICP PTB packet for
> example.
> >>
> >> How? It can’t send an ICMP because it doesn’t have *the* packet causing
> the
> >> problem to “reflect” back to the source. The ingress may not know who
> the
> >> source is (there may be thousands or millions of sources). So which
> source?
> >
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but only knows the SPI of the
> > Child SA, not who was the original sender. So it keeps track that for
> > this SPI the ESP packets cannot be larger than xxx bytes.
> >
> > Next time it receives a packet from the source and when it is
> > encrypting it, it will verify that it will fit the size set for that
> > Child SA, and if it is too big, it will generate ICMP PTB for that
> > specific packet.
> >
> > IPsec gateways have been doing that for years, and this has been
> > described in the RFC4301 section 8.2.1.
>
> That would happen because the tunnel packet caused PTB. This case is
> described in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong
> (IMO) is described in Section 4.3.1 and is related to RFC 3884, e.g., by
> subsuming the functions of a router inside the IPsec mechanism, rather than
> operating strictly as a tunnel, which should be represented as a link - and
> *links do not send ICMP messages.
>
> What SHOULD happen in IPsec is that the SPI should have an MTU (being a
> link) and the *router* where packets are forwarded into the tunnel should
> determine when packets that want to enter that link are too big - at which
> point, per RFC 1812, the *router* should be sending the ICMP.
>
> > 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.
>
> The only reason the packet would have been too big at the receiver is if
> it were to exceed the receiver’s reassembly buffer. That’s not what’s
> happening here.
>
> It seems like there’s confusion about the fact that the source can somehow
> avoid fragmentation of the tunneled packets. That can’t happen - see
> intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur.
> The receiver should never send PTBs for 64-byte IPv4 packets (or 1280B
> IPv6).
>
> Further, on-path fragmentation for IPv4 has been warned against (the
> source has to rate-limit to avoid ID reuse during expected reordering, per
> RFC 6864).
>
> > Now the sending end can do similar processing of this information that
> > it does for unauthenticated ICMP PTB messages received for ESP
> > packets.
>
> Receiving a fragment isn’t a PTB event, though, as noted above.
>
> > --
> > kivi...@iki.fi
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
>

-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] risav document at IPsec

[Michael Richardson]

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

[Michael Richardson]

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

[to...@strayalpha.com]

On Oct 31, 2022, at 5:17 AM, Michael Richardson  wrote:
> 
> 
> The other question is whether or not we can just leverage RFC9268 to do this.
> This is a recent 6man innovation.

You’d need to decide whether you are trying to fix IPv4 or IPv6 (this doc 
relies on IPv4) and whether you think RFC9268 headers will help or hurt the 
chances of your IPv6 packets getting through a net.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[to...@strayalpha.com]

HI, Tero, et al,,

Thanks for the clarification; I now understand that what you really are seeking 
is PLPMTUD for IPsec, but somehow using on-path fragmentation as a signal. 
That’s a mistake, IMO, largely because it serves only IPv4.

To the authors, again please see intarea-tunnels. The terms used here are 
ambiguous - “downstream” of a tunnel means traffic as it leaves the egress, but 
“downstream’ of the ingress could mean either that or the tunnel path itself 
(both are downstream).

> On Oct 31, 2022, at 4:18 AM, Tero Kivinen  wrote:
> 
> to...@strayalpha.com writes:
>>In the best case scenario, the security gateway informs the source node to
>>reduce the size of the inner packet with an ICP PTB packet for example. 
>> 
>> How? It can’t send an ICMP because it doesn’t have *the* packet causing the
>> problem to “reflect” back to the source. The ingress may not know who the
>> source is (there may be thousands or millions of sources). So which source?
> 
> The normal case to do that is that IPsec SGW keeps track of the size
> of packets that are ok, and which are too big based on the information
> it receives. I.e., it might have received unsecured ICMP PTB message
> from the network for its own Child SA, but only knows the SPI of the
> Child SA, not who was the original sender. So it keeps track that for
> this SPI the ESP packets cannot be larger than xxx bytes.
> 
> Next time it receives a packet from the source and when it is
> encrypting it, it will verify that it will fit the size set for that
> Child SA, and if it is too big, it will generate ICMP PTB for that
> specific packet.
> 
> IPsec gateways have been doing that for years, and this has been
> described in the RFC4301 section 8.2.1.

That would happen because the tunnel packet caused PTB. This case is described 
in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong (IMO) is 
described in Section 4.3.1 and is related to RFC 3884, e.g., by subsuming the 
functions of a router inside the IPsec mechanism, rather than operating 
strictly as a tunnel, which should be represented as a link - and *links do not 
send ICMP messages.

What SHOULD happen in IPsec is that the SPI should have an MTU (being a link) 
and the *router* where packets are forwarded into the tunnel should determine 
when packets that want to enter that link are too big - at which point, per RFC 
1812, the *router* should be sending the ICMP.

> 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.

The only reason the packet would have been too big at the receiver is if it 
were to exceed the receiver’s reassembly buffer. That’s not what’s happening 
here.

It seems like there’s confusion about the fact that the source can somehow 
avoid fragmentation of the tunneled packets. That can’t happen - see 
intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur. The 
receiver should never send PTBs for 64-byte IPv4 packets (or 1280B IPv6).

Further, on-path fragmentation for IPv4 has been warned against (the source has 
to rate-limit to avoid ID reuse during expected reordering, per RFC 6864).

> Now the sending end can do similar processing of this information that
> it does for unauthenticated ICMP PTB messages received for ESP
> packets. 

Receiving a fragment isn’t a PTB event, though, as noted above. 

> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Michael Richardson]

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

[Michael Richardson]

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] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Tero Kivinen]

to...@strayalpha.com writes:
> In the best case scenario, the security gateway informs the source node to
> reduce the size of the inner packet with an ICP PTB packet for example. 
> 
> How? It can’t send an ICMP because it doesn’t have *the* packet causing the
> problem to “reflect” back to the source. The ingress may not know who the
> source is (there may be thousands or millions of sources). So which source?

The normal case to do that is that IPsec SGW keeps track of the size
of packets that are ok, and which are too big based on the information
it receives. I.e., it might have received unsecured ICMP PTB message
from the network for its own Child SA, but only knows the SPI of the
Child SA, not who was the original sender. So it keeps track that for
this SPI the ESP packets cannot be larger than xxx bytes.

Next time it receives a packet from the source and when it is
encrypting it, it will verify that it will fit the size set for that
Child SA, and if it is too big, it will generate ICMP PTB for that
specific packet.

IPsec gateways have been doing that for years, and this has been
described in the RFC4301 section 8.2.1.

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.

Now the sending end can do similar processing of this information that
it does for unauthenticated ICMP PTB messages received for ESP
packets. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec