Minutes IETF117: opsec: Thu 22:30
minutes-117-opsec-202307272230-02

Introduction and Document Status, Chairs, 5 min.
ACTION: be kind to each other (CoC)

Implications of IPv6 Addressing on Security Operations,
draft-ietf-opsec-ipv6-addressing, Fernando Gont, 30 min
Jen: new issues verbatim, reference previous written issues
Jen: how is this really ipv6 specific?
Fernando: useful to provide context why issue exists, will only
reference existing documented issues
Jen (from chat): I think the draft refers to RFC9099 already
Tobias (from chat): I am not yet sure though, where it does so much more
than RFC9099, though
Jen: hosts may have multiple addresses -> that is acutally the common
case
Arnaud Taddei: in the EU there is the big DORA regulation which gives
the EU the capability to do pentesting using its TIBER-EU model, maybe
[Fernando] could look at that if that is "adding water to your mill"
Conclusion: Fernando continues to work on the draft.

Revisiting BGP Security Best Practices (BCP194 / RFC7454), Tobias
Fiebig, 10 min
Jen: does not really look like errata, but expecations of practices have
changed
Carlos: will contribute to the document
Conclusion: Tobias to submit a draft

On Network Path Validation, draft-liu-on-network-path-validation,
Chunchi Liu, 15 min
Gargi: slide 10 - the transit proof, the packet will go to the malicious
router, it is too late if you let the packet go into a malicious AS?
Chunchi: Needs some routing directive so it does not choose that route.
It will passively be interception as it is not going anywhere.
Gargi: Not let it exit the non-malicious AS, will bring that to the list

Will this have to be implemented in the fwd plane? what's the cost?
Chunchi: 1ms for computing proof, theoretically takes constant time
Jeffrey: You are assuming in node three on slide 10 that it is operating
normally in the system. What you cannot do, though, is to tell that
traffic has been diverted (MiM, for example). If node 3&4 are involved
in the hi-jacking that cannot be detected
Chunchi: Two solutions help: Transit proof & secure accumulator
If your goal is secrecy by hiding the traffic, that today is not
possible. The US has their flavor, there is flowspec. You cannot the
subversion of the path - but that is fine. If your core use case is that
you cannot subvert it, the use case might not be viable in principle
Chunchi: you must have some kind of why to at least have some way to
log/index the hops
Geoff: What you really need is strict source based routing, difficult to
stuff this into routers that you have no control of. Controlling the
behavior of every transmission element is "not the Internet" and does
not improve the security of BGP. And you are imposing a proof of
cooperating entities. In a certain scope that might work, but it will
not work in larger scope that are strictly private. Application have no
say in this kind of infrastructure. Application cannot tell the rest of
the infrastructure how to behave
Chunchi: might be a different paradigm.
Jen: put this discussion to the list & bring this to Path Aware Routing
RG
Tobias (as an individual): looks like security through obscurity, if you
can control your jurisdiction weaker crypto is assumed to be okay and
not leaking typically, but that never is true. Solving vendor "distrust
issues" on layer 3 does not seem to be a good idea? Maybe there are
better use cases?
Q: have you bench-marked the throughput
Chunchi: we are trying to work with the trusted hw folks
Rüdiger: are there really no fall-back routing where their packets
actually reach their destination? This would preclude failure of the
network compensation.