Jonathan Wood: Sections 6.6 and 6.7 discuss how DCS and DCA should be sent and processed. Much of this is based on RD semantics from RFC 2461. However, DCS and DCA semantics are different from RD, so in many cases I don't think this is appropriate. Specifically: Section 6.7 says When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Delegation Chain Advertisement. To obtain such advertisements quickly, a host MAY transmit up to MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation Chain Solicitations MAY be sent after any of the following events: o The interface is initialized at system startup time. o The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. o The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. o The host attaches to a link for the first time. o A movement has been indicated by lower layers or has been inferred from changed information in a Router Advertisement. o The host re-attaches to a link after being detached for some time. o A Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. All these will happen naturally as a consequence of a RS/RA exchange, if the host cannot form a delegation chain for the RA. So I think the text quoted above could be replaced with just the last item: o A Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. The following should also be changed: Delegation Chain Solicitations SHOULD be rate limited and timed similarly with Router Solicitations, as specified in RFC 2461 [6]. to perhaps just some text about rate limiting (if even that is necessary...) Section 6.6 says Routers MAY send unsolicited Delegation Chain Advertisements for their configured trust anchor(s). When such advertisements are sent, their timing MUST follow the rules given for Router Advertisements in RFC 2461 [6]. Periodic, unsolicited DCAs, however, do not serve the same purpose as unsolicited RAs. Usually hosts that care about the certificates in a DCA will have already retrieved them as a consequence of receiving an RA, or they won't care about them at all. The only case I can think of where unsolicited DCAs could be useful is if they contain proxied certificates for routers on other links (in which case hosts would not be able to discovery them by receiving RAs). So if I'm not missing something, I propose that the wording be changed to make this explicit, i.e. Routers MAY send unsolicited Delegation Chain Advertisements for other routers that hosts may encounter on other links. Routers should not otherwise send unsolicited Delegation Chain Advertisements. I'm not sure I agree with the timing rules either - some randomization as per RFC 2461 is probably a good thing, but we don't need to inherit the complexity involved with sending adverts more frequently on startup. Regarding DCA rate limiting, RFC 2461 only mandates rate limiting for RAs sent to the all-nodes multicast group. DCAs (as currently specified) are only sent to all-nodes if unsolicited (in which case rate limiting is moot) or the DCS has an unspecified address (which is probably not common). So the rate-limiting rule mostly misses the mark. In fact, one scenario where it would be useful is when a router first comes up. It will multicast an RA, which will likely cause all hosts to send DCSs, which will in turn cause the router to multicast (to the solicited-node MC address) a storm of DCAs. Since the rate limiting only covers all-nodes MC, it will not prevent this (and if it did, many nodes would not be able to process the RA). To handle this sort of situation, I propose all multicast DCAs be rate limited and monitored. If a router finds that it is responding to a DCS too soon after one has just been sent, it should set the DCA's ID to 0 and multicast it to the all-nodes group. This should ensure both that the network is not flooded with DCAs and that all nodes receive the DCA. ------------ Jari Arkko: > Sections 6.6 and 6.7 discuss how DCS and DCA should be sent > and processed. Much of this is based on RD semantics from RFC > 2461. However, DCS and DCA semantics are different from RD, > so in many cases I don't think this is appropriate. Ok, reading on... > Specifically: > > Section 6.7 says > > When an interface becomes enabled, a host may be unwilling to wait > for the next unsolicited Delegation Chain Advertisement. To obtain > such advertisements quickly, a host MAY transmit up to > MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each > separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation > Chain Solicitations MAY be sent after any of the following events: > o The interface is initialized at system startup time. > o The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > o The system changes from being a router to being a host, by having > its IP forwarding capability turned off by system management. > o The host attaches to a link for the first time. > o A movement has been indicated by lower layers or has been inferred > from changed information in a Router Advertisement. > o The host re-attaches to a link after being detached for some time. > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. > > All these will happen naturally as a consequence of a RS/RA exchange, > if the host cannot form a delegation chain for the RA. So I think the text > quoted above could be replaced with just the last item: > > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. Hmm... this sounds very good actually. It even covers the case when the router's key is re-configured but everything else stays the same. Just one check: you are replacing just the items, and keeping the rate limiting? I think we need that. Perhaps this could be the final text: The host has a need to retrieve a delegation chain when a Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. In these situations, the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain Solicitation messages, each separated by at least DCS_INTERVAL seconds. (And MAX_DCS_MESSAGES would be defined similarly to MAX_RTR_SOLICITATIONS, and DCS_INTERVAL similarly for RTR_SOLICITATION_INTERVAL) > The following should also be changed: > > Delegation Chain Solicitations SHOULD be rate limited and timed > similarly with Router Solicitations, as specified in RFC 2461 [6]. > > to perhaps just some text about rate limiting (if even that is > necessary...) Ah, you thought about this too. Well, I think the host should be able to send multiple messages if there's packet loss, but not too often. Maybe the text that I provided above works. > Section 6.6 says > > Routers MAY send unsolicited Delegation Chain Advertisements for > their configured trust anchor(s). When such advertisements are sent, > their timing MUST follow the rules given for Router Advertisements in > RFC 2461 [6]. > > Periodic, unsolicited DCAs, however, do not serve the same purpose as > unsolicited RAs. Usually hosts that care about the certificates in a DCA > will > have already retrieved them as a consequence of receiving an RA, or > they won't care about them at all. The only case I can think of where > unsolicited > DCAs could be useful is if they contain proxied certificates for routers on > other links (in which case hosts would not be able to discovery them by > receiving RAs). So if I'm not missing something, I propose that the wording > be changed to make this explicit, i.e. Routers are allowed to send the DCAs to the specific node (or its solicited-node address to be more exact). A periodic DCA to the all-nodes address might be received by all hosts. OTOH, the routers are also allowed to the send the solicited DCAs to the all-nodes address. This depends on what the source of the DCS was. If there's multiple nodes coming to the link at the same time, they probably don't have an address yet, and the DCA goes to all then... maybe you are right and we don't need periodic DCAs. > Routers MAY send unsolicited Delegation Chain Advertisements for other > routers that hosts may encounter on other links. Routers should not > otherwise send unsolicited Delegation Chain Advertisements. Hmm... there might be other means of receiving information from the other links. I wonder if we need a SEND specific scheme here. Delete periodic DCA completely? > I'm not sure I agree with the timing rules either - some randomization > as per RFC 2461 is probably a good thing, but we don't need to > inherit the complexity involved with sending adverts more frequently > on startup. > > Regarding DCA rate limiting, RFC 2461 only mandates rate limiting > for RAs sent to the all-nodes multicast group. DCAs (as currently > specified) are only sent to all-nodes if unsolicited (in which case rate > limiting is moot) or the DCS has an unspecified address (which is > probably not common). So the rate-limiting rule mostly misses the > mark. Ok. > In fact, one scenario where it would be useful is when a router first > comes up. It will multicast an RA, which will likely cause all hosts > to send DCSs, which will in turn cause the router to multicast (to the > solicited-node MC address) a storm of DCAs. Since the rate limiting > only covers all-nodes MC, it will not prevent this (and if it did, many > nodes would not be able to process the RA). To handle this sort of > situation, I propose all multicast DCAs be rate limited and monitored. > If a router finds that it is responding to a DCS too soon after one has > just been sent, it should set the DCA's ID to 0 and multicast it to the > all-nodes group. This should ensure both that the network is not > flooded with DCAs and that all nodes receive the DCA. Sounds good. Essentially, we'd be allowing the router to respond to the all-nodes address at its discretion. ------------ Jon Wood responds to Jari Arkko: > Hmm... this sounds very good actually. It even covers the case when the > router's key is re-configured but everything else stays the same. > > Just one check: you are replacing just the items, and keeping the > rate limiting? I think we need that. Perhaps this could be the final > text: > > The host has a need to retrieve a delegation chain when a > Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. In these > situations, the host MAY transmit up to MAX_DCS_MESSAGES > Delegation Chain Solicitation messages, each separated by at least > DCS_INTERVAL seconds. > > (And MAX_DCS_MESSAGES would be defined similarly to MAX_RTR_SOLICITATIONS, > and DCS_INTERVAL similarly for RTR_SOLICITATION_INTERVAL) Yes, I agree that we still need rate limiting. I think your text should cover it. > >> The following should also be changed: >> Delegation Chain Solicitations SHOULD be rate limited and timed >> similarly with Router Solicitations, as specified in RFC 2461 [6]. >> to perhaps just some text about rate limiting (if even that is necessary...) > > > Ah, you thought about this too. Well, I think the host should > be able to send multiple messages if there's packet loss, but > not too often. Maybe the text that I provided above works. Yes. > >> Section 6.6 says >> Routers MAY send unsolicited Delegation Chain Advertisements for >> their configured trust anchor(s). When such advertisements are sent, >> their timing MUST follow the rules given for Router Advertisements in >> RFC 2461 [6]. >> Periodic, unsolicited DCAs, however, do not serve the same purpose as >> unsolicited RAs. Usually hosts that care about the certificates in a DCA will >> have already retrieved them as a consequence of receiving an RA, or >> they won't care about them at all. The only case I can think of where unsolicited >> DCAs could be useful is if they contain proxied certificates for routers on >> other links (in which case hosts would not be able to discovery them by >> receiving RAs). So if I'm not missing something, I propose that the wording >> be changed to make this explicit, i.e. > > > Routers are allowed to send the DCAs to the specific node (or its solicited-node > address to be more exact). A periodic DCA to the all-nodes address might > be received by all hosts. OTOH, the routers are also allowed to the send the > solicited DCAs to the all-nodes address. This depends on what the source > of the DCS was. If there's multiple nodes coming to the link at the same > time, they probably don't have an address yet, and the DCA goes to all > then... maybe you are right and we don't need periodic DCAs. > >> Routers MAY send unsolicited Delegation Chain Advertisements for other >> routers that hosts may encounter on other links. Routers should not >> otherwise send unsolicited Delegation Chain Advertisements. > > > Hmm... there might be other means of receiving information from the > other links. I wonder if we need a SEND specific scheme here. Delete > periodic DCA completely? Yes, I think it probably should be removed completely. > >> I'm not sure I agree with the timing rules either - some randomization >> as per RFC 2461 is probably a good thing, but we don't need to >> inherit the complexity involved with sending adverts more frequently >> on startup. >> Regarding DCA rate limiting, RFC 2461 only mandates rate limiting >> for RAs sent to the all-nodes multicast group. DCAs (as currently >> specified) are only sent to all-nodes if unsolicited (in which case rate >> limiting is moot) or the DCS has an unspecified address (which is >> probably not common). So the rate-limiting rule mostly misses the >> mark. > > > Ok. > >> In fact, one scenario where it would be useful is when a router first >> comes up. It will multicast an RA, which will likely cause all hosts >> to send DCSs, which will in turn cause the router to multicast (to the >> solicited-node MC address) a storm of DCAs. Since the rate limiting >> only covers all-nodes MC, it will not prevent this (and if it did, many >> nodes would not be able to process the RA). To handle this sort of >> situation, I propose all multicast DCAs be rate limited and monitored. >> If a router finds that it is responding to a DCS too soon after one has >> just been sent, it should set the DCA's ID to 0 and multicast it to the >> all-nodes group. This should ensure both that the network is not >> flooded with DCAs and that all nodes receive the DCA. > > > Sounds good. Essentially, we'd be allowing the router to respond to > the all-nodes address at its discretion. Right. This is another reason to strike periodic DCA from the spec. ------------ ------------ ------------ ------------ ------------