Subject: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 14:56:22 -0700

Section 4.2.2 mentions that unsolicited broadcast is possible, why not
multicast? For IPv4, this would require a multicast address,  but for IPv6
it could be done to the All Nodes Multicast address on the link. There is no
broadcast in IPv6, so multicast will be required in that case anyway.

The draft also contains no guidelines about unsolicited. What is the default
intermessage time on broadcast/multicast? What about the port number and
TTL?

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?

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 2 Jul 2003 09:25:21 -0400

> broadcast in IPv6, so multicast will be required in that case anyway.
[eunsoo] Multicast is fine with me.

> intermessage time on broadcast/multicast? What about the port number and
[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.

The same port number as the solicited CARD reply is used for the unsolicted
CARD reply.

What do you think would be the proper TTL for the unsolicited CARD reply? I
thought TTL 1 should be fine between MN-AR.

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

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 14:53:39 -0700

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

> The same port number as the solicited CARD reply is used for the
unsolicted

OK.

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

> unsolicted replies from the solicited ones.

How are replay attacks prevented in the multicast case?

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 3 Jul 2003 10:33:20 -0400

> A default rate must be specified. The IESG will insist on this. See RFC
2608
[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?

> > What do you think would be the proper TTL for the unsolicited CARD
reply?
> I
[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
[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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 3 Jul 2003 09:23:32 -0700

> advertisement. What do you think?

Here are what some other protocols do.

1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value and
MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is 16
seconds.

2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways) suggests 12
hours for unsolicited DA advertisements. This is clearly too long for CARD,
since nodes can hand over at any time.

3) OSPF has a default route flooding period of about 20 min. This also seems
a bit long.

4) As a general observation, protocols that do excessive advertisement tend
to increase the base network load, reducing bandwidth for traffic, something
to be especially avoided on wireless networks. Novell's SAP for example was
infamous for this, and I am told that Apple Rendezvous can also if not
properly configured.

The question one must ask is if the MNs can solicit, what is the purpose of
the unsolicited message?  As an alternative, to reduce traffic from per MN
solicitations? If so, then having the message multicast more frequently than
the approximate lingering time of the MNs on the link won't end up saving
anything.

With this in mind, I'd suggest a default mean of 5 min, configurable to half
the approximate mean lingering time of mobile nodes on the link. The router
then randomly generates a time between 1 sec. and the mean for the actual
time (to avoid synchronization). An interesting experiment would be to look
at some data on 802.11 networks, like for example, the IETF network, and
find out long nodes do linger. YMMV of course, but it would give some more
realistic bounds.

Here are some other considerations:

1) If any of the CARD information changes, the router should multicast
immediately. The router should start by randomizing the initial message
between, say, 1 and 3 seconds in order to avoid clashes with other routers
on the link. And it should continue sending for, say 20 seconds, randomizing
the intermessage time, in case any of the messages are dropped. The draft
should recommend keeping dynamic attribute changes to a minimum, as this
would cause excessive advertisement. Perhaps a minimum change interval of 5
min.

2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:

   Unsolicited Router Advertisements are not strictly periodic: the
   interval between subsequent transmissions is randomized to reduce the
   probability of synchronization with the advertisements from other
   routers on the same link [SYNC].

The WG may want to consider requiring this of unsolicited CARD messages as
well.

3) Another way to avoid the clashing adverts problem is to have only one
router on the link do the advertisement. The WG may also want to consider
recommending that the protocol accommodate configuration such that one
router can be configured as the sole CARD multicast source. Or was the
protocol intended to accommodate different CARD information on routers
sharing the same link? It might be possible (but clearly undesirable from a
complexity standpoint) to have one set of access points in one geographical
area configured with one router and another with another but both routers on
the same subnet, and the possible CARs be different, since the possible
topological moves from the different geographical areas could be different.
The MIP group is grappling with this issue for movement detection, no
solution yet.

> [eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How

The check won't work in that case because there could be multiple hops
between the two. The two ARs should be using ESP to authenticate anyway.

            jak

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 4 Jul 2003 09:58:41 +0300 (EEST)

Hi,

I can't help but argue about the default value. There are so many
scenarios and network types that could make use of CARD that it would be
impossible to give a default value. In the worst case, with a WLAN
network, a user might only spend a few seconds within the cover area of
one AP, while in the IETF, most people are sitting down while the
connectivity is on, which implies a lingering time of minutes or even
hours...

I would go for a section that discusses shortly the transmission interval,
and could give some example values in different scenarios, but no
single standardized default.

My 2 cents,
Jukka

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Jul 2003 11:04:24 -0700

Jukka,

How is this any different than the default value for router discovery in RFC
2461? There are so many different kinds of wired links too: ATM, Ethernet,
token ring, PPP, etc.

            jak

----- Original Message ----- 
From: "Jukka MJ Manner" <[email-masked]>
To: "Seamoby Working Group" <[email-masked]>
Sent: Thursday, July 03, 2003 11:58 PM
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD

> > > > A default rate must be specified. The IESG will insist on this. See
RFC
> > > unsolicited replies would not involve time-sensitive operation, it
should
> > be
> > > > link. This is a cheap way to prevent an offlink attacker from
sending
> > > bogus

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 4 Jul 2003 21:27:42 +0300 (EEST)

Well,I guess it is not much different when you think about it...:)

Cheers,
Jukka