Pasi Eronen and Valtteri Niemi write: o Section 9.2.2 (technical/editorial): When Router Advertisements protected only with CGA (but not trusted root) are useful? If they are, document reasons... --------------- Jari Arkko responds: They are currently included because they require no configuration. But you are right that they might not offer any protection, at least no as currently specified. --------------- IETF-57 minutes: Michael: To me, this seems like worst of both worlds. We have code for both; can't use both; we have to deal with certs in kernel even when we don't want to talk to peers. Don't see optimizations except towards shortest IETF process. Jari: Different problems: ND problem, RD problem. Need slightly different security solution Pekka: Might help on router discovery for ad-hoc networks. But this is not the focus of WG. So dropping this is OK with me. Tuomas: Might make sense to protect, even if you don't have authorization for the router, to prove address ownership. Michael: Any network that doesn't have certificate is an "ad-hoc" network, e.g., this network at Telekom Austria, since DNS was not reloaded on Monday morning. Can't get certificate because they're closed. Maybe we should have more documents: How to protect ND with PK, how to protect RD with PK, how to get PK addressed CGA, how to deal with cert retrieval. We could proceed with getting reviews of some of the pieces. I feel afraid of getting a certificate for my router, because 95% of people won't be able to do that without putting out dollars. James: This is mainly simplicity. CGA with RD doesn't provide a lot of security, just that router is authorized to send packet with the address. Dave: Question is whether threats are significant enough to protect against Pasi: CGA-only RD protection may not be useful, but used with certificates, it might be. Rick: Isn't really secure to use CGA on these things, but you can choose any prefix you like, so it may be possible hijack a prefix. Dave: True, but this is denial of reachability. Rick: Unless you can tunnel to a different link. Tuomas: Using CGA and certs together makes sense, because you may trust router for a prefix, but not to steal IP address of another router on the link. Pekka: Getting feeling we want to use CGA with certs, but what about CGA without certs? We can discuss on the ML. --------------- James Kempf writes: Issue 14 received some discussion in Vienna. The question was raised by one of the reviewers whether having CGA-only protection on RAs would be sufficient for securing router discovery. This is independent of whether a router would use CGA for neighbor discovery. The best approach to an answer would seem to me to be to be to look at the threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA protection will satisfy them. This email attempts that analysis. Threats to RD are described in Section 4.2 of draft-ietf-send-psreq-03.txt. The following threats are discussed: 1) Malicious Last Hop Router - the attacking node sends legitimate-looking IPv6 RAs, or responds to a victim node's RSs with legitimate-looking IPv6 RAs, in an attempt to get the victim to use it as the default router. 2) Default router is 'killed' - the attacking node uses one of a variety of means to spoof other nodes into believing that the default router on the link has died, in which case, by RFC 2461, the nodes revert to using link local addresses only. One of these means involves sending out a bogus RA for the default router with lifetime 0. 3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet prefix to trick the victim into either using the prefix for an incorrect autoconfigured address or into thinking that the prefix is on-link so that the victim uses link local addressing instead of a global IPv6 unicast address, by sending a legitimate-seeming RA. 4) Bogus Link Parameters - the attacking node sends bogus link parameters (like whether or not stateful address configuration should be used) by sending a legitimate-seeming RA. The protection provided by CGAs is fairly simple: a receiver of a message signed by the sender and verifiable with the sender's public key has the assurance that the message was, in fact, sent from the CGA. In the absence of any network element or any additional processing between the router and the host, CGAs would seem insufficient to address all the threats above, though they would address 2, since the victim could clearly identify that the bogus RA did not issue from the legitimate default router. A malicious host could construct a CGA from its public key and use its private key to sign a bogus RA. The RA would be verifiable as issuing from the correct IPv6 address, but the RA would contain bogus information designed to launch an attack. Since there is no IP network element between the host and the router in the standard IP subnet architecture, this would suggest that CGA-only RD authentication is not sufficient to address all the threats. If, however, there exists a Layer 2 network element between the host and the router that is programmable such that it can perform sufficient Layer 3 processing to cryptographically verify the RA signature and filter on the CGA, then CGA-only RA security may be useful. The Layer 2 network element could be programmed with an ACL of CGAs for known good routers, and only pass RAs for those whose CGAs match the signatures and the ACL. Depending on the Layer 2 technology and the network element, some part of the subnet may still be vulnerable. For example, if the Layer 2 technology was multi-access prior to the filtering device, some number of hosts may be exposed to the bogus RA. Note that such a filtering device would still be subject to attack if CGAs were not employed, since the device could not verify the RA as issuing from the source address, providing an opening for an attacker. The following are possible actions the WG could take w.r.t. resolving this issue in the draft: A) Since the IP subnet architecture does not admit of devices between the host and router, the potential solution involving a Layer 2 filtering device is not of interest in an IETF standard. Therefore, the draft should state that CGA-only solutions are not sufficient for protecting RD in SEND. B) As a practical matter, some Layer 2 technologies of interest support such filtering devices, and adding the kind of Layer 3 filtering and network management functions described above to such devices for CGA-only protection is not all that difficult. Since a CGA-only solution may be simpler from a deployment and network management perspective in some networks than requiring routers to have certificates, the CGA-only solution should be fully articulated in a separate section in the draft. C) As in A), but mention the CGA-only solution in passing, and don't encourage it as a part of SEND. Suggest it is up to Layer 2 standardization bodies to incorporate this functionality in their specifications. WG members are encouraged to discuss these alternatives, express their preference, or suggest an additional alternative that I've missed. --------------- Alper Yegin: I agree that relying on filtering capabilities in the access network for solving router advertisement authorization problem cannot be "the IETF SEND standard solution." But nevertheless, I think this should be noted as one possible way to solve "the problem." Also stating the applicability of such a solution, optionally along with its strengths/weaknesses, etc. would be useful. After all, network administrators should understand not only the problem and one of its solutions, but also other solutions and how they might relate to each other. At the end, they'd be the one to choose among these solutions. On the CGA point: Physical access, MACsec or IPsec-based control already helps enabling filtering. What does CGA-based approach add to this? >So are you in favor of A, B, or C? D) Mention the possibility of filtering unauthorized RAs by relying on the physical access or crypto-based access authorization (i.e., using MACsec or IPsec). Such a solution is applicable when the hosts cannot directly communicate with each other without going through an access network device (such as an access point or access router) where this fitlering can take place. I would not suggest CGA-based RA filtering for the text, unless someone explains its benefits over the existing ways to check authorization. --------------- Alper Yegin writes: > By MACsec I assume you mean cryptographic protection on the MAC layer, or > possibly the kind of port-based filtering done by 802.1x? Possible combination of the two.. In the aforementioned network, if the physical security is not adequate (or you don't want to automatically authorize any node connected to the wired segment as a "router") then you can load a list of MAC addresses (or client IDs which are bound to MAC addresses upon 802.1X - if used) as ACL, and the AP filters out any router advertisement if it does not arrive on a MACsecured packet with an authorized identifier. > Can you explain how IPsec would work in this context? Similar to the L2 case... > What existing ways? The reason SEND was chartered is that the security in > RFC 2461 was considered inadequate (note: if you are thinking of AAA-based > solutions, not every access network will deploy AAA). We are just talking about how to prevent unauthorized router advertisements, which is just one half of SEND. Current approach of SEND WG is to use certificates to prove authorization for an advertisement. As I understand from your original e-mail, the WG is also considering a filter-based approach where CGAs are used as the "authentication/authorization method." What I'm saying is, yes, filter-based approaches are valid, but asking why we need a CGA-based scheme where physical security, MACsec, or IPsec-based filtering can be used. This has nothing to do with using CGAs for solving the address ownership problem (the other half of SEND). --------------- James Kempf: With regard to the original point of this email thread, I interpret your response to be that you don't see any need to mention CGA-based RA filtering in the draft, i.e. alternative A, because there are existing filter-based alternatives that satisfy any requirement for non-cert based RA security. Your alternative D involves deployment issues, which, as I've stated, are outside of SEND's scope, and therefore not appropriate for insertion in the WG draft. If you are interested in pursuing these deployment issues, I'd suggest talking to the OPS ADs about scheduling a BOF. Unlike other WGs, the SEND WG has made very strenuous attempts to stay focussed on completing its charter as quickly as possible, and not wandering off into trying to solve all the problems of local link security. --------------- Julien: Another benefits of CGA-only protection for RA can be some sort of opportunistic security: If there is several on-link routers that send RA's, the node has the ability to distinguish them based on their CGA's. Hence it may be possible of classifying contradictory routers and try to measure the connectivity they provide to select best performers and ignore their contradictors. For example if two routers advertize a default route, a node may try to communicate with a trusted remote host (its HA for instance) to see which of the two routers really forward packets to its HA. It is certainly not very secure, but by leveraging on the routing infrastructure it may be better than nothing (for example when there is no certs for DCC, like in ad-hoc set-up). Therefore, I suggest that the WG follows the following direction: > B) As a practical matter, some Layer 2 technologies of interest support > such filtering devices, and adding the kind of Layer 3 filtering and > network management functions described above to such devices for CGA-only > protection is not all that difficult. Since a CGA-only solution may be > simpler from a deployment and network management perspective in some > networks than requiring routers to have certificates, the CGA-only solution > should be fully articulated in a separate section in the draft. And perhaps mentions that measuring connectivity as a way of using CGA-only RA's protection in ad-hoc set-up? --------------- Greg Daley writes: I think that we have to avoid using CGA only RAs at all costs. The issue is that the Host doesn't know that the RA is genuine, rather than that the network doesn't, therefore any solutions whereby devices in the network access list RAs from known good CGA sources do not address the issue: That the RA doesn't contain enough information when it arrives at the MN to guarantee its validity. One difficulty comes in several wireless environements where a host is on the same cell as an attacker and the RA is visible directly from the wireless link. While this is not necessarily unsolvable in current wireless systems, it is irksome to have to worry about wireless link effects in a security system. More importantly, when a host moves to another cell which doesn't support this filtering. How do we know that we're only receiving white-listed RAs? The RA has to contain some authentication information to communicate its authoritas to the host. This is where the concept of Delegation Chains emerged from in the first place. Please don't put CGA only RAs into a solution. I think it's a solution looking for a problem. --------------- Jari Arkko: I don't really believe in the filtering approach. The main reason in my opinion for the possible use of CGAs for RAs would be the opportunistic security that was mentioned by Julien. However, at this point we do not really have a specific mechanism on the table to handle all the details of this opportunistic scheme. We had some proposals before the WG was formed, but nothing very detailed. Anyway, while this is certainly useful, it is also something that we could easily do later. So here's what I would propose: I think in Vienna we agreed that its OK to use CGA with certs for RAs, e.g. to avoid stealing the other routers address. But for the CGA-only case, we should leave it out from the spec. If we want to, we can revisit this and create an "ad hoc network SEND extension" later. --------------- This issue generated lots of technical interesting technical discussion. I'd like to suggest that we resolve the issue with Jari's proposal: So here's what I would propose: I think in Vienna we agreed that its OK to use CGA with certs for RAs, e.g. to avoid stealing the other router's address. But for the CGA-only case, we should leave it out from the spec. If we want to, we can revisit this and create an "ad hoc network SEND extension" later. --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------