>Bug is in the RFC for not describing how both ends would magically
>synchronize, with a sequence protocol which is unidirectional, with no ACK
>packets or whatever going back.
>With no description, it means that RFC author(s) never considered one side of
>the tunnel could die and restart.
>Contact the author(s) to get his thoughts maybe ?
I agree with you, but I don't know how to contacted the author(s). If
any news about this, it will be grateful let me know.
>You will learn that not everything put in RFC or other piece of paper makes
>sense.
>And the implementation is exactly implementing the RFC bug, because, why not ?
>Now if you believe you can make this work, please send patches.
Now I needs to regain a sense of the RFC. Thank you.
I had thought about this issue, but GRE didn't encrypt the SEQ field, so
it's difficult to let the other end to update the local SEQ, When the peer has
restarted.
Because the attacker can hack the packet easily.
Maybe do not use the SEQ is a good choice.
In other words If the attacker reply the packets with sequence number bigger
than the normal packets, can the tunnel work well? haw-haw, is this condition
able to meet
a CVE.
On Thu, Nov 24, 2016 at 7:52 PM, Liyang Yu (于立洋1) <yuliya...@le.com> wrote:
> I accept that the issue is not a CVE candidate. But it's a bug isn't
> it
Bug is in the RFC for not describing how both ends would magically synchronize,
with a sequence protocol which is unidirectional, with no ACK packets or
whatever going back.
With no description, it means that RFC author(s) never considered one side of
the tunnel could die and restart.
Contact the author(s) to get his thoughts maybe ?
>
> Thank you for your suggestions, about the format of mail, and not next time.
>
> Everything has its meaning. If sequence number is a joke, why the guys put
> it into RFC , even implemented the feature.
You will learn that not everything put in RFC or other piece of paper makes
sense.
And the implementation is exactly implementing the RFC bug, because, why not ?
Now if you believe you can make this work, please send patches.
>
> And if you means that SMP ( Symmetric Multi Processing )?
Yes.
If you enable sequences, GRE performance is abysmal on SMP, because linux uses
an extra lock, instead of allowing multiple cpus using GRE tunnel at the same
time, and GSO/TSO are disabled .
>
>
>
> On Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) <yuliya...@le.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>> BTW:
>>
>> Which RFC suggests UINT_MAX as GRE sequence number? Can you show me?
>>
>>
>>
>>
>>
>>
>
>
> RFC 2890
>
> In any cases, this is absolutely not a security issue nor a CVE candidate.
> Please remove secur...@kernel.org from CC, no need to spam security guys,
> they have enough on their plate.
>
> Please send text messages, no HTML is allowed on netdev
>
> Nobody sane uses GRE sequence numbers, precisely because GRE has no
> documented way to synchronize the source and destination of the tunnel.
> Basically, if you use GRE sequence numbers, you must re-start other side of
> the tunnel if one side had to restart, or risk dropping up to 2^31 packets.
>
> Really, this is not something that can be solved by using 'a different
> initial sequence number'
>
> linux GRE sequence number support is a joke, it does not support SMP for a
> start.
>
>
>
>>
>>
>>
>> On Wed, Nov 23, 2016 at 11:45 PM, Liyang Yu (于立洋1) <yuliya...@le.com> wrote:
>>
>> > Yeah，I means that recreate the tunnel again, But I don’t think the
>>
>> > patch can fix the bug. It only can make the first packet received
>> > successed. And the follow packet will droped also.
>>
>> > In function __gre_xmit line 366
>>
>> > tunnel->o_seqno++;
>>
>> >
>>
>> > If you restart from UINT_MAX, the 'o_seqno' of second packet will return
>> > to 0 again.
>>
>>
>>
>> The first packet after restart: o_seqno == UINT_MAX, the other end:
>> i_seqno = 0 The second packet after restart: o_seqno == 0, the other
>> end: i_seqno = 1
>>
>>
>>
>> So traffic should be back to normal.
>>
>>
>>
>> UINT_MAX is also what RFC suggests.
