Issue 44 discussion continues here after the publication of draft Mohan Prasarthy writes: > So I've thought about this issue a bit more and I don't agree that the > prefixes in the cert are advertisment rights and not routing rights. I think > this is a distinction without a difference, since why would a router > advertise prefixes without agreeing to route (i.e. not to ingress filter) > them (except to propagate a DoS attack)? Specifically, A router can advertise prefixes and not be a default router by setting the Router lifetime to zero. These two are different aspects in RFC2461. But your question is different i guess. Why would a router advertise prefixes and agree to route packets coming from different source other than the prefixes advertised ? RFC 2461 explicitly states that different routers can advertise different set of prefixes (section 6.2.7) ( I have seen this in practice and don't know how common it is) and is not an error. And it routes packet from hosts that configured the address from a different prefix advertised from a different router. One of the points of contention is whether we should change this existing behavior for SEND ? There is already a default router selection draft which has a "Route Information" option as part of the router advertisement which specifies the routers that should be preferred when sending packets to certain prefixes/addresses (destination). For example, if i am sending a packet to 3ffe::/16, and there are more than one router, i choose the one with the higher preference for a given prefix. Assume that the router advertisement where this route information option is protected using SEND. What should the host do ? Ignore the route information option and choose the router based on source prefix ? There are other examples where it shows why you may want to prefer one router over the other i.e 2 routers may advertise different set of prefixes and you prefer some routers for sending packets to certain destinations based on the route information option and is independent of the source address. We have to understand the interaction in those cases before we change the behavior. ----------- James Kempf writes: > A router can advertise prefixes and not be a default router by > setting the Router lifetime to zero. These two are different aspects > in RFC2461. But your question is different i guess. Yes. If the lifetime is zero, then by RFC2461, the host won't use it for a default router. The SEND spec isn't saying to change that. > Why would a router advertise prefixes and agree to route packets > coming from different source other than the prefixes advertised ? > RFC 2461 explicitly states that different routers can advertise > different set of prefixes (section 6.2.7) ( I have seen this in > practice and don't know how common it is) and is not an error. And > it routes packet from hosts that configured the address from a > different prefix advertised from a different router. One of the > points of contention is whether we should change this existing > behavior for SEND ? If that's the case, then the router can't be performing ingress filtering just on the prefixes it is advertising. I believe the relevent question here is whether a router advertising one prefix and routing another is: - not performing any ingress filtering? - ingress filtering on some set of prefixes that are not just advertised by itself but also on those advertised by another router on the link? Clearly, for secure last hop routing, the first practice is unacceptable. What the proposed text implies is that if the network operator wants secure routing, their routers must: - ingress filter on the prefixes the router is certified to route, - advertise exactly the prefixes that the certificate allows the router to accept so hosts know what will be routed, We could change this last point so that the router must: - advertise some subset of the prefixes the certificate allows the router to accept This would enable the case where there are a collection of routers on the link that all advertise a different set of prefixes, but the certificates on all the routers on the link certify the routers to route the union of the advertised sets. The host would still have to pick a prefix from the advertised ones that is within the set in the certificate (or check a DHCP assigned address against the certified prefixes). It would still require that the routers ingress filter on all the prefixes for which they are certified to route, or some subset of those. Do you think that would be sufficient? > There is already a default router selection draft which has a "Route > Information" option as part of the router advertisement which > specifies the routers that should be preferred when sending packets > to certain prefixes/addresses (destination). For example, if i am > sending a packet to 3ffe::/16, and there are more than one router, i > choose the one with the higher preference for a given prefix. > Assume that the router advertisement where this route information > option is protected using SEND. What should the host do ? Ignore the > route information option and choose the router based on source > prefix ? The Route Information option could still be used, it would only need to be consistent with the certified prefixes for which the routers on the link are ingress filtering. If it's not, there may be trouble. The sender may be an attacker trying to spoof the node into using an insecure route. The SEND spec should probably say something about this case as well. > There are other examples where it shows why you may want to prefer > one router over the other i.e 2 routers may advertise different set > of prefixes and you prefer some routers for sending packets to > certain destinations based on the route information option and is > independent of the source address. We have to understand the > interaction in those cases before we change the behavior. A certified default router can always issue a Redirect if there is a better route on the link. ----------- Mohan Prasarthy writes: > If that's the case, then the router can't be performing ingress > filtering just on the prefixes it is advertising. I believe the > relevent question here is whether a router advertising one prefix > and routing another is: > > - not performing any ingress filtering? > > - ingress filtering on some set of prefixes that are not just > advertised by itself but also on those advertised by another router > on the link? Yes, the router can ingress filter for all the prefixes on the link, more than what it is advertising. Not sure why you would end up in such a configuration. > Clearly, for secure last hop routing, the first practice is unacceptable. > > What the proposed text implies is that if the network operator wants secure > routing, their routers must: > > - ingress filter on the prefixes the router is certified to route, or ingress filter on all the prefixes that are assigned to the link. > - advertise exactly the prefixes that the certificate allows the > router to accept so hosts know what will be routed, > > We could change this last point so that the router must: > > - advertise some subset of the prefixes the certificate allows the > router to accept Sure, but this would need a different behavior for default router selection which in itself may or may not be good. > This would enable the case where there are a collection of routers > on the link that all advertise a different set of prefixes, but the > certificates on all the routers on the link certify the routers to > route the union of the advertised sets. The host would still have to > pick a prefix from the advertised ones that is within the set in the > certificate (or check a DHCP assigned address against the certified > prefixes). It would still require that the routers ingress filter on > all the prefixes for which they are certified to route, or some > subset of those. Do you think that would be sufficient? Clearly there are two options. The one that would need a change in default router selection algorithm (see more on this below) and the other by ingress filtering on all prefixes assigned on the link. > The Route Information option could still be used, it would only need > to be consistent with the certified prefixes for which the routers > on the link are ingress filtering. If it's not, there may be > trouble. The sender may be an attacker trying to spoof the node into > using an insecure route. The SEND spec should probably say something > about this case as well. Route information option is about destination prefixes and the ones in the certificate are about source prefixes. > A certified default router can always issue a Redirect if there is a > better route on the link. What do you mean by certified default router ? Redirect tells me to use a different router for sending packets to a given destination. How do you determine that the router is authorized to issue redirect ? Sorry, i must have missed some earlier discussion. This might be a bit off topic for the current discussion. ----------- Jari Arkko: Router selection depends on many factors, including - Router Information (RI) options for the destination address (draft-ietf-ipv6-router-selection-02.txt) - Prf field in the RA (same draft) - Router lifetime value as per RFC 2461. - Trustworthiness of the given router, handled by the usual SEND mechanisms. - Routing rights/expected ingress filtering behaviour, which is where this discussion started. The first three factors exist even in non-SEND hosts. Router lifetime has higher priority than the RI option or Prf values, i.e., a router with a zero lifetime does not get selected as a default router for anything regardless of any attractive RI options it might have. And specific information carried in RI, I think, has higher priority than the default router priority Prf. General trustworthiness of a router is an on/off kind of thing, similar to the router lifetime zero check. This means that it has higher priority than the other checks; a bad router will not be selected for anything. The interesting part is the routing rights issue. This is in fact the same thing as the expected ingress filtering; one of the questions we are debating is what kind of ingress filtering we should expect from routers when there are at present no explicit protocol means to determine this. I think James argued convincingly that the certs have routing rights information. The remaining questions are: (1) Are the routing rights same for all routers on the link? If they are not, then there is a need to change default router selection algorithms. Note that this is necessary regardless of SEND; ingress filtering by itself will already cause this. If the rights are the same for all routers, then current algorithms and SEND draft text are sufficient. (2) Are the advertised prefixes the same as the routing rights? I don't think they need to be. Clearly, we are not going to drop a RA just because it contains less prefixes than the router's cert. Advertised prefixes should be a subset of routing rights. (3) What is the priority between the routing rights information and other factors? Both routing rights and route information option, if not obeyed, can lead to dropped packets. Ingress filtering can drop packets with inappropriate source addresses, and disobeying a route information option can lead to a packet being sent to the wrong interface and network, with no guarantee that this networks can actually route the packet. So I would say that both factors are crucial. Inconsistency is possible, but is a configuration problem. Even without SEND, this can occur: host picks wrong source address, follows RI, packet discarded (either router config problem or host address source selection table config problem). Is there a need to talk about this in the IPv6 list? James? ----------- Greg Daley: > (1) Are the routing rights same for all routers on the link? > > If they are not, then there is a need to change default router > selection algorithms. Note that this is necessary regardless of > SEND; ingress filtering by itself will already cause this. > > If the rights are the same for all routers, then current > algorithms and SEND draft text are sufficient. I really don't care what preferences or other parameters routers advertise their capabilities as for default router selecation, so long as they are certified to route the prefix which I have as my source address. The trust which the host has of the delegation/certifcation should be sufficient to determine if the router is considered OK for routing. If there's no delegated authority for a particular prefix in the DCA, there shouldn't be any default routing through that router, regardless of the RA contents. > (2) Are the advertised prefixes the same as the routing rights? > > I don't they need to be. Clearly, we are not going to drop a RA > just because it contains less prefixes than the router's cert. > > Advertised prefixes should be a subset of routing rights. I think that for a particular security domain (for example a set of access networks) a router may be default for, I'd consider having a single 'default routing' certificate over those prefixes in the domain (which may be on several of the router's interfaces). In this case, the router's advertisment on a particular interface will not contain all of the prefixes, although the DCA would. I'd guess that this could be a fairly common deployment scenario for wireless access networks. If this raises sacreligious horror in anyone, I'll be happy to recant if someone will tell me why this is bad. > (3) What is the priority between the routing rights information and > other factors? > > Both routing rights and route information option, if not obeyed, > can lead to dropped packets. Ingress filtering can drop packets > with inappropriate source addresses, and disobeying a route > information option can lead to a packet being sent to the wrong > interface and network, with no guarantee that this networks can > actually route the packet. So I would say that both factors are > crucial. Inconsistency is possible, but is a configuration > problem. Even without SEND, this can occur: host picks wrong > source address, follows RI, packet discarded (either router config > problem or host address source selection table config problem). > > Is there a need to talk about this in the IPv6 list? James? I'd actually guess that the routing rights guarantee that the router will not apply ingress filtering to your packet _if_ on that interface, it advertises that prefix. Assuming otherwise means one of two things: Hosts may choose to send to a router with a prefix it are authorized to route, on an interface relevant to a different prefix (... should this packet be ingress filtered?). Or Authorization must be done on a per-interface basis through certification of a CGA or otherwise. (This is OK, but I guess there's could be a lot of certificates if this was done naively). Certainly it's worth taking this to the IPv6 list, but I'd guess we'd have to be clear about how these certificates are interpreted and authorized. ----------- James Kempf writes to the ADs: In the process of finishing up the SEND draft, a question (#44) came up on the relationship between ingress filtering, advertising, and router certificates. We've been discussing it on the list, but we need some advice about how to proceed. The SEND draft allows the router certificate to contain a collection of prefixes that the network operator has certified that the router is authorized to route. The router, in turn, advertises some set of prefixes that nodes on the link use for global unicast address autoconfiguration. As a first cut, one would expect that, from a security standpoint, a node should check whether the router has been delegated the authority to route the prefixes that it advertises (that is, the advertised prefixes are a subset of those in the certificate), and that the router would ingress filter on those prefixes it advertises. However, there is a corner case which apparently happens in practice where multiple routers on the same link advertise different sets of prefixes, and so the routers on the link would need to ingress filter on the union of advertised prefixes, rather than just those it advertises. Also, the certificates at each router would presumably need to authorize the routers for the union of the advertised prefixes. There is a third case in which a collection of routers in an access network on different links advertise different sets of prefixes, but for reasons of convenience, the network operator issues a certificate that covers all to each router. So each router must ingress filter on the advertised prefixes only, since only those prefixes apply to the link, even though the certificate authorizes them to route more. The technical question is what the relationship should be between advertised prefixes, certified prefixes, and ingress filtering? We have some preliminary thoughs (based on a suggestion I made) which are in the latest draft, but will probably need modification based on subsequent discussion. ----------- Jari Arkko adds: I would add that there's a related issue that has been discussed recently on the HIP and multi6 mailing lists. Here's what I think the issue is: there's an ingress filtering and default router problem even if you do not consider SEND at all. This has to do with the relationship of ingress filtering and default router selection. If put my cable and DSL boxes on the same network at home, hosts will route my packets more or less randomly through both routers -- but since the ISPs employ ingress filtering, packets with a source prefix from the other ISP will be dropped. Therefore, hosts should send packets with a prefix P preferrably through routers that are somehow known to recognize the prefix P. Router selection draft does not appear to help here, because it only deals with destination prefixes, not source prefixes. I am not aware of any other IPv6 feature which would help either, though I may have missed something. I did check with Pekka Savola, though, and he also thought this is a general issue. In conclusion it looks like this is potentially a wider issue than just SEND and IPv6. It seems in-scope for multi6, something like that is required by HIP, MOBIKE, and possible multihoming extensions of MIPv6, and SEND is expected to secure it. But I'm hoping you will point out something from the existing IPv6 RFCs and this is no longer an issue except for figuring out what the SEND certs should contain. ----------- James Kempf: I think I now agree with Greg Daley's point about having certs issued to all the routers in the access network. This would loosen the connection between the local subnet topology so that certs wouldn't be particularly useful for determining what addresses get ingress filtered, but it would simplify the O&M. So it seems like we ought to start with the simplier solution then later maybe move to the more complex one. I also think this issue is one that might be examined in another WG after SEND completes, but I would rather not get into it in SEND now. What do you think? ----------- Jari Arkko: I think I agree too. That also leaves any multi6, ipv6 solution to the ingress filtering problem for them -- just that whatever they do in terms of the current messages, the contents of those messages will be protected by SEND. ----------- Jari Arkko: I have reviewed this thread again, and I have made a few conclusions: o It seems that we agree about Greg's scenario where a router may get a single certificate that covers more one of its interfaces. This is important for practical purposes. It implies that the set of prefixes in the RA may be a subset of the prefixes in the cert. o There is a related non-SEND issue: an ingress filtering and default router problem exists even if you do not consider SEND at all. This has to do with the relationship of ingress filtering and default router selection. If put my cable and DSL boxes on the same network at home, hosts will route my packets more or less randomly through both routers -- but since the ISPs employ ingress filtering, packets with a source prefix from the other ISP will be dropped. Therefore, hosts should send packets with a prefix P preferrably through routers that are somehow known to recognize the prefix P. Router selection draft does not appear to help here, because it only deals with destination prefixes, not source prefixes. I am not aware of any other IPv6 feature which would help either. In the long run, this means that IPv6/multi6/send/someone has to solve this, probably even for the case that SEND is not used. o The key question is whether the default router selection should be modified in SEND or not? Draft 01 does not modify this behaviour. It simply says that if the advertised and certified prefixes don't match, another default router should be used. This still leaves the possibility that the routers ingress filter aggressively according to their own advertised prefixes, and packets sent with other prefixes from the link are dropped. But as Greg pointed out, the SEND certs ensure that advertisements are right, and if you see an advertisement from the router then you are sure that it will not ingress filter those prefixes. If we stick with this, it implies that SEND solves the problem only partially, i.e., we ensure that the advertisements and other options are authenticated and authorized. But we do not modify the default router selection, that would have to be done by someone else. I think that would be appropriate, particularly when such modification outside SEND could be used without SEND. If this looks reasonable, then the following modifications in the draft are needed: If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise exactly the prefixes for which they are certified. => If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise the prefixes for which they are certified, or a subset thereof. See also the diffs at: http://www.arkko.com/publications/send/issues/issue47diff.html I have a -02 strawman available at: http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt In addition, we need to work in ipv6/multi6/somewhere on the ingress filtering problem. Comments? ----------- Hesham Soliman: We seem to have this discussion roughly twice a year in different WGs ;-) The core of the problem is that a multi-addressed host, has no way of knowing the backhaul connectivity of the default router. I think that it might have been an oversight to not include the source address in the next hop determination algorithm, in addition to assuming that routers will only advertise prefixes that they won't ingress filter. In any case, this is going to affect any multihomed link, i.e. that has more than one router connected to different networks. Does anyone know where this should be addressed? IPv6 WG?? It affects PANA, nemo, multi6, IPv6 ....etc IMHO SEND is not the right place for this as we need a complete solution for IPv6. ----------- Jari Arkko: I agree with what you say. I think your comments also point to the direction that I'm proposing we take, i.e., SEND ensures that certs and advertisements agree, but that the rest of the problem is dealt with separately. ----------- Hesham Soliman: Yes. I just wanted to see if we can solve this general problem somewhere. Perhaps this should be brought up beyond this WG. ----------- James Kempf: Jari, I agree with the change. Wrt. getting further work on the ingress filtering issue, when I do the document writeup for the INT area ADs I will mention that the WG considered this problem and decided it was out of scope for SEND, but believe it should be addressed in another WG and not simply dropped. ----------- Mohan Prasarthy: I looked at the latest version you posted below. A couple of questions.. In section 6.1.1, The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element with an IPv6 address prefix for a prefix the router or the intermediate entity is authorized to advertise. If the entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. - The first part says nothing about routing for the prefix. It says ".. authorized to advertise". If we don't want to use it for routing at all, then can we be explicit ? Or i am confused with the resolution here, as the next line talks about routing for the prefix also. In any case, it should be explicitly stated here. - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like other prefixes, right ? If we can't, we should mention this explicitly. In section 7.3, If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise the prefixes for which they are certified, or a subset thereof. The use of the word "support" is confusing in the first line. Did you mean "support routing .." ? Network operators that do not want to constrain particular routers to specific prefixes SHOULD configure routers with certificates containing either the null prefix or no prefix extension at all. Did you mean "routers to route specific prefixes" ? ----------- Jari Arkko: > - The first part says nothing about routing for the prefix. It says > ".. authorized to > advertise". If we don't want to use it for routing at all, then can we be explicit ? > Or i am confused with the resolution here, as the next line talks about routing > for the prefix also. In any case, it should be explicitly stated here. I agree that this needs to fixed. I forgot this part. > - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like > other prefixes, right ? If we can't, we should mention this explicitly. I'm not sure I understand this. It seems like we need to define the null prefix to be 0/0 so that any further delegation would work correctly, in case prefixes are used there and we need to ensure that delegated prefixes are subsets of the original prefixes. Note: Null prefix != empty set. Null prefix is more like the set of all possible prefixes. > In section 7.3, > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise the prefixes for which they are certified, > or a subset thereof. > > The use of the word "support" is confusing in the first line. Did you > mean "support routing .." ? > > Network operators that do not want to constrain particular routers to > specific prefixes SHOULD configure routers with certificates > containing either the null prefix or no prefix extension at all. > > Did you mean "routers to route specific prefixes" ? I agree that these parts are confusing as well. I guess our earlier discussion with James about the routing vs. advertisement rights started from the fact that it was unclear whether the certs give routing or advertisement rights. James then argued that (a) PKIX drafts talk about routing rights and that (b) there's no real difference between routing and advertisement rights. Actually, I think advertisement rights must be a subset of routing rights (even if the advertising router does not offer itself as a default router). In the new agreement that we had, the ingress filtering problem is shifted to someone else. This implies that we have no use for the specific routing rights check. However, we still have a use for the advertisement rights check, which per above are a subset of the routing rights. In conclusion, I think the text should say the certs carry routing rights, and that advertisements must fall within the routing rights. Here's the modified draft: http://www.arkko.com/publications/send/issues/issue47diff.html http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt ----------- James Kempf: I agree with your proposal for specifying that advertising rights are a subset of routing rights. ----------- -----------