Loading ...
Sorry, an error occurred while loading the content.

RL-002 BACnet IP & NAT/PAT

Expand Messages
  • Roland Laird
    Dear BACnet/IP Working Group Members: I d like to share with the group the email exchange I had with Dean Matsen which raises the problems caused by Port
    Message 1 of 1 , Mar 10 2:47 PM
    • 0 Attachment

      Dear BACnet/IP Working Group Members:

       

      I’d like to share with the group the email exchange I had with Dean Matsen which raises the problems caused by Port Address Translation. It seems to be that PAT is main-stream and we will have to accommodate it. Please comment and see if we can find a solution. Also, it may be helpful to look back on Buddy Lott’s comments to the group which I believe raised the same concerns. I’ve attached the current revision of RL-002, with just minor changes since Chicago .

      Roland Laird

       


      From: Roland Laird [mailto:rlaird@...]
      Sent: Thursday, March 09, 2006 11:49 AM
      To: 'Matsen, Dean (WA26)'
      Subject: RE: About your BACnet/IP NAT proposal

       

      I’m starting to see what the issue is finally. This solution was not intended to address Port Address Translation (only static NAT). But, I agree there is no point making changes that are not going to work in the real world. I’m not able to think it through right now but will respond again – maybe tomorrow.

      Roland

       


      From: Matsen, Dean (WA26) [mailto:Dean.Matsen@...]
      Sent: Wednesday, March 08, 2006 4:00 PM
      To: Roland Laird
      Subject: RE: About your BACnet/IP NAT proposal

       

      Please think about this carefully.  You are assuming I am wrong and that you need to explain why I am wrong.  You need to think one level deeper than you are now.  Think about how the BACnet network layer accumulates information about what router to use to get to a specific network.  Don't forget that BACnet/IP implementations use concatenated IP Address + UDP port to represent a pseudo-MAC address.  This pseudo-MAC address is the only thing the BACnet network uses to address BACnet/IP devices, especially other BACnet routers.

       

      J.2.5 Forwarded-NPDU: Purpose

      This BVLL message is used in broadcast messages from a BBMD as well as in messages forwarded to registered foreign devices. It contains the source address of the original node as well as the original BACnet NPDU.

      Note that this language does not imply in any way that it is appropriate for two BBMD's to use a Forwarded-NPDU message for non-broadcast traffic.  This is the crux of the problem: what about non-broadcast traffic.  BACnet NPDU's that are NOT broadcasted are handled by the B/IP implementation, not by the BBMD.  The B/IP implementation forwards the message to the router for the target network using a message OTHER THAN the Forwarded-NPDU message.

       

      Yes, I understand that the message will be emitted into the public through the NAT router with an "SNET/SADR" that points back to the right place.  This is why we use BACnet routing for everything in a NAT environment.  but that is not the problem I am trying to explain.  This problem is different.  I only want to focus on the transaction between the two B/IP devices that are connecting the two BACnet networks.  Let's say the SNET of the message is 10.

       

      When the source B/IP implementation sends the message through the NAT router, the NAT router will place its IP address as the source address on the message and assign a random port to it.  Let's say the NAT router has a public address of 10.0.0.1.  The message it sends on will have a source address of (for example) 10.0.0.1:49152  (49152 = 0xC000, where 49152 is the randomly assigned source UDP port).

       

      The RECEIVING device will use the source IP address + UDP port to form the B/IP pseudo-MAC address.  This address is 0x0A000001C000.  

      The receiving device will update its routing infomation to say that the router to network 10 is B/IP address 0x0A000001C000.  However, this address is only a temporary back link using the temporarily assignd port 49152 (0xC000).

       

       

      The issue is NOT that it won't be delivered.  The issue is NOT that replies won't work most of the time.  The issue IS that the pseudo MAC address of the BACnet router (the B/IP pseudo-MAC) is randomly assigned by the NAT masquerading.  Furthermore, the address generally doesn't match the outside-to-inside forwarding address configured in the NAT router; in fact, it avoids it every time.

       

       

      Regards,

      Dean

       

       


      From: Roland Laird [mailto:rlaird@...]
      Sent: Wednesday, March 08, 2006 11:26 AM
      To: Matsen, Dean (WA26)
      Cc: Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

      You can have one device that resides on the actual BACnet Network that the BBMD is on. But, you don’t have to, its your choice. You can place the device itself on either side of the router.


      From: Matsen, Dean (WA26) [mailto:Dean.Matsen@...]
      Sent: Wednesday, March 08, 2006 11:14 AM
      To: Roland Laird
      Cc: Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

       

      I do understand the value of having all traffic going through the BACnet router.  However, I also have a device implemented at the B/IP implementation at the same subnet as the BBMD.  It is directly connected.  Its B/IP implementation is just another BACnet port to it.

       

      You are saying "on each subnet other than the BBMD".  What about the one device on the same subnet as the BBMD?  How do I implement it?

       

      Dean

       

       


      From: Roland Laird [mailto:rlaird@...]
      Sent: Wednesday, March 08, 2006 10:44 AM
      To: Matsen, Dean (WA26)
      Cc: Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

      Dean,

       

      I think the BIG POINT you are missing is that ALL communication from the IP subnet will be going through the BACnet Router integrated in the BBMD. All other devices behind the NAT router will be on a different BACnet Network. The “reply to” information will be in the BACnet network layer which the BBMD/BACnet Router will forward. This point is briefly made in the proposal:

       

      4) BACnet Devices on each subnet other than the BBMD must reside on a logically different BACnet network, and the BBMD device must also contain a BACnet router to those networks. This is because port forwarding results in all B/IP messages coming through the NAT router to be sent to only one address (the BBMD).

       

      Roland

       


      From: Matsen, Dean (WA26) [mailto:Dean.Matsen@...]
      Sent: Wednesday, March 08, 2006 10:20 AM
      To: Roland Laird
      Cc: Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

       

      Roland,

       

      Ok, I see what you mean about J.7.  Both of us are essentially arguing for the same device behavior in the end: all broadcasts need to be sent with Forwarded-NPDU messages.  My implementation doesn't actually send the broadcast to itself, but I see that the implementation needs to behave as if it did.  I will correct this part of my implementation.

       

      But your argument only covers broadcasts.  You mustn't forget that not all traffic goes through the BBMD, only broadcast traffic does.  This is even made more clear if you separate your BBMD and B/IP implementations and look at them separately.

       

      Read J.3.  It's short and to the point.  It is here that the masquerading issue is not resolved by the BBMD.

       

      The plain B/IP implementation will send messages directly to its peers, and this traffic will suffer the masquerading problem I have so far described.

      The recipient device will see messages coming from a randomly assigned B/IP pseudo MAC address.  The recipient must update its routing information when it sees an incoming message, so that it can update its "who is router to this network" information.

       

      The NAT router does not even have to change the temporary route for this to occur.  When a device issues an "I-Am" message (which is a broadcast), it will be sent with a Forwarded-NPDU message, which will have the correct NAT "reply to" address (note that this message will also go out of an on-the-fly mapping by the NAT router, but we compensate by having the originating address in the Forwarded-NPDU message).  However, subsequent traffic from the same device will go out (probably the same) masqueraded port, but without the embedded "reply to" information.  The receiving device has now received two messages from the same SNET from two different B/IP addresses.  The receiving device does not have a dependable MAC address (constructed from the source IP address + port) to answer the question "who is the router to network X".  This temporary route could change without notice to the BACnet devices, leading to intermittent connectivity.

       

       

      Roland, don't get me wrong.  I want your proposal to succeed.  I want to implement it and live happily ever after.  However, this issue needs to be addressed clearly and carefully.  If there are any assumptions being made that are outside the language of the standard, it needs to part of the proposal, otherwise interoperability will suffer.

       

       

      Dean

       

       

       


      From: Roland Laird [mailto:rlaird@...]
      Sent: Tuesday, March 07, 2006 3:11 PM
      To:Matsen, Dean (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

       

      The proposal will be expanded to include diagrams. The concept of having a router integrated into the same device as the BBMD is discussed in the J.7, so it is not new. A router integrated with the BBMD is necessary if more than one BACnet device is on the subnet because the port forwarding can only forward to one local IP. From there the BACnet router can route it to a different B/IP network with a different port number or an Ethernet network.

      As for always using forwarded NPDUs in NAT mode – I guess it may be another approach (verses an integrated router with the BBMD) to allowing more than one BACnet device behind a NAT router. Nobody’s suggested it before and I think it would require significantly more changes to the standard.

      Roland

       


      From:Matsen, Dean (WA26) [mailto:Dean.Matsen@...]
      Sent: Monday, March 06, 2006 4:32 PM
      To: Roland Laird
      Cc:Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

       

      Roland,

       

      It sounds like you are assuming my device can "send messages to itself" over B/IP (assuming it's all implemented in one device). 

       

      My BBMD implementation goes directly from BACnet to B/IP without depending on an intermediate B/IP link.  In fact, the BBMD functionality is basically just the B/IP implementation in an extended mode.  When I read Annex J, it seems to me it was implying this is the right way to do it.

       

      At the least, if your proposal if heavily dependent on either physical or virtual B/IP traffic, you should point that out in the caveat section.

       

      Aside from that, what about the other direction of using "Forwarded-NPDU" messages for everything when in "NAT mode" for a BBMD?

       

      Regards,

      Dean

       

       


      From: Roland Laird [mailto:rlaird@...]
      Sent: Monday, March 06, 2006 1:56 PM
      To:Matsen, Dean (WA26)
      Cc:Donaldson, Stuart (WA26)
      Subject: RE: About your BACnet/IP NAT proposal

       

      Hi Dean,

       

      I think there is some misunderstanding,

       

      All broadcasts between IP subnets will be forwarded NPDU’s.  The MS/TP network in point 1. you described would be routed to the B/IP network and send as an original bradcast. The NAT-Router would not forward it on as it is a broadcast. (If it did forward it you would not need the BBMD) The BBMD on the B/IP network (likely in the same device as the BACnet MS/TP to B/IP router) would pick it up and send it to the remote network as a forwarded NPDU.

       

      Roland

       


      From:Matsen, Dean (WA26) [mailto:Dean.Matsen@...]
      Sent: Monday, March 06, 2006 1:08 PM
      To: rlaird@...
      Cc:Donaldson, Stuart (WA26)
      Subject: About your BACnet/IP NAT proposal

       

       

      Roland,

       

      I think your proposal rl-002 regarding NAT support is an excellent idea, and I have even implemented a prototype.

       

      However, I noted something during operation of the prototype that may or may not throw a wrench into the

      works for this solution.  I did not think of it when I reviewed your document, and I wonder if you missed it

      too...

       

      In my first example, I have my NAT firewall set up this way:

       

      outside port: 10.0.0.1

      inside port: 192.168.1.1

      inside BACnet device: 192.168.1.100

      Forwarding 10.0.0.1:49001 -> 192.168.1.100:47808

       

      With the forwarding set this way, when device 192.168.1.100 sends a message outside the NAT firewall,

      the NAT masquerading preserves the "source UDP port" of 47808.  I assume there is a temporary mapping

      back to the device, for example:

      Temporary reply forwarding: 10.0.0.1:47808 -> 192.168.1.100:47808

       

       

      On the other hand, if I set up the NAT firewall like this:

       

      outside port: 10.0.0.1

      inside port: 192.168.1.1

      inside BACnet device: 192.168.1.100

      Forwarding 10.0.0.1:49001 -> 192.168.1.100:49001

       

      When device 192.168.1.100 sends a message outside the NAT firewall,  the NAT masquerading

      avoids port 49001 entirely, assigning a random "source port" to the message (say 51000 just for

      an example).  Once again, I assume there is a temporary mapping back to the original device:

      Temporary reply forwarding: 10.0.0.1:51000 -> 192.168.1.100:49001

       

      I guess the NAT system is assuming that the forwarding from 10.0.0.1:49001 -> 192.168.1.100:49001

      is for some special purpose, and probably unrelated to the outgoing message.  This is a logical

      assumption in the general case.

       

      The part that worries me about this is that NOT ALL messages sent between two BBMD's are

      "Forwarded-NPDU" messages.  In cases where the "Forwarded-NPDU" message is NOT used, the

      "source ip address:source port" becomes the effective MAC address of the originating device

      (and is the only "reply-to" information you have available).  The BACnet network layer uses this MAC

      information in many cases.  However, with the masquerading in effect, the MAC address may change

      from message to message according to the whims of the NAT router.

       

      In short, the Annex J networking is very dependent on the temporary forwarding entries in the NAT

      firewall.  There are unfavorable scenarios implied:

       

      1. The BACnet Network entity uses the source address of a transmission to determine the reply

      route back to a device.  Say an MS/TP device behind the firewall emits an "I-Am" message.  This message

      will get sent by the NAT-enabled BBMD as an "Original-Broadcast" (since it's BACnet routing,

      not special Annex J BACnet/IP forwarding).  The receiving device has no choice but to look at the source address

      (the masqueraded address of the NAT-enabled BBMD) as the back-route to the device that emitted the "I-Am".

      This back route is randomly generated, and only valid as long as the temporary forwarding entry

      exists in the NAT firewall.

       

      2. If BACnet/IP communications are taking place using randomly assigned NAT ports, and the NAT

      router gets reset (say due to a power glitch), any device inside the firewall may be the first to

      initiate an inside-to-outside communication, and it is possible that the wrong device could get its

      traffic assigned to the previously used BACnet/IP port.  Devices outside the firewall would have

      no knowledge that this has happened, and would continue to talk to the old port, which is then

      redirected to the wrong device.

       

       

      Possible solution:

       

      Perhaps force the use of "Forwarded-NPDU" for all BACnet/IP messages coming from a

      NAT-enabled BBMD?

       

       

       

       

      Please let me know if I can clarify further.  Please correct me if I am wrong.

       

       

       

      Regards,

      Dean Matsen

      Software Architect

      Honeywell Intl.

       

    Your message has been successfully submitted and would be delivered to recipients shortly.