Last Modified: 2003-05-02
Jun 03 | Submit Problem Statement Internet Draft | |
Jun 03 | Submit References Internet Draft | |
Jul 03 | Submit Filtering/Aggregation Methods Internet Draft | |
Aug 03 | Submit Methods of Controlling Policy Internet Draft | |
Sep 03 | Submit Effects of BGP Signaling Techniques Internet Draft | |
Oct 03 | Submit Operational Aspects of Routing Security Draft |
GROW WG Vijay is not present in the room Dave present Agenda bashing Dmitri volunteers to take notes ---------- Longest match draft David Meyer: Has anyone read it? Any comments? Very little response on the mailing list, comment now. Geoff Huston: This method seems to be a pretty major hack. Cannot see it universally deployed on a flag day, there is not a lot of attraction to this solution. Would want something more explicit rather than implicit. Best way to control prefix distribution is to have some explicit method. Generally it's a nice piece of work but not sure of applicability. David Meyer: Authors of the draft have been rather silent, what do others think? Geoff Huston: Pretty much yes Dave Meyer: Mature draft. Any comments? Is GROW taking all IDR work items now? Dave Meyer: Should this document go to informational? Scott Bradner: Don't take now, lack of opposition does not indicate no support. Dave Meyer: We need more consensus Scott Bradner: This is a generic problem, passiveness of a WG. Dave Meyer: [missed that] Yakov Rekhter: Do you gave any operational experience with this draft? Dave Meyer: No. Yakov Rekhter: So don't progress this document now. Randy Bush with AD hat on: No need of having code for experimental. Dave Meyer: Should be individual submission then. Geoff Huston: I would support that. Randy Bush When author resubmits, it comes to IESG, we would know from wg whether we should take it with care. Dave Meyer: Ok, enough for now. ---------- Dave Meyer: Next item - BGP TTL. Why not to use it generally, first for MSDP. Generalize it and make TTL draft. What feedback is on TTL usage based verifications? Geoff Huston: There's element of topology in this, in generalized way setting TTL may not be so good for other non-topology related usages. Dave Meyer: This is for multi-hop scenarios mainly Dave Ward: It's simple, it works, is implemented in number of protocols already, almost no effort, Non adjacent peers' support should be optional. Dave Meyer: Any multi-hop scenario should be made optional. Scott Bradner: Why not just to remove multi-hop support? TTL of 255 is particularly dangerous. Scott Bradner: ADs are always right. Dave Meyer: No comment on that. Dave Meyer: Yes What do you want to see happening after IETF? Geoff Huston: Isn't this recycled from PTOMAINE? Dave Meyer: Yes Geoff Huston: It is trying to explicitly nominate all the walls beyond that the prefix cannot cross If you get it wrong it will leak out. It is lots of effort to enumerate 90 % of a wall. Need to specify some characteristic that stops propagation. Route filtering in general could be unsafe. Dave Meyer: Please hum on support of this draft. Don't like. WG does not seem to have investment into those 3 drafts. Any comments? ---------- Bidirectional Forwarding Detection draft. Dave Ward presents. Dead rat on slide, laughter in a room. The problem - fast forwarding plane inactivity detection. Fast hellos problem - the faster you hello, the higher the load. Need specific protocol implementations. Unidirectional links are tricky. Some history - PLP, protocol hello mechanism. TLV structure is processing expensive. Kireeti has abandoned PLP, works on BFD now. MARP, for L2 switching space. BFD is low overhead, not only for link test, tests next hops in a forwarding plane. BFD runs on any data protocol, IPv4, IPv6, L2. Unicast point to point. Timer parameter change should not reset sessions - learned from ISIS and OSPF. Separate sessions for data and control links. No TLVs. Some small changes will make into -01 version. Any questions? Dave Meyer: A few questions: How hard it is to guess the discriminator and spoof it? Dave Ward: No encryption support. One can read the packet, decompose and lookup. Spoofing is possible Dave meyer: How is discriminator formed? Dave Ward: Any numeric value. David Meyer: Details? Dave Ward: Just pick any method. When someone sends you something that makes you think it is down, it is worse than TCP spoof. Dave Ward: TTL hack draft is the solution. What for not directly connected? Dave Ward: Someone jams the link between peers, I don't see the packet and assume you are down. This solution can handle transient conditions. David Meyer: What do you see happening to this draft? Dave Ward: Individual informational? Individual standard? Relocate for some other WG? David Meyer: The reason for asking is security aspects. Anyone from IESG has something to say on security? Dave Ward: Any hello based protocol can be taken down. David Meyer: Ok. Stewart Bryant: In echo mode, what happens when you get what you do not expect? Dave Ward: Could be encrypted? Alex Zinin: Regarding security, solution should have usable security mechanism. [Question: what if echo mode does not work?] Dave Ward: For nonadjacent peers TTL is unspecified. Between directly adjacent peers you send from yourself to yourself. Only spoof seems like some sending you more packets than you receive, implementation should detect receiving more packets than sending. Detection time is short. Alex Zinin: If someone is spoofing, should you check TTL value for echo mode? Dave Ward: If the source and destination are spoofed, should we drop the packet? Seems like yes. Randy Bush: Security is important. If it is on a wire how it is that different? Dave Ward: I could barely understand your question. Randy Bush: Lets take offline. If it is multi-hop, 10msecs is hardly achievable - multiple gigabit interfaces feeding into one peer. Secure multi-hop failure detection does not fit into tens of milliseconds. Dave Ward: Yes. Stewart Bryant: You have 80 msecs of packets in a pipe, you can't do much more. [you send a packet from Vienna, and a stream after] Yakov Rekhter: Worst case scenario is when you have 80 msec RTT and fiber cut in a middle. 40msecs is a speed of light, no draft would make that faster. David Meyer: What do you want further? Dave Ward: Going to individual submission. Randy Bush: It makes no difference which WG individual submission goes. ---------- Pedro Marques: Distributed Traffic Filtering Explore a mechanism to distribute traffic filtering rules through a network. DDos resistance. Manual configuration. Community based traffic attraction to a sink. Manual drop. Filtering granularity - ideally /32. Routing information and filtering information interdependence. Need diagnostic capabilities, not always available when just dropping. Inter-provider issues make things more complex. Bits and encoding are easy, operational model is interesting. Example of a customer advertising /24 Filter advertisement: dst=prefix, src=*, port=80 Filter accepted because matches routing best path Dave Ward: Transferring bits is easy because of using BGP? Pedro Marques: BGP is used for database transfer. Dave Ward: If we pass this thing via BGP, you can pass routes that are considered not a feasible route. Use a separate attribute to avoid decision process. Pedro Marques: Reason for BGP is a long administrative relationship between SPs. It is based on BGP. By using BGP we try to fit into that existing operational model. The second part is that it is different address family, different database, it has the same route selection rules as far as BGP is concerned but when you install them in LocRIB, those routes have different semantics. It is the same as unicast routing, not sure whether you understand. David Meyer: Work items for GROW WG - I wanted to talk later, but now it is good opportunity. One of work item questions is using BGP as a universal transport. Pedro Marques: We have been doing this for 5 years - RFC2547. David Meyer: It would be good to know what effect happens while continuing to load BGP with separate features? Pedro Marques: Let's talk on operational issues first. Dave Ward: We can craft BGP UTP (Universal Transport Protocol). Pedro Marques: It is implicit. You can only accept filter if your routing accepts the route. [someone] You cannot accept a filter if you have no route, is that correct? Pedro Marques: Yes. [someone] If you receive more specific, would it match? Pedro Marques: Yes, it is best match, if it is a subset of a destination. Ron Bonica: I think it is a useful mechanism. One comment - I would spend a lot of time before deployment thinking about possible security threats. Alex Zinin: Usefulness discussion may be distracted by BGP UTP. Do you have plans to take this work to IDR WG? Pedro Marques: Draft has -idr- in name. If people are interested, I would take it to IDR WG. Alex Zinin: Two parts of question: 1. Whether it is a good idea to signal filters? 2. Doing question 1 over BGP? Let's take second question to RTG meeting. Pedro Marques: [Comments on operational model.] Alex Zinin: [ no ] Randy Bush: I am not here to discuss BGP as a car wash protocol. Push back deals with routers that don't speak BGP, need to affect flows on that routers. Filtering is needed not only on a route level, port, etc. Need separate protocol for passing filters. David Meyer: take this to mailing list. Enke Chen: 1. Route reflector and confederation role in this scheme? 2. Customer uses BGP in an example, but most real customers don't. How about that case, impacts, etc? Pedro Marques: 1. RR and confederations work fine - the same model as for unicast. 2. Your NOC can configure this on BGP speaking router that has customer routes. No need to have this mechanism on a direct customer link. Enke Chen: 1. BGP is complex but scales well. [someone from mci] Typically customers are routed statically. [have no default] [slammer example] Pedro Marques: Just to clarify - routes originated from inside don't get validated. Pedro Marques: Let's take this offline. Felix Wu: To make this mechanism useful someone must do good analysis of what to block. Attacks may morph, need to modify flow specifications accordingly. Pedro Marques: That is a valid point. Not many flows are on attack on any single time. David Meyer: We are coming to the end of agenda. Let's take further discussions to mailing list. ---------- Meeting |