Re: [CARD Technical Issue] U flag and Unsolicited CARD

> > > The draft also contains no guidelines about unsolicited. What is the
> > default
> > > intermessage time on broadcast/multicast? What about the port number
and
> > > TTL?
> > >
> > [eunsoo] Since it is the AR that sends the unsolicited CARD replies, the
> > transmission rate will depend on the configuration. We tried to avoid
> > recommending an arbitrary number as default values without base.
> >
>
> A default rate must be specified. The IESG will insist on this. See RFC
2608
> for an example.
>
[eunsoo] If the IESG insist on setting the default value, we can set the
default maximum transmission rate of the unsolicited replies. Since
unsolicited replies would not involve time-sensitive operation, it should be
fine. A simple guess is "maximum once per second" like the router
advertisement. What do you think?

> > The same port number as the solicited CARD reply is used for the
> unsolicted
> > CARD reply.
> >
>
> OK.
>
> > What do you think would be the proper TTL for the unsolicited CARD
reply?
> I
> > thought TTL 1 should be fine between MN-AR.
> >
>
> If you make it 255, then the reply must have come from a node on the same
> link. This is a cheap way to prevent an offlink attacker from sending
bogus
> CARD replies. RFC 2461 uses this technique. The node should reject the
> message if the TTL is not 255.
>
[eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How
about AR-AR?

> > > Also, I'm not clear about why an unsolicited message needs to be
marked.
> > How
> > > would a MN utilize the U flag? How would processing of a solicited
v.s.
> > > unsolicited message differ?
> > >
> > >
> >
> > For solicited CARD replies, the receiver needs to match the reply to the
> > request by the sequence number. For unsolicited replies, there is no
> > matching request and thus the receiver should be able to distinguish the
> > unsolicted replies from the solicited ones.
> >
>
> How are replay attacks prevented in the multicast case?
>
[eunsoo] The unsolicited replies should have incremented sequence values and
thus the receiver will be able to differentiate newer messages from older
messages. Certainly the sequence number is generated by the sender and thus
the receiver does not match it to any of its requests. This is not
explicitly mentioned in the current draft. Thanks for the good point. I
think we can add it into the next revision.

Eunsoo