IETF 67 Internet Area Notes Location and date: San Diego, CA, USA, November 2006 Area Directors: Jari Arkko & Mark Townsley Note takers: Mark Williams and Phil Roberts SUMMARY - All three suggested (but declined) Internet area BOFs are being pursued as a part of existing WG activities or as pre-BOF work. - A call has been made to document legacy EAP methods as RFCs. Contact the ADs for further information. - IAB document recommends avoiding multiple link encapsulations whenever possible. - The meeting felt that spoofed source addresses continue to be a relevant problem that should be addressed. - There is some interest in working on enhancements to SEND. A new mailing list for this topic has been created. - Presentations on threat models for mobility and the role of identities in ID-locator split were given. NOTES 1. Agenda introduction No comments on the agenda 2. Status There were 3 BOF proposals - source address validation, mobile platform internet, dual stack moving internet SAVA - presentation today, not ready for bof, solicinting input, maybe could be irtf wg Mobile platform internet - being handled in nemo discussions Dual stack moving internet - dual stack in netlmm (waiting until netlmm gets done with base spec, then recharter netlmm. Not chartering more WGs in this space. Document status - (see slides) 3. Documenting Legacy EAP Methods http://www1.ietf.org/mail-archive/web/emu/current/msg00173.html The IESG would like to have the EAP methods documented, not to redesign, but to describe accurately what the protocols do - to be documented as RFC. Can be done as an individual submission to RFC editor - already negotiated. Please submit your methods! 4. Bernard Aboba on Multiple Encapsulations http://www.ietf.org/internet-drafts/draft-iab-link-encaps-05.txt Discussion -- Architectural and operational issues that arise from link layer protocols supporting multiple Internet Protocol encapsulation methods. See slides for the content. Brief summary: - History: ethernet vs. IEEE 802 encapsulations (894 and 1042) ethernet trailer encapsulation (rfc 893) ppp: 1332, 2472, 3518 ARM: 1483 and 1577 Some details about ppp, possible in theory to negotiate both layer 3 and layer 2, but not in practice 1042 addresses the mixed environment problem. 1122 came down in favor of IP over Ethernet (894). - Lessons: Multiple encaps should be avoided where possible. Automated discovery of link encapsulation is complex and inefficient. IP gateways are not a panacea (had to support separate virtual interfaces for each encap). This implies some questions for 16ng. Discussion: - Andy malis - 1577 specified you use the 1483 encapsulation. Bernard - 1483 had multiple choices? Andy - no one. - David Johnston - I am the .16 liaison to ietf. For your information, the issue around CS layers in .16 is being addressed slowly and there is GPCS which tries to forget about having knowledge. Regarding dix vs. ieee 802, in the context of 802.3 I believe? Bernard: yes. DJ - This doesn't help us much in .16. Bernard - the ppp case is the most analogous, because it mixes layer 2 and layer 3. Daniel Park - We don't have multiple encapsulation concern in terms of 16ng implementations yet, the 16 client doesn't have both convergence sublayers, so there is no implementation difficulty. DJ - You can support multiple CS if you want to, it is analagous to having two ethernet ports with two wires put together, you can have multiple if you want to do this. Bernard - Yes, you can use different prefixes and routing to tell them apart. 5. Ideas for Future Work on Source Address Verification (Ron Bonica and Jun Bi, 20 min) http://www1.tools.ietf.org/bof/trac/wiki/WikiStart Discussion and call for interest -- Would improved ingress filtering mechanisms be useful? Do we have any new ideas that would lead to improvements? Ron Bonica would still like to kick up some interest in the work netowork operator wants to be able to trust source address of packets, currently has to validate the source address himself. False positives are completely unacceptable. Paul Ferguson - I am a coauthor of bcp 38: how does this particular position present itself as a better option than bcp 38? Ron - Gaps are source address checking and reverse rpf checking, further from the packets source the likelihood of both kinds of errors increases. Ron continues -- we implement a trust model in which a router downstream (close to the source) marks a packet so upstream packets can trust the model. The details are how does the marking get done, how does the downstream router know when the upstream router really has done the checking. Jun Bi from cernet2 continued from the point of view of 2nd generation of china education and research network. The presentation was about the prototype implementation of this technology. Dave Thaler: On slide about potential where a upstream router marks packets. What are the potential actions? Bonica: Up to the operator to have policy. Might be to mark as best effort or might be discard untrusted. Thaler: if a packet is marked, you will bypass doing it (authentication) yourself, and trust that it's done? Bonica: yes. Thaler: are you envisioning that the trust marking is binary? or a spectrum with shades of trust. Bonica: probably the last. Bob Hinden: Is this really an important problem to solve anymore? with the people who do attacks, they take over real machines, they don't spoof; this induces a lot of complexity good guys have to pay for but bad guys don't. Bonica: SAVA doesn't protect from every botnet kind of attack but gives more certainty in tracing. Townsley: this is the kind of question we should be discussing at this stage: do we have a problem and is it worth solving - not talking about potential solutions. we need to determine whether raising the bar for hackers actually helps here, or whether it will simply move them to other avenues of attack, etc. Kurtis Lindqvist: the really hard problem is doing the ingress filtering. Is ingress filtering even scalable? Bonica: The current BCP doesn't address the problem of getting more people to do ingress filtering. Townsley: it happens out at the edge, a lot of access networks. Kurtis: if it were that easy, more would would be doing it. Eric Rosen: is there a problem that needs to be solved? seems to introduce an enormous amount of complexity, providers typically have zero trust in the routers outside, and routers inside you won't bother Bonica: Whether to catch a spoofed source is interesting; could there be any trust between operators and see whether they are willing to talk to each other. Defer to security people for a judgement on if there is a solveable problem here. Defer to operators on whether they can establish a level of trust with each other. Eric Rosen: Too easy to say you'll defer it to determine whether there is a real problem; is there a payoff to solving this problem - it's hard to get security infrastructure put into place even when there is a real problem. Danny McPherson - 25Gb/s attacks from spoofed source addresses would say there is a problem; the biggest attacks have confirmed that. New classes of attack such as DNS reflection/amplification attacks. Only about 50% of the providers implement urpf and bcp 38. If people don't configure source filters, they're not gonna do this (sava). Today they either forward packets or drop them, they won't color them. Bernard Aboba - we spent time on this problem at the unwanted traffic workshop. This is a very real problem. Reflection attacks are going to become more possible. The issue with BCP 38 needs to be at 100% for it to really matter, but it will never be 100%. If you have a situation where you don't get to 100% then you run the risk of losing the whole internet, you've got to find more. A lot of providers from which spoofed networks come from run really old moldy routers. David Johnston - what can be achieved better than bridged to bridged ethernets. Bernard - an old moldy device isn't going to do anything like ae/af, and if it's new you have lots of alternatives. Thaler - it's hard for me to wrap my head around this being a per packet problem, depending on how much. You trust the router it came from. If you do, it should be either mark or drop everything, how would you get some packets marked, and some not marked. Bonica - Marks on a packet not necessarily coming from the adjacent router. could be a mixture of marked (trusted) and unmarked (unknown status) packets. Paul Ferguson - is SAVA a v6 and v4 thing or just for v6? Bonica - v6 only, not sure it's solvable in v4 Mark T - Do we have a problem? Sam Hartman - Two separate questions here: first, is there a problem that we want to expend the effort to solve and second, does SAVA do anything useful in that direction? Mark - Polling the room if there is consensus that there is a problem - yes. There is also the question of whether SAVA is a possible solution. Too early to ask that question now. Bernard - Would be worthwhile to talk about solution requirements. Mark - Agreed. Also need to look at how and where the work would potentialy be done - IETF, IRTF, or something else possibly should have a BoF to address these two questions? 6. James Kempf on send (Secure Neighbor Discovery) Discussion and call for interest -- There has been some recent interest on various SEND extensions. Talk about the various proposals and ongoing work, and deployment status. Is there a need for new organized efforts in this space? Topics: - follow-on: interoperability and test? - unresolved issues in 3971 and 3972 - non-CGA secure addresses - secure proxy ND DoCoMo SEND releases for public domain in May 2006. About 20 downloads at the end of August. Is it time for interoperability test? Or get it in TAHI? There are some unresolved issues. WG disbanded after waiting for deployment interest for further work. Bernard: IEEE 802.1ar is an effort to standardize the MAC. It does mention SEND, so maybe there is something to look at there. Every manufactured device has a cert. It's not done yet. Kempf: there is also a discussion of certificates in .16 devices. Jari: On the minimum key length in 3971 and 3972. One requires 1000 bits and the other 384. It might be good to have them say the same thing. Kempf: We should look into that. May be a good reason for less stringent requirement in one. Alain: Folks are wanting to use v6 in .16, and there might be a use, also maybe in docsis. Erik: 16ng, is not proxy ND but relay and DAD Sam: proxy nd is not a standards track Thaler: it is in MIP Erik: 2461 says if you are going to do proxy this is how you're going to construct. Sam: should I keep holding up docs that don't work with SEND? Fred Templin: Proxy relay does come up in other contexts - not the same thing. Vidya: Question: If Secure Neighbor discovery is important in the edge network, why is it not important in the Home Network? are there any home networks that actually use this stuff? James: don't think so, when people deploy mip6 HA there isn't really a home link. Vidya: when we start laying architectures like MIP and NETLMM together you might run up against this. If you put the restriction in 3775 then you have to make the home link virtual. Jari: Show of hands please - result: there are 10-15 folks interested in extending CGAs, maybe 10 folks interested in extensions to SEND. 7. Vidya Narayanan: talk on IP mobility and threat models Discussion and call for interest -- There is much ongoing work for various security and key management mechanisms in the mobility space at the IETF. Talk about the baseline requirements and models for securing IP layer mobility, local mobility, and various optimizations. For content see slides. Discussion: Kempf: How is this different than anything between any other two communicating nodes? Vidya: it's not. Suresh Krishnan: There are some questionable assumptions, why is something higher up in the network more dependable tha something lower in the network? Vidya: if nodes not essential to operation of the protocol should fail (non-critical assets), it shouldn't affect the service. Suresh: why for example is the AR a non-critical asset? Vidya: because if the AR you are using now fails you can move to another AR. Suresh: but some of these definitions seem really arbitrary. You can say that for almost any element given sufficient redundancy. Jari: what are next steps? Vidya: goal is to collect feedback and provide guidelines. Alex: Are you planning a generic document on security for mobility? Vidya: Each IP mobility model may have some variations in the trust model; there are some basic assumptions. Alex: I don't think that is possible, need to talk about a particular deployment. Sam: See draft-housley-aaa-key-etc as an example. Vidya: it does a great job of addressing a much larger space; one of the problems is that there is no such document. 8. Geoff Huston: Role of Identities in ID-Locator Split Discussion -- Implications of the various choices of identifiers in an architecture where identities and locators have been separated. IP addresses are: endpoint identifiers, routing objects, key value for forwarding lookup in some network protocols, these things are distinguished there can be a lot of benefit from separating these functions... For full content, see slides. No time for comments/questions at the end of the presentation. 9. End of the meeting