From: Fan Du <fan.du@windriver.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 3/3] xfrm: Restrict "level use" for IPComp configuration
Date: Tue, 10 Dec 2013 10:39:51 +0800 [thread overview]
Message-ID: <52A67EF7.3070402@windriver.com> (raw)
In-Reply-To: <20131209103856.GL31491@secunet.com>
On 2013年12月09日 18:38, Steffen Klassert wrote:
> On Thu, Nov 28, 2013 at 10:52:41AM +0800, Fan Du wrote:
>>
>> diff --git a/net/key/af_key.c b/net/key/af_key.c
>> index 911ef03..d37a2c1 100644
>> --- a/net/key/af_key.c
>> +++ b/net/key/af_key.c
>> @@ -1895,6 +1895,12 @@ parse_ipsecrequest(struct xfrm_policy *xp, struct sadb_x_ipsecrequest *rq)
>> return -ENOBUFS;
>> }
>>
>> + /* IPComp requires level use option to accomodate both compressed
>> + * and non-compressed packet when checking policy.
>> + */
>> + if ((t->id.proto == IPPROTO_COMP)&& (t->optional == 0))
>> + return -EINVAL;
>> +
>> /* addresses present only in tunnel mode */
>> if (t->mode == XFRM_MODE_TUNNEL) {
>> u8 *sa = (u8 *) (rq + 1);
>> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
>> index 52efe71..d7216ea 100644
>> --- a/net/xfrm/xfrm_user.c
>> +++ b/net/xfrm/xfrm_user.c
>> @@ -1293,6 +1293,10 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
>> default:
>> return -EINVAL;
>> }
>> +
>> + /* Refuse any IPComp conf that missing "level use" */
>> + if ((ut[i].id.proto == IPPROTO_COMP)&& (ut[i].optional == 0))
>> + return -EINVAL;
>> }
>
> I think this will make a lot of people unhappy. It was never required
> to set 'optional' for ipcomp, and I'd bet that most users don't set
> it for ipcomp. I understand the problem, but we can't fix it like that.
Instead of making this check, what about wire 'optional' to 1? it doesn't
breaking existing script.
Do you have any other way to cure this problem other than 'optional'.
--
浮沉随浪只记今朝笑
--fan
next prev parent reply other threads:[~2013-12-10 2:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 2:52 [PATCH net-next 0/3] IPComp fixes Fan Du
2013-11-28 2:52 ` [PATCH net-next 1/3] xfrm: check user specified spi for IPComp Fan Du
2013-12-06 11:44 ` Steffen Klassert
2013-11-28 2:52 ` [PATCH net-next 2/3] xfrm: clamp down spi range for IPComp when allocating spi Fan Du
2013-12-06 11:42 ` Steffen Klassert
2013-12-09 6:27 ` Fan Du
2013-12-09 8:57 ` Steffen Klassert
2013-12-09 9:13 ` Fan Du
2013-12-09 9:51 ` Steffen Klassert
2013-12-09 9:58 ` Fan Du
2013-11-28 2:52 ` [PATCH net-next 3/3] xfrm: Restrict "level use" for IPComp configuration Fan Du
2013-12-09 10:38 ` Steffen Klassert
2013-12-10 2:39 ` Fan Du [this message]
2013-12-10 13:11 ` Steffen Klassert
2013-12-13 9:16 ` Fan Du
2013-12-06 9:58 ` [PATCH net-next 0/3] IPComp fixes Fan Du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A67EF7.3070402@windriver.com \
--to=fan.du@windriver.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.