Jonathan Trostle: (2) there's no mention of whether the host checks that its IP address is contained in the prefixes or ranges in the router's certificate. Suggestion: if not, the host MUST either find a new router or obtain a new IP address and recheck. (An IP address might be obtained using DHCP as well). ------- James Kempf: I think there's an implicit assumption that CGAs are being used with secure RAs, which might not necessarily be the case, so there probably should be some text in the spec about this. ------- Jari Arkko: First I'd like to understand this issue better. I think you are not talking about the router's own address -- because the router's address is either (a) link local or (b) given through the R flag and automatically within an advertised prefix. So I think we can agree that it is not possible for routers to give wrong addresses, as long as their RAs are valid. Secondly, we have the issue of the host's own addresses. I don't this is a matter of just checking if we have the right type of address already. When we receive the RA, we are building the default router list as well as a list of prefixes for the link. If this is the first time we hear from this router, it is possible that we have not heard from the prefixes yet either. So in this case we would need to adopt the router as least as far as prefixes and address autoconfiguration goes. When DAD completes later, at that point the host may for the first time have an address that is in the range of the router's certificates. I do not think we need to do anything special to cause address autoconfiguration to be performed for new prefixes, standard ND already takes care of that. But the question is perhaps what to do in terms of routing. As far as I know -- but I could easily have missed something - RFC 2461 does not restrict the use of a default router for just traffic that uses this router's prefixes. There is also no rule that says we can only use a default router only if we have succeeded in defining an address for one of the prefixes advertised by the router. Is there a need to change this for SEND? I'm not sure I see a need for a host to define an address P::IID just because it wants to send something from Q::IID over a router that only advertises P. There is no connection between P and Q, so I'm not sure what this would help. However, is there a need to restrict all traffic out from the router to use just those prefixes that the router advertised and is authorized to advertise? If we did this, it would provide automatic ingress filtering... but perhaps it would be too limiting. If we do not do this, a legitimate router could appear in other links, and fool hosts to use itself as a default router, even for traffic which uses prefixes that the router is not authorized to advertise. I guess the question is what the certificates actually authorize the router to do: to advertise prefixes, or to route traffic? Our own document seems confused on this point. Extract from Section 6.1.1: The X.509 IP address extension MUST contain at least one addressesOrRanges element that contains 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. We have the following alternatives: (1) Define the IP addresses as *advertisement* rights. No checks for using a default router. (2) Define the IP addresses as *routing* rights. Then routers might actually advertise less prefixes than they are authorized to route. A check would be needed to prevent hosts from using a default router for packets that have a source address not belonging to the authorized set. (3) Do (1) now and work on (2) later. I think option (2) sounds the right one. What do others think? Are there any issues in the host routing check that this would imply? Note that it would be at least conceptually a per-packet check. ------- James Kempf: I agree with option 2 but I don't think we need to specify how to do ingress filtering in the document, though it might be worthwhile to reference a document where it is described. A reference might be hard to track down, though, since it is such a commonly known security technique. ------- Greg Daley: How about: RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Also BCP0038) (Status: BEST CURRENT PRACTICE) I've only had a cursory look through (It's the current BCP though). It's a bit dated regarding the IPv4 addresses in the examples. but it may provide a good starting point. ------- Pekka Savola: I don't know anything about this SEND issue, but if you're interested about ingress filtering issues, I'd suggest taking a peek at draft-savola-bcp38-multihoming-update-02.txt .. it tries to update BCP38 a bit. (the doc is 95% done the IESG review and waiting for a revision to be published.) ------- Jari Arkko: I have thought some more of this. Unfortunately, I don't think adding a reference to ingress filtering is sufficient. The issue is not about how to do ingress filtering -- I was merely pointing out that if hosts never use default routers unless they are authorized for the given prefix, then the effect is that SEND nodes perform automatic ingress filtering for themselves. This does not remove the need for traditional ingress filtering because there could still be evil or non-SEND nodes. Anyway, the real issue is what kind of implications alternative 2 has for host implementations. Let me try to characterize the required changes: currently, hosts maintain a default router list. The default router which is currently in use is used for all outgoing non-local traffic (under error condititions we may round-robin through the other default routers). However, what is being proposed in alternative 2 is that a host would NOT be allowed to send packet with source prefix P to the default router unless this router was authorized to route P. Why is this a problem? It is not a problem, normally, because all the routers on the link would share the same set of authorized prefixes. Then the host can operate in the usual manner; it either has entries in the default router list or it doesn't. But any router is as good as the others. However, what if the routers have different authorizations? Then the algorithm to send a packet gets more complicated: instead of selecting the current default router, you'd have to find one that supports the prefix used in the source address field of the outgoing packet. Is this an issue? You tell me... For all I know, someone could have a hardware-based host IP layer which would be affected by this change. Is there something we can do about it? Could we require that on a SEND-enabled link, all routers be given the same authorized prefixes? Perhaps, but I fear error, configuration problem, and attack cases that would cause some trouble if we did this. Or can we design some way to pick the "largest" set of authorized prefixes from the default router candidates, and exclude other routers? ------- Mohan Prasarthy writes: >We have the following alternatives: > > (1) Define the IP addresses as *advertisement* rights. No checks > for using a default router. > (2) Define the IP addresses as *routing* rights. Then routers > might actually advertise less prefixes than they are authorized > to route. A check would be needed to prevent hosts from using > a default router for packets that have a source address not > belonging to the authorized set. I see the above as two separate set of rights. Why do we have to link them together ? When a router is considered as a default router, it means it can route for all packets whose *destination* address is considered off-link by the hosts. This has nothing to do with the source prefix (at least from the base IPv6 specs). If the host thinks that the router is authorized to be a default router, then it initialzes the default router list. Then, the default router selection whatever it may be, works transparently. ------- Jari Arkko writes: I think you are advocating alternative 1, i.e. having the cert extensions talk only about advertisement. And the ability of a router to act as a default router would be a separate thing, implied by the existence of any cert from the trusted root. The only thing that this does not address is that a legitimate router from link A could appear on link B and grab packets since it is the "default router". But you have a point about IPv6 separating advertisement and default routing. We should not change the IPv6 architecture in this respect in SEND. That leaves us with just two options: either we do as is suggested above, or we do that and in addition define "routing rights" to the certs. I'm starting to think that defining routing rights is too troublesome right now, and could be done as a later extension. So I agree with your suggestion Mohan. Here's the planned changes to the document: (1) We make it clear that the cert extensions apply to advertisement, not default router selection. (2) Add a description of the remaining attack in the security considerations section. One question remains: is there a need to say somewhere that SEND hosts should prefer a default router which has advertised the prefixes that the host uses. It might be possible to put a recommendation for this in the security considerations section. ------- Pekka Nikander: I haven't yet made my mind about the primary problem, but with regard to your implementation thoughts: > However, what is being proposed in alternative 2 is that a host would > NOT be allowed to send packet with source prefix P to the default > router unless this router was authorized to route P. > ... > However, what if the routers have different authorizations? Then > the algorithm to send a packet gets more complicated: instead of > selecting the current default router, you'd have to find one that > supports the prefix used in the source address field of the outgoing > packet. > > Is this an issue? I think that this sounds actually *good*. If we consider a case of a SoHo network connected through two different ISPs, both advertising different prefixes, what we need is exactly this kind of functionality. The host should select the outgoing router based on the source address (or vice versa, in the case of initial packets with undefined address from upper layers.) If we adopt this, I think that it becomes important to be able to override this with redirects. That is, it should be acceptable to get a redirect from an authorized router saying that the packets should still be sent to another router, even if the source address rule would not allow that. Finally, *if* we adopt this, IMHO it should be a SHOULD, not MUST. There may be reasons to configure a host otherwise, or to implement the default rule in a different way. ------- Mohan Prasarthy: > The only thing that this does not address is that a legitimate router > from link A could appear on link B and grab packets since it is the > "default router". I am trying to understand this a bit more. Are you saying that this threat exists even in the presence of a cert that says "router A is a default router" because it does not specify the link on which this router can be a default router ? > But you have a point about IPv6 separating advertisement and default > routing. We should not change the IPv6 architecture in this respect > in SEND. > > That leaves us with just two options: either we do as is suggested > above, or we do that and in addition define "routing rights" to the > certs. > > I'm starting to think that defining routing rights is too troublesome > right now, and could be done as a later extension. So I agree with > your suggestion Mohan. Here's the planned changes to the document: > > (1) We make it clear that the cert extensions apply to advertisement, > not default router selection. > (2) Add a description of the remaining attack in the security > considerations section. I agree that this sounds simple. But it is not still clear to me as to what the difficulty with respect to requiring a different cert for routing rights. Could you clarify ? > One question remains: is there a need to say somewhere that SEND hosts > should prefer a default router which has advertised the prefixes that > the host uses. It might be possible to put a recommendation for this > in the security considerations section. This again tries to link them together. I think we should just mention the threat if we are going to use the cert just for the advertisements. ------- Jari Arkko: > I am trying to understand this a bit more. Are you saying that this threat > exists even in the presence of a cert that says "router A is a default > router" because it does not specify the link on which this router can be a > default router ? Yes. > I agree that this sounds simple. But it is not still clear to me as to what > the > difficulty with respect to requiring a different cert for routing rights. > Could you clarify ? Yes. Hmm... here are some possible difficulties. I must confess that it is not a very compelling list. 1) If we have just one set of IP address rights in the certs, then we can use the ones defined in the pkix draft. If we need more, we need to define our own. 2) Some other unknown problem; we haven't thought about the routing right certs for a very long time. >> One question remains: is there a need to say somewhere that SEND hosts >> should prefer a default router which has advertised the prefixes that >> the host uses. It might be possible to put a recommendation for this >> in the security considerations section. > > This again tries to link them together. I think we should just mention the > threat > if we are going to use the cert just for the advertisements. Ok. ------- Jari Arkko: > I think that this sounds actually *good*. If we > consider a case of a SoHo network connected through > two different ISPs, both advertising different prefixes, > what we need is exactly this kind of functionality. > The host should select the outgoing router based on > the source address (or vice versa, in the case of > initial packets with undefined address from upper > layers.) I agree. OTOH, you could argue this is a general IPv6 or multi6 WG issue, and SEND should not go and fix their protocols ;-) Where does this leave us? You tell me... ------- James Kempf: 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, draft-ietf-pkix-x509-addr-as-extn has this to say about the purpose of the extension: This document defines two X.509 v3 certificate extensions that authorize the transfer of the right to use IP addresses and autonomous system identifiers from IANA through the regional Internet registries (RIRs) to Internet service providers (ISPs) and user organizations. The first binds a list of IP address blocks, often represented as IP address prefixes, to the subject (private key holder) of a certificate. The second binds a list of autonomous system (AS) identifiers to the subject (private key holder) of a certificate. The issuer of the certificate is an entity (e.g., the IANA, a regional Internet registry, or an ISP) that has the authority to transfer custodianship ("allocate") of the set of IP address blocks and AS identifiers to the subject of the certificate. These certificates provide a scalable means of verifying the usage right of IP address prefixes and AS identifiers, and may be used by routing protocols, such as Secure BGP [S-BGP], to verify legitimacy and correctness of routing information, or by Internet routing registries to verify data that they receive. While this doesn't rule out other uses, it does say the extension is specifically intended to authorize routing. If the host is not required to check its address against the prefixes in the certificate, then the prefix extension essentially serves no purpose and we can remove it. Presumably the signature on the RS allows the host to tell whether the prefixes in the advertisement were those intended to be advertised by the router. On the other hand, if the host is required to check, then the prefix extension serves as a means whereby the host can determine whether the router was authorized by its ISP to route those prefixes (and by route I mean here that the router is authorized to ingress filter so that only hosts claiming addresses with those prefixes can get packets on and off the link, since as was brought up earlier in this thread, default routing means taking packets from anybody on the link). While the distinction is not particularly important for stateless autoconfiguration, since the host will form prefixes from advertised prefixes anyway and the advertised prefixes would also presumably be certified, it could be useful for stateful autoconfiguration to the extent that it prevents an attacker from masqurading as a legitimate DHCP server and handing out bogus addresses. If there's an issue with multiple routers on a link advertising different prefixes, the ISP can configure the routers with certificates that have no prefix extension. This authorizes the router to route any prefix, and the host can send packets with an address having one prefix to a router that didn't advertise that prefix. There might also be an advantage to checking prefixes in situations where multiple ISPs are sharing the same last hop wireless (for example) link infrastructure. In that case, each ISP might have a different router, with a different set of certificates authorizing different prefixes. I agree that this is making a change in the way last hop routing is handled on IPv6, but the change is to introduce a level of authorization checking into last hop routing, that is, to make last hop routing more secure. Since that is the entire purpose of SEND, I believe it is an entirely appropriate change, exactly as for S-BGP and interdomain routing. So, in summary, I think the draft should say: - Nodes SHOULD check the advertised prefixes against the certified prefixes if the router certificate contains a prefix extension. Nodes SHOULD use one of the certified prefixes for stateless autoconfiguration. If none of the advertised prefixes match, then either there is a configuration problem or the advertising router is an attacker, and the host MUST use a different advertising router (if available) and inform the network operator. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified prefixes and MUST NOT use the address if the prefix is not certified. If the prefix is not certified, the node MUST inform the network operator, since it is either a misconfiguration or an attack. - 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. - Network operators that do not want to constrain particular routers to specific prefixes SHOULD configure routers with certificates in which there is no prefix extension (or maybe the null extension?). ------- Jari Arkko: Ok, I'm convinced. Mohan, Pekka? I did change your text a bit, James: o Reformulated the first part, e.g. added a MUST rule to discard the PI if the check fails. o I changed "use a router" to "use a router as its default router" to make it clear that we are using the router not just to get an address, but also to forward our packets. o I removed keywords related to informing the operator. Its hard for any product to comply to such a requirement. o Allowed either the null prefix or no prefix extension at all. Here's the new text and diff: http://www.arkko.com/publications/send/drafts/draft-send-ndopt.html#pivalidation http://www.arkko.com/publications/send/issues/issue44diff.html ------- ------- -------