HI Paul,
> > Actually, the format is the same for both request and response,
> > but depending on Num Hash Algs and AND Length and also on Length,
> > some fields may be omitted.
>
> > The most generic format is:
> >
> > 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 |
> > +-+-----------------------------+---------------+---------------+
> > | Num Hash Algs | ADN Length | |
> > +---------------+---------------+ +
> > ~ Authentication Domain Name ~
> > +---------------------------------------------------------------+
> > ~ Digest Hash Alg Identifiers ~
> > +---------------------------------------------------------------+
> > ~ Certificate Digest ~
> > +-------------------------------+-------------------------------+
> >
> > Figures 2 and 3 just show how this attribute
> > looks when Num Hash Algs, AND Length and Length
> > have specific values, which make sense for the request and response.
>
> I do think that is very confusing. I would prefer to see the field
> described once to make it more clear there is only one format.
Do you think the figure above should be added to the document
with fields description?
> But even so, wearing my implementer hat, this is not a friendly format
> to parse as various fields depend on other fields two levels deep.
> That is, I have to read in the data into a struct that has:
>
> struct ENC_DNS4 {
> uint32_t attr_type;
> uint32_t length;
> int numhash;
> int adnlen;
> char *blob
> };
>
> and then kludge around depending on numhash and adnlen. And if there
> are spare bytes left, I guess that must map to a cert digest then.
Sorry, but I don't buy this argument. IKEv2 has such attributes from
the very beginning. For example, to correctly parse SUPPORTED_ATTRIBUTES
you have to read the data into the similar struct:
struct SUPPORTED_ATTRIBUTES {
uint32_t attr_type;
uint32_t length;
char *blob;
}
and then use length to determine the number of attributes (and the correctness
of the SUPPORTED_ATTRIBUTES attribute itself). So conformant implementations
should have no problem with such things.
> compare that to say:
>
> 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 |
> +-+-----------------------------+---------------+---------------+
> | Num Hash Algs | Digest Hash Alg Identifiers ~
> +---------------+ ~
> ~ ~
> +---------------------------------------------------------------+
> ~ Certificate Digest ~
> +---------------------------------------------------------------+
> ~ ADN ~
> +---------------------------------------------------------------+
>
> This way we also do not need "ADN Length" anymore. It can state if
> "Num Hash Agls" is not 1, Certificate Digest is omited.
First, you still have to parse this attribute differently
depending on the "Num Hash Agls" value. But worse (wearing my implementation
hat),
this format is less friendly for parsing. The problem is that
with the current format the low level parsing routine is able
to correctly separate ADN, Hash Identifiers and Digest without any
knowledge of their internals and pass these separated pieces
of data to a higher level routine that actually knows what to do with them.
With your proposed format the low level routine must know
the length of the Digest field to correctly parse the data,
which depends on the Hash Identifier. For a low level routine this knowledge
is generally not available, so I would have to somehow pass this
information there.
> I'm still a little weirded out by how different request/response
> format is - it is supposed to be the same thing, but filled in, and
> the fact that the fields vary is kinda weird.
The format is actually the same, but depending on the request/response
some fields may be omitted. Don't you find it is weird that
in IKEv2 the whole data is omitted in the request if the length of the
attribute is 0?
I believe we follow the similar logic :-)
Regards,
Valery.
> Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
