Re: [manet] RFC7181 (OLSRv2) trouble with ANSN and router restart

Christopher Dearlove <christopher.dearlove@gmail.com> Fri, 23 July 2021 14:04 UTC

Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D813A0A73 for <manet@ietfa.amsl.com>; Fri, 23 Jul 2021 07:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9UBGuoPHcst for <manet@ietfa.amsl.com>; Fri, 23 Jul 2021 07:04:48 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713BE3A09D7 for <manet@ietf.org>; Fri, 23 Jul 2021 07:04:46 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id h24-20020a1ccc180000b029022e0571d1a0so1670055wmb.5 for <manet@ietf.org>; Fri, 23 Jul 2021 07:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q3hoCiazDMFhOgjZMExdeKPBcewSyW6ZWS3+zoMgFww=; b=h+OOj/UHMeoYQcCeLgo3rrTiGfFOpgjMpCRlE7g/rmysTsqnNSWm8yBr+08IkNiHlv oBwd9K8cny8dYEoquPdZmKxTO4W2YpJACe8STMhIx+79BLp0qSAzo6RDZCUi8fcMJJFD uQB1emxEYlspOuW2UgiD4ctQx+ejU6e49Io0KSRpdYwOko3rSds0lx8jGVOr4fqd+mYp iJk9PP3mYFrsTNlUMJIGj0LLgCSI6oxOUHQ1beCnBmkzx3aHSJUMoIgeV6NO4OOjafSx K/px7RyfYaeYaZnjt531urPJx9xiexSDayPRhluOkDMBAQONiFn3YMGLJp5ZerrhSmhM sFIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q3hoCiazDMFhOgjZMExdeKPBcewSyW6ZWS3+zoMgFww=; b=bbDcMbzsFJkVEQ9P1U/mZzSBU6s6qvNg9xs3fibIQRh01WmzfhsPKE64dfF/9Zvay9 Qj1xB4F1dX1ny8m4FybJ59J6vBwqvNdYwfgkieuELEZYIWkNaUooOt98iioZqEeL+jT0 Ljz4od7e8HFa/j+/tnsoGFKqx1a6Th5gs/+7O2pFHxOG26JrYgdfcd+sXL83ED8hYszE yiSel/WI7ANpl/0QIh+pAcWyfKPuGoQ0wq+X2yKewcoBFwreewARi2uOyOYl1RPrHr8c EJdw9aFx/yWXhOd5i8Tv6OiXVWq3PkN+Egq1Mq10YiihQga8pk55x/1be3u8L7A5VYqN X02w==
X-Gm-Message-State: AOAM531K/kYowoBQ/QG2DH3IQhoiqeqeQjPV6t06EKHKaQ5Zt5LpTdwh Fo7f997D0yZ2xJHwWZaYnlr/dLQDNPI=
X-Google-Smtp-Source: ABdhPJyotB5I7SE6Z1tIQDD+VLz4xcqCtLOJFa58uo46xk+klykklEJ3JL/OkIKy/G20K1BlPRlirw==
X-Received: by 2002:a1c:4b0a:: with SMTP id y10mr4696312wma.178.1627049083597; Fri, 23 Jul 2021 07:04:43 -0700 (PDT)
Received: from [172.20.10.4] (82-132-233-39.dab.02.net. [82.132.233.39]) by smtp.gmail.com with ESMTPSA id o5sm5018032wms.43.2021.07.23.07.04.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jul 2021 07:04:42 -0700 (PDT)
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Message-Id: <0CAB7ADE-16FB-4AE9-8497-72956E03F8F8@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB68A1F9-FB16-4E25-A322-2004E718A7E6"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Fri, 23 Jul 2021 15:04:41 +0100
In-Reply-To: <1627020703962.66100@fkie.fraunhofer.de>
To: MANET IETF <manet@ietf.org>
References: <1626937943164.99401@fkie.fraunhofer.de> <CA+-pDCdGjVPyVxnfMt2trN_Rk5J_btZrt2teFg43JSEbo0sn6g@mail.gmail.com> <1627020703962.66100@fkie.fraunhofer.de>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/XACM7X36kTRTqepkb2JCSurj_L0>
Subject: Re: [manet] RFC7181 (OLSRv2) trouble with ANSN and router restart
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2021 14:05:02 -0000

I didn’t addresss this.

> On 23 Jul 2021, at 07:11, Rogge, Henning <henning.rogge@fkie.fraunhofer.de> wrote:
> 
> The problem is easy to solve on the "sender" side, but if we manage I would like to solve it on the receiver side (of TCs).

First, I don’t think you have the receiver side issue you note. The information will eventually timeout unless the sender sends incomplete messages with valid MSN and latest ANSN. But that’s something it could do anyway.

There are heuristics you might add to say “ignore this message as it fails a smell test”. You can’t stop a router doing that, nor should you. There are various heuristics you could try. Some relevant to this situation, others not. One such is that if you see a message where MSN and ANSN show opposite behaviour, that’s a sign that router is misbehaving. If you interpret misbehaving as “probably reset, I should wipe all its data” that’s drastic but possible. But doing so on the basis of one message is a bit much. And I don’t think you’ll ever get a set of rules applicable to all situations. Which is why I used the term heuristics.

Either in an informational RFC on router reset behaviour, or in a non-normative annex to a standards track RFC, you could include advice on behaviour to look out for that suggests a misbehaving/reset router and that you MAY (no stronger) discard messages or even wipe the database if you see that, probably more than once.

In short, I don’t think this is a soluble, here are rules that always work, problem. But if you find a real problem in a real network you could include code that makes a tradeoff of handling that case while possibly making other cases behave less well. (For example the multiple MSNs/ANSNs I suggest in my last email might trigger some heuristics.) Information might help a network operator. If you are supplying an OLSRv2 implementation and have a heuristic you think is often useful, you could include it as an option. But it would be very easy to think up heuristics that in reality aren’t much use.