Subject: [babel] Some more questions about HMAC

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 29 Jun 2018 02:01:24 +0200

1. Is it legal for multiple PC/INDEX TLVs to appear in a single packet?

On the one hand, allowing it does not seem to cause any security issues.
On the other hand, it doesn't seem to give any extra flexibility.

We currently ignore all PC/INDEX except the last one.  It's a simple
change to drop any packet with multiple PC/INDEX TLVs.

Suggestion: the sender MUST NOT but the receiver need not detect that case.

2. Can the PC/INDEX TLVs appear before any CHALLENGE_RESPONSE?

If they can, you need to parse the whole packet before taking a decision.
If we say that CHALLENGE_RESPONSE MUST appear before any PC/INDEX, then
you can send the challenge and drop the packet as soon as you see an
invalid PC/INDEX.

We're currently taking the decision at the end of the packet (and
incidentally sending the TLVs in the wrong order).

3. How do we encode CHALLENGE_REQUEST/CHALLENGE_RESPONSE?

We're currently using a whole new TLV pair, which simplifies the first
parsing pass (the one that happens after we've validated HMAC but before
we've decided whether to accept the packet).  Other possibilities: use
sub-TLVs of ACK_REQUEST and ACK_REPLY.

C and W want to keep the separate TLV, which makes sense to me, as this
keeps the TLVs of the two passes separate (you either handle a TLV in the
first pass and ignore it in the main pass, or the opposite).

---

From: David Schinazi <[email-masked]>
Date: Thu, 28 Jun 2018 17:15:04 -0700

> On Jun 28, 2018, at 17:01, Juliusz Chroboczek <[email-masked]> wrote:
> 

Sounds good to me. We could add "receiver MUST silently ignore any
PC/INDEX after the first one to allow future extensibility? It doesn't get us
anything today but it also doesn't complicate things much - I could go either way.

> incidentally sending the TLVs in the wrong order).

As far as I know today Babel has no requirement of ordering of TLVs
(apart from updating the parser state for compression).
I'd prefer leaving the ordering open to implementors.
Technically an implementation can decide to not reparse a packet that
had a valid challenge response, it'll be like a packet loss.

> first pass and ignore it in the main pass, or the opposite).

I prefer using brand new TLVs because they are the only ones that are allowed to
be parsed when the PC/INDEX is wrong or unknown. If we want to save a
slot in the registry we could have one CHALLENGE TLV that has a bit in it
to indicate request or response.

David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 29 Jun 2018 02:56:43 +0200

> had a valid challenge response, it'll be like a packet loss.

No, you cannot do that -- you need to handle the PC/INDEX in order to
reset your per-peer state.

And you don't need to reparse -- you just save the PC/INDEX when you
encounter it, and delay acting upon it until you've reached the end of the
packet.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 28 Jun 2018 18:15:21 -0700

Agree. I was thinking about reparsing the packet for all the other TLVs,
but you're right about the PC/INDEX. But since you need to have
parsed both PC/INDEX and CHALLENGE_RESPONSE to update
the neighbor's index and PC, I don't think forcing ordering gets us much.

David

> On Jun 28, 2018, at 17:56, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel