Re: NHS Address

[David Horton <[e-mail]>]

|Someone asked on the list why the NHS IP address appeared in the NHRP
|registration packet.
|
|I may be missing something obvious, but I think that we reduce configuration
|(and therefore misconfiguration) if we allow a station to insert its own
|address in that field in a registration request.  (The reply should still
|have the correct NHS address, as should any registration confirmation later.)
|If the request is being delivered to an NHS serving the clients LAG directly,
|it will recognize this and accept the request.  If the request is handed to
|an NHS serving some other LAG< routing will still send it towards the correct
|LAG, causing the correct handling.
|

The way I read NHRP-7, the destination prefix address is intended to
be the address of the NHS that the station is trying to register with.
I think inserting the station's own address will cause problems with NHRP-7:-
"					If an NHS receives an NHRP
   Registration Request packet which has the Destination Protocol
   Address field set to an address other than the NHS's own protocol
   address then the NHS MUST forwards the packet along the routed path
   toward the Destination Protocol Address."

Say the designated NHS for the Home LAG receives the packet with the 
destination NHS specified as other than itself. So according to the
above, it must forward it, which is undesired behaviour.

I think the problem becomes more evident when there is a LAG containing
several routers. All of these are assumed to be NHRP capable from the 
fabric mode assumption. (Without considering SCSP for the moment), all
of these could be capable of being NHRP servers, but at a particular
moment, only one is the designated NHS. 

(problem 1) In the first scenario, the registering station could be
one of the routers not acting as the NHS today. So the designated
NHS would be sending both registration reply and a (forwarded) 
registration request back to the router.
 

Consider the situation where there are multiple NHS within a LAG
which have some method outside of NHRP for determining which will
act as the designated NHS. This could be an operator editting files.
This allows some level of fault tolerance.

(problem 2) A station is taken off the net, and during the time it
is off-line,  the designated server changes. When reconnecting, the station 
registers with the old configuration, i.e. it uses the old NHS address.

This leads to an dilemma, does the router that first receives the register
(a) believe its configuration, and forward it to the designated NHS, or
(b) trust the registering station, and forward to the requested NHS
    (and then what does the requested station do, assuming it is up)
(c) both, but who sends the reply?

I think the correct approach is to ignore the destination address 
in the packet that was set by the station station, and to
follow the routing and NHS designated based solely on the station's
source protocol address. This is what will be consulted when forwarding
a resolution request. So there is not much point sending
registration data a different way where it can't be retrieved.

A conservative approach in terms of ensuring the data is actually
registered where it is needed would be to send to both (if there is a 
difference). This will lead to a loop with designated server
forwarding to the requested destination, and then back again
until the hop count expires. (Unless the NHS keep some additional state).

I am also a bit concerned about the addresses that the station 
could put in here, e.g. an address in a LIS other than its own, or
a broadcast address. Could these lead to avalanches?

>From my point of view, this station end configuration of its NHS 
can only lead to problems. Can someone provide examples where the
configuration is of assistance and resolution processing will also
still work?


|						The reply should still
| have the correct NHS address, as should any registration confirmation later.

I believe the responding NHS should insert its own address in the Request
reply. However I think this is in conflict with NHRP-7, which implies
that the field is the same as what the requesting station set.

There are situations where the requesting station needs to also obtain
the NMBA address of the serving NHS. I realise this can be achieved
through use of the responder address extension, however the end-end
authentication extension can't be used in conjunction with extensions
that modify the packet en-route, specifically forward/reverse transit.
To avoid this problem, we intend to define an experimental vendor specific 
end-end authentication extension which creates the signature only
over the fixed and mandatory parts. The problem is that the responder
address extension is not part of the signature, and hence open to 
tampering. 

Hence I propose putting the NBMA address of the NHS in the mandatory
part of the registration reply. This is analagous to the Next Hop
addresses being in the mandatory part of the resolution reply.

The destination prefix extension is still left hanging in the 
unauthenticated part, but I think I can live with that.

|Yours,
|Joel M. Halpern				[e-mail]
|Newbridge Networks Inc.
|

In summary, I propose 
(1) removing the Destination  Protocol Address from the 
    Registration Request packet.
(2) Adding a Server NBMA address to the Registration Reply packet,
    leaving (a possibly renamed) Destination  Protocol Address which
    is filled in by the responding NHS.

Cheers,
David

 David Horton
 Centre for Information Technology Research
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: [e-mail]       Phone [phone]   Fax [phone]