Subject: [babel] Work to do

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 25 Mar 2018 02:30:26 +0100

Hello to all,

We've had a productive IETF, and therefore we've got a lot of work to do.
My understanding of the current situation.

1. draft-ietf-babel-rfc6126bis

This has been in last call, like, forever.  We're still waiting for IESG
review, let's please make it happen.  Donald, Russ, could you please poke
the responsible AD?

(I'm still not happy about Unicast Hellos, but I understand I'm in the
minority, so I'll shut up.  Er, no, I'll keep complaining loudly, but
I won't block the process.)

2. draft-ietf-babel-source-specific

This is ready for standardisation.  Joel Halpern has reviewed -02 and -03,
and the -03 review was positive.  Last call, please?

3. draft-ovsienko-babel-rfc7298bis

Denis has produced a -00.  I believe that Toke is interested both in
reviewing the draft and implementing it, and so am I.  The subject of
adoption was raised at the meeting, and nobody objected.  So:

  3.1 is anyone opposed to adopting this draft?
  3.2 Denis, do you want to produce a new revision before adoption, or are
      we welcome to adopt?
  3.3 Toke, do you want to review before adoption, or are we welcome to adopt?

I am in favour of adopting straight away.

4. Babel over DTLS

Three points of contention:

  4.1 does DTLS go over the Babel port, or do we request a different port
      for Babel over DTLS?
  4.2 is the client port equal to the server port, or do we use ephemeral
      ports on the client side?
  4.3 do we leave Hello/IHU unprotected, or do we send Hello/IHU over
      unicast and do something smart for link quality estimation?

I think that Antonin and David should get in touch, and produce
a compromise draft that it not necessarily consensual (perhaps with all
reasonable choices outlined).  Once we have a draft, we can ask for
adoption, and work out the details at the working group level.

5. draft-ietf-babel-information-model

Barbara's working copy (post -01) makes a lot of sense to me.  I suggest
she should submit -02 with the changes we discussed, and have it reviewed
by Toke, David, and hopefully Markus.  Since Toke's implementation is the
most complete, his input is likely to be the most useful (and critical).

My wishes for a safe return home, and kisses on both cheeks to all of you,

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 25 Mar 2018 18:33:20 +0200

>   3.3 Toke, do you want to review before adoption, or are we welcome

No reason to block adoption; I'll get around to reviewing it eventually,
but probably not in the next couple of months. And I am quite confident
that we can work out any issues that may crop up after adoption.

> most complete, his input is likely to be the most useful (and

I'll review it, but as above, not now :)

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Mar 2018 09:04:04 +0000

> > Barbara's working copy (post -01) makes a lot of sense to me.  I
> > suggest she should submit -02 with the changes we discussed, and have
> > it reviewed by Toke, David, and hopefully Markus.  Since Toke's
> > implementation is the most complete, his input is likely to be the
> > most useful (and critical).
> 

And, please, not before I post -02...
Barbara

---

From: David Schinazi <[email-masked]>
Date: Mon, 26 Mar 2018 16:27:57 +0200

> On Mar 25, 2018, at 03:30, Juliusz Chroboczek <[email-masked]> wrote:
> 

+ 1

> and the -03 review was positive.  Last call, please?

+1

> I am in favour of adopting straight away.

+1, I'll definitely review this draft but that can happen after WG adoption

> adoption, and work out the details at the working group level.

Sounds like a good plan to me.

Antonin, do you want to take the lead on the Babel over DTLS draft?

> most complete, his input is likely to be the most useful (and critical).

Happy to review -02.

David

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Mar 2018 14:16:22 -0400

Hi,

On Sat, Mar 24, 2018 at 9:30 PM, Juliusz Chroboczek <[email-masked]> wrote:
> ...
> ...

While I think there is pretty strong support for this draft in the WG, I do
not believe that the Routing Directorate review comments that were sent 3
January 2018 have been resolved. In particular those related to OAM which
were also discussed on the BABEL WG mailing list. I believe that if we just
declare consensus in the WG and request publication of the current draft,
our AD or the IESG will just bounce the document back to us for the reason
given in the Routing Directorate review. (There is also an Operations
Directorate review pending which I think will say the same thing when it is
done.) The BABEL WG Charter says "Particular emphasis will be placed on
work needed for a Proposed Standard routing protocol, such as ensuring
manageability and strong security. "

> and the -03 review was positive.  Last call, please?

OK, I'll start the WG Last Call. I believe this draft should be normatively
dependent on rfc6216bis.

> I am in favour of adopting straight away.

"Adopting" isn't that big a deal. People can review and discuss this draft
on the BABEL WG mailing list prior to adoption. So I don't see any rush.
I'll consider this message by Juliusz to be the start of a 2-week adoption
call.

>   4.1 does DTLS go over the Babel port, or do we request a different port

As I said in London, I think it would be fairly easy to get a 2nd port
assigned if we want.

>       unicast and do something smart for link quality estimation?

I think you need at least authentication for Hello/IHU.

> adoption, and work out the details at the working group level.

Sounds like a reasonable course of action.

> most complete, his input is likely to be the most useful (and critical).

Sounds good. Of course, anyone is welcome to review it.

6. Applicability document. The BABEL WG Charter says:

- As the Proposed Standard version of Babel is completed, an
Applicability Statement should be finalized to guide those potentially
interested in deploying Babel. This Applicability Statement may
include deployment advice and will be published as an RFC.

Given that there clearly are applicability criterion (there are occasional
posts to the mailing list that some particular application is or is not
appropriate for BABEL) and that I think the effort to produce an acceptable
applicability draft is pretty small, it a bad sign that
draft-ietf-babel-applicability-01.txt has been expired for over 6 months.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 26 Mar 2018 21:17:45 +0200

> January 2018 have been resolved.

I am not requesting publication at the current time.  I am requesting a review.

The comments received in January do not constitute a review.  The reviewer
only discussed Sections 1 and 2 (Introduction and Conceptual Overview),
and then spent the rest of her review claiming that we do not deal with
management.  I suspect that she may not even have read the technical parts
of rfc6126bis.

> In particular those related to OAM which were also discussed on the
> BABEL WG mailing list.

I have sent a lengthy reply about management on 7 January, and requested
a full review (in a separate mail).  It has been over two months now, and
I have received no reply from her.

> I believe that if we just declare consensus in the WG and request
> publication of the current draft,

I am not requesting publication at the current time.  I am requesting
a full review of the document, including the technical parts.  It's up to
the IESG, of course, but I am of the conviction that this can only be
achieved by choosing a different reviewer.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 26 Mar 2018 20:53:21 +0100

---- On Sun, 25 Mar 2018 02:30:26 +0100 Juliusz Chroboczek  wrote ---- 
>I won't block the process.) 

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. If there is no Address field but there is a TS/PC sub-TLV and 7298bis tries to use that and somebody swaps the packets between two point-to-point links, I wonder if that makes another attack possible.

So far the implied destination address doesn't seem to be an obviously safe design. I currently see a few ways of getting rid of this edge case:
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)
3. 7298bis does destination address protection too for all packets (7298 did only source, as 6126 is multicast-only).

I am still considering those options, feedback is welcome. One thing I wanted to confirm is whether point-to-point links in Babel are always meant to have addresses or they can be address-less.

> 3.2 Denis, do you want to produce a new revision before adoption, or are 

OK to go into further work as it is, I have a rough plan of remaining changes, but cannot make everything in one quick go right now.

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 26 Mar 2018 22:25:01 +0200

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

> 2. 6126bis simply mandates Address in IHU (AE = 1 or 3)

I'm fine with either of these.

> 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 still considering those options, feedback is welcome. One thing
> I wanted to confirm is whether point-to-point links in Babel are always
> meant to have addresses or they can be address-less.

You need an adress to put in the source field of the IP packet.  For IPv6,
this SHOULD be a link-local address.  For IPv4, this could be an address
assigned to a different interface of the same node, but carrying Babel
over IPv4 is NOT RECOMMENDED.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Mar 2018 22:34:19 +0200

Juliusz Chroboczek <[email-masked]> writes:

> For IPv4, this could be an address assigned to a different interface
> of the same node, but carrying Babel over IPv4 is NOT RECOMMENDED.

Seeing as this is the case, and that no implementations run on IPv4, the
IPv4 support is entirely theoretical. So I wonder whether it wouldn't
make more sense to drop it entirely from the spec?

-Toke

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Mar 2018 16:54:18 -0400

Hi Juliusz,

> I am not requesting publication at the current time.  I am requesting a review.

Sorry for misunderstanding you. The term "IESG Review" refers to the
ballot process and telechat in the IESG which occurs after AD review
and after publication request.

> management.  I suspect that she may not even have read the technical parts

I'll go back and re-read the conversation from January.

> I have received no reply from her.

That is certainly a legitimate complaint. I'll see what I can do.

> achieved by choosing a different reviewer.

Actually, it isn't up to the IESG. The document is still inside the
BABEL WG. If appropriate, we can certainly request assistance from our
AD. But, until WG consensus is declared and publication is requested,
the IESG normally doesn't have involvement with individual WG drafts.

Getting a full review with fresh eyes is an excellent path to take. As
I say, I'll see what I can do.

Thanks,
Donald

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 26 Mar 2018 22:16:50 +0100

---- On Mon, 26 Mar 2018 21:25:01 +0100 Juliusz Chroboczek  wrote ---- 
>I'm fine with either of these. 

Alright. Then 2 would be straightforward if the problem does not require 3 (see below).

>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 destination address can be covered by the integrity check too with no additional expense of bytes in the protocol encoding.

>over IPv4 is NOT RECOMMENDED. 

"Unnumbered interface" is the correct term from OSPF. It is out of scope in Babel, right?

-- 

    Denis Ovsienko

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Mar 2018 17:19:59 -0400

Hi Juliusz,

On Mon, Mar 26, 2018 at 4:54 PM, Donald Eastlake <[email-masked]> wrote:
>> ...  I am requesting

Poking around a bit, it turn out that Alia Atlas, 5 days ago on her
last day as BABEL WG AD, requested a new Routing Directorate review
and requested an Operations Directorate review. I'll ping the assigned
reviewers and see if I can get the reviews done earlier rather than
later.

Thanks,
Donald

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Mar 2018 23:47:06 +0200

Denis Ovsienko <[email-masked]> writes:

> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 27 Mar 2018 16:17:41 +0200

> and after publication request.

My bad.  Sorry for getting this wrong.

> I say, I'll see what I can do.

Thanks.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 28 Mar 2018 11:08:46 +0100

>least, that's the case with Bird and (I think) babeld. 

The host IP stack discards a packet if the destination isn't a local address or a joined multicast group. Now if someone intercepts or copies a Babel packet from A to B and rewrites the destination with C and feeds the new packet towards C, can anything go wrong? This may be the same as to ask if any arbitrary unicast Babel packet may be sent over multicast.

Sorry, I am still thinking about it.

-- 

    Denis Ovsienko

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2018 12:20:41 +0200

Denis Ovsienko <[email-masked]> writes:

> The host IP stack discards a packet if the destination isn't a local
> address or a joined multicast group. Now if someone intercepts or
> copies a Babel packet from A to B and rewrites the destination with C
> and feeds the new packet towards C, can anything go wrong? This may be
> the same as to ask if any arbitrary unicast Babel packet may be sent
> over multicast.

Yeah, don't see why that is not equivalent to the multicast case as you
say.

In principle there is nothing preventing anyone from the link of
unicasting a packet to anyone at the link-layer with a multicast
destination address (to get it delivered to the Babel socket), is there?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Mar 2018 14:44:11 +0200

> Yeah, don't see why that is not equivalent to the multicast case as you say.

Alice sends Bob a unicast Hello with seqno 42, properly authentified.
Chloe captures the Hello, and resends it to Damian.
Damian accepts it as a properly authentified unicast Hello from Alice to Damian.

The flaw here is a combination of two facts, neither of which is harmful
in itself:

  - a unicast Hello doesn't carry its destination in the body;
  - the HMAC algorithm doesn't protect the destination address.

There are other TLVs that have the same property -- IHU with AE=0, AckReqs
and Acks.  Additionally, it is not known what future extensions will do.
Hence, I suggest that HMAC should be protecting the destination address.

I'll send a detailed mail with all of my issues with the current draft
after I speak with the students on Friday.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2018 14:49:27 +0200

> Hence, I suggest that HMAC should be protecting the destination

But nothing about the unicast spec requires that the packet actually be
sent with a unicast destination address. That presumably needs to be
fixed, then?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Mar 2018 15:08:04 +0200

> sent with a unicast destination address. That presumably needs to be

Section 3.4.1 of 6126bis:

   There are two kinds of Hellos: Multicast Hellos, which use a per-
   interface Hello counter, and Unicast Hellos, which use a per-
   neighbour counter.  A Multicast Hello with a given seqno MUST be sent
   to all neighbours on a given interface, either by sending it to a
   multicast address or by sending it to one unicast address per
   neighbour (hence, the term "Multicast Hello" is a slight misnomer).
   A Unicast Hello carrying a given seqno should normally be sent to
   just one neighbour (over unicast), since the sequence numbers of
   different neighbours are not in general synchronised.

We can strengthen this if you wish.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2018 15:11:29 +0200

> We can strengthen this if you wish.

Well, "should normally be" is not going to fix any security issues ;)

