Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

["John G. Scudder" <[e-mail]>]

Hi Stephen,

I'm doing a final update of the draft to cover comments in IE SG review. I'd like to discuss yours a bit.

On Mar 10, 2015, at 10:12 AM, Stephen Farrell <[e-mail]> wrote:

> - There is a perhaps missing security consideration. I think
> this kind of protocol behaviour argues that any kind of
> BGPSEC encryption needs to use an AEAD ciphersuite.  (Which
> we'd likely do these days anyway, so that's not a biggie.)
> The reason is if say CBC or a stream cipher were used, then
> an attacker could play with ciphertext is various ways that
> might interact with this error handling behaviour so as to
> expose information that is intended to be protected by the
> BGPSEC mechanism. Such an attack would probably be
> pooh-poohed by all but tin foil hat folks, but it could
> still be worth noting (maybe in section 8?) and as we've
> seen recently, many of the tin foil hat fears turn out to be
> realistic, sadly.

Since you balloted "no objection", would I be right to think you won't have a cow if we don't make this change? I confess to not knowing the difference between AEAD and a hole in the ground nor do I understand the attack you allude to, so at the least I would have to find someone to either educate me or write the text for me. So far we haven't considered confidentiality to be important for BGP security -- although you reference encryption in connection with BGPSEC, BGPSEC is actually entirely about integrity and authenticity and specifically disclaims confidentiality, see draft-ietf-sidr-bgpsec-threats-09.

If you feel strongly about having this covered, I'd appreciate if you pointed me at someone who could help with education and/or specific text.

> I noted a few nitty nits:
> 
> - section 2: AFI/SAFI are used without expansion

Will fix.

> - 3.d: "well-known mandatory attributes" sort of yells for a
> reference, doesn't it.

At first I was going to agree with you, but then I reminded myself that the entirety of section 3 is a set of amendments to RFC 4271, Section 6.3, and says so in its first paragraph. As such, one might think the reference in the first paragraph ought to be sufficient. I'm not dead set against the extra reference if you feel strongly, but it does seem redundant so for now I'm not adding it.

> - 3.e: "cases that specify" - specify where? I think you
> mean in the updated RFCs but it might be nice to say that

Actually we mean the cases enumerated in RFC 4271 Section 6.3, again as indicated in the first paragraph. I do think this would be clear to someone who had reviewed that reference (which I don't fault you for not having done) so again, I'm going to refrain from repeating the reference here unless you want to make a further case for it.

> - 5: NRLI is expanded after 1st use

Okay.

Thanks for the comments,

– John