On Tue, Mar 19, 2019 at 10:35 PM Herbert Xu <herb...@gondor.apana.org.au> wrote:
>
> On Tue, Mar 19, 2019 at 01:42:53PM -0700, Cong Wang wrote:
> >
> > IIRC, it is Steffen who suggested to add IPPROTO_ROUTING/IPPROTO_DSTOPTS
> > back to commit 6a53b7593233. My xfrm knowledge is not enough to
> > figure out IPPROTO_ROUTING/IPPROTO_DSTOPTS.
>
> OK I dug into the history of xfrm_id_proto_match and this is
> definitely not right. The intention appears to be that
> IPSEC_PROTO_ANY should only match genuine IPsec protocols, i.e.,
> AH/ESP/COMP, while the special value of zero will match everything.
>
> So I think what we should do is get rid of the validation function
> that you added in 6a5t3b7593233, and then change those internal
> functions which were incorrectly using IPSEC_PROTO_ANY to using
> zero instead.
Good point. Replacing IPSEC_PROTO_ANY with zero should
work too, but on the other hand, id.proto is still never allowed to
be any other protocol than these 6 listed, no?
>
> Does anybody still use IPPROTO_ROUTING/IPPROTO_DSTOPTS? It's always
> a pain when people come and add features and then don't shoulder
> the burden of maintaining them.
Yeah, at least iproute2 does the same check:
static const struct typeent xfrmproto_types[] = {
{ "esp", IPPROTO_ESP }, { "ah", IPPROTO_AH }, { "comp", IPPROTO_COMP },
{ "route2", IPPROTO_ROUTING }, { "hao", IPPROTO_DSTOPTS },
{ "ipsec-any", IPSEC_PROTO_ANY },
{ NULL, -1 }
};
