[NOTE: Much thanks to Fernando Gont for taking the minutes -- Warren ] [Warren opens the meeting. Note well, blue sheets] Administrivia ========================================== At the end of the official agenda there's time for additional items. [Warren] We have an updated charter, but this didn't receive much attention. [KK] Existing charter was from 2009 It needed some cosmetic changes. More emphasis on informational RFCs, and rearranged text. Proposed text has been placed in IESG review. This will be discussed in the IESG telechat on August 15. In addition to the updated text, milestones will be updated. ============================================= *** BGP security -- Presented by Gunter van de Velde Slides: http://www.ietf.org/proceedings/87/slides/slides-87-opsec-1.pdf Gunter notes that none of the authors present at the meeting, and goes through the slideware. Gunter describes that the I-D added some text about route flap dumping. What it says here is "don't". Joel: I think what it says is "look at RIPE 378 from 2006". In general it should really say "don't". There are cases in which you might to use it, but.. don't. [Gunter] The latest document from RIPE they have discovered that 0.01% of the Internet prefixes actually break the majority of your peering as such. What RIPE has done is putting some rout flap dumping in place which fixes that. I think there's a new document about this. Some vendors are putting this as being the standard for BGP. [Jeff Adams ?]: There's a draft around.. Randy's? The RIPE considerations are very useful. Problem is that in order to implement them you need to carry more state for more time for route flap dumping. The matrix space for most current implementations isn't big enough to accommodate that right now. People are having to change their implementations to allow long enough observation.-- if your goal for this document is BCP, then depending on how long it takes to publish, it might be inappropriate because people don't do it. (Gunter goes through the rest of the slideware) [???] With putting real time black-holing in the scope for this document. It's a common practice. It's part of people's operational security. RTBH seems like it might be a good fit. [Gunter] It's a very good technology. Not sure if it should be discussed in effect of having these peering recommendation policies in place. It should probably be picked up. I think it's documented in some RFC. [Joel] I think it is 6538. Had some comments I sent to the authors. This section on SIDR as it exists today is not that useful. It could be genuinely useful as we're getting to the point where we can say what you might do if you did. Facebook has managed to sign their prefixes -- if they can do it, you can do it. Whether you can use it operational use it for validation and reject things that don't validate is another question. It's time to start to talk about that. This document might be the right place to do that. RIRs provides examples that look like the behavior of a RIR if you're a large transit provider, but in my experience large transit providers already know how RIRs work. This is more useful for people constructing policies for leaf networks connected to their providers. Examples should be reversed. e.g. Examples of what it looks like if you're an edge network building RIR policy for your edge network. [Ron] The RPKI validation has an operational document. You just need a pointer. [Warren] We'd like some folk that might be willing to provide feedback on this document (Ron already did). ====================================== (KK presenting ipv6-security) Slides: http://www.ietf.org/proceedings/87/slides/slides-87-opsec-3.pdf Notes that they received lots of good feedback since the Orlando meeting. (goes through slideware) [Alissa Cooper] Last week we published RFC 6973 "privacy considerations for internet protocols". Might be worth looking at. In the logging section you might want to comment for how long to keep the logs, preventing unauthorized access. In 6man we will be having a discussion about the security/privacy aspects of IPv6 addresses that might be of interest to this I-D. Warren asks how many folks read the last version of this ID, and asks for volunteers to read the I-D and send comments. ========================================== (Fernando presents nd-security) Slides: http://www.ietf.org/proceedings/87/slides/slides-87-opsec-2.pdf (goes through his slideware) Fernando notes that there was some discussion about removing stuff that is already covered in RFC 3756. He notes that he believes that some valuable information would be lost if we did that. Also, information would become fragmented and spread among different documents. In any case, as discussed with the chairs, this is something that could be discussed later on. [Gunter] Are you socializing this document with other operation wgs such as v6ops? [Fernando] I don't think I've posted a heads up about this document in other wgs. Actually, I just posted a reference to this document as part of a discussion about other document -- but not in a brad-new thread. [Warren] One advantage of posting would be getting more reviews. Warren asks how many folks read the document, and asks how many additional folks might be willing to read. He asks (from the folks that read it) how many think the document is worth adopting as a wg item. (similar number to the folks that read the document). This will be taken to the wg. [?? 32:38] It's a valuable document, and agree that it's better to have all this in a single document. (Warren closes the meeting)