On 8/27/2019 6:53 PM, Stephen Farrell wrote:
Hiya,
On 27/08/2019 23:41, Adrian Farrel wrote:
You had me at the mention of beer.
That's a deal then:-)
Actually, that would be a useful conversation both in a PCE context
and in a wider SDN context. (Always said that the SDN architecture
was missing a bit of security work).
I'd also love us to have some clarity about TCP-AO. It's like we were
all told we must use TCP-AO in our protocol specifications as the
silver bullet, and now the shiny outer layer has tarnished a bit. But
that is worthy of a separate thread.
Yeah. TCP-AO is a fine thing and would've solved some problems
had it been deployed but I guess reality chose otherwise and it
has now been 9 years so maybe it's time to call that one.
I'm wondering if that's more a question of education of the end user
rather than the availability of an implementation. I got curious and
googled TCP-AO implementations and got
https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/security/b-ncs5500-system-security-cli-reference/b-ncs5500-system-security-cli-reference_chapter_010.html#wp2845038086
and
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-authentication.html
so at least for BGP there appears to be actual shipping code that
includes TCP-AO as one of its security pillars.
(Note - I'm just scanning over the above pages and didn't actually
confirm TCP-AO support, but the wording does seem to imply that)
Later, Mike
But I
guess that's a question that the esteemed routing and sec ADs
can figure out. I think the main downside of text such as is in
this draft is that some RFC readers may waste effort on it for
no benefit so it seems a bit of a disservice for us to keep on
pretending. OTOH, maybe all the relevant implementers already
know to ignore it already. (Or ignore all crypto stuff all the
time;-)
BTW - I'd still love to know if TLS is as fictional as TCP-AO
for PCEP:-)
Cheers,
S.
Best, Adrian
-----Original Message----- From: Stephen Farrell via Datatracker
<noreply@xxxxxxxx> Sent: 27 August 2019 23:32 To: secdir@xxxxxxxx Cc:
pce@xxxxxxxx; ietf@xxxxxxxx;
draft-ietf-pce-stateful-hpce.all@xxxxxxxx Subject: Secdir last call
review of draft-ietf-pce-stateful-hpce-11
Reviewer: Stephen Farrell Review result: Has Nits
Hiya,
This draft doesn't define new protocol but rather describes a way to
use existing PCE stuff in what I guess is a new way.
The nit I see is the usual, presumably fictional, reference to
TCP-AO. I mean, if nobody actually does that, why bother? Esp. if
you have a TLS option that's (I hope) less fictional. (Is TLS less
fictional for PCEP btw?) OTOH, I guess that nearly everyone now knows
that referring to TCP-AO is just a figleaf to try keep security nerds
happy, so maybe it's ok that we all suspend disbelief;-(
Other than that, I did have two questions that occurred to me, but
that are by no means a reason to hold up this draft - if answers
required some action, it'd almost certainly not be something that'd
be fixed here. But I'm still curious:-)
1. Has anyone spent any significant amount of time/effort attempting
to attack an H-PCE network as a PCEP speaker? (And written that
up:-) It looks to me like there're enough moving parts here that any
real stateful hierarchical PCE network could be fairly likely to
have interestingly exploitable problems in the face of such an
attacker.
2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the
ability to e.g. use different SubjectAltNames in x.509 certificates
might create the potential for some kind of deliberate or accidental
loops to be created somewhere.
Again, there's no reason to hold this up to try answer (or even to
understand) those questions. I'd be happy to chat over a beer with
someone at IETF106 about 'em as that might be easier than a bunch of
mail.
Cheers, S.
