Graham Bartlett (grbartle) wrote:
> From my limited experience the performance of many applications is
> degraded when traffic is received out of order.
If the flows are marked differently, then they are from different
applications, so it does not matter.
--
Michael Richardson ,
Hi Michael
>From my limited experience the performance of many applications is degraded
>when traffic is received out of order.
cheers
On 31/03/2019, 02:37, "IPsec on behalf of Michael Richardson"
wrote:
Graham Bartlett (grbartle) wrote:
> I see this as a really hard
Michael Richardson writes:
Valery Smyslov wrote:
> And I really want to make reassembling feature optional and negotiable.
It seems to me that the receiver has to indicate that it supports it or not,
(just like we do for compression), and the sender either uses it or does not.
This seems
Christian Hopps wrote:
> This is a good question. We currently indicate it's a local
> configuration decision, but we may want to go deeper into possible
> options in the draft.
> Right now we see 3 options:
> - A static configured value for the SA
> - Inherit the
Valery Smyslov wrote:
> having think a bit more about reassembling on a receiving side, I think
> that there may be some issues. You rely on ESP SN to properly
> reassemble the IP packets, but there is at least one case when it
> doesn't work - when IPsec protects multicast
Graham Bartlett (grbartle) wrote:
> I see this as a really hard problem to solve (and don't have a
> solution).
> The issue is, if you're mixing different traffic into an encrypted
> payload then there's a very good chance your inner flows are going to
> start becoming out
Hi Chris
Sorry, I meant to catch you yesterday, but had to leave.
I see this as a really hard problem to solve (and don't have a solution).
The issue is, if you're mixing different traffic into an encrypted payload then
there's a very good chance your inner flows are going to start becoming
Hi Graham,
This is a good question. We currently indicate it's a local configuration
decision, but we may want to go deeper into possible options in the draft.
Right now we see 3 options:
- A static configured value for the SA
- Inherit the "best" value from the encapsulated traffic.
-
Hi Chris
Thanks for the presentation yesterday.
I have been thinking about traffic with different DSCP markings.
e.g if I have voice, video and web traffic (with their configured DSCP), it
looks like all three flows could be sent in a single encrypted payload and the
DSCP marking in the outer
Hi Christian,
having think a bit more about reassembling on a receiving side,
I think that there may be some issues. You rely on ESP SN to
properly reassemble the IP packets, but there is at least one
case when it doesn't work - when IPsec protects multicast traffic
and there are several senders
Hi Chris,
> There are other ways to skin this cat though. :)
>
> One option is that instead of sending a new CC info report on the interval
> timer expiry if we haven't received a
> response "ack" yet, we simply update the data (last seq num seen, drop count
> and timestamp) we sent
>
Hi Chris,
> Sure, I'm definitely open to changes, and in particular with the congestion
> info report. This is just the first
> draft. :)
>
> So my reading of IKEv2 indicated that one way notifications were supported,
> not that they were *only* to be
> used for unprotected error notification
Sure, I'm definitely open to changes, and in particular with the congestion
info report. This is just the first draft. :)
So my reading of IKEv2 indicated that one way notifications were supported, not
that they were *only* to be used for unprotected error notification though.
Yes, they are
Hi,
> We utilize a send only (i.e., no response expected) IKEv2
> INFORMATIONAL exchange (37) to transmit the congestion information
> using a notification payload of type TFS_CONGEST_INFO (TBD). The The
> Response bit should be set to 0. As no response is expected the only
>
On Mon, 11 Mar 2019, Christian Hopps wrote:
Here's some new work on improving IP traffic flow security. I've requested a
presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF
104, and will hopefully be able to present this work at that time as well.
Thanks. I did a
15 matches
Mail list logo
