Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)

From: Denis Ovsienko <[email-masked]>
Date: Wed, 01 Nov 2017 16:35:04 +0000

---- On Tue, 31 Oct 2017 17:25:26 +0000 Toke Høiland-Jørgensen<[email-masked]> wrote ---- 
 > Denis Ovsienko <[email-masked]> writes: 
 >  
 > >  > I'm terribly sorry if I'm being obtuse here, but from this comment it  
 > >  > seems to me that your objection is specifically to the use of the term  
 > >  > 'bidirectional reachability', because you read that to imply something  
 > >  > stronger than what Babel does?  
 > >  >   
 > >  > If so, what term would you suggest to use instead? Or would it suffice  
 > >  > to explicitly spell out that this is a weaker property than in some  
 > >  > other places (which?)?  
 > > 
 > > No problem, let me explain one more time. 
 > > 
 > > The way Babel is currently specified allows a protocol instance think 
 > > it has a 2-way exchange with a neighbour, whereas in reality it can be 
 > > just fed with replayed old packets. That's the way the protocol is 
 > > literally specified, no matter what was originally meant and what 
 > > comments were made on the mailing list or in person. 
 > > 
 > > The way it is commonly specified for other protocols involves a nonce 
 > > or another proof of freshness. For example, completing a 3-way TCP 
 > > handshake on behalf of a random remote host is impossible with just 
 > > replayed packets. TCP-based protocols rely on this property; non-TCP 
 > > protocols have to implement this property themselves: DD sequence 
 > > numbers in OSPF, nonces in IKE, MPTCP, IPv6 mobility and even almost 
 > > (but not really, because the nonce is not in the right TLV type) 
 > > Babel. There are examples in many other protocol designs as this is 
 > > quite an old problem. 
 >  
 > Yeah, this is what I meant: You're saying that "bidirectional 
 > reachability" has a specific, well-defined and ubiquitous meaning which 
 > implies certain security properties (such as replay protection). 
 >  
 > However, prior to you brining it up, I have not been aware of any such 
 > well-defined meaning of the term. For TCP, for instance, it's called the 
 > "3-way handshake". So I would agree with you that if the term used was 
 > "handshake", your point stands. But simply using "bidirectional 
 > reachability" in the informal way it is used in the Babel spec does not 
 > imply such a specific term to me. So I would ask you to point me any 
 > definitions that include this implication of the wording currently in 
 > the Babel spec? 

3.4.  Neighbour Acquisition

   Neighbour acquisition is the process by which a Babel node discovers
   the set of neighbours heard over each of its interfaces and
   ascertains bidirectional reachability.  On unreliable media,
   neighbour acquisition additionally provides some statistics that may
   be useful for link quality computation.

The text says "ascertains bidirectional reachability" and in the network protocols language this is a statement with a meaning. Then Section 3.4.2 further elaborates on how this is done and it takes to stare at the TLV diagrams for quite a while to realize the actual behaviour is different.

If the protocol does not deliver this property either the text or the protocol need to be fixed. What actually is in the box must be what is says on the box.

 > -Toke 
 >  
 > P.S., as I said, I'm fine with adding a note to, say, section 3.4.2 that 
 > makes it clear that the protocol does *not* have this stronger property. 

Yes, exactly.

-- 

    Denis Ovsienko

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 01 Nov 2017 17:42:37 +0100

Hi Denis

I think this is the critical point:

> The text says "ascertains bidirectional reachability" and in the
> network protocols language this is a statement with a meaning.

Which "network protocols language" are you referring to?

As I said, I did not get the same specific meaning out of Section 3.4
when I first read it; and I have not been able to find a definition of
this term anywhere through my (admittedly limited) googling. So if you
could provide a reference, that would be helpful :)

-Toke

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 06 Nov 2017 15:47:56 +0000

---- On Wed, 01 Nov 2017 16:42:37 +0000 Toke Høiland-Jørgensen  wrote ---- 
>could provide a reference, that would be helpful :) 

Hello Toke.

The "network protocols language" I was referring to does not have a definite normative reference as far as I know. It is a vague set of related concepts, but it gets more clear with studying specifications and implementations.

