On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: > I agree that the solution should not merely rely on the presence of a > validating ROA. > But there is some more detail here that is worth looking into. The path was > fully signed > and assume all signatures are valid. Then clearly the origin AS actually > announced it. > The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4) or > 102::/16 (v6)? > The ROA has AFI information, but the signed update does not (currently). > https://tools.ietf.org/html/rfc6482#section-3.3 > “Within the ROAIPAddressFamily structure, addressFamily contains the > Address Family Identifier (AFI) of an IP address family. This > specification only supports IPv4 and IPv6. Therefore, addressFamily > MUST be either 0001 or 0002.” > > Hence, as Keyur has surmised, there is a possibility that the ROA can help > resolve the ambiguity here. > But the ambiguity would still persist if the same origin AS happens to have > ROA(s) for > both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the probability is > extremely small). > So, yes, a robust solution calls for something more than a validating ROA. > The ambiguity goes away if the AFI (of the announced prefix) is included by > the origin AS > on the wire as well as in the sequence of octets that are signed.
When there's no attack, I don't think there's any ambiguity about what NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs in the right places on the wire. The only change that I think needs to happen for this issue is including (S)AFIs in the data that's signed. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
