Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

[Tero Kivinen <[e-mail]>]

[e-mail] 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.

  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.

  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.

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. 

> > > 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 ...

-- 
[e-mail]