If the goal was only to state exactly what to do, source code would work. However, the goal of the specification is to make it clear to the readers what was originally meant and what they can reasonably expect from an implementation.

On one hand, a reader may interpret an under-specified text the way they mean, not the way the author means. On the other, over-specified text ultimately becomes a source code. Finding the right balance is a vague problem, as far as I see using the right language helps to make it smaller.

-- 
    Denis Ovsienko

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 08 Nov 2017 10:41:45 +0900

Denis Ovsienko <[email-masked]> writes:

> The "network protocols language" I was referring to does not have a
> definite normative reference as far as I know. It is a vague set of
> related concepts, but it gets more clear with studying specifications
> and implementations.

Right, but that makes it one of those things that reasonable people can
disagree on. Which I guess what is going on here.

Now, seeing as the problem this creates is a security issue, I agree
with David that the security considerations section is the place to add
a note. So an way to fix this would be adding something like this to the
first paragraph of section 6 (some wordsmithing probably needed):

"In particular, the bidirectional reachability detection in Babel is not
a full handshake and does not offer any security guarantees (such as
replay protection). Any security extensions to Babel need to take this
into account."

Would this address your concerns, do you think? :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 08 Nov 2017 16:41:06 +0100

> first paragraph of section 6 (some wordsmithing probably needed):

I don't agree.

Babel is a completely insecure protocol.  It MUST therefore be used
together with a hop-to-hop security mechanism.  Depending on the
deployment model, this could be one of the following:

  * physical layer security (e.g. physically secured Ethernet);
  * link-layer security (e.g. WPA2, 802.1X, VPN);
  * network-layer security (e.g. IPsec);
  * transport-layer security (e.g. DTLS);
  * application-layer security (e.g. 7298bis).

If Babel is not properly secured, it is vulnerable to a wide range of
attacks (lower-metric, higher seqno, longer prefix, Hello-based DoS,
IHU-based DoS, etc.)  This is something that must be made perfectly clear
to the reader.

> replay protection). Any security extensions to Babel need to take this

Singling out this particular property is misleading for many reasons.  It
implies that this is the most serious vulnerability in unsecured Babel,
which is simply not true.  It also implies that a reliable three- or
four-way handshake does offer some sort of security guarantees, which it
does not.  In effect, the user will find himself wondering whether he
missed something.

In short, your suggestion makes the document less rather than more clear.
I would therefore be opposed to adding such a sentence.

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Wed, 8 Nov 2017 10:32:17 -0800

On Nov 8, 2017, at 07:41, Juliusz Chroboczek <[email-masked]> wrote:
> which is simply not true.

The current text of the Security Considerations section already offers an example of a vulnerability in unsecured Babel.

>>>    Any attacker can misdirect data traffic by advertising routes with a
>>>    low metric or a high seqno

Which strikes me as rather more serious than replay attacks on the bidirectional reachability detection.

> I would therefore be opposed to adding such a sentence.

Perhaps some compromise can be found by strengthening the admonition in the Security Considerations section to use a hop-to-hop security mechanism according to the deployment model, and to provide a more detail list of the vulnerabilities available when that security layer is breached.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Nov 2017 13:40:57 -0500

On Wed, Nov 8, 2017 at 1:32 PM, james woodyatt <[email-masked]> wrote:

> The current text of the Security Considerations section already offers an
> example of a vulnerability in unsecured Babel.
>
> Perhaps some compromise can be found by strengthening the admonition in
> the Security Considerations section to use a hop-to-hop security mechanism
> according to the deployment model, and to provide a more detail list of the
> vulnerabilities available when that security layer is breached.
>

I strongly agree.  At least a mandatory-to-implement hop-to-hop security
mechanism and what attacks it protects against is critical.

Regards,
Alia

> --james woodyatt <[email-masked]>
>
>
>
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Nov 2017 20:42:38 +0200

On Nov 8, 2017, at 8:40 PM, Alia Atlas <[email-masked]> wrote:
> I strongly agree.  At least a mandatory-to-implement hop-to-hop security mechanism and what attacks it protects against is critical.

