* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Opsec Status Pages

Operational Security Capabilities for IP Network Infrastructure (Active WG)
Ops Area: Benoit Claise, Warren Kumari | 2004-Oct-14 —  

IETF-99 opsec minutes

Session 2017-07-19 1330-1500: Berlin/Brussels - Audio stream - opsec chatroom


minutes-99-opsec-00 minutes

          OPSEC IETF-99 Notes
          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 things.
          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 publishing.
          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?

Generated from PyHt script /wg/opsec/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -