On Thu, Feb 2, 2012 at 10:15 AM, Stephen Kent <[email protected]> wrote: > I was not able to follow the proposal you outlined in your long message > about using hash values and nonces distributed via DNSSEC.
Okay, I'll make it short and sweet. All the information used for validating AS paths is stored in DNS with DNSSEC protection. The _only_ information is an _encoding_ of which AS neighbors A has, under a zone controlled by A exclusively. (This would be some kind of encoding of A->B, A->F, A->J, A-W. Who does A send routes to, in other words.) The basic model is out-of-band for validation, on the in-band data (AS_PATH). What is published is per-AS feasible-neighbor-AS information. It does not stop literal forging of AS paths or their signatures. It does, however, limit possible forgeries to actual feasible AS paths, and further limits discoverable path "hops" to those visible and in use. Combined with the origin validation, you get everything you need. (Contrast this with the risk of exposed on-router private keys, where literally _any_ AS-path could be forged via the AS of that router, off-axis.) > However, I would > agree with Ross's comment, i.e. any secret value used in the computation of > a hash chain is the moral equivalent of a private/secret key. Thus > compromise of that per-router secret also will have adverse consequences. I > also will note that non-repudiation is not the required security service in > this context. One needs broadcast authentication, a service offered by > digital signatures. The authentication is "broadcast" in that an AS does not > know all of the other ASes that will have to verify a sig (of whatever form) > on an update. The use of SHA and nonces is to minimize crypto weaknesses (encrypting the same content repeatedly with different keys), and to make significantly less trivial discovery of potential forward paths. SHA over nonce makes guessing futile. Publication of data is necessarily exposed for verification, but only actually used and visible paths can be enumerated this way. Nonce-changing further reduces the window of use or re-use of a given signature. It is not strictly necessary, IMHO, but is available. Exposure of a nonce does not create a security issue as such. At most it affords the ability for adversaries to learn of potential leak vectors. Suitable leak-prevention techniques make this a moot point. Nonce-rolling is a scalable counter-measure. Pre-hashed and pre-signed zone data could be staged for rapid roll of nonces. The DNSSEC zone(s) could easily include two nonces worth of data with no exposure or risk, in fact. The nonce, while used for generating keys for look-up into DNS, does not directly make possible modification to DNS data itself. NB: the nonce is not used for the DNSSEC keying at all. DNSSEC is the broadcast mechanism, and is not constrained by the limitation of "best path only" that in-band signatures suffers from. Now, for a worked example: Consider prefix A.B.C.D/E. Origin validation restricts it to being announcement by N. N has a DNSSEC zone with N->L and N->J (encoded with nonce and hashes). L has a DNSSEC zone with L->W and L->X. J has a DNSSEC zone with J->Y and J->L. X has a DNSSEC zone with X->Z and X->M. Consider AS "Z", peering with X. X is able to announce A.B.C.D/E with AS_PATH of "X L N" or "X L J N" only. Anything else will fail validation. Z will _only_ accept prefixes whose AS_PATH values match published AS-hops (per AS), and whose AS_PATH terminates/starts with matching values of the neighbor_as and origin_as. Contrast this to in-band signatures being used. If the key to a router in L were compromised, then literally any forged AS_PATH could be created. The only restrictions would be that the AS-path would need to be "X .* L N". When combined with leak counter-measures, OOB signatures are as strong as in-band signatures. OOB can consist of both signatures, and signalling. In-band signalling is implicit only, as "beaconing" demonstrates. (OOB signalling, for example, could be "notify" messages with TSIG or SIG protection.) Out-of-band signalling is not possible for in-band methods (without significant cost and possibly new protocol elements). OOB signalling makes possible rapid invalidation of removed neighbor relationships, and removes the need for beaconing. OOB permits pushing invalidation directly to every ASN and every router. Invalidation is crypto-protected (DNSSEC). OOB is not delayed by hop-by-hop validation and signing or other BGP mechanisms. The window for replay is much closer to zero, and achieves this at a reduced, rather than increased, operational performance impact. Of course, this is all _currently_ aimed at demonstrating that an alternative is possible, not to the evaluation of this specific instance of an alternative. It is meant to place the issue of key management risk on the table, as it were. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