A security model that protects against _anything_ requires it to actually be secure.   The current draft has no such mechanism.   So if you want to make something MTI, we can't do it with the current draft, or we'd be requiring people to implement mickey-mouse security.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Nov 2017 13:47:32 -0500

On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon <[email-masked]> wrote:

> A security model that protects against _anything_ requires it to actually
> be secure.   The current draft has no such mechanism.   So if you want to
> make something MTI, we can't do it with the current draft, or we'd be
> requiring people to implement mickey-mouse security.
>

Requiring a transport security isn't feasible?

A new routing protocol without solid security is not going to progress
successfully.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Nov 2017 13:56:57 -0500

I didn't say it wasn't feasible. I said it's not in this document. :)

---

From: james woodyatt <[email-masked]>
Date: Wed, 8 Nov 2017 11:10:41 -0800

On Nov 8, 2017, at 10:47, Alia Atlas <[email-masked]> wrote:
> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> On Nov 8, 2017, at 8:40 PM, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
> A new routing protocol without solid security is not going to progress successfully. 

I think the compromise I was proposing is that RFC6126bis could be published with a “strong admonition” in its Security Considerations section that various security vulnerabilities are available unless an appropriate hop-by-hop security layer according to the deployment model is also used in conjunction with RFC 6126bis. I suspect the Working Group would prefer this instead of actually specifying and requiring a mandatory-to-implement security layer suitable for all deployment models. You’re saying the Working Group is going to lose that argument.

Having a procedural requirement to establish a tight coupling between the routing protocol and its universal and integrated security layer for Babel to progress successfully is a good thing to have aired before the end of Working Group Last Call.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Nov 2017 14:25:55 -0500

Hi James,

On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt <[email-masked]> wrote:

> I think the compromise I was proposing is that RFC6126bis could be
> published with a “strong admonition” in its Security Considerations section
> that various security vulnerabilities are available unless an appropriate
> hop-by-hop security layer according to the deployment model is also used in
> conjunction with RFC 6126bis. I suspect the Working Group would prefer this
> instead of actually specifying and requiring a mandatory-to-implement
> security layer suitable for all deployment models. You’re saying the
> Working Group is going to lose that argument.
>
> Having a procedural requirement to establish a tight coupling between the
> routing protocol and its universal and integrated security layer for Babel
> to progress successfully is a good thing to have aired before the end of
> Working Group Last Call.
>

 Let me add in Kathleen and Eric here as well.

I have to take a read through the updated draft myself, but I can see no
reason to not adequately address control-plane security in
a new routing protocol when it is moving to the Standards track.  Making
sure that security is adequately addressed is one of the
attributes that we look for in standards track work.

The charter does say "Particular emphasis will be placed on work needed
for a Proposed Standard routing protocol, such as ensuring manageability
and strong security."  and among the Work Items are:

" Address security needs for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security may be
included in the base spec or the base spec may normatively reference a
separate Proposed Standard specification. This is required as part of
moving Babel to Proposed Standard."

I am very pleased with the work and discussion so far on clarifying and
improving Babel.
This aspect is also critical.

Regards,
Alia

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Nov 2017 17:44:41 -0800

Hi Alia,

I strongly believe the security should be decoupled from the routing protocol.
You could have a network where parts of it are using DTLS, parts use IPsec,
parts are in a bunker on the moon and rely on physical security.
Babel was designed to be used in heterogeneous networks.
While I suspect Juliusz originally meant Wi-Fi vs Ethernet, I think this key
principle of the protocol applies to local security properties as well.

Thanks,
David

> On Nov 8, 2017, at 11:25, Alia Atlas <[email-masked]> wrote:
> 
> Hi James,
> 
> On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> On Nov 8, 2017, at 10:47, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
> I have to take a read through the updated draft myself, but I can see no reason to not adequately address control-plane security in
> a new routing protocol when it is moving to the Standards track.  Making sure that security is adequately addressed is one of the
> I am very pleased with the work and discussion so far on clarifying and improving Babel.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Nov 2017 21:50:26 -0500

Hi David,

