Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg <[e-mail]>]

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/