Subject: [MBONED] AMT - new message proposed

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 10:18:23 +0100

This was originally sent to the AMT mailist list last night but it was 
considered more appropriate for mboned.

There was some concern expressed on the AMT list about proposing changes

at this stage when AMT is in wg last call (apparently has been for some
time). 
But there was also concern expressed that *not* including key changes to
the 
spec at the earliest opportunity has little value.

I've made a slight correction to my posting last night, included here:

Tony
----------

I've been involved with testing the UT Dallas Gateway implementation 
and Cisco's Relay implementation over the past week or so.

A number of things have come to light which require more detailed /
tighter 
specification. I'll try and detail these later in a separate e-mail.

Tests have exposed an anomalous condition whereby the Relay and Gateway 
become out of sync; the Relay expires the tunnel but the G/w does not. 
This can probably be corrected by a clearer definition of tunnel expiry 
timeouts and what messages refresh them at what intervals. But there
still
may be situations where a Relay receives a Gateway message
"unexpectedly"
and there are other scenarios, described below, that need further 
consideration. 

To cater for these scenarios I'm proposing the introduction of a new
message
type: RESET. 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x7  |   Len |  IPV  |    Reason     |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Response Nonce (bounced by Relay)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Alternate Relay IP address #1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ..............                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Alternate Relay IP address #n                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: message type 0x7 RESET
Len: length of this message in 32-bit words
IPV: IP version of any addresses being carried
Reason: codes tbc
Response Nonce: Nonce from the Gateway's message that triggered this
Reset 
Alternate IP address: IP address of alternate Relay

It essentially works like this:

The Reset is only ever issued by the Relay.

It's sent when the Relay receives any message *other than a Discover*
but 
the Relay has no tunnel to the said G/w. In this situation something has

clearly gone wrong. 

The G/w keeps track of the Nonces on outstanding messages sent to a 
particular Relay.If a Reset is returned which includes any of those 
outstanding Nonces the G/w immediately tears down its tunnel with that 
Relay and re-Discovers. 

There's also the situation where, for policy reasons, or strict tunnel
limits, 
the Relay refuses a G/w Discover...

If the Relay has reached its tunnel limit, the Relay should withdraw the

anycast prefix [suggested by Dino@cisco]. There could be a transient
state 
where the Discover arrives but it's not quite withdrawn the prefix yet. 
In this case the Reset "reason" code should indicate that. In response
the 
G/w would wait 1-2 secs before re-Discovering rather than re-Discovering

immediately.

Policy might dicate only certain IP addresses can set up a tunnel. In
this 
case the Relay should respond to non-authorized Gateways with a Reset
with 
at least 1 alternate Relay IP address (configured). This means the Relay

has to accept (if it doesn't already) Discovers not targeted at the
Relay 
anycast address.

Could we find consensus for this?

Tony
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 30 Sep 2008 09:37:26 -0400

Hello;

On Sep 30, 2008, at 5:18 AM, Tony Ballardie wrote:

> timeouts and what messages refresh them at what intervals.

<Wearing no hats>

Uncovering bugs by encouraging implementation, tests and deployment is  
a good thing.

Now, it is necessary to evaluate the severity of the problem.

How much of a problem was this in your testing ? How severe would you  
rate this issue ?

Given that resources are limited, would it be better for us to spend  
effort
achieving a "clearer definition of tunnel expiry timeouts and what  
messages refresh them at what intervals,"
or by adopting the reset message ?

> But there

Does this happen otherwise in testing ? Or is this just a "it would be  
nice" corner case.

The other deployers and testers should feel free to chime in here.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 30 Sep 2008 09:37:26 -0400

Hello;

<Wearing no hats>

Regards
Marshall

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 15:43:10 +0100

> How much of a problem was this in your testing ? How severe would you

It is (or was since fixes have been implemented) a failure scenario. I
was experiencing a situation where my Gateway would establish a tunnel,
I'd join a group and receive data over it, but the tunnel would expire
because the G/w sent no REQUESTs to refresh the Relay's state, so the
Relay expired the tunnel and data flow stopped.

> or by adopting the reset message ?

I think trying to get consensus on a clearer spec definition would be a
very good start.

> > still may be situations where a Relay receives a Gateway message
> > "unexpectedly"
> 

I'd suggest it's necessary for protocol completeness. 

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 15:43:10 +0100

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 16:20:30 +0100

Here are the key issues I think need tightening up.

Note: I propose some suggestions below, some of which are motivated by
the fact that we MUST bear in mind that a vast deployed user base uses
Windows, and MS Windows Media has a "multicast timeout" of about 10secs;
if no mcast data flows by then the protocol "rolls over" to a unicast
alternative. Not expressing a MS preference, just reality. It's vital we
take WM into account.

Proposals:

- the AMT Query should not be able to dictate how often the G/w sends an
AMT Request. The G/w must dictate this for local firewall policy
reasons. Many home router stateful firewalls have a default state
timeout of 30secs or less [I'd like to get more stats on this if anyone
has any?].

- the AMT Request interval needs defining, taking into account the
above. Suggestion: 25secs [REQUEST_INTERVAL].

- how many Requests per interval should be sent and at what frequency?
Suggestion: 3 Requests per interval, sent within a 2sec [i.e.
REQUEST_TIMEOUT - see below] interval.

- need to specify how lack of Request response (AMT QUERY) is handled.
Important for protocol robustness. Suggestion: re-Discover if, after
[REQUEST_TIMEOUT], no QUERY is received.

- Relay Discovery: during a Discover event, how many should be sent and
at what frequency? Suggestion: send 3 within a 3sec [DISCOVERY_TIMEOUT]
interval.

- Should specify an action if there's no response to a Discover, e.g.
log message to AMT console. Exit?

- for firewall state reasons, I would recommend not allowing the
flexibility for Requests to use different source port numbers, or a
different source port from the Discover. [I don't see what's to be
gained from allowing that, only potential negatives due to firewall].

- the AMT Request packet format diagram is titled "AMT Relay
Advertisement" in revision 09 of the draft.

- integration of new RESET message for protocol completeness, and to
convey tunnel refusal (e.g. due to policy restrictions) from a Relay to
a G/w.

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 16:20:30 +0100

Proposals:

Tony