Should servers be allowed to open new paths?

[mirjak]

In RFC9000 path migration is restricted to clients only, mainly because of problems with NATs which a) is the main use case to have migrations (address change at the client only) and b) could anyway cause failure for mitigation attempts from the server.

However, with multipath, failure of opening a new path is less critical as the old path(s) is not abandon at the same time. Therefore we should further discussion if that restriction is still technical useful or if it can be released easily.

This issue was initially discussed as part of issue #31

[yfmascgy]

I think there might be also a security concern. Suppose a victim's address is advertised and the server attempts to open a new path with that address.

[obonaventure]

If we want the server to be able to create a new path, we need to define a new frame that allows the client to advertise the addresses and port numbers that it listens to. This is not difficult and could allow an IPv4 server to advertise its IPv6 address, but my understanding was that such frames were outside the scope of the current draft and should be part of another draft. We can extract material from draft-deconinck-quic-multipath about address advertisement and propose another that in another draft if you think that this could be useful.

[mirjak]

Yes, I think we already agreed that address advertisement should be a separate draft. However, even if the server knows already another address of the client (e.g. by using some advertisement on the higher layer), currently the server is not allowed to open a new path. This restriction made sense for the use cases for migration and made life easier. However as long as you can still use the old path in the multipath case while waiting for path probing to success, I don't see a real risk in letting the server also open new paths.

[huitema]

I would rather move that discussion to a separate draft, and keep the initial multipath draft aligned with RFC 9000.

[mirjak]

I don't think that this is necessarily something for a separate draft. If there is no good reason to keep this restriction, we should remove it. If there are good reasons we should at least document them. What are the reasons?

[mirjak]

I think we should discuss this at the next meeting!

[tfpauly]

I agree with @huitema that this should be a separate draft, where server-initiated paths can be handled holistically. The multipath shouldn't be the place that concept gets introduced.

[mirjak]

At IETF-113 there were concerns about the implications of this change. While some people were interested in this to support additional use cases, there was also quite some feedback to rather leave that for another extension (maybe together with address discovery mechanism). In any case, more analysis of the implication is needed (e.g. review discussion about this restriction for RFC9000). Leaving this open for now for further discussion.

[qdeconinck]

Revisiting this issue now, I agree on the fact that this should be a separate draft. On the other hand, the current draft proposal does not introduce any element that would prevent such server-initiated path in the future, so I suppose the current draft is going in the right direction.