Re: I-D Action: draft-ietf-bfd-large-packets-05.txt
Working Group, After a fumble in -04, -05 updates -03's republish earlier this week with a YANG module to configure the padded size. Comments are appreciated. YANG doctor review will be getting requested as we hopefuly move this forward soon. -- Jeff and Albert On Tue, Jan 30, 2024 at 12:09:02PM -0800, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a > work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. > >Title: BFD Encapsulated in Large Packets >Authors: Jeffrey Haas > Albert Fu >Name:draft-ietf-bfd-large-packets-05.txt >Pages: 12 >Dates: 2024-01-30 > > Abstract: > >The Bidirectional Forwarding Detection (BFD) protocol is commonly >used to verify connectivity between two systems. BFD packets are >typically very small. It is desirable in some circumstances to know >that not only is the path between two systems reachable, but also >that it is capable of carrying a payload of a particular size. This >document discusses thoughts on how to implement such a mechanism >using BFD in Asynchronous mode. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-05.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts >
I-D Action: draft-ietf-bfd-large-packets-05.txt
Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. Title: BFD Encapsulated in Large Packets Authors: Jeffrey Haas Albert Fu Name:draft-ietf-bfd-large-packets-05.txt Pages: 12 Dates: 2024-01-30 Abstract: The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-05.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-05 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts
I-D Action: draft-ietf-bfd-large-packets-04.txt
Internet-Draft draft-ietf-bfd-large-packets-04.txt is now available. It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. Title: BFD Encapsulated in Large Packets Authors: Jeffrey Haas Albert Fu Name:draft-ietf-bfd-large-packets-04.txt Pages: 8 Dates: 2024-01-30 Abstract: The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts
Re: Optimizing Authentication - periodic re-authentication
On Jan 28, 2024, at 3:21 PM, Jeffrey Haas wrote: > There's at least two possible ways to address this: > 1. We simply don't worry about periodic re-auth for no-auth or NULL-auth. > We thus don't protect against this attack. If you care about this attack, > use Meticulous Keyed ISAAC and the attack goes away. > 2. We test periodic strong authentication by using a Poll sequence. If we > don't receive a Fin within the Detect Interval with strong auth, compromise > should be expected. I think that the recommendation should be "if not using strong authentication or ISAAC, then periodically use poll mode". > [1] Yes... the only attack we have in this mode is "keep the session Up when > it might otherwise not be". I expect the usual hilarity when we get to > security area review. Not all attacks have negative effects. I'm reminded of a "buffer overflow" report from many years ago for some of my software. The overflow wasn't a network-based overflow, which would have been worrying. Instead, the report was "it is possible to create configuration file data which results in overflow, which can make the software do things". I think it took about 4 rounds before I manage to get it through that if an attacker can write to the configuration files, he can just *configure* the software to do something. He doesn't need to "exploit" it with an overflow. I that hope that the secdir review can avoid commenting on useless and irrelevant attacks. Alan DeKok.
