Subject: Re: [babel] Comments about rfc7298bis

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 02 May 2018 19:54:03 +0200

>>> 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? 

>> 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?

Denis,

Did I miss an e-mail?  I don't see an answer to the above.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 02 May 2018 23:31:16 +0100

---- On Wed, 02 May 2018 18:54:03 +0100 Juliusz Chroboczek  wrote ---- 
>Did I miss an e-mail? I don't see an answer to the above. 

1. Terminology: the data unit is called a TS/PC number, this has been the term since 2012.
2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU TLV, the additional requirement for IHU TLVs grouping or placement you describe does not exist.

If you go back a couple messages up this thread, hopefully you will see we had discussed both points before.

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 May 2018 00:37:32 +0200

> 2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU
> TLV, the additional requirement for IHU TLVs grouping or placement you
> describe does not exist.

I'm sorry if I'm slow, Denis, please explain.

Supposef that a node has 1000 neighbours on a single interface.  In the
original protocol, it can send a single Hello and a single Update followed
with 1000 IHUs split across 50 packets.

What's the encoding in 7298bis if all 1000 neighbours require auth?

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 03 May 2018 11:32:29 +0100

---- On Wed, 02 May 2018 23:37:32 +0100 Juliusz Chroboczek  wrote ---- 
>What's the encoding in 7298bis if all 1000 neighbours require auth? 

Per each packet: one TS/PC TLV and at least one HMAC TLV (as 7298 explains it)
Per each IHU TLV: one TS/PC sub-TLV (as 7298-bis explains it)

If you read the full I-D and confirm you have done that, I will appreciate that.

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 May 2018 23:55:37 +0200

> If you read the full I-D and confirm you have done that, I will

I have read the I-D, although I skipped over the parts that merely restate
what is in 6126.  I still don't understand how you deal with more TC/PC
sub-TLVs than can fit in a packet.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 04 May 2018 15:06:21 +0100

---- On Thu, 03 May 2018 22:55:37 +0100 Juliusz Chroboczek  wrote ---- 
>sub-TLVs than can fit in a packet. 

Juliusz, the data item you are referring to is called "TS/PC", and this term has been around since 2012. I have already mentioned this before. Do you understand this leaves an impression of a conversation that is not fully two-way?

Regarding your recent concerns about 7298-bis data items not fitting into output packets, the task of fitting protocol data items into a packet buffer is neither new nor really difficult. This is one of the minor tasks you had done yourself when you authored RFC 6126 and its implementation. Specifically, you managed to place IHU TLVs, which consume either 8 octets (AE 0) or 12 octets (AE 1) or 16 octets (AE 3) into a sending buffer without overflowing it. So far so good for RFC 6126 (same for 6126-bis).

RFC 7298 discusses the additional buffer margin for the [per-packet] TS/PC TLV and HMAC TLV(s) in sufficient detail. Besides the margin, the buffer management remains exactly the same (and same for 7298-bis).

In 7298-bis the [IHU TLV-specific] TS/PC sub-TLV consumes 8 octets, so an IHU TLV now consumes either 16 octets (AE 0), or 20 octets (AE 1) or 24 octets (AE 3). The buffer management task again remains exactly the same, it is just one of its input data items that now comes in a different size.

This way, I am sorry to explain that from my point of view it reads as if you are claiming you do not understand how sending buffer management works in RFC 6126. If this is the case and your assumption is this is a fault of 7298-bis or myself, it is likely wrong.

But the main point is, sending buffer management is not the only or the biggest concern here. The main goal of 7298-bis is to add a true bi-directional exchange proof to 7298. This is exactly the approach you suggested if you remember. I believe the proposed solution achieves that goal, can you prove me wrong in that? If the working group intends to deliver proper quality results, this is one of the unfinished work items on that we could (and should) spend our energy.

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 07 May 2018 16:24:45 +0200

> Regarding your recent concerns about 7298-bis data items not fitting
> into output packets, the task of fitting protocol data items into
> a packet buffer is neither new nor really difficult.

