[Babel-users] RFC: Babel packet authentication

[Dave Taht]

wow. I had come up with something that relied on the underlying ntp
layer being secured with autokey, at one point, and then boosting the
metric of routes received from unauthenticated sources (or ignoring,
optionally)

(I may have posted something to the list on this.
 I figured it wasn't going to be secure enough)

I'll have to think about this after I get back from vacation...

but I didn't lay out the packet signing bits at all...

hmm....


On Sun, May 20, 2012 at 10:29 PM, Denis Ovsienko <infrastation at yandex.ru> wrote:
> Hello, list.
>
> Cover letter and reasoning
> ==========================
> This draft suggests improving Babel protocol in the way of packet authentication. Packet authentication is an approach, which most other IGPs use to ensure, that received protocol packets were originated by the same router, which is claimed as packet sender, and were delivered unchanged.
>
> Babel (in the definition of RFC6126) lacks any builtin authentication means, but explicitly allows for arbitrary trailing data after the main packet body and specifies, that unknown TLVs in the main packet body must be silently ignored.
>
> An implementor of an authenticated Babel network is left with the following options:
> * Authenticate all packetes in the network (e.g. WPA).
> * Selectively authenticate Babel packets with IPSec policy.
> * Implement Babel packet-level authentication using trailing data.
> * Implement Babel packet-level authentication using TLVs.
> * Do something else.
>
> The TLV option, to my opinion, makes the most sense. I need to make my reasons, which come from several months of studying packet structures of RIP-2, OSPF-2 and OSPF-3. In partucular, this study involved developing and fixing Quagga code to protect it from malformed packets (which may be malformed in a lot of ways). In the cases of RIP-2 and OSPF-2 this experience also included structures and methods used in packet authentication.
>
> RIP-1 (RFC1058) packets did not have any authentication and contained fixed-size data structures (RTEs) with routing information. RIP-2 (RFC2453) introduced simple password authentication and reused leading RTE for authentication information. Keyed-MD5 hash authentication (RFC2082) was added later and used trailing RTE for hash digest data, which did exactly fit, but only till Cryptographic (RFC4822) authentication was defined, which allowed for longer trailing data.
>
> OSPF-2 (RFC2328) had Keyed-MD5 authentication in the basic specification and necessary flexibility in the packet header to allow for hash digests of other lengths, which (HMAC-SHA family) were added by RFC5709. However, the hash digest never belonged to the main packet body. OSPF-2 did not allow for new protocol-scope parameters to be carried in a packet (type-9 opaque LSAs did not quite fit for the job), and LLS (RFC5613) was established in the form of 2nd (in the case of OSPF-2) trailer, a container for TLVs.
>
> OSPF-3 (RFC5340) removed all support for authentication in favour of IPv6 AH/ESP means. LLS (RFC5613) was also defined for OSPF-3, which got its own (1st) trailer with LLS TLVs. However, AH/ESP did not become a complete solution, and (2nd) trailer with HMAC-SHA (RFC6506) authentication data was established.
>
> There are lessons, which can be learned from this history.
>
> First, authentication is very likely to appear in a routing protocol at some point, even if it is missing in the beginning. Authenticating all packets passing a network interface may be impossible, given particular bandwidth requirements. IPv6 AH matches the space of the problem only in a part and adds to maintenance costs. An optional purpose-builtin authentication is often the optimal solution, which leaves the space for every other option.
>
> Second, it is better to keep packet structure pattern as uniform as possible. Considering efforts required to develop, audit and debug program code, switching from fixed-size structures to TLVs and back is notably more expensive, than working within one particular pattern. In the scope of Babel, this would mean that TLV-based authentication model would be better, than one using trailing data.
>
> Third, modern cryptography tends to replace established hash algorithms with those, which are not yet compromised, hence protocol authentication should allow for arbitrary hash functions and algorithms. This draft follows established best practice in doing this.
>
> Fourth, every protocol described above allows for at most one hash digest per protocol packet, although multiple keys may be available, and uses one hash algorithm from several available. There are key rollover methods defined, which address key selection problem. However, a single digest makes it impossible to perform a seamless change of a hash algorithm or authenticate within multiple administrative domains. This concern is addressed by this draft.
>
> An essential specification below is likely to include the right amount of key ideas required for the solution. Some of the ideas are borrowed from the RFCs mentioned above, but a few are original to this specification. An implementation of this spec would be completely transparent for all current Babel implementations. Transparency with future versions would only require permanently reserving two TLV types, which Juliusz can hopefully approve.
>
> I would be glad to have this draft eventually developed into a formal RFC. Talking about a proof of concept, I guess it's possible to add required functionality to Quagga babeld in a reasonable time.
>
> Changes in data structures
> ==========================
> 1. Three variables are added to the structure representing a Babel protocol.
> 1.1 PC (16-bit unsigned integer)
> 1.2 TS (32-bit unsigned integer)
> 1.3 MaxDigests (unsigned integer of an arbitrary size, which may remain "unset")
>
> 2. The structure representing a Babel neighbor is also extended with PC and TS variables of the same type and size.
>
> 3. The structure representing a Babel interface is extended to allow for a list of Security Associations (defined below).
>
> 4. Two additional TLVs are defined: Packet Counter/Timestamp (PC/TS) and HashDigest (HD).
>
> 4.1. PC/TS TLV
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |    Type = 11  |    Length     |        Packet Counter         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                           Timestamp                           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Fields :
>
>   Type            Set to 11 to indicate a PC/TS TLV.
>
>   Length          The length of the body, exclusive of the Type and
>                   Length fields.
>
>   Packet Counter  A 16-bit unsigned integer in network byte order.
>
>   Timestamp       A 32-bit unsigned integer in network byte order.
>
>
> 4.2. Hash Digest TLV
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |    Type = 12  |    Length     |             Key ID            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |       Digest...
>   +-+-+-+-+-+-+-+-+-+-+-+-
>
>   Fields :
>
>   Type            Set to 12 to indicate an HD TLV.
>
>   Length          The length of the body, exclusive of the Type and
>                   Length fields.
>
>   Key ID          A 16-bit unsigned integer in network byte order.
>
>   Digest          A variable-length sequence of octets, typically 20
>                   or more octets long.
>
>
> Semantics of PC/TS data structure
> =================================
> PC and TS are essentially two parts of a strictly increasing 48-bit unsigned integer number, which is typically referred to as "crypto sequence number" in several other specifications.
>
> This specification does not call it a "crypto sequence number" (to avoid confusion with Babel sequence numbers) and defines different handling for each part of PC/TS.
>
> The "Packet Counter" field is intended to hold the value of a counter, which belongs to the whole Babel protocol instance and is incremented with each protocol packet being sent. The counter will wrap (reset to 0) upon reaching maximum value.
>
> The "Timestamp" field is used as a PC wrap counter: when PC reaches the maximum value and wraps, TS is incremented.
>
> When TS reaches the maximum value, it wraps (resets to the "initial" value defined below).
>
> It is also possible for TS to be incremented before PC wraps, in this case PC must be set to 0.
>
> There are several ways possible to initialize and update TS, so that PC/TS number may have additional properties besides being strictly increasing.
>
> 1. The most basic approach is to assign TS := 0 on Babel protocol instance start and increment it only on PC wrap. PC/TS numbers would repeat after each protocol restart and induce a PC/TS quarantine period, if the neighboring routers have not aged the previous protocol instance out by the time new instance is started.
>
> 2. Use TS as a "wrap/boot counter" and store it in NVRAM each time it changes (see RFC6506 4.1). This would allow for unique PC/TS across router's deployed life.
>
> 3. Use UNIX timestamp as TS source. That is, if current UNIX timestamp is greater than current TS value, the latter must be set to the former and PC reset to 0. This also allows for lifetime-unique PC/TS number, but without NVRAM.
>
> All these approaches are compatible with this specification. Implementors of this specification and operators of the implementations are free to decide, which particular approach is used by which particular Babel router. There are some additional notes concerning use of UNIX timestamp.
>
> 3.1. Using UNIX timestamp as TS source is appropriate only if router's local clock is never adjusted backwards, otherwise each such adjustment will place the router into a PC/TS quarantine.
>
> 3.2. If a router is sending more than 64K Babel packets per second for a limited period of time, PC will wrap more often, than once per second, and TS will exceed UNIX timestamp. Once the packet rate drops, UNIX timestamp will eventually reach the value of then-current TS. Babel routers permanently sending more than 64K protocol packets per second will suffer periodic PC/TS quarantines. This is not viewed as a problem of practical significance.
>
> 3.3. A seamless switch from "basic" to "UNIX" TS approach is possible, but not the other way. This allows for a case, where a freshly deployed Babel router would use "basic" PC/TS approach until it has acquired necessary routes and completed initial network clock synchronization. Once this is done, it can be permanently reconfigured to use the "UNIX" approach without any interruption to Babel protocol exchange.
>
> Definitions of Security Associations
> ====================================
> An authentication key (AK) is defined as a secret data with associated ID (a 16-bit unsigned integer) and a set of lifetime attributes.
>
> Depending on the current date and time (which change), each AK may be distinguished as active or inactive according to its lifetime attributes (which do not change between configuration changes).
>
> A configured security association (CSA) is defined as an interface-specific unique combination of one particular hash algorithm (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512) and one set of 1 or more AKs.
>
> Key IDs must be unique within the scope of one given CSA.
>
> A Babel interface may have any number of CSAs (including 0) at operator's discretion.
>
> An effective security association (ESA) is a CSA with inactive AKs excluded, as evaluated against current date and time.
>
> A valid ESA can have 0 or more AKs.
>
> Changes in packet sending
> =========================
> If the current outgoing interface has no CSAs, the current packet is processed without any changes to the original sending process.
>
> Otherwise, the following steps are taken.
>
> 1. A PC/TS TLV is appended to the main packet body. PC and TS values are assigned as described above.
>
> 2. For each of the interface ESAs, for each AK of the current ESA an HD TLV is appended to the main packet body. This TLV must have "Length" field set to L+2, "Key ID" field set to ID of the current AK and "Digest" field (L bytes long) set to source address of the current packet, zero-padded to L bytes. Generation process may be stopped, if MaxDigests is set and number of HD TLVs reaches MaxDigests value.
>
> 3. The current packet (Pout) is then copied and the copy (Pout') set aside.
>
> 4. For each of the interface ESAs, for each AK of the current ESA (in the same very order as in step 2, and respectively for each of the HD TLVs generated) a HMAC procedure is performed, using Pout' as "m" input and AK as "Ko" input, with hash digest output written to "Digest" field of the current HD TLV of Pout (this way, "m" remains constant for every HMAC round, but "H" and "Ko" may change). If HD TLVs generation process was limited due to MaxDigests threshold, this process must also be terminated at the same threshold.
>
> 5. Pout' is discarded, Pout is treated as the current packet. Since this point, no more changes are allowed to the packet, which is now ready for remaining transmission procedures.
>
> Changes in packet reception
> ===========================
> If the current incoming interface has no CSAs, the current packet is processed without any changes to the original receiving process.
>
> Otherwise, the following steps are taken.
>
> 1. PC/TS TLV of the packet (PCr, TSr) is verified against stored PC and TS values of the Babel neighbor originating the packet (PCs, TSs). If TSr < TSs, the packet is discarded and processing stops. Otherwise, if TSr > TSs, processing proceeds to step 2. Otherwise, if PCr > PCs, processing proceeds to step 2. Otherwise the packet is discarded and processing stops.
>
> 2. A copy (Pin') of the current packet (Pin) is made and set aside.
>
> 3. For each of the HD TLVs present in Pin' the "Digest" field is set to source address of the current packet and zero-padded up to length of the current HD TLV.
>
> 4. For each of the HD TLVs present in Pin all ESAs are looked up, which have hash digest length = "Length" field of the current TLV minus 2 and an AK with ID = "Key ID" field. For each of the ESA-AK pairs found a HMAC procedure is performed with m = Pin', Ko = KA and H = hash function of the current ESA. If HMAC output matches the "Digest" field of the current TLV, processing proceeds to step 6.
>
> 5. Apparently, none of the HD TLVs matched any of the ESAs. Pin and Pin' are discarded and processing stops.
>
> 6. PC and TS value of the current Babel neighbor are updated to the PC and TS values of the current packet PC/TS TLV (PCs := PCr; TSs := TSr).
>
> 7. Pin' is discarded, Pin is accepted for remaining receiving procedures.
>
>
> --
>     Denis Ovsienko
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net