Hello Valery, Thanks for commenting on the draft .
2014-02-21 12:02 GMT+01:00 Valery Smyslov <[email protected]>: > Hi, > > I have some comments regarding the draft. > > First, I'm a bit puzzled by intended status of the draft: Standards Track. > From my understanding this means, that the document defines some protocol, > that needs to be standardized to get interoperability. But the draft > defines > no protocol, it just speculates on what contents of IKE/IPsec SA must > contain. > While no doubt it is helpful, I think that the proper intended status for > the draft > is Informational. > You are right, the draft is intended to be INFORMATIONAL. This is already changed in version -01, but will be uploaded later as this draft tool is disable until 3th march. > > Then, I've been always thinking that the content of the IKE/IPsec SA is > an implementation issue. The draft tries to mandate this content, > but it lacks plenty of absolutely needed information (this is especially > true > for IKE SA), like MID counters, window bitmaps, lifetimes, credential > information, > VIDs, features, statistics and so on. > Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some information was missing, but they actually appear in the structure example on the Appendix. These parameters, together with those pointed out by Yogendra in previous comments, are explicitly added in their corresponding sections. > > On the other hand, the draft tries to mandate one way of presenting some > data, > ignoring the fact that it is not the only (and probably not the best) > way. For example, > instead of transferring nonces and DH secret to the other node one may > transfer computed SK_* keys. This approach may have some advantages both > from security and performance perspectives. > We actually think sending keys is one quick way to build an IKE_SA/IPsec_SA. As I said before, all the keys SK_* were included in the Appendix but are missing within the lists in sections 4 and 5. They are added in the following version of the draft -01. We also included three different level of parameters in order to classify their relevance: *Mandatory, Optional or Vendor Specific*. Note that the draft does not intend to define the format for transferring the parameters/contexts. The draft actually identifies each parameter that MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify the relevance of the parameter, it can be defined as Mandatory (M), Optional (O) or Vendor Specific (V). I have one question concerning about comment concerning the keys (SK_*), : A node can send all the keys (SK_*) to avoid their recalculation in the other node, ignoring the Nonces and DH secret. However, ignoring Nonces might lead to the impossibility of REKYING crypto material. Please correct me if I'm wrong. So my question is: Are you proposing to add all SK_* together with the Nonce and DH information? Or, do you think that sending all keys might be enough (ignoring Ni, Nr and DH-related information)? Kind Regards, Daniel Palomares > Regards, > Valery Smyslov. > > > ----- Original Message ----- > *From:* Daniel Palomares <[email protected]> > *To:* [email protected] > *Sent:* Thursday, February 13, 2014 6:09 PM > *Subject:* [IPsec] Draft: IKEv2/IPsec Context Definition > > Hi, > > Please find a draft we have Posted. They concern the definition of IKEv2 > and IPsec contexts. > Comments are welcome, > > BR, > > Daniel Palomares > > > > > > Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. > > Revision: 00 > Title: IKEv2/IPsec Context Definition > Document date: 2014-02-12 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt<http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt> > Status: > https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ > Htmlized: > http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 > > > Abstract > > IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a > single address by the end user. The traffic is then split between > the nodes via specific IP load balancing policies. Once a session is > assigned to a given node, IPsec makes it difficult to assign the > session to another node. This makes management operations and > transparent high availability for end users difficult to perform > within the cluster. > > This document describes the contexts for IKEv2 and IPsec that MUST be > transferred between two nodes so a session can be restored. This > makes possible to transfer an IPsec session transparently to the end > user. > > > > *Daniel* *PALOMARES* > > *Orange Labs, Issy-les-Moulineaux* > > +33 6 34 23 07 88 > > ------------------------------ > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
