Subject: DCS and DCA semantics

From: Jonathan Wood <[email-masked]>
Date: Wed, 15 Oct 2003 19:01:28 -0700

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.

Jonathan

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

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Oct 2003 09:59:42 +0200

Jon,

Unfortunately I don't have time to think about or
incorprate these changes now.  Hence, we have to
wait for -01 with this.

Jari,

Could you create a new trackable issue on this?

--Pekka

> if the host cannot form a delegation chain for the RA. So I think the text
> unsolicited RAs. Usually hosts that care about the certificates in a DCA 
> will
> DCAs could be useful is if they contain proxied certificates for routers on
> receiving RAs). So if I'm not missing something, I propose that the wording

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2003 18:33:54 +0200

> so in many cases I don't think this is appropriate.

Ok, reading on...

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

> to perhaps just some text about rate limiting (if even that is 

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.

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

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

> probably not common). So the rate-limiting rule mostly misses the

Ok.

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

--Jari