Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 , 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] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 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. Can you explain why this is an issue? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 like a good solution. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 "best" value from the encapsulated traffic. The DSCP value is only meaningful within an AS. The end points of the tunnel and the outside of the tunnel are really different diffserv domains. The ECN markings are in the same byte, and we do things with that, but that's not the DSCP. Changing the DSCP would seem to enable traffic analysis. As TFS needs to do congestion control, I think that the ECN markings should be used by TFS, and TFS should do ECN markings upon entry/exit of the tunnel itself, after some processing itself. It might mark congestion seen more often than the outside of the tunnel sees if it needs the users of the tunnel to back down because they are exceeding the allocation. It might also ignore congestion if the congestion is due to the extra traffic. So I think that the DSCP needs to be configured appropriately for the AS that is sending the packets. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 traffic and there are I don't think it is useful to run tfs for multicast traffic. > 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. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 of order when they are sent encapsulated. Can you explain why this is an issue? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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" 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) 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" 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. > > internet-dra...@ietf.org 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 > > i-d-annou...@ietf.org > > 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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) 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" 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. internet-dra...@ietf.org 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 > i-d-annou...@ietf.org > 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 signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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" 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. internet-dra...@ietf.org 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 > i-d-annou...@ietf.org > 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 in SA. In this case SN will repeat, so your reassembling mechanism won't work (well, there is no any replay protection in this case too). And I really want to make reassembling feature optional and negotiable. Regards, Valery. > 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. > > internet-dra...@ietf.org 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 > > i-d-annou...@ietf.org > > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 > previously to be current, keep the message ID the same and resend the > message. Would changing the data in > the message prior to resending be preferable? No, all retransmissions of IKE message with the same Message ID must be binary identical. Regards, Valery. > Thanks, > Chris. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 though. Yes, they are currently only > used for errors, but again I didn't > read they were restricted to that use alone. No, unidirectional notifications cannot be used in regular IKE SAs. The reason is that both peers must have common view on the next Message ID to be used in each direction. If unidirectional message with Message ID N is lost, its sender will never know that and think he can safely use Message ID N+1 for the next exchange, while the receiver will discard N+1, since N is not received yet (I assume for simplicity that IKE window size is 1). This simply won't work. In current IKEv2 unidirectional messages are exceptions and can only be sent unencrypted outside any existing IKE SA. > The reason I did not want to make the report sending reliable is that they > are continuously sent on an > relatively short interval. It didn't make a lot of sense to be re-sending a > possibly growing queue of reports > repeatedly, when the latest one would do. Then send them over IPsec. Regards, Valery. > Thanks, > Chris. > > > > > On Mar 11, 2019, at 11:43 AM, Valery Smyslov wrote: > > > > 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 > >>payload should be the congestion information in the notification > >>payload. > >> > >> This very much violates the state machine model of IKEv2, and I would > >> not be in favour of this without strong arguments of why requiring a > >> response (even if empty) is harmful. > > > > Strongly agree. Actually, one-way notifications are only defined > > in IKEv2 for unprotected error notifications when no IKE SA exists > > (like INVALID_IKE_SPI notifications). They simply don't work > > for regular IKEv2 traffic. > > > > Regards, > > Valery. > > > >> Paul > >> > >> ___ > >> 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 > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 currently only used for errors, but again I didn't read they were restricted to that use alone. The reason I did not want to make the report sending reliable is that they are continuously sent on an relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing queue of reports repeatedly, when the latest one would do. Thanks, Chris. > On Mar 11, 2019, at 11:43 AM, Valery Smyslov wrote: > > 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 >>payload should be the congestion information in the notification >>payload. >> >> This very much violates the state machine model of IKEv2, and I would >> not be in favour of this without strong arguments of why requiring a >> response (even if empty) is harmful. > > Strongly agree. Actually, one-way notifications are only defined > in IKEv2 for unprotected error notifications when no IKE SA exists > (like INVALID_IKE_SPI notifications). They simply don't work > for regular IKEv2 traffic. > > Regards, > Valery. > >> Paul >> >> ___ >> 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 > signature.asc Description: Message signed with OpenPGP ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 > payload should be the congestion information in the notification > payload. > > This very much violates the state machine model of IKEv2, and I would > not be in favour of this without strong arguments of why requiring a > response (even if empty) is harmful. Strongly agree. Actually, one-way notifications are only defined in IKEv2 for unprotected error notifications when no IKE SA exists (like INVALID_IKE_SPI notifications). They simply don't work for regular IKEv2 traffic. Regards, Valery. > Paul > > ___ > 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] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
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 quick read and I'm still digesting this, but one thing seems a concern: 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 payload should be the congestion information in the notification payload. This very much violates the state machine model of IKEv2, and I would not be in favour of this without strong arguments of why requiring a response (even if empty) is harmful. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
