Skip to main content

Minutes IETF99: opsec

Meeting Minutes Operational Security Capabilities for IP Network Infrastructure (opsec) WG
Date and time 2017-07-19 11:30
Title Minutes IETF99: opsec
State Active
Other versions plain text
Last updated 2017-08-09


Chris Morrow is the jabber scribe.

Eric Vyncke (Ron Bonica & Fernando Gont based on recording) is the minute taker.

Gunter opens the WG meeting with the usual bluesheets and other administrative

WG Documents Status

draft-ietf-opsec-ipv6-eh-filtering-03 has only received 5 emails since March
2015 and the -00.


Fernando presents quicky his I-D: it is critical to improve the state of
affairs with respect to the 'widespread' drops of packets with EHs. Open
question about whether to refer to RFC 2460 or to RFC 8200. Ron Bonica, as
co-author, the main difference is hop-by-hop that is no more required to be
inspected in all cases. Warren Kumari: before WGLC should send it to 6MAN. A
dozen of people have read the draft. Chairs: not a lot of discussions on email,
so, let's do a WGLC and have extensive review on the list.

Merike has no slide. I-D started in 2012... Authors had received a lot of good
comments representing more than 10 hours of work to incorporate them (specially
about ULA & NAT66). Fernando Gont: was there anything controversial? Merike
only about the text not really about the content. Nathalie Trenaman: thank you
for the document which has helped RIPE writing their IPv6 security training.

IPv6 Security
Presenting a documented previously presented at an academic conference.
Potential issue coming with the EU privacy policy of May 2018 considering IP
address as personal data. Merike Kaeo: thank you for the work.


Already presented at IETF-97 in GROW WG. The idea is to create a set of
prefixes per AS (received possible over different eBGP sessions) and use this
set to apply uRPF on all interfaces where those BGP information were received.

Warren Kumari: how much extra work is it? just like another VRF?

Eric Meuler: ok, but this is pushing customer protection to other transit
provider (so losing controls).

Igor Gashinsky: does not work for CDN (doing anycast)? A lot of traffic
engineering also do NO_EXPORT from specific to specific. Another blocking is
about default route received from  one peer together with more specific (=> the
specific ones are removed).

Jeff Haas: due to many open questions, this will be implemented any time soon.

Job Snijder: let's start with something kind, good to see the 'benefit of the
doubt' in an area where black and white does not apply. NO_EXPORT + traffic
engineering can jeopardize the technique. Overclaiming prefixes from an
isolated AS from all prefixes from the same AS.

Warren Kumari: suggesting a work-around for Igor's special case. Igo but I do
not want to advertise my relationship with some ASN (for confidentiality which
is also an issue for this approach).

Merike Kaeo: where it will work and what it will break will be critical when


How can a device at the edge prevent generating spoofed ICMP message (attacks
against packet too big but also for reset). The idea is to apply BCP38 on the
original packet included in the ICMP payload.

Warren Kumari: do we have existing implementation, Eric Vyncke: yes in firewalls

Document adoption by the WG will be done on the list.


Doing NFV prevents auditing of the traffic previously done by inspecting the
physical cabling. A crypto proof is required. One approach is Shamir's Secret
Sharing implemented very easily notably in open source VPP. Issue with SSS,
there is no proof of the order of traversal. A second technique, is 'onion
crypto' (step by step encryption with different keys per node). Much more heavy
on crypto to verify and mark packet but we have more and more crypto chips on
line card.

There have been a couple of security reviews but the authors would love to get
more reviews by OPSEC.

Jeff Haas: this is what AH IPsec is for

Warren Kumari: can we accept that the payload has been compromised

Chris Morrow/Warren Kumari: can we also do by chaining AH/ESP ?

Jean-Michel Combe: the origin node should also be able to verify the path?