SAVI Meeting Monday 17 November 2008 ----- Summary of Decisions so far: - Christian Vogt Design decisions that narrow down our solution for the purpose of actual engineering. Captured in draft-vogt-savi-rationale. Solution space prescribes the SAVI solution is on the first link (between host and first router). We cannot change the host but can change the router. SAVI could be implemented on the first router or on an IP-aware switch. Three stages: 1) derive legitimate addresses from on-link traffic 2) bind the legitimate IP address to a lower-layer binding anchor 3) enforce binding Three design questions which are a trade-off between security strength and ease of deployment. 1) How do you prove IP address ownership? Should we snoop existing traffic or require the use of SeND? 2) How to bind this (what is the anchor)? Options may vary with link-layer: MAC address, switch port, etc. 3) How far should we make use of existing techniques? Do we complement ingress filtering or does SAVI replace it? SAVI should be as widely deployed as possible - so we want to make it easy. SAVI will only be of benefit if it is widely deployed. 1) Weak ownership proof is okay - where stronger security is possible we will make use of it. 2) We want to support all binding anchors - provide recommendations for the network admin and provide defaults for a given link-layer technology. 3) We should complement ingress filtering and not replace it. We will pre-require ingress filtering for the SAVI solution. Two techniques for SAVI to operate: 1) Learn about routers that are routers 2) Learn which prefixes are on-link Whenever a SAVI device learns about a new router it will need to be less strict regarding enforcement for a router - when using on-link prefix detection a SAVI device would increase the security (add a prefix) to the allowed list. We would like to use one of them (the use of on-link prefixes). Dave Thaler: It would appear the on-link prefixes are slightly more dangerous than learning routers - because of false drops a network administrator may decide to turn off on-link prefix SAVI. FCFS SAVI ----- SAVI complements ingress filtering by providing higher granularity. Two types of packets: first hop packets (SAVI performs validation) or forwarded packets (verify they came from a valid router). Main thing SAVI must provide is a way to verify a source address is valid for the host. In first come first serve, the first host to use a given source address it becomes the owner of the address (and it can use it for as long as it needs). Binds the IP to the layer 2 anchor. Frank: The first packet - is this control or data? If the host configures a static IP and doesn't send any packet for a long time - what happens when another host uses the address and then sends a packet before the statically assigned host? > It is a possible attack Dave: The SAVI device can use the IP address until further notice? How long? What about temporary addresses that you may change frequently - how do we know when to stop using it? What mechanisms? > The idea is to have some timeout -but I don't know what it would be. Fred: Perhaps you should bind this to ND (ie, if the Neighbour Cache has an entry then so should SAVI). What about a flooding address attack. > The impact is that for each new address you would need to include it again in SAVI data. Dave: What happens when the SAVI table fills up? Fred: If i forget older things (ie, purge old entries), then cant I start using the address now? Device movement in FCFS: If a devices moves to a new port (binding) we would use Neighbour Discovery (NUD) to check whether the host still exists on the old port. If we do not receive any answer we can then allow the movement event. Dave: You might be able to do something like this to answer the binding expiration problem. If you need to evict something you could use NUD to evict something that is no longer in use. Jari: You may need to add MAC address in addition to the port to cater to a mobility host. Z: You must assume (in IPv6) that any interface may have multiple addresses > There is no problem. Its only when you have a single IP address being used by multiple interfaces. F: SAVI needs to be sure to send NUD to the right port (based on where a SAVI registered address was). Dave: Anycast? What about the use of the override bit - you could say that if the old binding had the override of false, and the new binding has an override of true - you might be able to more quickly react to the new binding location. Frank: How do you have multiple hosts with the same address on the same link? I don't think this is valid. > Me neither. Is this (FCFS) good enough ? Does it provide sufficient security? Dave: On the question of whether we need to store the packet while performing NUD? This isn't too different to what the router would do while performing NUD. Scope of SEND SAVI: If we have SeND then we have strong security mechanism - leverage SeND for higher security. Use the same SeND messages in order to perform the SAVI function. We use CGA to validate a host has a valid IP address - anyone that has a valid key are legal users of that address - thus two or more entries of the same IP address ARE valid (provided the key is valid). We just need to have purge/cleanup in the DB. Frank: I prefer FCFS for implementation in the switch, but I think the SeND solution is better to implement in the router. This is because it would be a high burden on a switch to perform the key processing. > If you move it to the router you lose some security. In the switch you are at the right place you have a very strong L2 archor. Frank: Yes - but I think this is a tradeoff. Jari: Deployment/implementation issue - but having it in the switch may be useful. When links support SeND nodes and non-SeND nodes Jun Bi then presented SAVI scenarios and solution space. Deliverables ----- For the first working group deliverable: is draft-mcpherson-savi-threat-scope is a reasonable starting point. 7 in favour, 0 against. Design rationale: draft-vogt-savi-rationale (Christian mention the content presented by Jun Bi will be merged). 7 in favour, 0 against. IPv4/IPv6 draft-bagnulo-savi-fcfs. 11 in favour, 2 against. Eric: How do you do SAVI with address configuration packets. How does it work when you move from one switch port to another. IPv6 solution for SeND: draft-bagnulo-savi-send: 8 in favour, 1 against. Suresh: Trivial attack to a SAVI implementation using SeND. Could send Bogus CGA/SeND to create a DoS.