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 out of order when they are sent encapsulated. So for a mix of DSCP traffic I see the following occurring; - A static configured value for the SA > priority queuing of traffic of priority traffic flows doesn't occur when it's > encrypted as everything is sharing the same DSCP - Inherit the "best" value from the encapsulated traffic. >low priority traffic gets a free ride if it's bundled with traffic of high >priority - Inherit the "worst" value from the encapsulated traffic. >high priority traffic gets a downgrade when it's bundled with low priority >traffic I'd be interested to see testing with various traffic flows and traffic that requires some form of quality of service. I've seen similar solutions break real time traffic. cheers On 29/03/2019, 10:35, "Christian Hopps" <[email protected]> wrote: 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. - Inherit the "worst" value from the encapsulated traffic. Thanks, Chris. Graham Bartlett (grbartle) <[email protected]> writes: > 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 header is ignored. > > How do you look to address the challenges that this will bring with regards to traffic prioritisation ? > > Many thanks > > On 11/03/2019, 14:33, "IPsec on behalf of Christian Hopps" <[email protected] on behalf of [email protected]> wrote: > > > Hi ipsecme folks, > > 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, > Chris. > > [email protected] writes: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-hopps-ipsecme-iptfs-00.txt > > Pages : 22 > > Date : 2019-03-11 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic flow > > security by adding traffic flow confidentiality to encrypted IP > > encapsulated traffic. Traffic flow confidentiality is provided by > > obscuring the size and frequency of IP traffic using a fixed-sized, > > constant-send-rate IPsec tunnel. The solution allows for congestion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf..org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
