Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Tero Kivinen <kivi...@iki.fi> > Envoyé : mardi 31 janvier 2023 14:49 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : Valery Smyslov <smyslov.i...@gmail.com>; draft-ietf-ipsecme- > add-...@ietf.org; ipsec@ietf.org > Objet : RE: [IPsec] Shepherd review of the draft-ietf-ipsecme-add- > ike > > mohamed.boucad...@orange.com writes: > > > > 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. > > > > > > Hm... I think my co-authors can comment on this. > > > > > > > [Med] This is intended. The requestor can suggest any of the > > parameters in a request. That is already covered by the > following: > > > > * " 0 if the Configuration payload has types CFG_REQUEST (if no > > * specific DNS resolver is requested) ..." > > * "If the initiator does not want to request specific DNS > resolvers, > > * it sets the Length field to 0 ..." > > * "For a given attribute type, the initiator MAY send either an > > * empty attribute or a list of distinct suggested resolvers." > > This is different case. > > I.e., there are (possibly) 3 different formats of CFG_REQUEST: > > CP(CFG_REQUEST) = > ENCDNS_IP6() > > i.e., length = 0, initiator just request responder to send us > informationfor ENCDNS_IP6. [Med] Yes. > > CP(CFG_REQUEST) = > ENCDNS_IP6(Service Priority = 0, Num Addresses = 0, > ADN Length = 16, IP addresses = (), > Authentication Domain Name = "doh1.example.com", > Service Paramters = "???") > > i.e., initiator requesting the responder to return information for > Authentication Domain Name of doh1.example.com, and not providing > priority or address of it, but perhaps including some service > parameters it want the that server to have. [Med] Yes, the initiator may include a suggested ALPN (protocol) for example to specifically indicate it is looking for DoT (or another protocol). The initiator may omit the ADN, but only include service parameters (typically, ALPN) to indicate a preferred transport protocol. > > CP(CFG_REQUEST) = > ENCDNS_IP6(23, 1, 16, > (2001:DB8:99:88:77:66:55:44), > "doh1.example.com", > "???") > > initiator requesting the responder for specific information, most > likely something that it got last time, and initiator proposes it > to the responder, in case it is still valid, and responder can > send that same information back if it is valid, or return > something else. [Med] Yeah, but still this is just a suggested value and it is up to the responder to decide to honor it or not. If a preference does not make sense, the response will simply ignore it. > > Btw, for the second use case where the initiator fills in some of > the information about the server it wants to talk to, it would be > usefull to allow Service Priority to be 0, and explictly mention > that this is not AliasMode, this is meaning that initiator does > not care about the exact priority or does not know the priority, > so it used 0 as placeholder. [Med] The initiator can use any non-null value for the priority in such case. No need to relax the constraint imposed on svcpriority. > > > > > 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. > > > > > > OK. > > > > [Med] Actually, no. We don't have a mix. The AF is determined by > the > > attribute type. This is why we have the following: "One or more > IPv4 > > (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6)." > > Yes, I know, but it does not say how those IP-addresses are > encoded in that field. They could be sent out as 16-octet values > for both IPv4 and IPv6 addresses, where the IPv4 address would > only use last 4 octets :-) Only way to know that this is not true > is to check the formula in Length calculation... > > It is obvious that they are encoded as 4 octets for each IPv4 > address and there is nothing between them, and same for IPv6 > addresses, except each address takes 16 octets, but I think it > would be good to explain it here. > > Something like this: > > For ENCDNS_IP4 this field contains one or more 4 octet IPv4 > address, and for ENCDNS_IP6 this field contains one or more 16 > octet IPv6 address. Address in this field can be used to reach > ... > [Med] OK, will be fixed. > -- > kivi...@iki.fi _________________________________________________________________________________________________________________________ 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
