I think David is right. This is embarrassing. I was looking at the syntax for the protocol in response to David's previous message, realizing that there's no text about what the NLRI length and NLRI prefix fields' syntax should be, looking right at those fields, thinking only that we needed to copy the text from 4271/4760, and did not spot this.
This is embarrassing for the whole wg for not spotting the syntax laxness. And embarrassing to all the security folk. There's a standard problem in security protocols about not signing any old group of bits you are given because the signed bits might be used in some other context. So this should have been spotted much earlier. I keep hoping if I look at it closely there's a reason why this is not a problem. Surely SteveK/MattL/SteveB/RussH/etc if the problem were this obvious? Have you two looked at this? --Sandy On Feb 10, 2015, at 4:48 PM, David Mandelberg <[email protected]> wrote: > All, while coming up with the example below, I realized another issue. > The structure in 4.1 doesn't include an Address Family Identifier. > Unless I missed something, this means that a signature for 1.2.0.0/16 > would be exactly the same as a signature for 102::/16. This would be a > much more practical attack than the one I originally though of. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
