Pekka Savola: During discussion of ND-proxy applicability w/ send at v6ops, an open issue in SEND came up: what is the deployment model of SEND? Is it practical? That is, I think we'd like the vendors to turn on SEND by default if they implement it, right? But at the same time, it might take quite long before SEND is widely enough deployed that actively using it would make sense. I don't quite remember how it is in the document, but it struck me that one possibility (if an "active model" would not be deemed useful) would be to have a "trigger" of a kind. SEND would be active, but not used -- until some activity triggers it. Such trigger could be e.g., receiving a SEND-enabled router advertisement, or CGA-signed Neighbor Discovery packet. The idea here would be to make sure SEND is enabled and out there, in "passive" mode -- preserving resources and hassle until it's actually needed. These are quite raw thoughts for now, but perhaps this might trigger some discussion on the transition to SEND. ----------------- James Kempf: For hosts, I think it should be possible to have SEND be on by default, since it has been designed to be completely backward compatible. Section 8 of draft-ietf-send-ndopt-04.txt describes that. For routers, it's a bit more complicated since the router must be configured with a certificate. This requires the network provider to take some action to actually enable SEND for router authentication. This also requires the host to have a suitable certificate for the common trust anchor. Many operating system platforms now have certificate management systems that contain a collection of certificates for various CAs used in SSL, so these can be leveraged without requiring any host configuration, but a certificate closer to the network provider's CA that would require configuration can reduce the size of the certificate exchange and is obviously preferable. Not sure if this answers your question? ----------------- Greg Daley: As a deployment issue, you're right: there won't be many devices using SEND initially, so there may be a requirement to fall back to ND in the case that no-one is doing SEND. We'll need to be careful that decisions about this don't leave hosts with a mechanism where other devices can cause them to turn off SEND though. I'd guess that when operating within a particular network, it is fairly straightforward: Once you receive an authorized RA with a SEND signature in it, SEND should be run on the host. I'd guess that hosts may wish to use SENDC before then though, for the purpose of mutual authentication with other SEND devices on the link. Also, it may not make sense to delay generation or utilization of CGAs until SEND authorization occurs (especially for link-local). There are also devices which will be moving around between different IP links/subnets, though. These won't have a choice as to whether SEND is turned on for a particular router or subnet. In the case that SEND is on for one router, it doesn't imply that SEND should be used on nearby subnets. We may see a situation where a host has had SEND operation on one subnet, and ignores router advertisements on a new subnet because of that. Checking reachability to the current SEND router may be one mechanism which is useful to ensure that we are still connected to a subnet (so unsecured ND messages can't override SEND messages), but when the host has moved, or the SEND router has died, this may take a long time with existing NUD/SEND Timestamp techniques. So it may also be necessary to "trigger (?)" switching SEND off in some cases. These devices may know about their wireless connectivity (for example upper later (secured?) packet reception halts, Link layer information suggests change...), and would have to reset the ND state, including potentially security. ----------------- James Kempf: Greg, Please read Section 8 of draft-ietf-send-ndopt-04.txt and let the WG know if you see anything there that would require SEND to be turned or "triggered" off on a network where the router or any of the other nodes do not support SEND. The intent of the design is that SEND nodes should "just work" with standard RFC 2461 nodes (including routers). ----------------- Jari Arkko: Pekka, this is an important issue to discuss, but I believe solutions go beyond simple triggers. Most importantly, SEND already has a built-in backwards compatibility mechanism specifically designed to address at least parts of the issue. Going a bit deeper to the details, I believe the situation is as follows: - Hosts can generally follow the current SEND specification as soon as they have support for it; they will still work in non-SEND environments, and generating addresses via CGA or via EUI-64 IIDs should not have a significant difference to others. - There's two exceptions, however, and the first one is stateful address autoconfig. Currently we do not have a specification for SEND protection of addresses assigned by someone else. So for such addresses, the hosts should continue to use regular ND (even if they use SEND otherwise). I believe our specifications say this too, though I should check to see how clearly it has been said. - The other exception is that to protect the RAs, there is a need to configure a trust root that the hosts can trust. This looks like another "use it when you have it" case. That is, when you don't have a trust root you'll just be using the non-SEND routers or SEND routers with a different root. I may have to check that this is clearly described in Section 8, but this has at least been the intent. - For routers, I think the answer is similar: if you haven't been configured to use SEND yet and have the certs for it, you pretty much cannot do SEND. No big deal, hosts survive even in this case. ----------------- Pekka Savola: > This is an important issue to discuss, but I believe > solutions go beyond simple triggers. Most importantly, > SEND already has a built-in backwards compatibility > mechanism specifically designed to address at least > parts of the issue. Agreed. > Going a bit deeper to the details, I believe the > situation is as follows: > > - Hosts can generally follow the current > SEND specification as soon as they have support > for it; they will still work in non-SEND environments, > and generating addresses via CGA or via EUI-64 IIDs > should not have a significant difference to others. Yes. The critical question, which I was really grasping at, was whether there could be any drawbacks for enabling SEND support immediately. The obvious one is at least the computational overhead but that is probably acceptable. Are there others? One particular issue that triggered this discussion at v6ops was the proposal to use ND-proxy in the unmanaged ("home") environment if the ISP would not give other than just a /64 prefix. This raises a number of questions like: - is SEND applicable in this scope (might be, if the home has non-bridged WLAN router, but the ISP is unlikely to support SEND routing certificates in any case)? - would this break SEND so badly that that might lead to disabling SEND in the OS's deployed at home? We would not want SEND turned off by default (I think) The point here would be either: a) making sure that enabling SEND by default has no problems, and could be done by the supporting implementations, or b) ensuring that sufficient "triggers" or other transition mechanisms are in place so that even if SEND is not active by default, it would at least be "dormant" for the case when it would be needed. ----------------- Pekka Savola: > This implies that most of what you appear to require > should work in the current specification. Take a look > at Section 8 and tell us if something is missing. Right. This appears to be fine. > But I'd like to understand your example better to > determine what you are worried about. Who is the > proxy in this case and where is the router? For example: /-- ND node A /--- SEND node 1 / eth0 /-- SEND node 2 [ISP router] --- p2p link --- [ND-proxy] ---- SEND node 3 \-- ND node B In this case, SEND would work out of the box between SEND nodes 2 and 3. If ND-proxy didn't strip off SEND options (i.e., just modified the L2 information), communication between SEND node 1 and {2,3} would fail without fallback. Communication between any SEND and any ND node would work still. Another case would be: /-- ND node A [WLAN]/--- SEND node 1 / /-- SEND node 2 [ISP router] --- p2p link - [ND-proxy] -- bridge ----- SEND node 3 \-- ND node B [wired eth] .. where the sole purpose of ND-proxy would be to be able to extend a /64 subnet provided by the ISP to the home network when the p2p link and the home network would have dissimilar media that bridging them would be impossible (PPP + Ethernet?). In this scenario, SEND would work inside the network with everyone -- It would not work with the ISP router if it supported SEND though (but in that case, the ISP might probably be offering prefix delegation in any case). > If the proxy just modifies the link layer address in > the ND message, this would be seen as an attack, and > the message dropped. Right. > If the proxy sends its own ND > message or strips off the SEND options, this would > be seen simply as a non-SEND ND message and communications > would be possible, albeit without protected ND. How much > current deployment is there for IPv6 capable ND proxies, > and what do they do? Draft-thaler-ipv6-ndproxy-01 > does not talk about this, nor the use of AH, maybe > it should... Agreed. Stripping off would make the communication work (I think, may need some analysis?) but would disable SEND. So, if ND-proxy and SEND is a concern, maybe this would be a workaround; something to consider for ND-proxy document. ----------------- James Kempf: > The critical question, which I was really grasping at, was whether > there could be any drawbacks for enabling SEND support immediately. > The obvious one is at least the computational overhead but that is > probably acceptable. Are there others? The WG tried hard in the compatibility design to make it possible for SEND and nonSEND nodes to work together on a link without any need for additional configuration on either the nodes or the network, or triggers to require SEND to be turned off. If you or anyone else sees anything that the WG missed please by all means let the WG know soon, since the draft is about to go to the IESG. W.r.t. computational overhead, there is more overhead initially when calculating a CGA address, but the additional per ND operation overhead if the link has no certified router or other SEND nodes should be really minimal, since it should be just RFC 2461 ND with a couple of checks for additional options. > One particular issue that triggered this discussion at v6ops was the > proposal to use ND-proxy in the unmanaged ("home") environment if the > ISP would not give other than just a /64 prefix. This raises a number > of questions like: > > - is SEND applicable in this scope (might be, if the home has > non-bridged WLAN router, but the ISP is unlikely to support SEND > routing certificates in any case)? If the ISP only gives a /64 prefix, then the ISP's router would need to provide a certificate for router discovery security. But the nodes could use CGA for ND security among themselves, which would not require any action on the part of the ISP. Not sure what your point is about a non-bridged WLAN router. > - would this break SEND so badly that that might lead to disabling > SEND in the OS's deployed at home? We would not want SEND turned > off by default (I think) Ignoring the issue of ND-proxy for the moment - that is, assuming the home nodes are communicating directly to/from the Internet via the ISP's router - the design is intended to have SEND nodes interoperate with nonSEND nodes, including the router, without any hinderance. > The point here would be either: > > a) making sure that enabling SEND by default has no problems, and > could be done by the supporting implementations, or This was the intent of Section 8 in draft-ietf-send-ndopt-04.txt. Of course, the real test of whether the design's intent is met is when we hold some interoperability tests and try it out. > b) ensuring that sufficient "triggers" or other transition mechanisms > are in place so that even if SEND is not active by default, it > would at least be "dormant" for the case when it would be needed. Again, the design is intended to have interoperation work without any triggers or other transition mechanisms. W.r.t. ND-proxy, as brought up in the thread on the IPv6 list during IETF 59, the difficulty is that the current ND-proxy draft in the IPv6 WG assumes the proxy is basically an L2 device, so there is really no way for a "proxy" SEND, should one be designed, to be used, since there is no L3 entity on which to anchor it. A L2 ND-proxy could, of course, strip SEND ND options off of RAs, in which case the RAs would be accepted by the SEND nodes as if they had been sent by a nonSEND router. In any case, the L2 proxy shouldn't affect SEND for nodes performing ND address resolution on the same side of the proxy, and packets to nodes with L2 addresses on the other side of the proxy would have to go through the router anyway because their L2 addresses would not be visible through the proxy, though SEND could presumably be used on packets sent for DAD. ----------------- Greg Daley: It's not text, but here are some ideas about the section. I think that the rules which ae defined in section 8 are basically OK. I'm still unsure whether we believe a SEND router is secure just based on the signature option, since when we arrive on the network, we don't necessarily have a delegation chain for that router. For the first 0-500ms, we has essentially an "unsecured router". The rules in section 8 are sound and don't leave holes in the case that a host moves for non-SEND routers, although it looks like this implies the standard reachability testing from ND (NUD). The second last dot point indicates that we should select reachable SEND routers over reachable non-SEND routers (and there are similar explanations for ND). This is the trigger to switch on SEND for Router Discovery. I'd guess that this implies that we want reachable non-SEND routers over unreachable SEND routers. This may be the switch-off for SEND, but may have to be specified. If we want to talk a bit more about SEND router/neighbour reachability, it may be possible to keep some reachability state for a SEND router until we've checked that it isn't in fact reachable, but allow usage of a non-SEND router in the case we have other reliable information which can be used for change detection (This is starting to sound a little like DNA though). For example this could be our own link-layer telling us about arrival on a new LAN segment. The current non-SEND to SEND transition case needs some checks, since a signed CGA addressed router advertisement may take routing away from a legitimate non-SEND router, without using any authorization information. This is worse than the current state since it occurs without NUD checks for the current router. Perhaps this is one strategy: ?? A host MAY treat unauthorized SEND routers as insecure, but allow temporary adoption of insecure routers (including non-SEND routers) while authorization is being checked. This SHOULD only be done if the host believes there may have been a link or L2 change. This aims to prevent overriding a good SEND config with an unsecured one. Checking authorization in this case is the determination of delegation information for SEND, or the unreachability of the currently configured router (whichever is determined sooner). This may cause a temporary state change of state such as: 1) default router configuration 2) neighbour cache state for the configured router Packets sent to these unsecured routers may be lost or subverted to other addresses or used for man-in-the-middle attacks. Care should be taken to ensure that any routing state changes can be rolled back in the case of current router indicates its reachability. In the case that the unreachability of the current router router is determined, such changes MAY be committed, and a unsecured or non-SEND router adopted as current. Otherwise, only authorized SEND router advertisements can override existing SEND configurations. ?? I'm not sure if this preserves the same security properties in the general case, though. In this case, we'd need two indicators (flags?): one for signed NC messages, and one for router authorization. reception of a signed NC message wouldn't be sufficient to override the (signed, authorized) SEND router. Currently there's only a 'Secured' flag. Which may be misleading. ----------------- James Kempf: > I'm still unsure whether we believe a SEND router > is secure just based on the signature option, since > when we arrive on the network, we don't necessarily have > a delegation chain for that router. For the first > 0-500ms, we has essentially an "unsecured router". If speed is not at issue, the node can use DCS/DCA in order to solicit a delegation chain if it doesn't have one. If speed is at issue (as in a handover situation), then the node should obtain the certificate chain prior to moving using something like CARD. Alternatively, as we discussed on this list earlier, the ISP can provision the access network routers with the same certificate, as some Web services do with duplicate servers, with correspondingly more risk in the event of compromise. Then a mobile node would not need to obtain any additional cert chain information unless it moved outside of the access network. I don't see this as any different than any other security protocol, in which there is some time up front in which both sides don't trust each other, then they negotiate via a procedure whereby they prove their trustworthiness. So, in a sense, you are right that for an initial period, the router is not known to the node to be trustworthy, but that is not much different than any other security situation. How long it takes depends on the amount of preconfiguration available. It is true that the node doesn't have the opportunity to do a CRL check prior to accepting the signature, but this is unavoidable, since the node does not, at that time, have a connection to the Internet. The spec says that the node should perform certificate revocation checking as soon as possible afterwards and terminate using the router if the check fails or fails to complete. So there will be some period of time in which the node is using the router but has not yet verified the revocation status of the router's certificate. > The rules in section 8 are sound and don't leave holes in the case > that a host moves for non-SEND routers, although it looks > like this implies the standard reachability testing from ND (NUD). The SEND spec is not concerned with the basic discovery procedure of 2461. In that sense, it is different from DNA. > The second last dot point indicates that we should select > reachable SEND routers over reachable non-SEND routers (and > there are similar explanations for ND). This is the trigger > to switch on SEND for Router Discovery. Essentially, yes. > I'd guess that this implies that we want reachable non-SEND > routers over unreachable SEND routers. > This may be the switch-off for SEND, but may have to be > specified. Doesn't this cover it: o The conceptual sending algorithm is modified so that an insecure router is selected only if there is no reachable SEND router for the prefix. That is, the algorithm for selecting a default router favors reachable SEND routers over reachable non-SEND ones. > If we want to talk a bit more about SEND router/neighbour > reachability, it may be possible to keep some reachability > state for a SEND router until we've checked that it isn't > in fact reachable, but allow usage of a non-SEND router in > the case we have other reliable information which can be used > for change detection (This is starting to sound a little > like DNA though). > For example this could be our own link-layer telling us about > arrival on a new LAN segment. > > The current non-SEND to SEND transition case needs some checks, > since a signed CGA addressed router advertisement may take > routing away from a legitimate non-SEND router, without using > any authorization information. This is worse than the current state > since it occurs without NUD checks for the current router. > > Perhaps this is one strategy: > > ?? > > A host MAY treat unauthorized SEND routers as insecure, > but allow temporary adoption of insecure routers > (including non-SEND routers) while authorization > is being checked. This SHOULD only be done if > the host believes there may have been a link or L2 change. > This aims to prevent overriding a good SEND config > with an unsecured one. > > Checking authorization in this case is the determination > of delegation information for SEND, or the unreachability > of the currently configured router (whichever > is determined sooner). > > This may cause a temporary state change of state > such as: > > 1) default router configuration > > 2) neighbour cache state for the configured router > > Packets sent to these unsecured routers may be lost or subverted > to other addresses or used for man-in-the-middle attacks. > > Care should be taken to ensure that any routing state > changes can be rolled back in the case of current router > indicates its reachability. > > In the case that the unreachability of the current router > router is determined, such changes MAY be committed, > and a unsecured or non-SEND router adopted as current. > > Otherwise, only authorized SEND router advertisements can override > existing SEND configurations. How about adding this as a bullet to the list: o A node MAY adopt an insecure router, including a SEND router for which full security checks have not yet been completed, while security checking for the SEND router is underway. Security checks in this case include delegation chain solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt an insecure router if a SEND router becomes unreachable, but SHOULD attempt to find a SEND router as soon as possible, since the unreachability may be the result of an attack. Note that accepting an insecure router opens the node to possible attacks, and nodes that choose to accept insecure routers do so at their own risk. The node SHOULD in any case prefer the SEND router as soon as a new SEND router appears and security checks are complete I think we should leave out the L2 change part because this might also be useful for fixed hosts. I also don't think we need to delineate the attacks, since they are described elsewhere. > ?? > > I'm not sure if this preserves the same security > properties in the general case, though. > > In this case, we'd need two indicators (flags?): one for signed > NC messages, and one for router authorization. > reception of a signed NC message wouldn't be sufficient to > override the (signed, authorized) SEND router. > > Currently there's only a 'Secured' flag. Which may be misleading. Where would flags be necessary? ----------------- Greg Daley: > Alternatively, as we discussed on this list earlier, the ISP can provision > the access network routers with the same certificate, as some Web services > do with duplicate servers, with correspondingly more risk in the event of > compromise. Then a mobile node would not need to obtain any additional cert > chain information unless it moved outside of the access network. I'd actually be loathe to put this into a specification though. There are better ways to do this. > I don't see this as any different than any other security protocol, in which > there is some time up front in which both sides don't trust each other, then > they negotiate via a procedure whereby they prove their trustworthiness. So, > in a sense, you are right that for an initial period, the router is not > known to the node to be trustworthy, but that is not much different than any > other security situation. How long it takes depends on the amount of > preconfiguration available. > > It is true that the node doesn't have the opportunity to do a CRL check > prior to accepting the signature, but this is unavoidable, since the node > does not, at that time, have a connection to the Internet. The spec says > that the node should perform certificate revocation checking as soon as > possible afterwards and terminate using the router if the check fails or > fails to complete. So there will be some period of time in which the node is > using the router but has not yet verified the revocation status of the > router's certificate. I agree. There's a tradeoff between preconfiguration, speed and trust which may come up. Describing some of these issues may be relevant to do in DNA, though. > Doesn't this cover it: > > o The conceptual sending algorithm is modified so that an insecure > router is selected only if there is no reachable SEND router for > the prefix. That is, the algorithm for selecting a default router > favors reachable SEND routers over reachable non-SEND ones. I think it does, but there the duration to determine unreachability is a lot longer than to determine reachability (for example if we move subnets). In this case, we may have received messages from devices purporting to be routers well before we time-out on our NUD tests. Alternatively, if there was some extra information in a router advertisement which implies the old router's unreachability (like a link identifier) then there may be an indication of unreachability which hasn't been confirmed. Indicating that there may be situations where you'd like to use the unsecured router though makes sense. I think discussions of the timing/tradeoffs are best made elsewhere. > How about adding this as a bullet to the list: > > o A node MAY adopt an insecure router, including a SEND > router for which full security checks have not yet been completed, > while security checking for the SEND router is underway. Security > checks in this case include delegation chain solicitation, certificate > verification, CRL checks, and RA signature checks. A node > MAY also adopt an insecure router if a SEND router > becomes unreachable, but SHOULD attempt to find a SEND > router as soon as possible, since the unreachability may be the > result of an attack. Note that accepting an insecure router > opens the node to possible attacks, and nodes that > choose to accept insecure routers do so at their own risk. The node > SHOULD in any case prefer the SEND router as soon as > a new SEND router appears and security checks are complete This looks good. > I think we should leave out the L2 change part because this might also be > useful for fixed hosts. I also don't think we need to delineate the attacks, > since they are described elsewhere. Indeed. > Where would flags be necessary? Don't worry, I was guessing that the 'secured' indication used prevuiously was just the RA signature check (which is immediately available and didn't include the authorization which isn't). Your new text block clarified that. ----------------- Jari Arkko: The text agreed upon by Jim and Greg seems good to me (with small edits). See http://www.arkko.com/publications/send/issues/issue69diff.html Btw, I spent some time thinking about the proxy neighbor discovery limitation, and whether we should say something more about it in the current specification. Such as recommending that mobile nodes should not use SEND for their home address while on the home link. However, it seems that the rules on how to treat the proxy case are quite specific to the application, and there's a danger of starting to specify the proxy operation. So I finally came to the conclusion that the current text about the limitation is sufficient; lets deal with the rest in a future specification, and also take SEND into account in the ipv6 proxy draft. ----------------- James Kempf: Sounds good. ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------- -----------------