I think got it, sorry for being so slow.  Contrary to what I believed,
7298bis only requires TS/PC sub-TLVs to be included in existing IHUs.  It
does not require a full set of TS/PC sub-TLVs to be included in every
packet.  See Section 5.4 point 4 -- it only requires rejecting packets if
there's no sub-TLV in a matching IHU.  On the other hand, if a packet does
not include a matching IHU, then it is accepted as soon as the TS/PC TLV
(not sub-TLV) is good.

Is that right, Denis?

If so, then I'd like to understand why this is safe.  Intuitively, I'd say
that by allowing packets without a matching TS/PC sub-TLV, replay attacks
might still be possible.  Now, the MUST in Section 3.4.3 of 6126bis
should mitigate most such attacks, but I'm still a little worried.

Denis, can you please point me where you explain why accepting packets
with no matching TS/PC is safe?

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 07 May 2018 23:36:47 +0100

---- On Mon, 07 May 2018 15:24:45 +0100 Juliusz Chroboczek  wrote ---- 
>does not require a full set of TS/PC sub-TLVs to be included in every 

You get this part right. IHUs appear in outgoing packets anyway. On an interface configured for authentication all IHUs start to have a TS/PC sub-TLV because an IHU is a reaction to a Hello, and only authentic Hellos make it in, thus the ANM table has a received TS/PC number to send back in every IHU.

>there's no sub-TLV in a matching IHU. On the other hand, if a packet does 

Not quite. Section 5.4 item 4 means: if there are any IHU TLVs that are going to be actioned by the main protocol instance and do not quote a *fresh* *enough* TS/PC number of the incoming interface, discard the packet.

>not include a matching IHU, then it is accepted as soon as the TS/PC TLV 

Correct.

>Is that right, Denis? 

Not exactly there yet, but I am glad to confirm this is much closer. Thank you for studying the details, Juliusz.

>with no matching TS/PC is safe? 

Let me try to answer this as far as I understand the question. If that is not what you mean, please ask again.

The new guard specifically triggers on stale (i.e. not proven fresh) IHUs and lets the timers do eventual handling of any related protocol structures. This is not completely and immediately safe, but it looks good enough. Specifically, it is still possible to intercept packets sent by a speaker, wait until it goes off the air and replay the packets soon enough for them to be accepted and processed normally (no more than once each packet). But the key difference is, in 7298-bis the time window for this spoofing is now limited and under control with TSPCMaxRTT. This is very close to MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF from RFC 7183, but without the need for all speakers to have synchronized clocks.

This 2-way TS/PC check is better than 1-way but not as good as 3-way. However, my understanding is, for multicast protocol exchange 2-way is as far as it can scale (i.e. hundreds of neighbours on a single segment would have a hard time trying to maintain O(n**2) 3-way unicast exchanges).

Do you see any ways for this to go wrong?

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 10 May 2018 01:41:42 +0200

Thanks for the explanation, that helps.  I'm going to read 7183 when
I have time.

> Do you see any ways for this to go wrong?

Probably not, but I'm not quite comfortable yet.  Please be patient,
I probably get the details wrong in the following example.

Suppose that Chloe has captured a large number of packets previously sent
by alice.  Alice left the network, and state relevant to Alice has expired
at Bob.

Now Alice joins the network, and sends

  A: Hello, TS/PC = 42

Now Chloe sends a replayed packet:

  C (spoofing A): Update (::/0, 0), TS/PC = 43

Bob sees this as a route announcement from Alice, so he inserts a default
route in its route table.  Since Alice hasn't sent an IHU yet, the link
cost is infinite, so the route doesn't get installed.

Bob sends a Hello:

  B: Hello, TS/PC = 57

and Alice sends an IHU with the correct TS/PC echo:

  A: IHU(TS/PC=57), TS/PC = 43

the IHU gets ignored, due to the obsolete TS/PC (43), but then Alice
resends the IHU:

  A: IHU(TS/PC=57), TS/PC = 44

This packet is correct, so BOB sets its txcost to something finite, and
bang, the route suddenly is selectable, and Bob installs the route that
was spoofed by Chloe.

What am I missing?

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 11 May 2018 08:33:45 +0100

---- On Thu, 10 May 2018 00:41:42 +0100 Juliusz Chroboczek  wrote ---- 
>by alice. Alice left the network, and state relevant to Alice has expired 

(Implied: Alice reuses TS/PC numbers, Bob uses a short enough ANMTimeout.)

