Subject: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt

From: "Snyder, Brian" <[email-masked]>
Date: Mon, 5 May 2014 20:03:19 +0000

Hello all,

Nobo and I have been working on publishing a new informational  RFC related to proxying BFD via monitored links.  This is written as a generalized solution for all monitored links, but with satellite use case as the primary example.  Additionally, prior to writing this document, I have actually coded up a proof of concept which has been proven to work in the stated use case.

If anyone would care to review and comment it would be most appreciated.

Thanks,
Brian & Nobo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 05, 2014 3:34 PM
To: Nobo Akiya; Snyder, Brian; Nobo Akiya; Snyder, Brian
Subject: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt

A new version of I-D, draft-snyder-bfd-proxy-connections-monitored-links-00.txt
has been successfully submitted by Brian Snyder and posted to the IETF repository.

Name:		draft-snyder-bfd-proxy-connections-monitored-links
Revision:	00
Title:		BFD Proxy for Connections over Monitored Links
Document date:	2014-05-05
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-snyder-bfd-proxy-connections-monitored-links-00.txt
Status:         https://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-monitored-links/
Htmlized:       http://tools.ietf.org/html/draft-snyder-bfd-proxy-connections-monitored-links-00

Abstract:
   This document describes a Bidirectional Forwarding Detection (BFD)
   proxy mechanism to allow intermediate networking equipment (ex:
   Satellite HUB/Modem) to intercept BFD packets and to generate BFD
   packets to relay the health of connection monitored links.

   Note that this is an informational document that does not propose any
   changes to the BFD protocol.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 May 2014 12:29:25 -0400

Brian,

On Mon, May 05, 2014 at 08:03:19PM +0000, Snyder, Brian wrote:
> Nobo and I have been working on publishing a new informational  RFC
> related to proxying BFD via monitored links.  This is written as a
> generalized solution for all monitored links, but with satellite use case
> as the primary example.  Additionally, prior to writing this document, I
> have actually coded up a proof of concept which has been proven to work in
> the stated use case.
> 

Thank you for bringing this to the Working Group's attention.  The
proposal makes no changes to the BFD protocol from an endpoint's
perspective, so there is no specific requirement for BFD standards work.  

Were you looking for this draft to be adopted within the WG?  If so, it'd
require a minor re-chartering.

I did have two bits of technical feedback on the draft:
1. The security considerations already discuss the need for the proxy to be
involved in the security.  IMO, citing GTSM as a security mechanism is
probably not sufficient in such satellite networks without assurance that
the link itself is encrypted.  While I'd presume that would be an inherent
requirement of such networks, that's not stated. :-)

2. I wonder if such networks have the equivalent of LAG using multiple
radios.  If so, what do you expect to be the implications on BFD on LAG?

-- Jeff

---

From: "Snyder, Brian" <[email-masked]>
Date: Tue, 6 May 2014 18:13:55 +0000

Jeff,

Answers embedded....  Thanks for engaging....

Regards,
Brian

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 12:29 PM
To: Snyder, Brian
Cc: [email-masked]
Subject: Re: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt

Brian,

On Mon, May 05, 2014 at 08:03:19PM +0000, Snyder, Brian wrote:
> generalized solution for all monitored links, but with satellite use 
> case as the primary example.  Additionally, prior to writing this 
> document, I have actually coded up a proof of concept which has been 
> proven to work in the stated use case.
> 

Thank you for bringing this to the Working Group's attention.  The proposal makes no changes to the BFD protocol from an endpoint's perspective, so there is no specific requirement for BFD standards work.  

Were you looking for this draft to be adopted within the WG?  If so, it'd require a minor re-chartering.

[BS] - I had discussed this with Nobo a while back when I was starting the project and he suggested there might be interest in an informational RFC.    I would like it to be adopted by a WG, though honestly, I'm not 100% sure if it relates more to the BFD or the MANET group (I sent the notification to both).  Is that what you mean by 're-chartering'? Forgive me, but this is my first experience attempting to do something like this, so not sure...
The novelty of this idea is that one would think DLEP was a better match to my problem set, but after studying both, it turns out BFD (with a proxy) is actually much more suited to solve my problem....  Hence my confusion about the best WG to publish this too.

