Re: [Anima] GRASP M_FLOOD captured from Reggie.py -- could it be wrong?

Carsten Bormann <cabo@tzi.org> Sun, 13 December 2020 20:59 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814643A0982 for <anima@ietfa.amsl.com>; Sun, 13 Dec 2020 12:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.005
X-Spam-Level:
X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SCqCzuAAYcT6 for <anima@ietfa.amsl.com>; Sun, 13 Dec 2020 12:59:02 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C153A0980 for <anima@ietf.org>; Sun, 13 Dec 2020 12:59:01 -0800 (PST)
Received: from [192.168.217.124] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CvH1v0yn9zyX4; Sun, 13 Dec 2020 21:58:59 +0100 (CET)
Content-Type: multipart/alternative; boundary=Apple-Mail-632CB2FF-7988-4016-82B3-A89CD3011D30
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20a41277-59b8-dcae-c1e6-ebe440111840@gmail.com>
Date: Sun, 13 Dec 2020 21:58:58 +0100
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org
Message-Id: <A2C1203C-4042-405E-B975-8F7D9F281194@tzi.org>
References: <20a41277-59b8-dcae-c1e6-ebe440111840@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: iPhone Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/6u72UpudsnMi2s2v-Kv1R3tIr4M>
Subject: Re: [Anima] GRASP M_FLOOD captured from Reggie.py -- could it be wrong?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Dec 2020 20:59:05 -0000

I’m looking at this from my phone, but I think Michael is right. 

   flood-message = [M_FLOOD, session-id, initiator, ttl,
                     +[objective, (locator-option / [])]]

Says each pair of objective and locator-option/empty should be packed into its own array. 

It could have said

   flood-message = [M_FLOOD, session-id, initiator, ttl,
                     +(objective, (locator-option / []))]

In which case the array elements would be alternating between objective and locator-option/empty. 

But it doesn’t. 

Note that these two-element arrays are the 5th 6th etc elements of the outer array; there is no one-element array. 

Sent from mobile, sorry for terse

> On 13. Dec 2020, at 21:32, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Sorry I'm still on vacation and this takes a bit more care to check than
> I can do until I'm home. You could well be right, it's a long time since 
> I checked that code against the draft so I could have got it wrong or never
> updated it. I think we went round the loop on the CDDL more than once.
> 
> We're flying back to Auckland tomorrow, I should be able to check
> this on Wed NZ time.
> 
> Regards
>   Brian
> 
>> On 14-Dec-20 08:43, Michael Richardson wrote:
>> 
>> I captured this from Reggie.py (diag output below) a few days ago:
>> 
>> [9, 3591865773, h'2607F0B0000F000200000000000005F7', 120000,
>>    [
>>      ["AN_join_registrar", 5, 1, "EST-TLS"],
>>      [103, h'2607F0B0000F000200000000000005F7', 6, 80]
>>    ]
>> ]
>> 
>> (formatting is mine)
>> 
>> I'm confused by this.
>>    Objective-Name: "AN_join_registrar",
>>    objective-flags: 5,
>>    loop-count: 1,
>>    objective-value: "EST-TLS"
>> 
>> and then the locator-option starts with 103...?
>> 
>> I guess I'm still confused by why this is:
>>  [ [objective1],[locator2-option], [objective2],[locator2-option],...]
>> 
>> and not:
>>  [ [objective1, locator2-option], [objective2, locator2-option],...]
>> 
>> or maybe:
>>  [ [[objective1], [locator2-option]], [[objective2], [locator2-option]],...]
>> 
>> 
>> given that it says:
>> flood-message = [M_FLOOD, session-id, initiator, ttl,
>>                +[objective, (locator-option / [])]]
>> 
>> so I reviewed RFC8610 so under +[], which is section:
>> section 3.2 (Ocurrence). + => "one or more",
>> section 3.4 (Array).
>> 
>> I conclude that I think that Reggie.py is wrong.
>> I think that this is the same mistake that we made in BRSKI.
>> 
>> I am using the code at:
>>    commit cf716f69e74041081c3eb93131deefe43baea8bb (HEAD -> master, origin/master, origin/HEAD)
>>    Author: Brian E Carpenter <brian.e.carpenter@gmail.com>
>>    Date:   Tue Nov 17 12:28:14 2020 +1300
>> 
>>    Dummy AN-overview for redirect
>> 
>> 
>> The entire packet is captured as test data at:
>>  https://github.com/AnimaGUS-minerva/connect/blob/main/src/graspsamples.rs
>> 
>> what I saw:
>> 85                                      # array(5)
>>   09                                   # unsigned(9)
>>   1A D61785AD                          # unsigned(3591865773)
>>   50                                   # bytes(16)
>>      2607F0B0000F000200000000000005F7  # "&\a\xF0\xB0\x00\x0F\x00\x02\x00\x00\x00\x00\x00\x00\x05\xF7"
>>   1A 0001D4C0                          # unsigned(120000)
>>   82                                   # array(2)
>>      84                                # array(4)
>>         71                             # text(17)
>>            414E5F6A6F696E5F726567697374726172 # "AN_join_registrar"
>>         05                             # unsigned(5)
>>         01                             # unsigned(1)
>>         67                             # text(7)
>>            4553542D544C53              # "EST-TLS"
>>      84                                # array(4)
>>         18 67                          # unsigned(103)
>>         50                             # bytes(16)
>>            2607F0B0000F000200000000000005F7 # "&\a\xF0\xB0\x00\x0F\x00\x02\x00\x00\x00\x00\x00\x00\x05\xF7"
>>         06                             # unsigned(6)
>>         18 50                          # unsigned(80)
>> 
>> 
>> What I think I should have seen:
>> 
>> [9, 3591865773, h'2607F0B0000F000200000000000005F7', 120000, [[["AN_join_registrar", 5, 1, "EST-TLS"], [103, h'2607F0B0000F000200000000000005F7', 6, 80]]]]
>> 
>> 85                                      # array(5)
>>   09                                   # unsigned(9)
>>   1A D61785AD                          # unsigned(3591865773)
>>   50                                   # bytes(16)
>>      2607F0B0000F000200000000000005F7  # "&\a\xF0\xB0\x00\x0F\x00\x02\x00\x00\x00\x00\x00\x00\x05\xF7"
>>   1A 0001D4C0                          # unsigned(120000)
>>   81                                   # array(1)
>>      82                                # array(2)
>>         84                             # array(4)
>>            71                          # text(17)
>>               414E5F6A6F696E5F726567697374726172 # "AN_join_registrar"
>>            05                          # unsigned(5)
>>            01                          # unsigned(1)
>>            67                          # text(7)
>>               4553542D544C53           # "EST-TLS"
>>         84                             # array(4)
>>            18 67                       # unsigned(103)
>>            50                          # bytes(16)
>>               2607F0B0000F000200000000000005F7 # "&\a\xF0\xB0\x00\x0F\x00\x02\x00\x00\x00\x00\x00\x00\x05\xF7"
>>            06                          # unsigned(6)
>>            18 50                       # unsigned(80)
>> 
>> 
>> 
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>>           Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima