Subject: Re: [babel] Comments about rfc7298bis

From: Denis Ovsienko <[email-masked]>
Date: Wed, 04 Apr 2018 01:58:28 +0100

---- On Fri, 30 Mar 2018 20:37:32 +0100 Juliusz Chroboczek<[email-masked]> wrote ---- 
 > Dear all, 
 >  
 > The following is a summary of discussions that I've had with David 
 > Schinazi, Clara Dô, and Weronika Kołodziejak.  I'm no longer sure who made 
 > which comment, so I'll just summarise the discussion. 
 >  
 > 1. We still don't have a clear and concise description of the attack 
 > against 7298.  That would be helpful, especially if we are meant to work 
 > together. 

Let me remind, the most illustrated description so far is in the IETF 97 working group meeting materials.

 > 2. The procedure that consists in putting the source IP into the HMAC 
 > field before hashing is bizarre.  A more straightforward solution would be 
 > to prepend the source IP to the whole Babel packet, similarly to the TCP 
 > pseudo-header.  Note that this does not break the ability to have multiple 
 > HMACs. 

Yes, fine.

 > 3. I think it is necessary to protect the destination IP in addition to 
 > the source IP.  This prevents some pretty obvious attacks against IHU, Ack 
 > and Unicast Hello TLVs, and might in the future prevent attacks against 
 > extensions. 

Yes, fine.

 > 4. For clarity, the TC/PC sub-TLV should be renamed to TC/PC Echo. 

Clarity is important. Could also be "My TS/PC" for the TLV and "Your TS/PC" for the sub-TLV if that reads better.

 > 5. It's not clear to me what happens when a diskless clock-less node 
 > reboots and loses its sequence number.  I'm sure it's described somewhere 
 > in the document, please point me at the right place. 

Section 5.1 describes it, you are referring to item (a), which is the worst implementation case. The 2nd paragraph of Section 3.7 clarifies the consequences.

(All references for the -00 revision of the 7298bis I-D.)

 > 6. I'm not sure that the IHU TLV is the right place to put the TC/PC 
 > echo -- what about putting it in a sub-TLV of TC/PC itself? 

IHU is the right place as it means: "I have heard you, X, and _your_ last valid TS/PC from my point of view was Y". Y is specific to X, and a Babel packet can contain IHUs for more than one X.

 > 7. What's the fragmentation procedure when the whole set of TC/PC echos 
 > exceeds the size of a packet? 

As far as I understand it, the behaviour should be the same as it is without the security mechanism, except the additional margin discussed in Section 6.2 (which now has to upgrade the formula to account for the new sub-TLV). Does this look right?

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 04 Apr 2018 22:20:53 +0200

> working group meeting materials.

Denis, we'd really need something concise.  Do you think you could write
it up in one page (60 lines)?

> As far as I understand it, the behaviour should be the same as it is
> without the security mechanism, except the additional margin discussed
> in Section 6.2 (which now has to upgrade the formula to account for the
> new sub-TLV). Does this look right?

What happens if the number of neighbours is so large that the complete set
of TC/PC echos does not fit in a full-size packet?

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 05 Apr 2018 14:37:19 +0100

---- On Wed, 04 Apr 2018 21:20:53 +0100 Juliusz Chroboczek  wrote ---- 
>it up in one page (60 lines)? 

The matter is, you have already seen a few versions of the problem statement, of assorted brevity. That did not work and I would like to understand why. Which ones have you read and tried to understand? What specifically did you understand? What specifically you did not understand and why?

>of TC/PC echos does not fit in a full-size packet? 

The same thing happens as if there is no authentication at all and the number of neighbours is so large that the complete set of IHU TLVs does not fit. The existence and handling of the threshold are not specific to 7298bis, which only amends its exact value. And the term is "TS/PC".

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 Apr 2018 17:30:55 +0200

> The same thing happens as if there is no authentication at all and the
> number of neighbours is so large that the complete set of IHU TLVs does
> not fit.

I'm not sure I understand.  The set of IHUs can be easily split across
multiple packets -- the absence of an IHU does not imply that the
neighbour has been dropped.  If I understand correctly (correct me if I'm
wrong), your draft requires sneding the full set of IHU+TC/PC echo in
a single packet.  If I'm right, then a mechanism is needed to deal with
overflow, no?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 05 Apr 2018 08:38:18 -0700

> On Apr 5, 2018, at 06:37, Denis Ovsienko <[email-masked]> wrote:
> 

Hi Denis,

I was trying to refresh my memory on this attack and was not able to find a concise description.
I have read everything I could find on the topic and I have understood everything I read,
but having a short summary would be very helpful to the community.
Maybe that already exists and I have just failed to find it, in which case could you point me to it please?

Thanks,
David