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

[Michael Baer <[e-mail]>]

I do not have any objection to the resolutions below, but I did notice
something else while looking at the NLRI processing for BGPsec.  For
prefixes that do not end on octet boundary, the value of the trailing
bits between the end of the prefix and the octet boundary are undefined.
Both RFC 4271 p20 and the multiprotocol RFC 4760 p7 use the same
language,

 "Note that the value of trailing bits is irrelevant."

I was unable to find text in another RFC or within the protocol draft
that explicitly sets these bits.  If any of those bits get changed from
what the originator signed, the signature will be invalid even though
the NLRI is otherwise valid according to the RFCs.  Practically
speaking, these bits likely get set to zero by most (all?) routers
anyway.  But it would probably be good to have text in the protocol
document explicitly setting them when creating signatures. Something
like,

"Any trailing bits in the NLRI prefix between the prefix length and the
next octet boundary are set to zero when calculating the signatures."

-Mike


>>>>> On Tue, 24 Feb 2015 12:38:07 -0500, Matthew Lepinski <[e-mail]> said:

    ML> I am in the process of resolving issues in the bgpsec-protocol document in
    ML> order to get out a new version before Dallas.

    ML> Based on the discussion in this thread, I believe the best way forward is:
    ML> 1) Add a small amount of security considerations text to address the
    ML> original concern that David raised. (I believe the consensus is that this
    ML> concern cannot be converted into an actual attack. However, other readers
    ML> might reasonably have the same concern as David and so there is no harm
    ML> laying the concern to rest in security considerations.)

    ML> 2) Given that origin validation is now decoupled from path validation, we
    ML> will put the AFI under the BGPsec signature to avoid potential IPv4 vs IPv6
    ML> issues.

    ML> Any objections to this resolution of these issues?

    ML> - Matt Lepinski

    ML> On Tue, Feb 17, 2015 at 6:40 PM, David Mandelberg <[e-mail]>
    ML> wrote:

    >> 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/
    >> 
    >> 
    >> _______________________________________________
    >> sidr mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/sidr
    >> 
    >> 

    ML> _______________________________________________
    ML> sidr mailing list
    ML> [e-mail]
    ML> https://www.ietf.org/mailman/listinfo/sidr

-- 
Michael Baer
[e-mail]
Senior Software Engineer
Parsons Global Shared Services, Cyber Security Division
C: 530.902.3131