>bang, the route suddenly is selectable, and Bob installs the route that 

It looks like this attack would work they way you describe it. To spell the nuances, what 7298-bis would do on top of 7298 is detect packets with incoming IHUs that are not a fresh enough response to the local TS/PC number. Without IHUs it is only the TS/PC+HMAC check, and with reused local TS/PC number the bi-directional exchange is not actually proven. So that's a good point.

Moreover, if Bob reuses his outgoing TS/PC numbers too, it will take to power-cycle A and B at the same time, then record the exchange, and then C will be able to replay a complete (Hello+IHU+Update) protocol exchange to any of those two each time they reboot.

As far as I see after thinking about this new input for a day, the principal way to fix this would be to mandate that TS/PC number must be increasing across the lifetime of a speaker (7298-bis Section 5.1 item (a) goes away, item (c) becomes the recommended default, item (b) refines the requirements for the timestamp source).

A secondary measure would be to have a large ANMTimeout by default (since item (a) no longer applies) and to save ANM table across reboots, this way old replayed Update TLVs will be less likely to produce inactive routes in the absence of new IHU TLVs.

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 13 May 2018 15:56:19 +0200

> As far as I see after thinking about this new input for a day, the
> principal way to fix this would be to mandate that TS/PC number must be
> increasing across the lifetime of a speaker (7298-bis Section 5.1 item
> (a) goes away, item (c) becomes the recommended default, item
> (b) refines the requirements for the timestamp source).

A: Hello, Update(X), TS/PC=42

The packet is captured by C.  At this point, A and B simultaneously reboot
and loose their ANM state.

C spoofing A: Hello, Update(X), TS/PC=42

Since B has lost its ANM state, it accepts this packet as authentic, and
learns a spoofed route to X through A.  At which point, an (authentic)
Hello/IHU exchange happens:

B: Hello, TS/PC=57
A: Hello, IHU(B, TS/PC=57), TS/PC=43

B's cost to A becomes finite, and the replayed route is installed.

Note that I'm not sure that this is a serious attack -- C has managed to
get B to route through A, it has not managed to redirect traffic through
itself.

> A secondary measure would be to have a large ANMTimeout by default
> (since item (a) no longer applies) and to save ANM table across reboots,

If we assume that the ANM table is persistent, then a lot of things become
much easier.  Another solution would be to assume that all nodes have
real-time clocks, and require that TS/PC carries a timestamp that's no
more than 20 seconds in the past.

However, I think a more general fix is possible -- the attack above is due
to B accepting a (spoofed) packet from A although it has no recent ANM
state for A.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Tue, 15 May 2018 00:25:26 +0100

---- On Sun, 13 May 2018 14:56:19 +0100 Juliusz Chroboczek  wrote ---- 
>get B to route through A, it has not managed to redirect traffic through 

Makes sense. The root causes are the same as before -- only the packets with relevant IHU TLVs can be tested for freshness and the main protocol instance actions Update before establishing a 2-way relation with a neighbour.

>much easier. Another solution would be to assume that all nodes have 

It seems to me it would make sense to recommend a persistent ANM table only if the implementer can do it safely, because trying to write to disk something that changes a few times a second may actually break things on a sudden power cycle. It should do its job even as a purely run-time structure.

>more than 20 seconds in the past. 

That's exactly what RFC 7183 defines, but the issue is synchronous offline clocks are either expensive, or unavailable for obvious practical reasons. 7298-bis is supposed to achieve the same effect with TSPCMaxRTT and only requires the clocks to be monotonic. The idea is roughly similar to the RTT Babel extension.

>to B accepting a (spoofed) packet from A although it has no recent ANM 

Not quite, but almost there. As far as I see it, the missing design point is to let only Hello TLVs in before seeing a packet with a proven fresh IHU TLV. This way the replayed packets _before_ the IHU will not affect the main protocol instance. As a consequence, any speaker will be able to discard its ANM table on shutdown safely.

Once again, for this to work the outgoing TS/PC number must be strictly increasing across the lifetime of a speaker, as explained before. This also gets rid of the replayed Updates _after_ authentic IHUs as the freshness proof will actually work. And this is doable in spite of sudden and frequent reboots.

Do you see what I mean?

-- 

    Denis Ovsienko