Hi Tero,
On 4/22/13 5:29 AM, "Tero Kivinen" <[email protected]> wrote: >Sri Gundavelli (sgundave) writes: >> Hi Tero, >> >> Thanks a lot for the review comments. This is very helpful. >> >> Please see inline. >> >> >> On 4/18/13 2:26 AM, "Tero Kivinen" <[email protected]> wrote: >> >> >In section 3 and 4, there is text saying: >> > >> >---------------------------------------------------------------------- >> >... >> > Length (2 octets) >> > Length of the value field in octets. In this case, its 4. >> >... >> > Length (2 octets) >> > Length of the value field in octets. In this case, its 16. >> >... >> >---------------------------------------------------------------------- >> > >> >But the length of the configuration attribute value can also be 0 for >> >the requests. At least in general case, I do not know whether this >> >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable >> >option or something else. In normal case the client either sends empty >> >request, and server fills the value in, or the client sends request >> >telling the preferred value, and server either replies with that or >> >something else. >> >> The goal is to allow the client to request for the configuration value, >>so >> the server can populate it. So, the client sends a request with a >> NULL/0.0.0.0 value, and the server can include the Attribute with a >>proper >> value in the response message. > >In normal IKEv2 case the configuration payload in that case will be >empty, see RFC5996 section 3.15.1: > >---------------------------------------------------------------------- >3.15.1. Configuration Attributes >... > The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request > information from its peer. If an attribute in the CFG_REQUEST > Configuration payload is not zero-length, it is taken as a suggestion > for that attribute. The CFG_REPLY Configuration payload MAY return > that value, or a new one. It MAY also add new attributes and not > include some requested ones. Unrecognized or unsupported attributes > MUST be ignored in both requests and responses. >... >---------------------------------------------------------------------- > >It would be better to use same mechanisms for all IKEv2 configuration >attributes, and not make special cases for some attributes. OK. This is fine. I will make the change. > >> >The draft also says: >> > >> >---------------------------------------------------------------------- >> > Multiple instances of this Attribute with different values can be >> > present in the configuration payload and there is no implied >> > preferrential order. >> >---------------------------------------------------------------------- >> > >> >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS >> >the multi-valued return values only work in a way, that client sends >> >as many entries in the request as it is willing to get back in the >> >reply, and server can only return as many (or fewer) items there was >> >in the request. This is to allow client to decide whether it wants to >> >support multi-valued addresses. Do you want to do similar thing here, >> >or is it assumed that all implementations do allow multiple values for >> >this attribute? The text from RFC5996 says as follows: >> >> >> The client should be able to include a single a instance of the >>Attribute >> with a value of 0.0.0.0, but the server should be able to offer one or >> more instances of the Attribute. >> >> In this case, there is no real requirement for the client to indicate >> capability for multiple instances. We can safely assume the client can >> handle one or more values. > >Ok, if client is known to be able to handle multiple values, then >there is no need to indicate that by sending multiple requests. Ack. > >> >---------------------------------------------------------------------- >> > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the >> > internal network, sometimes called a red node address or private >> > address, and it MAY be a private address on the Internet. In a >> > request message, the address specified is a requested address (or >> > a zero-length address if no specific address is requested). If a >> > specific address is requested, it likely indicates that a >>previous >> > connection existed with this address and the requestor would like >> > to reuse that address. With IPv6, a requestor MAY supply the >>low- >> > order address octets it wants to use. Multiple internal >>addresses >> > MAY be requested by requesting multiple internal address >> > attributes. The responder MAY only send up to the number of >> > addresses requested. >> >---------------------------------------------------------------------- >> > >> >This also points out how the request can either be empty or have some >> >previously used value in. Do you want to do similar thing here? >> >> The request should be empty. I don't believe ePDG is sending specific >> hints over S2b interface and so we are bound by that interface >>definition. >> I will check the spec to be sure. > >In configuration payload format the empty attribute means that the >attribute length is 0, and the value is omitted, in your case the >attribute length was not allowed to be 0, so the attribute cannot be >empty, but I think it would be better to change it so it can have >length "0 or 4 octects" and "0 or 16 octects", just like all other >IKEv2 Configuration Attributes. >-- Sure. I will make the change to allow empty container. Regards Sri > >[email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
