Re: [babel] Work to do (IHU TLV AE 0)

[Toke Høiland-Jørgensen <[e-mail]>]

Denis Ovsienko <[e-mail]> writes:

> ---- On Mon, 26 Mar 2018 21:25:01 +0100 Juliusz Chroboczek  wrote ---- 
>>> There is one more important thing to check before setting 6126bis in 
>>> stone. The current revision of 6126bis says an IHU TLV may omit Address 
>>> (AE = 0). The current revision of 7298bis needs Address meaningfully set 
>>> so that the receiving node can pick the TS/PC sub-TLV from the IHU TLV 
>>> and translate that to the age threshold in units of seconds. 
>> 
>>I need to think that over. 
>> 
>>> 1. 6126bis and 7298bis coordinate to have IHU AE 1 or 3 when 7298bis is 
>>> enabled 
>>> 2. 6126bis simply mandates Address in IHU (AE = 1 or 3) 
>> 
>>I'm fine with either of these. 
>
> Alright. Then 2 would be straightforward if the problem does not require 3 (see below).
>
>>> 3. 7298bis does destination address protection too for all packets (7298 
>>> did only source, as 6126 is multicast-only). 
>> 
>>Please clarify. 6126 already allows unicast operation, except for Hello 
>>TLVs (Section 3.1 of RFC 6126). 
>
> I am sorry, a more correct wording would be: the destination address
> was not meaningful in 6126 (I remember discussing this with you at
> some point). Do the new unicast provisions in 6126bis make the
> destination address meaningful? I.e. can a man in the middle change it
> and cause any damage beyond ignored Babel packets?

The packet destination address is not checked on the receiver,
regardless of whether the packet was sent over unicast or multicast. At
least, that's the case with Bird and (I think) babeld.

-Toke