Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*IPsec\s+and\s+Path\s+MTU\s*$/: 52 ]

Total 52 documents matching your query.

1. IPsec and Path MTU (score: 1)
Author: <broonie@xxxxxxxxxxxxx>
Date: Tue, 15 Jun 2004 22:43:34 +1000
Can someone explain the rationale behind dst->path and dst_pmtu to me? As far as I can see it was introduced specifically for IPsec. However, it seems to me that it makes no sense whatsoever in that
/archives/netdev/2004-06/msg00370.html (8,505 bytes)

2. Re: IPsec and Path MTU (score: 1)
Author: l <hadi@xxxxxxxxxx>
Date: Tue, 15 Jun 2004 10:50:37 -0400
Herbert> Can someone explain the rationale behind dst->path and Herbert> dst_pmtu to me? Herbert> As far as I can see it was introduced specifically for Herbert> IPsec. However, it seems to me that i
/archives/netdev/2004-06/msg00374.html (10,307 bytes)

3. Re: IPsec and Path MTU (score: 1)
Author: ert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 16 Jun 2004 21:43:45 +1000
I'd say that we should get the stack to work with the hosts that do send ICMP replies first, and then worry about those that don't :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~
/archives/netdev/2004-06/msg00417.html (9,446 bytes)

4. Re: IPsec and Path MTU (score: 1)
Author: xxxx>
Date: Wed, 16 Jun 2004 22:10:26 +1000
Actually that's still broken for nested tunnels. If we get an ICMP packet for a peer in the middle of the bundle, it is not easy to find the corresponding dst's to update. So how about this solution:
/archives/netdev/2004-06/msg00420.html (11,450 bytes)

5. Re: IPsec and Path MTU (score: 1)
Author: xxxxxxxxxx>
Date: Wed, 16 Jun 2004 10:12:12 -0400 (EDT)
I think this sounds reasonable, and it is complicated (there's a reason why it hasn't been implemented yet). - James -- James Morris <jmorris@xxxxxxxxxx>
/archives/netdev/2004-06/msg00425.html (8,946 bytes)

6. Re: IPsec and Path MTU (score: 1)
Author: xxxxxx>
Date: Wed, 16 Jun 2004 10:43:19 -0400
Herbert> I'd say that we should get the stack to work with the hosts Herbert> that do send ICMP replies first, and then worry about those Herbert> that don't :) The proposal there is a compromise bet
/archives/netdev/2004-06/msg00426.html (10,880 bytes)

7. Re: IPsec and Path MTU (score: 1)
Author: xxxxxxxx>
Date: Wed, 16 Jun 2004 23:56:53 +0400
Each SA bundle referring to a dst has pmtu derived from pmtu of that dst. So, actually, I do not understand the question. If the policy uses the raw IP level path dst, it inherits this pmtu. Alexey
/archives/netdev/2004-06/msg00442.html (10,017 bytes)

8. Re: IPsec and Path MTU (score: 1)
Author: id S. Miller" <davem@xxxxxxxxxx>
Date: Thu, 17 Jun 2004 00:23:41 +0400
Yes, this is absolutely true. BTW we talked about this already. The problem here is pure technical. In any case pmtu on path going through tunnel is _lower_ than dst_path() and has to be recalculate
/archives/netdev/2004-06/msg00445.html (10,273 bytes)

9. Re: IPsec and Path MTU (score: 1)
Author: y Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Wed, 16 Jun 2004 13:49:04 -0700
Yes, it seems we should finally implement this beast.
/archives/netdev/2004-06/msg00449.html (9,751 bytes)

10. Re: IPsec and Path MTU (score: 1)
Author: xxxx>
Date: Thu, 17 Jun 2004 09:13:17 +1000
The problem is that each bundle can have only one PMTU. But there can be an arbitrary number of paths over each bundle. Sorry, should be fixed now. -- Visit Openswan at http://www.openswan.org/ Email
/archives/netdev/2004-06/msg00464.html (10,392 bytes)

11. Re: IPsec and Path MTU (score: 1)
Author: eff Garzik <jgarzik@xxxxxxxxx>
Date: Thu, 17 Jun 2004 09:11:50 +1000
Agreed. However, the we don't have enough dst's in the bundle as it is because each policy only has one bundle, but there may be aa arbitrary number of different paths and hence different PMTUs over
/archives/netdev/2004-06/msg00465.html (12,339 bytes)

12. Re: IPsec and Path MTU (score: 1)
Author: x>
Date: Thu, 17 Jun 2004 10:58:43 -0700
Do you see what xfrm_get_mss() does? It calls into x->type->get_max_size() and this is where ESP reports this kind of thing (re: block padding).
/archives/netdev/2004-06/msg00485.html (10,384 bytes)

13. Re: IPsec and Path MTU (score: 1)
Author: xxxxxx>
Date: Thu, 17 Jun 2004 23:01:58 +0400
Seems, I still do not understand what you mean. Returning to the beginning: Diverge where exactly? On path where packets are transformed? PMTU discovery cannot do something clever for this case: we
/archives/netdev/2004-06/msg00496.html (10,402 bytes)

14. Re: IPsec and Path MTU (score: 1)
Author: xxxxxx>
Date: Fri, 18 Jun 2004 07:31:30 +1000
Yes I know. But this is only used in TCP currently. It is also rather expensive so you'd really want to cache the results rather than calling it for every packet. For example, xfrm4_check_tunnel_size
/archives/netdev/2004-06/msg00516.html (10,473 bytes)

15. Re: IPsec and Path MTU (score: 1)
Author: rbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Jun 2004 07:38:32 +1000
Let's go for an exampe: We have an IPsec tunnel to our default gateway, 0.0.0.0/0[any] 0.0.0.0/0[any] any out ispec esp/tunnel/192.168.0.2-192.168.0.1/ Suppose that the MTU of 192.168.0.1 is 1500, an
/archives/netdev/2004-06/msg00517.html (11,677 bytes)

16. Re: IPsec and Path MTU (score: 1)
Author: rbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 17 Jun 2004 15:22:16 -0700
Right. I'm sorry, is someone trying to do NFS/UDP over IPSEC? My condolences. :-) More seriously, it is a fringe case. We do need to handle it, but it is no accident that there haven't been very many
/archives/netdev/2004-06/msg00519.html (10,200 bytes)

17. Re: IPsec and Path MTU (score: 1)
Author: >
Date: Thu, 17 Jun 2004 15:29:21 -0700
This is what Alexey is talking about. When we send a packet out for an IPSEC rule, we have to remember the inner (per-transform pre-tunnel) IP addresses (keyed by outer IP address and ESP/AH spi) in
/archives/netdev/2004-06/msg00520.html (11,093 bytes)

18. Re: IPsec and Path MTU (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Fri, 18 Jun 2004 09:09:18 +1000
Nope, it breaks TCP as well. Whether you're TCP/UDP or whatever, you have to pass xfrm4_tunnel_check_size(). That function uses an incorrect derivation of the MTU, thus potentially blocking maximal p
/archives/netdev/2004-06/msg00526.html (11,151 bytes)

19. Re: IPsec and Path MTU (score: 1)
Author: erbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Jun 2004 09:12:41 +1000
Right, that's *what* Alexey is talking about. But it's *not* what I'm talking about :) Correct. But before we get to that, let's fix the simple case first. Cheers, -- Visit Openswan at http://www.ope
/archives/netdev/2004-06/msg00528.html (11,829 bytes)

20. Re: IPsec and Path MTU (score: 1)
Author: tephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 17 Jun 2004 16:14:03 -0700
Remote gateway is supposed to encapsulate the ICMP message and send it back to the other gateway isn't it?
/archives/netdev/2004-06/msg00529.html (9,800 bytes)


This search system is powered by Namazu