Hello all, A minor technical note about Issue #22. Section 2.25, last paragraph reads:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch. The original text does not mention what the SPI should be (it is practially implied what it should be set to, but is still not mentioned in the text). Presumably one would set the this to be the SPI of the Child SA that caused the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA notification). This way, the Initiator knows which rekeying attempt resulted in this error. I would propose to change this text to: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify Payload, which is copied from the SPI field in the REYEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch. Regards, Matt 2009/12/14 Tero Kivinen <kivi...@iki.fi> > Paul Hoffman writes: > > At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote: > > >Hi, I want to check one point. > > >At the last paragraph in Section 2.5, there is a mention of refering > > >the figures in Section 2. > > >Does it mean we should refer all fighres in Section 2? > > >Or does it mistake section 2 for section 1? > > > > Good catch. It should say "...the order shown in the figures in > > Sections 1 and 2". We split some of the figures out of 2 into 1, but > > we still have ones that have payload orders in section 2. > > In the RFC4306 most of the figures with payloads were in the section > 1. Section only had Cookies, EAP and Configuration payload examples. > > Basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange > figures have always been in the section 1. > > This is the situation also now (i.e. draft-ietf-ipsecme-ikev2bis-06 > still has the basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and > INFORMATION exchange figures in section 1 and the only change is that > we splitted one of those figures (CREATE_CHILD_SA) from one figure to > 3 figures (creating new Child SA, rekeying IKE SA, rekeying Child SA). > > Section 2 never had any figures listing payload orders for example for > CREATE_CHILD_SA exchange. > > So this bug has been in the document before the bis document, i.e. it > was in the RFC4306. > > On the other hand as we now say that "implementations MUST NOT reject > as invalid a message with those payloads in any other order." I do not > think this is that big issue. Also the payload order is now only > SHOULD not MUST anymore. > > BTW, I think that change is one of the significant changes we should > list in the RFC4306, i.e. following the payload order of the figures > in section 2 is no longer MUST, it is now SHOULD (and applies to > figures in section 1 too). > > Also it is no longer a SHOULD that messages with different payload > order than in those in figures in section 2. Now implementations MUST > NOT reject messages bacause different payload orders. > -- > 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