I did have two bits of technical feedback on the draft:
1. The security considerations already discuss the need for the proxy to be involved in the security.  IMO, citing GTSM as a security mechanism is probably not sufficient in such satellite networks without assurance that the link itself is encrypted.  While I'd presume that would be an inherent requirement of such networks, that's not stated. :-)

[BS] - Fair enough.  And yes, most sat networks do utilize RF link encryption (some even use TRANSEC).  It's optional (of course) - but I can make it that clearer that it's an option/expectation for security needs.

2. I wonder if such networks have the equivalent of LAG using multiple radios.  If so, what do you expect to be the implications on BFD on LAG?

[BS] - The lag to geo sync satellites is ~ 260ms one way.  The implication I am making though is the proxy equipment is on the respective LAN sides (sat hub and remotes) so the propogation RF LAG is not noticeable to the BFD routing endpoints.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 6 May 2014 19:01:18 +0000

Hi Jeff, Brian, all,

> Thank you for bringing this to the Working Group's attention.  The proposal
> makes no changes to the BFD protocol from an endpoint's perspective, so
> there is no specific requirement for BFD standards work.
> 
> [BS] - I had discussed this with Nobo a while back when I was starting the
> project and he suggested there might be interest in an informational RFC.    I
> would like it to be adopted by a WG, though honestly, I'm not 100% sure if it
> relates more to the BFD or the MANET group (I sent the notification to both).
> Is that what you mean by 're-chartering'? Forgive me, but this is my first
> experience attempting to do something like this, so not sure...
> The novelty of this idea is that one would think DLEP was a better match to
> my problem set, but after studying both, it turns out BFD (with a proxy) is
> actually much more suited to solve my problem....  Hence my confusion
> about the best WG to publish this too.

Initial direction of this BFD proxy was scoped only for Satellite, and targeted to the MANET WG. But a short chat with AD revealed that better direction may be to write this up as a generic BFD technique and share it with the MANET WG. Although the document is more interesting from MANET angle, I think pursuing this as a BFD document makes better sense. So yes, minor re-charter will be needed by the BFD WG if the document can generate sufficient interests.

-Nobo

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 May 2014 16:24:21 -0400

Brian,

On Tue, May 06, 2014 at 06:13:55PM +0000, Snyder, Brian wrote:
> project and he suggested there might be interest in an informational RFC.
> I would like it to be adopted by a WG, though honestly, I'm not 100% sure
> if it relates more to the BFD or the MANET group (I sent the notification
> to both).  Is that what you mean by 're-chartering'? Forgive me, but this
> is my first experience attempting to do something like this, so not
> sure...

Chartering in the IETF WG context is the list of things IETF "management"
have agreed we can officially work on. :-)

http://datatracker.ietf.org/wg/bfd/charter/

Based on Nobo's feedback elsewhere in the thread, I think it makes sense to
hold off on a charter/adoption request until you've had a chance to get this
shown around in manet as well.  Once you've done that and are wanting to get
this adopted by a working group, BFD would be a fine home for the work, I
think.

> [BS] - Fair enough.  And yes, most sat networks do utilize RF link encryption (some even use TRANSEC).  It's optional (of course) - but I can make it that clearer that it's an option/expectation fo…

The issue is that since BFD is a connectionless protocol, on a RF link there
is a greater than normal chance for insertion of malicious traffic when
there is no encryption.  Since BFD being told that it is down can trigger
bad behaviors by its consumers, this is a Bad Thing. :-)

A comment on the sensitivity of BFD and the need either for layer 2
encryption to protect against this along with GTSM and/or strong BFD
authentication would address the concern.

> [BS] - The lag to geo sync satellites is ~ 260ms one way.  The implication I am making though is the proxy equipment is on the respective LAN sides (sat hub and remotes) so the propogation RF LAG i…

Ok, so link bundles are an unlikely feature in this case.  Thanks for
answering.

-- Jeff