Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
+1 on adopting this draft. -Original Message- From: IPsec On Behalf Of Valery Smyslov Sent: Thursday, March 14, 2019 4:38 AM To: 'Tero Kivinen' ; ipsec@ietf.org Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 Hi, as author of the document I (obviously) support its adoption. It's a building block for QSKE solution (at least how the WG sees it now) so I think we should adopt it. Regards, Valery. > This document has been stable for some time, and I think it is ready > to go forward. Because of that I will start one week long WG > adoptation call for this draft which will expire end of next week > (2019-03-22). > > If you have any reasons why this should not be adopted as WG document, > send email to the list as soon as possible. > -- > kivi...@iki.fi > > ___ > 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] I-D Action: draft-hopps-ipsecme-iptfs-00.txt
Valery Smyslov writes: If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are adding fragility here that isn’t really needed though. It makes the functioning of the unidirectional tunnel depend more heavily on the reverse direction traffic working when that isn’t actually needed for the tunnel to operate. Yes, don't break IKE core things. I was hoping there would be an openness to possible improvements, and wasn't looking to just break well established protocols. An earlier mail from Paul made it sound like other use-cases have wanted for expanded functionality as well. This isn't a blocker for this work, so if other people agree that it's not worth trying to improve IKE to support this use case, we can just conform rather than try to improve things. Thanks, Chris. Regards, Valery. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
Hi, as author of the document I (obviously) support its adoption. It's a building block for QSKE solution (at least how the WG sees it now) so I think we should adopt it. Regards, Valery. > This document has been stable for some time, and I think it is ready > to go forward. Because of that I will start one week long WG > adoptation call for this draft which will expire end of next week > (2019-03-22). > > If you have any reasons why this should not be adopted as WG document, > send email to the list as soon as possible. > -- > kivi...@iki.fi > > ___ > 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] I-D Action: draft-hopps-ipsecme-iptfs-00.txt
> > No, all retransmissions of IKE message with the same Message ID must be > > binary identical. > > Perhaps we could relax this requirement for this particular message though. > This seems like a simple tightly- > focused semantic change which gets us past the roadblock. No, we cannot. Retransmissions are sent when no response is received. You don't know whether request or response was lost. If you retransmit packet not equal to original, then you don't know which packet the responder received - first or second. I guess in your case you don't care, but in general it's not appropriate. > FWIW, regarding retransmission and message IDs, one thing I considered was > not even using the message ID > at all (e.g., let it be 0) but this seemed too radical as a first approach. > :) > > If there really is no way to work around this, I suppose we just require > retransmissions of CC info reports until > they are ACKd or things are torn down b/c of drops (i.e., normal INFO > exchange). It does feel like we are > adding fragility here that isn’t really needed though. It makes the > functioning of the unidirectional tunnel > depend more heavily on the reverse direction traffic working when that isn’t > actually needed for the tunnel to > operate. Yes, don't break IKE core things. Regards, Valery. > Thanks, > Chris. > > > > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
