OSPF WG Minutes, IETF 79 ===================== WG chairs: Acee Lindem & Abhay Roy Working Group status - Acee Lindem Slides: http://www.ietf.org/proceedings/79/slides/ospf-0.ppt - One RFC published since the last IETF. - Two active drafts: OSPF Multi-instance, and OSPF Transport Instance for using OSPF applications other than routing. No implementations are known, but since they aren't so complex they will possibly advance them ahead of implementations. A lot of people are interested in them. Routing for IPv4-Embedded IPv6 Packets - http://www.ietf.org/id/draft-cheng-ospf-ipv4-embedded-ipv6-routing-00 - Dean Cheng Slides: http://www.ietf.org/proceedings/79/slides/ospf-1.ppt Acee: I think this belongs in the BEHAVE WG, but good to have it presented here. The stuff from BEHAVE is already happening, I'm not suggesting any change. Just putting the pieces together and making this Informational. We'll discuss this. As a WG member I wouldn't mind if this is in our WG. Phased OSPF Link-State Database Synchronization - http://www.ietf.org/id/draft-dimitri-ospf-phased-db-sync-00.txt - Dimitri Papadimitriou Slides: http://www.ietf.org/proceedings/79/slides/ospf-5.ppt Abhay: Who's read the draft? (Several hands raised.) Questions? Alvaro Retano: This can still be done in 2 steps, its just how you describe the database. You define 2 types of state: normal routing and then other state that is distributed. First describe the DB as only routing info, and then a sync of other stuff using out-of-band database exchange. Dimitri: Yes. You can start to have stages of synchonization between databases. Manav Bhatia: Objective of this draft is different. Motivation is to prioritize the routing info that is exchanged when the routers form an adjacency. The objective of RFC 4811 is different. If you have a high number of non-routing links, then this is helpful. Abhay: Alvaro is saying you can use the exact same mechansim, anything you don't want can be sent in a later phase. Manav: OK Acee (as WG member): I think this draft focuses on one component of separation of routing and non-routing information, and I see a lot of complexity. For example, you said that every place we check for full you check for full as in RFC 2328. But there is one case in reliable flooding you have to check whether any router is in exchange state for handling MAXAGE LSAs. I don't see that adding this extra phase is to give you enough benefit for the pain. Andrew: Don't forget why did the other RFCs. We did have concerns of adding applications in OSPF and how it would impact routing. We need some way of splitting up the information. That's one of the solutions. We can argue the best tool, but we definitely need to solve the problem to make sure routing convergence is not impacted. This use case would not apply, but we neeed to go through them one by one. Abhay (as WG member): You're making an assumption that OPAQUE is not used for routing info, and we might do that in the future. Have you considered OSPFv3? Dimitri: Those might be next steps. Yi Yang: You ask for LSAs and they come from other side. The remote side will decide which LSAs to send. It's the requester's responsibility to decide which LSAs to ask for first. Dimitri: You ask for some, and then ask for others? Yi: When one guy receives the request of description packets, it will ask which ones for routing and which for opaque. It's the requester's job to decide. Abhay: Running short of time, take other questions to the list. Acee: This is offered as an alternative to putting the non-routing info in seperate instances. That's the frame by which we will discuss it on the list. Everyone agrees that we want to protect convergence of base IP routing if we put other stuff in OSPF. OSPF Hybrid Broadcast and P2MP Interface Type - http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt - Jeff Zhang Slides: http://www.ietf.org/proceedings/79/slides/ospf-9.ppt Abhay: How many people have read the draft? (Not many hands) OK, need more review. Acee: Reasonable problem to solve, need to decide whether its a big enough problem to solve to make it a Proposed Standard. Situations are shown on first slide after title. If people are running into this then everyone should do it the same way and it should be standardize. Discuss on the list. OSPFv3 Stub Router Advertisement - http://www.ietf.org/id/draft-shishio-ospf-ospfv3-stub-01.txt - Shishio Tsuchiya Slides: http://www.ietf.org/proceedings/79/slides/ospf-2.pptx Acee: I think this is kind of like a low hanging fruit, that we should have this standardized. We've actually implemented the compatibility mode for OSPFv3, it's well known. The question is we have RFC 3537 and he's asking if this should be seperate or combined with that one re-spun. At the same time, we have another draft (the router bit for v2) that is not being presented at this IETF. Because of that. maybe we want to keep this seperate for now. We can take that to the list as well. How many people read this one? (Not too many) Of the drafts presented to day, this one is easier to judge but we'll discuss it on the mailing list Abhay: To answer the last qustion on your slide, RFC 3137 didn't introduce any compatibility issues so it doesn't make sense for that to be a proposed standard. CCAMP about OSPF-TE extensions for WDM networks - http://www.ietf.org/draft-peloso-ccamp-wson-ospf-oeo-02.txt - Giovanni Martinelli Slides: http://www.ietf.org/proceedings/79/slides/ospf-3.ppt Acee: This is Giovanni doing the presentation, and he's going to give an overview of WSON and CCAMP. I think there's 5-6 presentations in the CCAMP meeting this afternoon. Giovanni: Actually, this is just one of the drafts! Acee: You're not adding anything to the TE node address, you're adding it as a new top level TLV - Right? Giovanni: In the connectivity map, other proposals are on the table to extend it in other ways. Lou Berger (CCAMP co-chair): We have quite a bit of activity related to the information sent in OSPF, general encoding, specific encoding, both node and link. Quite a bit of info, and we really appreciate additional review from members of this WG ... Please take a look and give us feedback. Lots of info that needs to be carried and that also translates into a lot of bytes. Hiding Transit-only Networks in OSPF - http://www.ietf.org/draft-yang-ospf-hiding-00.txt - Yi Yang Slides: http://www.ietf.org/proceedings/79/slides/ospf-4.pptx Acee: How many people read the document? (A few) How many people think it's a good requirement? (A few) Same people who read it liked it, sounds reasonable. Does have some protocol implications. Backward compatibility is that you let it happen and you just install a host route, right? Yi: Yes, at the end. Because we use a specific subnet mask, we want a every router in the area to ignore it, but worst case is you get a host route. If some routers on the path have been upgraded, they won't install the host route. Gentleman from France Telecom: The purpose of your draft is for routing scalability? Yi: Infrafrustructure protection. Same Gentleman: If you're pinging the interface then what? Acee: You wouldn't want to hide it. Acee: Discuss on the list whether this is a problem and whether to address it. It seems for a point to point link you'd make it an unnumbered link but there's the other two cases. Alvero Retano: There's a lot of ICMP extensions, so you can ping unnumbered or other interafaces. Robert Raszuk: How does this work, interaction with LDP? Yi: No Albert Tian: If LDP is used to carry mostly loopback, I don't see any problem. Supporting Authentication Trailer for OSPFv3 - http://www.ietf.org/draft-bhatia-manral-auth-trailer-ospfv3-01 - Manav Bhatia Slides: http://www.ietf.org/proceedings/79/slides/ospf-6.ppt Acee: One disadvantage of this proposal is that this is might put some people in the Secuirty Area who make their living warning of the dangers of OSPFv3 replay protection out of work. :^) Richard Graveman: How do you solve the replay problem better than IPsec? Acee: Like in OSPFv2. As part of OSPFv2, you're carrying the sequence number. Richard: OK, when the bound gets exceeded? Acee: Should never happen. Richard: But IPsec has a 4 byte counter too. With manual keys you should never exceed the limit. The problem you think you're solving is a phantom problem. Manav: No protection against replays ... you violate RFC 4301. Richard: So turn on IKE and the replay counter. Brian Weis: Discussing repay protection is a red herring ... This draft just adds an integrity tag. Whether or not there is replay protection, or how good it is, is a different discussion. Brian; It would be a lot cleaner to describe the cryptography by pointing to the FIPS 198 document rather than re-writing the algorithm. There's a risk of getting it wrong, and it's hard to evaluate. The only addition is "apad", which is just a value placed in the packet before you do the HMAC. Acee: How many read the draft? (Only 3 or so hands). OK, take the discussion to the list. Mechanism to protect OSPFv2 authentication from IP Layer Issues - http://www.ietf.org/draft-bhatia-karp-ospf-ip-layer-protection-00.txt - Manav Bhatia Slides: http://www.ietf.org/proceedings/79/slides/ospf-7.ppt Acee: The rumors of OSPFv2 vulnerabilities are greatly exaggerated. Brian: When using a group key and anti-replay, it's indeed important to include the source address in the authentication data, but I'm not sure if thi is the right way to do it. Brian: Why the existing particular "apad" value important, I notice it's the same in all the routing protocols? Tony Li: NIST said this was the set of random bits that needs to be used, They didn't say why. Richard: They said it should match other uses, and wouldn't approve it otherwise. Acee: Why not use a new authentication type, and include a new pseudo header (containing the source address) in the digest calculation? Manav: I thought of it, but couldn't think of anything other than source address that should be included. Manav: Is this something to solve? Richard: Use ESP and a VPN tunnel to protect the address. Manav: You don't get IPsec for free in some platforms, and in some cases IPsec is not an viable. Richard: The people I was talking to were RSVP-TE, not OSPF to route IP as in CCAMP. Manav: I'm not aware of this environment. Richard: I'm just saying to look at the CCAMP stuff. They already have IPsec between these endpoints. In another world, there's already an IPsec tunnel between these devices. Manav: But there's a lot of other worlds. Stronger, Automatic Integrity Checks for OSPF Packets Mechanism to protect OSPFv2 authentication from IP Layer Issues - http://www.ietf.org/draft-jakma-ospf-integrity-00.txt - Manav Bhatia Slides: http://www.ietf.org/proceedings/79/slides/ospf-8.ppt Brian: Just to clarifiy, this is when you don't want to use cryptographic authentication? You mentioned that sometimes crypto processing is too expensive for these devices. Manav: Right, if using crypto you don't need this. Brian: So why define an MD5 type, you might as well do authentication if you're going to do that much processing. Abhay: Why not define another authentication tag instead? Manav: That mechanism is already overloaded, and this is backward compatible with that. If it's NULL authentication, you can use this checksum. This isn't authentication really, it's just a checksum. Acee: I don't like that this is happening by default. I don't think it's that great a problem. It should be an option, a new NULL authentication checksum type in the field. Backwards compatibility is an important issue, it should't be an automatic change in behavior to start using a new OSPF(v3) checksum. Abhay: Can't you do this as a new auth type in your other draft or OSPFv3? But then you have to add a new auth type for v2. Acee: Anyone running OSPF in your deployed network? (a few hands) Anyone using crypto? (No hands) Can't ask if you use crypto solely as a checksum then. OSPF Fast Notifications - http://www.ietf/org/draft-kini-ospf-fast-notification-00.txt - Sri Kini Slides: http://www.ietf.org/proceedings/79/slides/ospf-10.pdf Acee: An analogy: what BFD is to hellos, this proposoal is to flooding. Sri: Right. (Name Unknown): What is the applicability? Sri: Depends on what you want to react to. If you want to flood a large database, this mechanism is not applicable. In other cases, it can be useful. Abhay: Is it fair to say that the use case is a subset of routers perhaps a hop away? Network of 100 routers, a few on teh edges are 5-10 hops away. You want to get the info to them quickly. Sri: Yes, anytime the flooding includes a large diameter area. Abhay: If number of nodes increase, and almost everyone wants to know the info, then this becomes useful. Sri: Depends on the dynamicness of the network not so much the nodes. Albert Tan: In a ring topology, in provider networks this is a case the a node pretty far away from the failure is interestind in knowing and convergence time matters. This is one topology where fast flooding would reduce packet loss.