Subject: Re: DCS and DCA semantics

From: Jonathan Wood <[email-masked]>
Date: Sun, 2 Nov 2003 17:30:32 -0800

On Oct 30, 2003, at 8:33 AM, Jari Arkko wrote:

> Jonathan Wood wrote:

<...>

>> 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)

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.

Jon

>
> --Jari
>
>
> --------------------------------------------------------------------
> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
> body to <[email-masked]>.
> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
> --------------------------------------------------------------------

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------