I do agree that flexibility is important. The logic behind having one
mandatory-to-implement
security mechanism is that the different implementations are able to
securely interoperate.
If one vendor implements DTLS and another does IPsec, then those two
vendors can't
interoperate securely - and since connectivity is almost always viewed as
more critical than
security, that is the one that gets tossed.

This is particularly important in a home environment, where one can't
assume a knowledgeable
operator and where it is more possible that private information may be
conveyed via route
information pertaining to individuals' personal equipment.

There are probably several different options - around what requires
integrity protection, what
needs confidentiality, what should be built in as a protocol extension
versus what can be used
at the transport layer.

I don't have any technical opinion or preference - but this needs to be
easy enough for a small
enterprise or home user to pull equipment from different vendors out of the
boxes over a period
of years - and have them work securely together.  I don't have solutions
for the keying issues -
or thoughts as to whether opportunistic encryption might be good in some
cases.

Regards,
Alia

On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi <[email-masked]> wrote:

>>> A security model that protects against _anything_ requires it to
>>> actually be secure.   The current draft has no such mechanism.   So if you
>>> want to make something MTI, we can't do it with the current draft, or we'd
>>> be requiring people to implement mickey-mouse security.
>>>
>>

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Nov 2017 19:00:29 -0800

Alia,

I agree with that use case, but I think this should be standardized as part of the
Babel Homenet Profile. For different vendors to interoperate we will need that.
Today a Babel device that only has ethernet ports will not interoperate with
a device that only has Wi-Fi, and that's not a deficiency. Even if we were to
mandate a solution (e.g. Babel over DTLS), that will not improve security
if we do not specify how to establish trust. That's why I think security should be
handled per use case, and for example I really hope we will standardize how
to establish trust, exchange keys and secure Babel for the Homenet.
At the end of the day encryption and integrity only work when you've
established trust, and that can't be done in a way that works for all
possible use cases.

David

> On Nov 8, 2017, at 18:50, Alia Atlas <[email-masked]> wrote:
> 
> Hi David,
> 
> I do agree that flexibility is important. The logic behind having one mandatory-to-implement
> security mechanism is that the different implementations are able to securely interoperate.
> If one vendor implements DTLS and another does IPsec, then those two vendors can't
> interoperate securely - and since connectivity is almost always viewed as more critical than
> This is particularly important in a home environment, where one can't assume a knowledgeable
> operator and where it is more possible that private information may be conveyed via route
> There are probably several different options - around what requires integrity protection, what
> needs confidentiality, what should be built in as a protocol extension versus what can be used
> at the transport layer.
> 
> I don't have any technical opinion or preference - but this needs to be easy enough for a small
> enterprise or home user to pull equipment from different vendors out of the boxes over a period
> of years - and have them work securely together.  I don't have solutions for the keying issues -
> or thoughts as to whether opportunistic encryption might be good in some cases.
> 
> Regards,
> Alia
> 
> 
> On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alia,
> 
>> On Nov 8, 2017, at 11:25, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi James,
>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Nov 2017 23:18:47 -0500

David,

The charter is unspecific as to whether it is a mechanism that is integral
to Babel,
an extension as with the pre-standard Babel, or over a transport.  There
does have
to be a dependency (normative reference) on something to implement.

There's a long history of discussion on automatic key management.  If the
basic
mechanism is in place, even opportunistic security can be better than
nothing.
Having a manual key put in isn't good - but having the support for a key
allows
better ways of building trust.

I haven't been following homenet closely. What does the Babel Homenet
Profile currently
say on this?  How far away is that from being finished.

Regards,
Alia

On Wed, Nov 8, 2017 at 10:00 PM, David Schinazi <[email-masked]> wrote:

>>>> I strongly agree.  At least a mandatory-to-implement hop-to-hop
>>>> security mechanism and what attacks it protects against is critical.
>>>>
>>>>
>>> Having a procedural requirement to establish a tight coupling between
>>> the routing protocol and its universal and integrated security layer for
>>> Babel to progress successfully is a good thing to have aired before the end
>>> of Working Group Last Call.
>>>
>>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Nov 2017 23:30:48 +0100