I guess the important bit is to mandate that the receiving end discard
the packet if it is not received "correctly". But this could be added to
7298bis instead I guess...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Mar 2018 15:35:02 +0200

> Well, "should normally be" is not going to fix any security issues ;)

I think we're not understanding each other.  What security issue are you
speaking about?  What attack exactly is fixed by putting MUST here?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2018 15:41:40 +0200

> speaking about?  What attack exactly is fixed by putting MUST here?

Erm, the one you were just talking about?

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2018 15:42:54 +0200

> Erm, the one you were just talking about?

(not saying that MUST send over unicast will fix anything by itself;
just that it needs to be dealt with as part of a solution)

-Toke

---

From: David Schinazi <[email-masked]>
Date: Fri, 30 Mar 2018 07:59:09 -0700

Taking a step back and thinking about the security properties here,
I don't see a security issue with the text "A Unicast Hello carrying a given seqno should normally be sent to just one neighbour".
The conceptual property of unicast hellos is that the seqno is from a different pool as the multicast seqno.
That means that I MUST treat them separately when I receive them to avoid mixing up cost estimations,
however as a sender I can very well send the same unicast seqno to all my neighbors if I so choose.
As such it is not a problem to send Unicast Hellos to the multicast address (even though I don't see a reason to do so).
The attack that Juliusz described was where Eve takes an unicast Hello from Alice destined for Bob and sends it to Damian,
in that case the problem arises because Damian will check the timestamp/packet counter from the Alice-Damian relationship
and get a seqno from the Alice-Bob relationship.

The attack stems from the fact that packets can be replayed with a falsified destination address.
The simplest fix is to have the destination address as part of the inputs to the HMAC function.

Here is a proposal: we replace the current construct where the IPv6 source address is written into the HMAC field before HMAC
with a different construct akin to the TCP pseudo-header: we set the HMAC field to all zeroes and prepend the source and
destination IP addresses to the Babel payload before computing the HMAC. This is simpler and does not require us to place requirements
on the size of the HMAC output.

Thanks,
David

> On Mar 28, 2018, at 06:42, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel