NBNS & IP addresses.

[Christopher R. Hertel]

[
  This is part of discussion going on over on the jCIFS list.  The jCIFS
  team (DD, in particular) is currently working on a NetBIOS Name Server
  (NBNS, aka WINS) implementation in Java.  This question came up: 

  When a name registration arrives, if the source address in the UDP
  header does not match the NB_ADDRESS field value, what should we do with
  the request?

  I'm CCing the Samba-tech list because it's an interesting discussion
  (IMHO).  The previous message is viewable from the jCIFS email archive,
  which is at:  http://lists.samba.org/listproc/jCIFS/

  Chris -)-----
]

Dave CB writes:
> 	Hmmn: if you mean in rfc 1002 sect 5.1.4.1, a name registration
> 	request should, if accepted, result in the registrant being
> 	granted ownership of the name. In the old NetBLOOIE scheme
> 	the address would have to be an ethernet address, come
> 	from the packet and be unique courtesy of the roms on the 
> 	sender's ethernet card.

Yep.

In the original NetBIOS system, the name *was* an address.  NetBEUI mapped
the NetBIOS names to different MAC addresses, Ethernet or Token Ring. 
RFC1001,1002 maps the NetBIOS names to IP addresses.  It's basically the
same idea, except that mapping to the layer-three IP address instead of a
MAC address makes it possible for the virtual NetBIOS LAN to extend over a
routed network.  At the heart of it, what you are doing is emulating a
NetBIOS LAN (and jumping through some wild hoops to do it). 

> 	In the IP world, the situation is almost the inverse: names
> 	are relatively unimportant, and addresses don't have any
> 	strong guarantees associated with them.

It depends on how you think of it.  Again, a NetBIOS name is a MAC address
on a NetBIOS LAN.  Don't let the fact that it's alpha-numeric throw you. 

> 	So let's look at the possible cases
> 
> Case Description	Addresses	Result
> ==== ===========	========	======
> 1    sender is sane	match		no problem, use either
> 
> 2    sender is multihomed differ	use either or both

A while back I had an E'mail conversation with Jeremy (Jeremy Allison,
Samba-Team Co-captain) about this.  As I recall (and I really do need to
check on this because it was a while ago), the way that multi-homed hosts
are handled is that name registrations must be *sent from the interface
registering the name*.  This ensures that the packet and NB_ADDRESS IP
values match.

> 3    sender goofs	differ		we use return address
> 
> 4    someone's lying	differ		we reject the lie

These two are basically the same.  Treat them as a lie.

> 5    someone's proxying	differ		we use NB_ADDRESS

Good question.  There's WINS Proxy code in nmbd I think.  Best to have a
look.

> 	From the server, we can't tell a goof from a multihost from 
> 	a lie from a proxy, based on the contents of the packet.

You're right that all we know is that the IPs match, or that they don't.

> 	The only additional data we can obtain is the canonical
> 	mapping of the name to zero or more IP addresses, if we
> 	can do a DNS lookup in the time allowed. 

That assumes that the DNS and NetBIOS names map to one another.  This is
a bad assumption in many cases.  Microsoft have had trouble with this.

> 	In the case of  multihomed hosts, we would "have" to look in 
> 	the DNS to find out that they're multihomed. However, a 
> 	multihomed host is going to have **problems** if it tries 
> 	to register multiple copies of a supposedly-unique name.

Can't trust the DNS.  I think we're going to have to see how Samba handles
multi-homed hosts.

> 	That means a multihomed machine is not going to be able to
> 	convince an rfc-compliant NBNS to register more than one ip 
> 	address for it, which could make routing somewhat indirect (;-))

Who said that there is such a thing as an RFC-compliant NBNS?

> 	More importantly, it reduces case 2 to either-or, not both.

Yep.  The fudge work-around is that the multi-homed host must send its
registrations from the correct interface.

> 	If we accept the name, we have to chose one of the two addresses.
> 	In the case of an error, the return address is the obvious right 
> 	one: it actually worked. If we use NB_ADDRESS, it may or may not work.

Yep.

> 	Case 4 is a denial of service attack.  Machine Z wants to set 
> 	the name to a bogus value.  We could reject it, accept and set 
> 	it to <bogus>  or accept and set it to Z. 
> 	If we set it to either <bogus> or Z , the real owner of the name 
> 	will go into name-challenge processing and probably fail.

I've actually seen NBNS corruption attacks.  My gut would be to deny a
registration if the two IPs don't match, but I think we'll have to see
what Samba and NT do.

> 	Case 5, proxying, implies we should use the address passed.
> 	Samba does do wins proxying, but not this kind...

A WINS Proxy allows a B node (broadcast only) to use the WINS database
(without knowing it's doing so).  So, a WINS Proxy passes a broadcast
query to the NBNS in point-to-point fashion, and then hands back the
result.  The question is:  Does a WINS proxy also send broadcast
registration requests to the NBNS server? 

> 	If we eliminate proxying, we get "use return address" as
> 	the answer save in the case of someone lying.

...so should we assume that a mismatch is lying, or that it's an error.  I
say the former, since a non-broken implementation shouldn't send a
mismatch. 

> 	I'm tempted to try an experiment: try two possible
> 	scenarios and see what the clients do, and
> 	specifically what error message they provide to the
> 	user/sysadmin.

It would be interesting to see what the Samba and NT NBNS servers do if
there is a mismatch.

> 	1) Deny, and say we had a conflict with an existing address.
> 	   return the NB_ADDRESS as the one that the client should
> 	   talk to.  This will probably just cause the clients to
> 	   go insane trying to talk to themselves, then try to do
> 	   the same dumb mistaken registry again. Vary the reason
> 	   among Refused error, Active error (common case) and 
> 	   Name in conflict error to see which works best.

Oh, this would be fun!

> 	2) Accept, and use NB_ADDRESS to see what happens.
> 	   It may just cause challenge processing. It may cause
> 	   code paths to be used for the very first time in history (;-))
> 
> 	The latter would allow proxying, and would not make the denial-
> 	of servcie attack any worse.  It might, however, not be supported
> 	by the client implementations.

So, when can you send us your results!?

Chris -)-----

-- 
Samba Team -- http://samba.org/                -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/               -)----- crh at ubiqx.mn.org
ubiqx Team -- http://www.interads.co.uk/~crh/ubiqx/