> That's why I think security should be handled per use case,

I agree with you, David, but I think Alia may have a point.  The Babel
community has to define one default security mechanism, and send a clear
message telling implementers that unless you have good reasons to do
otherwise, this is the mechanism you should be implementing.

We can discuss whether this mechanism should be MTI or strongly recommended,
but since we haven't done our homework (defining the recommended mechanism),
that discussion would be very premature at this point.

Current candidates for the recommended security mechanism include:

  - 7298bis or something similar (vide RFC 5709);
  - DTLS;
  - dynamically keyed IPsec.

There are other possibilities (e.g. statically keyed IPsec together with
an application layer replay protection mechanism), but I don't think they
are strong contenders.

Just like you, David, I love arguing about MTI (and just like you, I think
that MTI is a silly idea), but right now I suggest we be good, and
implement one or more of the above so we can have an adult discussion on
which security mechanism we wish to recommend.  (Call me an integrist, but
I really don't think one can have an adult discussion until one has tried
one's hand at implementing the protocol one supports.  You know who you
are.)  My aim would be to have an implementation of DTLS ready in time for
IETF 101, but I'm not sure I'll succeed.

If our respected chairs agree, I can make a quick presentation at IETF 100
on the subject.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 09 Nov 2017 23:38:50 +0000

---- On Wed, 08 Nov 2017 01:41:45 +0000 Toke Høiland-Jørgensen  wrote ---- 
>Would this address your concerns, do you think? :) 

Hello all.

I tried to come up with a more detailed problem statement, after some thinking let me propose the following change to the current I-D:

--- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
+++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
@@ -819,7 +819,7 @@ runs the route selection procedure (<xref target="route-selection"/>).</t>
 
 </section>
 
-<section title="Bidirectional Reachability Detection">
+<section title="Bidirectional Reachability Detection" anchor="bidir-reachability">
 
 <t>In order to establish bidirectional reachability, every node sends
 periodic IHU ("I Heard You") TLVs to each of its neighbours.  Since IHUs
@@ -2267,6 +2267,23 @@ from a link-local IPv6 address; since routers don't forward link-local IPv6
 packets, this provides protection against spoofed Babel packets being sent
 from the global Internet.  No such natural protection exists when Babel
 packets are carried over IPv4.</t>
+
+<t>It may be not obvious that this revision of this document specifies
+(<xref target="bidir-reachability"/>) "bidirectional reachability" in such a
+way that it is impossible to relate the data in a legitimate incoming IHU TLV
+to a particular prior outgoing Hello TLV. A Babel speaker will accept as a
+proof of the bidirectional reachability any IHU TLV that lists its router-id,
+even if the IHU TLV comes in a replayed or duplicate packet.</t>
+
+<t>One consequence of this is that even when the authentication mechanism
+defined in <xref target="RFC7298"/> is deployed in a network segment, a replay
+attack is possible if the attacker can intercept authenticated Babel packets
+on their way between two speakers and store them offline instead of the normal
+delivery. Then if the attacker later replays the stored packets towards the
+receiver, the authentication mechanism will accept them because it has not
+seen them before, and the base protocol instance will process the TLVs in
+those packets, "detect" the sending neighbour and try to act respective route
+updates.</t>
 </section>
 
 <section title="Acknowledgments">
@@ -2398,6 +2415,8 @@ Hoiland-Jorgensen.  The address compression technique was inspired by
   <seriesInfo name="RFC" value="5444"/>
 </reference>
 
+<?rfc include="reference.RFC.7298.xml"?>
+
 </references>
 
 <section title="Cost and Metric Computation">

-- 

    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 10 Nov 2017 01:21:19 +0100

> I tried to come up with a more detailed problem statement, after some
> thinking let me propose the following change to the current I-D:

Please check my message of 8 November 2017 about why I'm not going to
apply that.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 10 Nov 2017 16:23:56 +0000

---- On Fri, 10 Nov 2017 00:21:19 +0000 Juliusz Chroboczek  wrote ---- 
>Please check my message of 8 November 2017 about why I'm not going to 

