Hi David, Thanks for the detailed reply.
Joe's comments below on lack of congestion control and small traffic load were specifically for the 'acknowledged data transfer mode' (draft-0) that leveraged IKEv2's exchange structure and windowing mechanism. Based on the comments, the updated draft (draft-1) deprecated 'acknowledged data transfer mode' and only uses 'un-acknowledged/unreliable data transfer mode' that does not use IKEv2's exchange structure and windowing mechanism and is very similar to IPSec ESP. Hence the comments do not apply to the new draft and IKEv2 data channel provides similar service as DTLS and IPSec-ESP/UDP (NAT-T). Thanks, -Amjad -----Original Message----- From: Black, David [mailto:[email protected]] Sent: Tuesday, May 27, 2014 5:51 PM To: Amjad Inamdar (amjads); IPsecme WG ([email protected]) Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Hi Amjad, > I glanced through RFC 5405 and I think the unacknowledged UDP based > data transfer provided by IKEv2 data channel is similar to DTLS and > IPSec-over-UDP (used with NAT-T). Please let me know if I am missing anything > here. Sure, Joe originally wrote: > This mechanism lacks congestion control, and so needs to be used only > where its load is known to be a small fraction of capacity. In > specific, IKE's window mechanism allows for increasing the window size > but not decreasing it, as is needed to react to network congestion. > > The acknowledged data transfer mode uses IKE's window mechanism, which > is presumably set to a small value, and may result in very low throughput. > Attempts to increase this window size to overcome this limitation can > easily increase burstiness and network loss. I believe both comments continue to apply. IKEv2 is self-limiting in its use of UDP courtesy of IKEv2's exchange structure; this draft proposes to change that. If the intended use case really is IoT, then something can be said about the limited amount/rate of traffic that is involved. Thanks, --David > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:[email protected]] > Sent: Monday, May 26, 2014 3:37 AM > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG > ([email protected]) > Subject: RE: New Version Notification for > draft-amjads-ipsecme-ikev2-data- channel-01.txt > > Hi David, > > I glanced through RFC 5405 and I think the unacknowledged UDP based > data transfer provided by IKEv2 data channel is similar to DTLS and > IPSec-over-UDP (used with NAT-T). Please let me know if I am missing anything > here. > > Thanks, > -Amjad > > -----Original Message----- > From: Black, David [mailto:[email protected]] > Sent: Wednesday, April 30, 2014 7:53 PM > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); IPsecme WG > ([email protected]) > Subject: RE: New Version Notification for > draft-amjads-ipsecme-ikev2-data- channel-01.txt > > Amjad, > > I'm sorry, but that would be incorrect; please read RFC 5405 and apply > its design guidance. > > Thanks, > --David (Transport Directorate member and tsvwg WG co-chair) > > > -----Original Message----- > > From: Amjad Inamdar (amjads) [mailto:[email protected]] > > Sent: Wednesday, April 30, 2014 2:52 AM > > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG > > ([email protected]) > > Subject: RE: New Version Notification for > > draft-amjads-ipsecme-ikev2-data- channel-01.txt > > > > Hi David, > > > > In the new version (version 1) of the draft, unlike IKEv2 control > > packets the data packets are not acknowledged and hence the comments > > on congestion and windowing no longer apply. > > > > Thanks, > > -Amjad > > > > -----Original Message----- > > From: IPsec [mailto:[email protected]] On Behalf Of Black, > > David > > Sent: Friday, April 18, 2014 3:58 AM > > To: Rajeshwar Singh Jenwar (rsj); IPsecme WG ([email protected]) > > Subject: Re: [IPsec] New Version Notification for > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > Well, Joe Touch's comments on congestion still apply: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html > > > > I suggest consulting RFC 5405 on this topic, and applying its guidance. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: IPsec [mailto:[email protected]] On Behalf Of Rajeshwar > > > Singh Jenwar (rsj) > > > Sent: Wednesday, March 12, 2014 10:27 PM > > > To: IPsecme WG ([email protected]) > > > Subject: [IPsec] FW: New Version Notification for > > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > > > Hi, > > > > > > We (Amjad and I) have published new version of "Data over IKEv2 > > > for application security" draft based on inputs/comments received. > > > Please review and provide comments/inputs/questions. > > > > > > Kind Regards, > > > Raj > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] > > > Sent: Wednesday, March 12, 2014 5:13 PM > > > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); > > > Rajeshwar Singh Jenwar (rsj); Amjad Inamdar (amjads) > > > Subject: New Version Notification for > > > draft-amjads-ipsecme-ikev2-data-channel- > > > 01.txt > > > > > > > > > A new version of I-D, > > > draft-amjads-ipsecme-ikev2-data-channel-01.txt > > > has been successfully submitted by Amjad S. Inamdar and posted to > > > the IETF repository. > > > > > > Name: draft-amjads-ipsecme-ikev2-data-channel > > > Revision: 01 > > > Title: IKEv2 based lightweight secure data communication draft- > > > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > > > Document date: 2014-03-12 > > > Group: Individual Submission > > > Pages: 15 > > > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipsecme- > ikev2-data-channel-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme- > ikev2- > > > data-channel/ > > > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2- > data- > > > channel-01 > > > Diff: http://www.ietf.org/rfcdiff?url2=draft-amjads-ipsecme- > ikev2- > > > data-channel-01 > > > > > > Abstract: > > > The Internet Key Exchange (IKEv2) protocol provides authentication, > > > confidentiality, integrity, data-origin authentication and anti- > > > replay. Currently, IKEv2 is mainly used as a control channel to > > > negotiate IPsec SA(s). IPsec is not well suited to provide transport > > > layer security for applications as it resides at the network layer > > > and most of the IPsec implementations require integration into > > > operating systems making it difficult to deploy. IPsec uses > > > different sessions for control and data traffic which is not NAT and > > > load balancer friendly. TLS/DTLS, the other popular security > > > mechanism to provide the above security services does not mandate > > > mutual peer authentication and Diffie Hellman exchange. > > > > > > This document describes an IKEv2 based lightweight secure data > > > communication protocol and a way to provide transport layer security > > > for UDP client/server applications. The protocol provides integrity > > > protected encryption and integrity-only protection based on > > > application needs. As most of the IoT applications are UDP based, > > > IKEv2 can be used for key management as well secure data > > > communication in IoT due to its simplicity, scalability, > > > lightweightedness and ease of deployment. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > IPsec mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
