Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike
Hi, I confirm that I'm not aware of any IPR related to this draft. Regards, Valery. > Hi all, > > As a input to the writeup, we are replying to the IPR poll on-list. > > I don't have any IPR nor I'm aware of any related to this draft. > > My co-authors replies will follow soon. > > Cheers, > Med > > > -Message d'origine- > > De : Tero Kivinen > > Envoyé : dimanche 29 janvier 2023 18:01 > > À : draft-ietf-ipsecme-add-...@ietf.org > > Objet : Shepherd write-up information > > > > __ > ___ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne > doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez > le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles > d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be > protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its > attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or > falsified. > Thank you. > > ___ > 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] Shepherd review of the draft-ietf-ipsecme-add-ike
Here are some my review comments while reading draft-ietf-ipsecme-add-ike: -- The text in section 3.1 should say that if length is 0, then no Service Priority, Num Addresses etc fields are present. I.e., add text in first bullet under Length saying that if length is zero, then later fields are not present. -- Also the text in Num Addresses indicate that it would be valid to send CFG_REQUEST with proposed Service Priority, but having Num Addresses set to zero? Is this intended? I.e., is the client allowed to request data, but not propose IP address? If so, perhaps add sentence to Num Addresses explaining that it can be 0 for CFG_REQUEST when no specific address is request, but other parameters are requested. -- In IP Address(es) explictly mention that it is field contain 4 octet IPv4 addresses, or 16 octet IPv6 address without any delimeters etc. This can be derived from the calculation of the length field, but I think it should be mentioned here, even when it is obvious. -- In section 3.2 it is not clear what the length of the Hash Algorithm Identifiers fields is. It contains list of hash algorithms or one hash algorithm if this is response, but it is not clear what is response. We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other hand CFG_SET is usually used to set the parameters, thus the Certificate Digest would be required there. I would assume that there is only one Hash Algorithm Identifier for CFG_REPLY and CFG_SET, and then the Certificate Digest field is present. For CFG_REQUEST the Hash Algorithm Identifier is a list of two octet hash algorithm identifiers and the Certificate field is omitted. For the CFG_ACK only first 4 octets are included and Length is set to zero. I think it would be better to split the Figure 2 to three different figures: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+---+---+ |RESERVED | ADN Length | +---+---+ ~ Authentication Domain Name ~ +---+ ~ Hash Algorithm Identifier (2 octets) ~ +---+ ~ Certificate Digest~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+---+---+ |RESERVED | ADN Length | +---+---+ ~ Authentication Domain Name ~ +---+ ~ List of Hash Algorithm Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK. and then explain the Hash Algorithm Identifier and List of Hash Algorithm Identifiers separately. Actually is there any point of having ADN Length and Authenticated Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes with certain domain names with different hash algorithms? Perhaps we should define the format for CFG_REQUEST as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +---+---+ ~ List of Hash Algorithm Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike
I am not aware of any intellectual property rights claims with draft-ietf-ipsecme-add-ike. -d > On Jan 29, 2023, at 10:30 PM, mohamed.boucad...@orange.com wrote: > > Hi all, > > As a input to the writeup, we are replying to the IPR poll on-list. > > I don't have any IPR nor I'm aware of any related to this draft. > > My co-authors replies will follow soon. > > Cheers, > Med > >> -Message d'origine- >> De : Tero Kivinen >> Envoyé : dimanche 29 janvier 2023 18:01 >> À : draft-ietf-ipsecme-add-...@ietf.org >> Objet : Shepherd write-up information >> > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike
I am not aware of any IPR that applies to this draft. Cheers, -Tiru On Mon, 30 Jan 2023 at 12:00, wrote: > Hi all, > > As a input to the writeup, we are replying to the IPR poll on-list. > > I don't have any IPR nor I'm aware of any related to this draft. > > My co-authors replies will follow soon. > > Cheers, > Med > > > -Message d'origine- > > De : Tero Kivinen > > Envoyé : dimanche 29 janvier 2023 18:01 > > À : draft-ietf-ipsecme-add-...@ietf.org > > Objet : Shepherd write-up information > > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