Hello Juliusz.

That message states that Babel is unsecure and discusses offloading the problem elsewhere, also that the proposed (at that time) additional text for the Security Considerations section does not make everything clear enough.

Now that I have clarified that additional text a little but you are still unhappy about it, would you like to suggest any improvements to the text?

Thanks.

-- 

    Denis Ovsienko

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 11 Nov 2017 02:10:24 -0500

Hi Juliusz,

I think a presentation on security alternatives at the BABEL WG meeting
this coming Friday would be a good idea. The BABEL Charter is pretty clear
in mandating better security than that in rfc6126bis, either in rfc6126bis
or in a document normatively referenced by rfc6162bis, is a gating factor
in the approval of BABEL as an IETF Standards Track protocol.

I have submitted a Meetecho request for this, which is actually one day
past the deadline, but I'm hopefully they will accept it since it is for
the last time slot of the week...

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: Sat, 11 Nov 2017 15:20:50 +0100

> That message states that Babel is unsecure and discusses offloading the
> problem elsewhere,

No, it doesn't say that.  It says that singling out your pet security
property and stating that Babel doesn't have does not have it does not
improve the document.

This, Denis, is unfortunately typical of interacting with you: you keep
assuming that people are saying something, and in effect don't read what
they are actually saying.

-- Juliusz

---

From: Justin Kilpatrick <[email-masked]>
Date: Sat, 11 Nov 2017 14:39:18 -0500

In addition to traffic and protocol message security I would be
interested in discussing what it would take to harden Babel against
malicious input.

Things like ratelimiting of update requests and sanity checking
prefixes. There are good questions about what's really necessary and how
it impacts the standard.

Unfortunately I won't be able to attend the WG meeting myself, a summary
or recording will have to suffice.

--
  Justin Kilpatrick
  [email-masked]

On Sat, Nov 11, 2017, at 02:10 AM, Donald Eastlake wrote:
> Hi Juliusz,
> 
> I think a presentation on security alternatives at the BABEL WG meeting this coming Friday would be a good idea. The BABEL Charter is pretty clear in mandating better security than that in rfc6126bis, either in rfc6126bis or in a document normatively referenced by rfc6162bis, is a gating factor in the approval of BABEL as an IETF Standards Track protocol.
> 
> I have submitted a Meetecho request for this, which is actually one day past the deadline, but I'm hopefully they will accept it since it is for the last time slot of the week...
> 
> Thanks,
> Donald
> _________________________________________________
> babel mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Nov 2017 09:40:53 +0800

> prefixes. There are good questions about what's really necessary and how

This would be very good.   Can you possibly attend via Meetecho?

---

From: Justin Kilpatrick <[email-masked]>
Date: Sat, 11 Nov 2017 20:45:18 -0500

That would be great.

--
  Justin Kilpatrick
  [email-masked]

On Sat, Nov 11, 2017, at 08:40 PM, Ted Lemon wrote:
> On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick
> <[email-masked]> wrote:>> Things like ratelimiting of update requests and sanity checking
>> prefixes. There are good questions about what's really necessary
>> and how>> it impacts the standard.
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Nov 2017 09:50:00 +0800

> That would be great.

Wonderful.   Here's the remote participation info: https://www.ietf.org/meeting/100/remote-participation.html <https://www.ietf.org/meeting/100/remote-participation.html>

The session starts at 9:30 singapore time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Babel&iso=20171117T0930&p1=236&ah=2 <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Babel&iso=20171117T0930&p1=236&ah=2>

---

From: Alia Atlas <[email-masked]>
Date: Sat, 11 Nov 2017 20:50:31 -0500

Justin,

Please do give MeetEcho a try.  It allows very good interactivity/
You do need to pre-register and it's good to run the test program as well
beforehand.

Regards,
Alia

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Nov 2017 09:51:33 +0800

> The session starts at 9:30 singapore time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Babel&iso=20171117T0930&p1=236&ah=2 <https://www.timeanddate.com/worldclock/fixedtime.html?msg=B…
BTW, note that if you are in the U.S., this is going to be Thursday evening, not Friday evening. :)