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

RE: [bacnet-ip-wg] New Update RL-002-4

Expand Messages
  • Matsen, Dean (WA26)
    Dear IP-WG: Ok, I have implemented RL-002-4 as described, and there is still a subtle problem. It is not a specific problem with this iteration of RL-002, it
    Message 1 of 14 , Apr 6 5:33 PM
    • 0 Attachment
      New Update RL-002-4

      Dear IP-WG:

       

      Ok, I have implemented RL-002-4 as described, and there is still a subtle problem.  It is not a specific

      problem with this iteration of RL-002, it was always there, although I missed it in my testing.

       

      I have pointed out previously that foreign devices are the bane of BACnet/IP with NAT.  I

      promised Buddy Lott that I would come up with an example where it breaks down.

      This is not a made up example, I have BAS-O-Matic sniffer traces of the transaction

      described below.

       

      SETUP:

       

      Suppose you have a NAT-enabled BBMD + B/IP device at address 192.168.20.100, UDP port 47801, behind a firewall.

      The BBMD is configured to think its public IP address is 192.168.21.201, port 48020.  The

      device instance of the B/IP device is 100.

       

      The firewall's public address is 192.168.21.201, and it forwards port 48020 to 192.168.20.100:47801.

      It's not important to this example, but the firewall's internal address is 192.168.20.254.

       

      A foreign device is outside the firewall at 192.168.21.2, and it listens on port 47808 (BAC0).

       

      TRANSACTIONS:

       

      The foreign device registers with the NAT-enabled BBMD, using address 192.168.21.201 and port 48020,

      the public address of the NAT-enabled BBMD.

       

      The foreign device then emits a "Who-Is 100" request, sending the request via "Distribute Broadcast

      to Network" to address 192.168.21.201 port 48020.

       

      The BBMD distributes the broadcast as needed, the broadcast gets into the B/IP device, the B/IP

      device responds "I-Am 100", and the BBMD repeats this broadcast.

       

      The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of Originating

      Device" containing the address 192.168.21.201:48020 (the BBMD's public address).  The

      source UDP port for the datagram containing this response is actually 47801 because of port

      address translation.  No problem – this is a Forwarded-NPDU so we can look at the true originating

      address in there.

       

      The foreign device concludes that device 100 is reachable via B/IP address 0xC0A815C9BB94

      (on the "local" network, no routing necessary).

       

      Then the foreign device sends an Original-Unicast-NPDU to 192.168.21.201:48020 (=0xC0A815C9BB94),

      containing a ReadProperty requesting a property from the device object (model-name, in my case).

       

      Then device 100 responds with another Original-Unicast-NPDU back to address 192.168.21.2:47808.

      However, once again the source UDP port of the datagram is 47801 because of port address

      translation.  Since the source IP address and UDP port for this response is 192.168.21.201:47801,

      the B/IP address is 0xC0A815C9BAB9, not what the foreign device is expecting, which is

      0xC0A815C9BB94.

       

      SUMMARY OF THE PROBLEM:

       

      Foreign devices still broadcast through BBMD's but carry on unicast conversations point-to-point,

      just like other BACnet/IP devices do in non-NAT situations.

       

      Note that the retracted DCM-003 solved this problem, but it requires a small change to foreign

      device implementations.

       

      If anyone has a valid solution for this, please speak up!

       

      Regards,

      Dean

       


      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
      Sent: Thursday, April 06, 2006 10:34 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] New Update RL-002-4

       

      Dean IP-WG

       

      I see your point from 6.5.3.  However, as far as establishing address of BACnet router is concerned, one should note that the "Who-Is/I-Am" method is an APP/ASE layer consideration.  All the network layer should be looking at here is the NPCI, which has an "SNET" and a source MAC address.  So 6.5.3 is not really very disciplined in keeping network layer issues separate from higher layer issues, unless one accepts that the Who-Is/I-Am causes the router to be discovered as a side effect.  

       

      I guess the closest pure approximation for proper network layer implementation would be to update routing information only on global broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My current implementation also updates the information for unicasts.  In retrospect, I guess this does not agree with 6.5.3; sorry for the confusion there.

       

      As far as point 7 is concerned, no it was not a security issue, it was to compute the correct source port address.  Since all broadcasts should come in the form of Forwarded-NPDU messages, I am thinking that only updating routing information on global broadcasts may totally solve this problem.  For what it's worth, I don't like point 7 very much either, so I'm really happy if there is a solution that doesn't need it.

       

      Thanks, Roland!

       

       

      Dean

       

       


      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Roland Laird
      Sent: Thursday, April 06, 2006 8:06 AM
      To: BACnet-IP-WG@yahoogroups.com
      Subject: [bacnet-ip-wg] New Update RL-002-4

       

       

      Dear IP-WG

      Attached is RL-002-4. I've modified a bit of wording throughout and have added points 4 and 8 from RL-002-DM-1 to the NAT configuration items. Yellow highlights are changes from the existing standard not previous versions of RL-002. Also, I added 2 diagrams for discussion.

      Other Items in RL-002-DM-1:
      I don't agree with the main thrust of point 2 requiring port forwarding regardless of UDP port. I maintain that the mapping refered to will/should only occur using F-NPDU messages which provide the correct IP/Port so the UDP Port does not need to be excluded. In the standard 6.5.3  it refers to 4 methods for establishing the address of a BACnet router. 1) Manual config, 2) Who-is/I-am, 3) Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in request/directed response. Only the 4th method will not work with B/IP and PAT. This 4th method is not a good idea anyhow and its use should be discouraged. At any rate normal directed communications should never cause a router to update its routing table and it is only these directed communications that the correct port (to use for future requests to the source network) is undeterminable.

      I accept that a NAT Router may modify the source port as stated in point 7, but I don’t understand why the need for only processing messages that come from sources in the BDT. Is this for security or am I missing the point?

       

      Roland
      <<RL-002-4.doc>>

       

    • Swan, Bill (WA26)
      The material preceding this is setup, but I will note for clarification: The foreign device concludes that device 100 is reachable via B/IP address
      Message 2 of 14 , Apr 7 11:23 AM
      • 0 Attachment
        New Update RL-002-4

        The material preceding this is setup, but I will note for clarification:

         

        The foreign device concludes that device 100 is reachable via B/IP address 0xC0A815C9BB94 (192.168.21.201:48020, this is what was intended to be set up)

        (on the "local" network, no routing necessary).

         

        Then the foreign device sends an Original-Unicast-NPDU to 192.168.21.201:48020 (=0xC0A815C9BB94),

        containing a ReadProperty requesting a property from the device object (model-name, in my case).

         

        Then device 100 responds with another Original-Unicast-NPDU back to address 192.168.21.2:47808.

        However, once again the source UDP port of the datagram is 47801 because of ("lazy", 47801 is not in use by the NAT/PAT router) port address

        translation.  Since the source IP address and UDP port for this response is 192.168.21.201:47801,

        the B/IP address is 0xC0A815C9BAB9, not what the foreign device is expecting, which is

        0xC0A815C9BB94 (192.168.21.201:48020),.

         

        So, because the PAT firewall does not do bi-directional port translation (it doesn't touch up outgoing messages to reflect the configured inbound address), the return address is wrong.

         

        Bill Swan

          Chair, ASHRAE/SSPC 135 (BACnet)

          Engineering Fellow

          Honeywell Automation and Control Systems

          Alerton

         


        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Matsen, Dean (WA26)
        Sent: Thursday, April 06, 2006 5:34 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

         

        Dear IP-WG:

         

        Ok, I have implemented RL-002-4 as described, and there is still a subtle problem.  It is not a specific

        problem with this iteration of RL-002, it was always there, although I missed it in my testing.

         

        I have pointed out previously that foreign devices are the bane of BACnet/IP with NAT.  I

        promised Buddy Lott that I would come up with an example where it breaks down.

        This is not a made up example, I have BAS-O-Matic sniffer traces of the transaction

        described below.

         

        SETUP:

         

        Suppose you have a NAT-enabled BBMD + B/IP device at address 192.168.20.100, UDP port 47801, behind a firewall.

        The BBMD is configured to think its public IP address is 192.168.21.201, port 48020.  The

        device instance of the B/IP device is 100.

         

        The firewall's public address is 192.168.21.201, and it forwards port 48020 to 192.168.20.100:47801.

        It's not important to this example, but the firewall's internal address is 192.168.20.254.

         

        A foreign device is outside the firewall at 192.168.21.2, and it listens on port 47808 (BAC0).

         

        TRANSACTIONS:

         

        The foreign device registers with the NAT-enabled BBMD, using address 192.168.21.201 and port 48020,

        the public address of the NAT-enabled BBMD.

         

        The foreign device then emits a "Who-Is 100" request, sending the request via "Distribute Broadcast

        to Network" to address 192.168.21.201 port 48020.

         

        The BBMD distributes the broadcast as needed, the broadcast gets into the B/IP device, the B/IP

        device responds "I-Am 100", and the BBMD repeats this broadcast.

         

        The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of Originating

        Device" containing the address 192.168.21.201:48020 (the BBMD's public address).  The

        source UDP port for the datagram containing this response is actually 47801 because of port

        address translation.  No problem – this is a Forwarded-NPDU so we can look at the true originating

        address in there.

         

        The foreign device concludes that device 100 is reachable via B/IP address 0xC0A815C9BB94

        (on the "local" network, no routing necessary).

         

        Then the foreign device sends an Original-Unicast-NPDU to 192.168.21.201:48020 (=0xC0A815C9BB94),

        containing a ReadProperty requesting a property from the device object (model-name, in my case).

         

        Then device 100 responds with another Original-Unicast-NPDU back to address 192.168.21.2:47808.

        However, once again the source UDP port of the datagram is 47801 because of port address

        translation.  Since the source IP address and UDP port for this response is 192.168.21.201:47801,

        the B/IP address is 0xC0A815C9BAB9, not what the foreign device is expecting, which is

        0xC0A815C9BB94.

         

        SUMMARY OF THE PROBLEM:

         

        Foreign devices still broadcast through BBMD's but carry on unicast conversations point-to-point,

        just like other BACnet/IP devices do in non-NAT situations.

         

        Note that the retracted DCM-003 solved this problem, but it requires a small change to foreign

        device implementations.

         

        If anyone has a valid solution for this, please speak up!

         

        Regards,

        Dean

         


        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
        Sent: Thursday, April 06, 2006 10:34 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

         

        Dean IP-WG

         

        I see your point from 6.5.3.  However, as far as establishing address of BACnet router is concerned, one should note that the "Who-Is/I-Am" method is an APP/ASE layer consideration.  All the network layer should be looking at here is the NPCI, which has an "SNET" and a source MAC address.  So 6.5.3 is not really very disciplined in keeping network layer issues separate from higher layer issues, unless one accepts that the Who-Is/I-Am causes the router to be discovered as a side effect.  

         

        I guess the closest pure approximation for proper network layer implementation would be to update routing information only on global broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My current implementation also updates the information for unicasts.  In retrospect, I guess this does not agree with 6.5.3; sorry for the confusion there.

         

        As far as point 7 is concerned, no it was not a security issue, it was to compute the correct source port address.  Since all broadcasts should come in the form of Forwarded-NPDU messages, I am thinking that only updating routing information on global broadcasts may totally solve this problem.  For what it's worth, I don't like point 7 very much either, so I'm really happy if there is a solution that doesn't need it.

         

        Thanks, Roland!

         

         

        Dean

         

         


        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Roland Laird
        Sent: Thursday, April 06, 2006 8:06 AM
        To: BACnet-IP-WG@yahoogroups.com
        Subject: [bacnet-ip-wg] New Update RL-002-4

         

         

        Dear IP-WG

        Attached is RL-002-4. I've modified a bit of wording throughout and have added points 4 and 8 from RL-002-DM-1 to the NAT configuration items. Yellow highlights are changes from the existing standard not previous versions of RL-002. Also, I added 2 diagrams for discussion.

        Other Items in RL-002-DM-1:
        I don't agree with the main thrust of point 2 requiring port forwarding regardless of UDP port. I maintain that the mapping refered to will/should only occur using F-NPDU messages which provide the correct IP/Port so the UDP Port does not need to be excluded. In the standard 6.5.3  it refers to 4 methods for establishing the address of a BACnet router. 1) Manual config, 2) Who-is/I-am, 3) Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in request/directed response. Only the 4th method will not work with B/IP and PAT. This 4th method is not a good idea anyhow and its use should be discouraged. At any rate normal directed communications should never cause a router to update its routing table and it is only these directed communications that the correct port (to use for future requests to the source network) is undeterminable.

        I accept that a NAT Router may modify the source port as stated in point 7, but I don’t understand why the need for only processing messages that come from sources in the BDT. Is this for security or am I missing the point?

         

        Roland
        <<RL-002-4.doc>>

         

      • Buddy Lott
        All, I am a little confused by the description of the BBMD & Bacnet-IP device. Are they part of the same hardware? Is 102.168.20.100:47801 the address of the
        Message 3 of 14 , Apr 7 7:24 PM
        • 0 Attachment
          New Update RL-002-4

          All,

           

          I am a little confused by the description of the BBMD & Bacnet-IP device. Are they part of the same hardware? Is 102.168.20.100:47801 the address of the BBMD & BIP device?

           

          If they are, then failure here is depending on the FD confirming that the source of the response came from the destination of request. Is this common practice? If it is, then this really surprises me.

           

          If they are not, then we have violated one of the most important assumptions: there are no BIP devices using the BBMD. The BBMD is part of router the routes to another logical BIP network.

           

          Thanks

           

          *******************************************************************

           

          Buddy Lott
          Firmware Design Engineer
          19476 Industrial Dr .
          New Paris , IN 46553
          574.831.5250 x 197
          blott@...

           

          *******************************************************************


          From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
          Sent: Thursday, April 06, 2006 8:34 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] New Update RL-002-4

           

          Dear IP-WG:

           

          Ok, I have implemented RL-002-4 as described, and there is still a subtle problem.  It is not a specific

          problem with this iteration of RL-002, it was always there, although I missed it in my testing.

           

          I have pointed out previously that foreign devices are the bane of BACnet/IP with NAT.  I

          promised Buddy Lott that I would come up with an example where it breaks down.

          This is not a made up example, I have BAS-O-Matic sniffer traces of the transaction

          described below.

           

          SETUP:

           

          Suppose you have a NAT-enabled BBMD + B/IP device at address 192.168.20.100, UDP port 47801, behind a firewall.

          The BBMD is configured to think its public IP address is 192.168.21.201, port 48020.  The

          device instance of the B/IP device is 100.

           

          The firewall's public address is 192.168.21.201, and it forwards port 48020 to 192.168.20.100:47801.

          It's not important to this example, but the firewall's internal address is 192.168.20.254.

           

          A foreign device is outside the firewall at 192.168.21.2, and it listens on port 47808 (BAC0).

           

          TRANSACTIONS:

           

          The foreign device registers with the NAT-enabled BBMD, using address 192.168.21.201 and port 48020,

          the public address of the NAT-enabled BBMD.

           

          The foreign device then emits a "Who-Is 100" request, sending the request via "Distribute Broadcast

          to Network" to address 192.168.21.201 port 48020.

           

          The BBMD distributes the broadcast as needed, the broadcast gets into the B/IP device, the B/IP

          device responds "I-Am 100", and the BBMD repeats this broadcast.

           

          The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of Originating

          Device" containing the address 192.168.21.201:48020 (the BBMD's public address).  The

          source UDP port for the datagram containing this response is actually 47801 because of port

          address translation.  No problem – this is a Forwarded-NPDU so we can look at the true originating

          address in there.

           

          The foreign device concludes that device 100 is reachable via B/IP address 0xC0A815C9BB94

          (on the "local" network, no routing necessary).

           

          Then the foreign device sends an Original-Unicast-NPDU to 192.168.21.201:48020 (=0xC0A815C9BB94),

          containing a ReadProperty requesting a property from the device object (model-name, in my case).

           

          Then device 100 responds with another Original-Unicast-NPDU back to address 192.168.21.2:47808.

          However, once again the source UDP port of the datagram is 47801 because of port address

          translation.  Since the source IP address and UDP port for this response is 192.168.21.201:47801,

          the B/IP address is 0xC0A815C9BAB9, not what the foreign device is expecting, which is

          0xC0A815C9BB94.

           

          SUMMARY OF THE PROBLEM:

           

          Foreign devices still broadcast through BBMD's but carry on unicast conversations point-to-point,

          just like other BACnet/IP devices do in non-NAT situations.

           

          Note that the retracted DCM-003 solved this problem, but it requires a small change to foreign

          device implementations.

           

          If anyone has a valid solution for this, please speak up!

           

          Regards,

          Dean

           


          From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
          Sent: Thursday, April 06, 2006 10:34 AM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] New Update RL-002-4

           

          Dean IP-WG

           

          I see your point from 6.5.3.  However, as far as establishing address of BACnet router is concerned, one should note that the "Who-Is/I-Am" method is an APP/ASE layer consideration.  All the network layer should be looking at here is the NPCI, which has an "SNET" and a source MAC address.  So 6.5.3 is not really very disciplined in keeping network layer issues separate from higher layer issues, unless one accepts that the Who-Is/I-Am causes the router to be discovered as a side effect.  

           

          I guess the closest pure approximation for proper network layer implementation would be to update routing information only on global broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My current implementation also updates the information for unicasts.  In retrospect, I guess this does not agree with 6.5.3; sorry for the confusion there.

           

          As far as point 7 is concerned, no it was not a security issue, it was to compute the correct source port address.  Since all broadcasts should come in the form of Forwarded-NPDU messages, I am thinking that only updating routing information on global broadcasts may totally solve this problem.  For what it's worth, I don't like point 7 very much either, so I'm really happy if there is a solution that doesn't need it.

           

          Thanks, Roland!

           

           

          Dean

           

           


          From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Roland Laird
          Sent: Thursday, April 06, 2006 8:06 AM
          To: BACnet-IP-WG@yahoogroups.com
          Subject: [bacnet-ip-wg] New Update RL-002-4

           

           

          Dear IP-WG

          Attached is RL-002-4. I've modified a bit of wording throughout and have added points 4 and 8 from RL-002-DM-1 to the NAT configuration items. Yellow highlights are changes from the existing standard not previous versions of RL-002. Also, I added 2 diagrams for discussion.

          Other Items in RL-002-DM-1:
          I don't agree with the main thrust of point 2 requiring port forwarding regardless of UDP port. I maintain that the mapping refered to will/should only occur using F-NPDU messages which provide the correct IP/Port so the UDP Port does not need to be excluded. In the standard 6.5.3  it refers to 4 methods for establishing the address of a BACnet router. 1) Manual config, 2) Who-is/I-am, 3) Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in request/directed response. Only the 4th method will not work with B/IP and PAT. This 4th method is not a good idea anyhow and its use should be discouraged. At any rate normal directed communications should never cause a router to update its routing table and it is only these directed communications that the correct port (to use for future requests to the source network) is undeterminable.

          I accept that a NAT Router may modify the source port as stated in point 7, but I don’t understand why the need for only processing messages that come from sources in the BDT. Is this for security or am I missing the point?

           

          Roland
          <<RL-002-4.doc>>

           

        • rlaird@reliablecontrols.com
          Hi Buddy, I understood the device to be part of the BBMD, and residing on the global BACnet network that the FD joins, otherwise we would not have this problem
          Message 4 of 14 , Apr 7 8:12 PM
          • 0 Attachment
            Hi Buddy,

            I understood the device to be part of the BBMD, and residing on the global
            BACnet network that the FD joins, otherwise we would not have this problem
            at all, because the source address would be taken from the network layer.
            It's only at the BACnet TSM level that we have to verify the source
            address is the one we used in the request. In this case the source address
            is taken directly from the IP and UDP headers (because of not being
            routed).

            I suspect the problem that Dean is seeing is specific to the particular
            NAT Router that he is using. At least I hope so - I have never seen this
            behaviour before.

            Of course, the problem could be eliminated by placing the device on the
            router side of the BBMD (all in the same device) assuming there is also an
            integral router in the device.

            Roland.


            > All,
            >
            >
            >
            > I am a little confused by the description of the BBMD & Bacnet-IP
            > device. Are they part of the same hardware? Is 102.168.20.100:47801 the
            > address of the BBMD & BIP device?
            >
            >
            >
            > If they are, then failure here is depending on the FD confirming that
            > the source of the response came from the destination of request. Is this
            > common practice? If it is, then this really surprises me.
            >
            >
            >
            > If they are not, then we have violated one of the most important
            > assumptions: there are no BIP devices using the BBMD. The BBMD is part
            > of router the routes to another logical BIP network.
            >
            >
            >
            > Thanks
            >
            >
            >
            > *******************************************************************
            >
            >
            >
            > Buddy Lott
            > Firmware Design Engineer
            > 19476 Industrial Dr.
            > New Paris, IN 46553
            > 574.831.5250 x 197
            > blott@...
            >
            >
            >
            > *******************************************************************
            >
            > _____
            >
            > From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
            > On Behalf Of Matsen, Dean (WA26)
            > Sent: Thursday, April 06, 2006 8:34 PM
            > To: bacnet-ip-wg@yahoogroups.com
            > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
            >
            >
            >
            > Dear IP-WG:
            >
            >
            >
            > Ok, I have implemented RL-002-4 as described, and there is still a
            > subtle problem. It is not a specific
            >
            > problem with this iteration of RL-002, it was always there, although I
            > missed it in my testing.
            >
            >
            >
            > I have pointed out previously that foreign devices are the bane of
            > BACnet/IP with NAT. I
            >
            > promised Buddy Lott that I would come up with an example where it breaks
            > down.
            >
            > This is not a made up example, I have BAS-O-Matic sniffer traces of the
            > transaction
            >
            > described below.
            >
            >
            >
            > SETUP:
            >
            >
            >
            > Suppose you have a NAT-enabled BBMD + B/IP device at address
            > 192.168.20.100, UDP port 47801, behind a firewall.
            >
            > The BBMD is configured to think its public IP address is 192.168.21.201,
            > port 48020. The
            >
            > device instance of the B/IP device is 100.
            >
            >
            >
            > The firewall's public address is 192.168.21.201, and it forwards port
            > 48020 to 192.168.20.100:47801.
            >
            > It's not important to this example, but the firewall's internal address
            > is 192.168.20.254.
            >
            >
            >
            > A foreign device is outside the firewall at 192.168.21.2, and it listens
            > on port 47808 (BAC0).
            >
            >
            >
            > TRANSACTIONS:
            >
            >
            >
            > The foreign device registers with the NAT-enabled BBMD, using address
            > 192.168.21.201 and port 48020,
            >
            > the public address of the NAT-enabled BBMD.
            >
            >
            >
            > The foreign device then emits a "Who-Is 100" request, sending the
            > request via "Distribute Broadcast
            >
            > to Network" to address 192.168.21.201 port 48020.
            >
            >
            >
            > The BBMD distributes the broadcast as needed, the broadcast gets into
            > the B/IP device, the B/IP
            >
            > device responds "I-Am 100", and the BBMD repeats this broadcast.
            >
            >
            >
            > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of
            > Originating
            >
            > Device" containing the address 192.168.21.201:48020 (the BBMD's public
            > address). The
            >
            > source UDP port for the datagram containing this response is actually
            > 47801 because of port
            >
            > address translation. No problem - this is a Forwarded-NPDU so we can
            > look at the true originating
            >
            > address in there.
            >
            >
            >
            > The foreign device concludes that device 100 is reachable via B/IP
            > address 0xC0A815C9BB94
            >
            > (on the "local" network, no routing necessary).
            >
            >
            >
            > Then the foreign device sends an Original-Unicast-NPDU to
            > 192.168.21.201:48020 (=0xC0A815C9BB94),
            >
            > containing a ReadProperty requesting a property from the device object
            > (model-name, in my case).
            >
            >
            >
            > Then device 100 responds with another Original-Unicast-NPDU back to
            > address 192.168.21.2:47808.
            >
            > However, once again the source UDP port of the datagram is 47801 because
            > of port address
            >
            > translation. Since the source IP address and UDP port for this response
            > is 192.168.21.201:47801,
            >
            > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is
            > expecting, which is
            >
            > 0xC0A815C9BB94.
            >
            >
            >
            > SUMMARY OF THE PROBLEM:
            >
            >
            >
            > Foreign devices still broadcast through BBMD's but carry on unicast
            > conversations point-to-point,
            >
            > just like other BACnet/IP devices do in non-NAT situations.
            >
            >
            >
            > Note that the retracted DCM-003 solved this problem, but it requires a
            > small change to foreign
            >
            > device implementations.
            >
            >
            >
            > If anyone has a valid solution for this, please speak up!
            >
            >
            >
            > Regards,
            >
            > Dean
            >
            >
            >
            > _____
            >
            > From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
            > On Behalf Of Matsen, Dean (WA26)
            > Sent: Thursday, April 06, 2006 10:34 AM
            > To: bacnet-ip-wg@yahoogroups.com
            > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
            >
            >
            >
            > Dean IP-WG
            >
            >
            >
            > I see your point from 6.5.3. However, as far as establishing address of
            > BACnet router is concerned, one should note that the "Who-Is/I-Am"
            > method is an APP/ASE layer consideration. All the network layer should
            > be looking at here is the NPCI, which has an "SNET" and a source MAC
            > address. So 6.5.3 is not really very disciplined in keeping network
            > layer issues separate from higher layer issues, unless one accepts that
            > the Who-Is/I-Am causes the router to be discovered as a side effect.
            >
            >
            >
            > I guess the closest pure approximation for proper network layer
            > implementation would be to update routing information only on global
            > broadcasts (which includes Who-Is/I-Am), but never on unicasts. My
            > current implementation also updates the information for unicasts. In
            > retrospect, I guess this does not agree with 6.5.3; sorry for the
            > confusion there.
            >
            >
            >
            > As far as point 7 is concerned, no it was not a security issue, it was
            > to compute the correct source port address. Since all broadcasts should
            > come in the form of Forwarded-NPDU messages, I am thinking that only
            > updating routing information on global broadcasts may totally solve this
            > problem. For what it's worth, I don't like point 7 very much either, so
            > I'm really happy if there is a solution that doesn't need it.
            >
            >
            >
            > Thanks, Roland!
            >
            >
            >
            >
            >
            > Dean
            >
            >
            >
            >
            >
            > _____
            >
            > From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
            > On Behalf Of Roland Laird
            > Sent: Thursday, April 06, 2006 8:06 AM
            > To: BACnet-IP-WG@yahoogroups.com
            > Subject: [bacnet-ip-wg] New Update RL-002-4
            >
            >
            >
            >
            >
            > Dear IP-WG
            >
            > Attached is RL-002-4. I've modified a bit of wording throughout and have
            > added points 4 and 8 from RL-002-DM-1 to the NAT configuration items.
            > Yellow highlights are changes from the existing standard not previous
            > versions of RL-002. Also, I added 2 diagrams for discussion.
            >
            > Other Items in RL-002-DM-1:
            > I don't agree with the main thrust of point 2 requiring port forwarding
            > regardless of UDP port. I maintain that the mapping refered to
            > will/should only occur using F-NPDU messages which provide the correct
            > IP/Port so the UDP Port does not need to be excluded. In the standard
            > 6.5.3 it refers to 4 methods for establishing the address of a BACnet
            > router. 1) Manual config, 2) Who-is/I-am, 3)
            > Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in
            > request/directed response. Only the 4th method will not work with B/IP
            > and PAT. This 4th method is not a good idea anyhow and its use should be
            > discouraged. At any rate normal directed communications should never
            > cause a router to update its routing table and it is only these directed
            > communications that the correct port (to use for future requests to the
            > source network) is undeterminable.
            >
            > I accept that a NAT Router may modify the source port as stated in point
            > 7, but I don't understand why the need for only processing messages that
            > come from sources in the BDT. Is this for security or am I missing the
            > point?
            >
            >
            >
            > Roland
            > <<RL-002-4.doc>>
            >
            >
            >
            >
            >
            > _____
            >
            > YAHOO! GROUPS LINKS
            >
            >
            >
            > * Visit your group "bacnet-ip-wg
            > <http://groups.yahoo.com/group/bacnet-ip-wg> " on the web.
            >
            > * To unsubscribe from this group, send an email to:
            > bacnet-ip-wg-unsubscribe@yahoogroups.com
            > <mailto:bacnet-ip-wg-unsubscribe@yahoogroups.com?subject=Unsubscribe>
            >
            > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
            > Service <http://docs.yahoo.com/info/terms/> .
            >
            >
            >
            > _____
            >
            >
          • Buddy Lott
            Hi Roland, I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN
            Message 5 of 14 , Apr 8 7:28 PM
            • 0 Attachment

              Hi Roland,

               

              I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

               

              I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

               

               

               

              *******************************************************************

               

              Buddy Lott
              Firmware Design Engineer
              19476 Industrial Dr .
              New Paris , IN 46553
              574.831.5250 x 197
              blott@...

               

              *******************************************************************


              From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...
              Sent: Friday, April 07, 2006 11:13 PM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: RE: [bacnet-ip-wg] New Update RL-002-4

               


              Hi Buddy,

              I understood the device to be part of the BBMD, and residing on the global
              BACnet network that the FD joins, otherwise we would not have this problem
              at all, because the source address would be taken from the network layer.
              It's only at the BACnet TSM level that we have to verify the source
              address is the one we used in the request. In this case the source address
              is taken directly from the IP and UDP headers (because of not being
              routed).

              I suspect the problem that Dean is seeing is specific to the particular
              NAT Router that he is using. At least I hope so - I have never seen this
              behaviour before.

              Of course, the problem could be eliminated by placing the device on the
              router side of the BBMD (all in the same device) assuming there is also an
              integral router in the device.

              Roland.


              > All,
              >
              >
              >
              > I am a little confused by the description of the BBMD & Bacnet-IP
              > device. Are they part of the same hardware? Is 102.168.20.100:47801 the
              > address of the BBMD & BIP device?
              >
              >
              >
              > If they are, then failure here is depending on the FD confirming that
              > the source of the response came from the destination of request. Is this
              > common practice? If it is, then this really surprises me.
              >
              >
              >
              > If they are not, then we have violated one of the most important
              > assumptions: there are no BIP devices using the BBMD. The BBMD is part
              > of router the routes to another logical BIP network.
              >
              >
              >
              > Thanks
              >
              >
              >
              > *******************************************************************
              >
              >
              >
              > Buddy Lott
              > Firmware Design Engineer
              > 19476 Industrial Dr .
              > New Paris , IN 46553
              > 574.831.5250 x 197
              > blott@...
              >
              >
              >
              > *******************************************************************
              >
              >   _____
              >
              > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
              > On Behalf Of Matsen, Dean (WA26)
              > Sent: Thursday, April 06, 2006 8:34 PM
              > To: bacnet-ip-wg@yahoogroups.com
              > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
              >
              >
              >
              > Dear IP-WG:
              >
              >
              >
              > Ok, I have implemented RL-002-4 as described, and there is still a
              > subtle problem.  It is not a specific
              >
              > problem with this iteration of RL-002, it was always there, although I
              > missed it in my testing.
              >
              >
              >
              > I have pointed out previously that foreign devices are the bane of
              > BACnet/IP with NAT.  I
              >
              > promised Buddy Lott that I would come up with an example where it breaks
              > down.
              >
              > This is not a made up example, I have BAS-O-Matic sniffer traces of the
              > transaction
              >
              > described below.
              >
              >
              >
              > SETUP:
              >
              >
              >
              > Suppose you have a NAT-enabled BBMD + B/IP device at address
              > 192.168.20.100, UDP port 47801, behind a firewall.
              >
              > The BBMD is configured to think its public IP address is 192.168.21.201,
              > port 48020.  The
              >
              > device instance of the B/IP device is 100.
              >
              >
              >
              > The firewall's public address is 192.168.21.201, and it forwards port
              > 48020 to 192.168.20.100:47801.
              >
              > It's not important to this example, but the firewall's internal address
              > is 192.168.20.254.
              >
              >
              >
              > A foreign device is outside the firewall at 192.168.21.2, and it listens
              > on port 47808 (BAC0).
              >
              >
              >
              > TRANSACTIONS:
              >
              >
              >
              > The foreign device registers with the NAT-enabled BBMD, using address
              > 192.168.21.201 and port 48020,
              >
              > the public address of the NAT-enabled BBMD.
              >
              >
              >
              > The foreign device then emits a "Who-Is 100" request, sending the
              > request via "Distribute Broadcast
              >
              > to Network" to address 192.168.21.201 port 48020.
              >
              >
              >
              > The BBMD distributes the broadcast as needed, the broadcast gets into
              > the B/IP device, the B/IP
              >
              > device responds "I-Am 100", and the BBMD repeats this broadcast.
              >
              >
              >
              > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of
              > Originating
              >
              > Device" containing the address 192.168.21.201:48020 (the BBMD's public
              > address).  The
              >
              > source UDP port for the datagram containing this response is actually
              > 47801 because of port
              >
              > address translation.  No problem - this is a Forwarded-NPDU so we can
              > look at the true originating
              >
              > address in there.
              >
              >
              >
              > The foreign device concludes that device 100 is reachable via B/IP
              > address 0xC0A815C9BB94
              >
              > (on the "local" network, no routing necessary).
              >
              >
              >
              > Then the foreign device sends an Original-Unicast-NPDU to
              > 192.168.21.201:48020 (=0xC0A815C9BB94),
              >
              > containing a ReadProperty requesting a property from the device object
              > (model-name, in my case).
              >
              >
              >
              > Then device 100 responds with another Original-Unicast-NPDU back to
              > address 192.168.21.2:47808.
              >
              > However, once again the source UDP port of the datagram is 47801 because
              > of port address
              >
              > translation.  Since the source IP address and UDP port for this response
              > is 192.168.21.201:47801,
              >
              > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is
              > expecting, which is
              >
              > 0xC0A815C9BB94.
              >
              >
              >
              > SUMMARY OF THE PROBLEM:
              >
              >
              >
              > Foreign devices still broadcast through BBMD's but carry on unicast
              > conversations point-to-point,
              >
              > just like other BACnet/IP devices do in non-NAT situations.
              >
              >
              >
              > Note that the retracted DCM-003 solved this problem, but it requires a
              > small change to foreign
              >
              > device implementations.
              >
              >
              >
              > If anyone has a valid solution for this, please speak up!
              >
              >
              >
              > Regards,
              >
              > Dean
              >
              >
              >
              >   _____
              >
              > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
              > On Behalf Of Matsen, Dean (WA26)
              > Sent: Thursday, April 06, 2006 10:34 AM
              > To: bacnet-ip-wg@yahoogroups.com
              > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
              >
              >
              >
              > Dean IP-WG
              >
              >
              >
              > I see your point from 6.5.3.  However, as far as establishing address of
              > BACnet router is concerned, one should note that the "Who-Is/I-Am"
              > method is an APP/ASE layer consideration.  All the network layer should
              > be looking at here is the NPCI, which has an "SNET" and a source MAC
              > address.  So 6.5.3 is not really very disciplined in keeping network
              > layer issues separate from higher layer issues, unless one accepts that
              > the Who-Is/I-Am causes the router to be discovered as a side effect.
              >
              >
              >
              > I guess the closest pure approximation for proper network layer
              > implementation would be to update routing information only on global
              > broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My
              > current implementation also updates the information for unicasts.  In
              > retrospect, I guess this does not agree with 6.5.3; sorry for the
              > confusion there.
              >
              >
              >
              > As far as point 7 is concerned, no it was not a security issue, it was
              > to compute the correct source port address.  Since all broadcasts should
              > come in the form of Forwarded-NPDU messages, I am thinking that only
              > updating routing information on global broadcasts may totally solve this
              > problem.  For what it's worth, I don't like point 7 very much either, so
              > I'm really happy if there is a solution that doesn't need it.
              >
              >
              >
              > Thanks, Roland!
              >
              >
              >
              >
              >
              > Dean
              >
              >
              >
              >
              >
              >   _____
              >
              > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
              > On Behalf Of Roland Laird
              > Sent: Thursday, April 06, 2006 8:06 AM
              > To: BACnet-IP-WG@yahoogroups.com
              > Subject: [bacnet-ip-wg] New Update RL-002-4
              >
              >
              >
              >
              >
              > Dear IP-WG
              >
              > Attached is RL-002-4. I've modified a bit of wording throughout and have
              > added points 4 and 8 from RL-002-DM-1 to the NAT configuration items.
              > Yellow highlights are changes from the existing standard not previous
              > versions of RL-002. Also, I added 2 diagrams for discussion.
              >
              > Other Items in RL-002-DM-1:
              > I don't agree with the main thrust of point 2 requiring port forwarding
              > regardless of UDP port. I maintain that the mapping refered to
              > will/should only occur using F-NPDU messages which provide the correct
              > IP/Port so the UDP Port does not need to be excluded. In the standard
              > 6.5.3  it refers to 4 methods for establishing the address of a BACnet
              > router. 1) Manual config, 2) Who-is/I-am, 3)
              > Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in
              > request/directed response. Only the 4th method will not work with B/IP
              > and PAT. This 4th method is not a good idea anyhow and its use should be
              > discouraged. At any rate normal directed communications should never
              > cause a router to update its routing table and it is only these directed
              > communications that the correct port (to use for future requests to the
              > source network) is undeterminable.
              >
              > I accept that a NAT Router may modify the source port as stated in point
              > 7, but I don't understand why the need for only processing messages that
              > come from sources in the BDT. Is this for security or am I missing the
              > point?
              >
              >
              >
              > Roland
              > <<RL-002-4.doc>>
              >
              >
              >
              >
              >
              >   _____
              >
              > YAHOO! GROUPS LINKS
              >
              >
              >
              > *      Visit your group "bacnet-ip-wg
              > <http://groups.yahoo.com/group/bacnet-ip-wg> " on the web.
              >
              > *      To unsubscribe from this group, send an email to:
              >       bacnet-ip-wg-unsubscribe@yahoogroups.com
              > <mailto:bacnet-ip-wg-unsubscribe@yahoogroups.com?subject=Unsubscribe>
              >
              > *      Your use of Yahoo! Groups is subject to the Yahoo! Terms of
              > Service <http://docs.yahoo.com/info/terms/> .
              >
              >
              >
              >   _____
              >
              >



            • Matsen, Dean (WA26)
              Roland, Regarding your last point, I totally agree that this could solve the problem. However, from what I ve heard, there is currently a push to require a
              Message 6 of 14 , Apr 10 10:37 AM
              • 0 Attachment

                Roland,

                 

                Regarding your last point, I totally agree that this could solve the problem.  However, from what I've heard, there is currently a push to require a device instance wherever there is a network entity (I'm sure Bill Swan can elucidate from whence that comes).  If it ever comes to that, it would be much better to have all the B/IP implementations "sharing" the same network entity, above which there is a single device instance.  If we head down the "virtual routing" path, later on down the road we might find ourselves being required to implement a device instance in the same place where it's a problem right now anyway.

                 

                In any case, it seems like setting the bar pretty high to require a virtual routing implementation to support NAT.

                 

                For now, I have implemented a hybrid of RL-002 and DCM-003.  Basically all I did was add a "NAT-unicast" message, which the B/IP implementation uses instead of "Original-Unicast-NPDU".  This message basically looks like a Forwarded-NPDU message, with the "B/IP of originating device" field.  The ONLY down side to having such a message (that I can see) is that foreign devices need to accept and process it (and I was hoping to avoid changing the foreign device implementation).

                 

                By the way, the NAT routers that I am using are Linksys BEFSR41 routers, sold at CompUSA.  You may be right in saying the behavior is not totally correct (I don't know).  But these routers are ubiquitous.  It seems like we have to treat them like a de-facto standard.  I have also heard that they are based on Linux distributions, which I doubt would have problems with the NAT implementation.  I suppose Linksys/CISCO could have supplied their own IP forwarding engine, but I'm not sure whey they would bother.

                 

                In any case, I am not using some routers I found under a rock – these are more credible than that.

                 

                Dean

                 


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...
                Sent: Friday, April 07, 2006 8:13 PM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                 


                Hi Buddy,

                I understood the device to be part of the BBMD, and residing on the global
                BACnet network that the FD joins, otherwise we would not have this problem
                at all, because the source address would be taken from the network layer.
                It's only at the BACnet TSM level that we have to verify the source
                address is the one we used in the request. In this case the source address
                is taken directly from the IP and UDP headers (because of not being
                routed).

                I suspect the problem that Dean is seeing is specific to the particular
                NAT Router that he is using. At least I hope so - I have never seen this
                behaviour before.

                Of course, the problem could be eliminated by placing the device on the
                router side of the BBMD (all in the same device) assuming there is also an
                integral router in the device.

                Roland.


                > All,
                >
                >
                >
                > I am a little confused by the description of the BBMD & Bacnet-IP
                > device. Are they part of the same hardware? Is 102.168.20.100:47801 the
                > address of the BBMD & BIP device?
                >
                >
                >
                > If they are, then failure here is depending on the FD confirming that
                > the source of the response came from the destination of request. Is this
                > common practice? If it is, then this really surprises me.
                >
                >
                >
                > If they are not, then we have violated one of the most important
                > assumptions: there are no BIP devices using the BBMD. The BBMD is part
                > of router the routes to another logical BIP network.
                >
                >
                >
                > Thanks
                >
                >
                >
                > *******************************************************************
                >
                >
                >
                > Buddy Lott
                > Firmware Design Engineer
                > 19476 Industrial Dr .
                > New Paris , IN 46553
                > 574.831.5250 x 197
                > blott@...
                >
                >
                >
                > *******************************************************************
                >
                >   _____
                >
                > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
                > On Behalf Of Matsen, Dean (WA26)
                > Sent: Thursday, April 06, 2006 8:34 PM
                > To: bacnet-ip-wg@yahoogroups.com
                > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
                >
                >
                >
                > Dear IP-WG:
                >
                >
                >
                > Ok, I have implemented RL-002-4 as described, and there is still a
                > subtle problem.  It is not a specific
                >
                > problem with this iteration of RL-002, it was always there, although I
                > missed it in my testing.
                >
                >
                >
                > I have pointed out previously that foreign devices are the bane of
                > BACnet/IP with NAT.  I
                >
                > promised Buddy Lott that I would come up with an example where it breaks
                > down.
                >
                > This is not a made up example, I have BAS-O-Matic sniffer traces of the
                > transaction
                >
                > described below.
                >
                >
                >
                > SETUP:
                >
                >
                >
                > Suppose you have a NAT-enabled BBMD + B/IP device at address
                > 192.168.20.100, UDP port 47801, behind a firewall.
                >
                > The BBMD is configured to think its public IP address is 192.168.21.201,
                > port 48020.  The
                >
                > device instance of the B/IP device is 100.
                >
                >
                >
                > The firewall's public address is 192.168.21.201, and it forwards port
                > 48020 to 192.168.20.100:47801.
                >
                > It's not important to this example, but the firewall's internal address
                > is 192.168.20.254.
                >
                >
                >
                > A foreign device is outside the firewall at 192.168.21.2, and it listens
                > on port 47808 (BAC0).
                >
                >
                >
                > TRANSACTIONS:
                >
                >
                >
                > The foreign device registers with the NAT-enabled BBMD, using address
                > 192.168.21.201 and port 48020,
                >
                > the public address of the NAT-enabled BBMD.
                >
                >
                >
                > The foreign device then emits a "Who-Is 100" request, sending the
                > request via "Distribute Broadcast
                >
                > to Network" to address 192.168.21.201 port 48020.
                >
                >
                >
                > The BBMD distributes the broadcast as needed, the broadcast gets into
                > the B/IP device, the B/IP
                >
                > device responds "I-Am 100", and the BBMD repeats this broadcast.
                >
                >
                >
                > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of
                > Originating
                >
                > Device" containing the address 192.168.21.201:48020 (the BBMD's public
                > address).  The
                >
                > source UDP port for the datagram containing this response is actually
                > 47801 because of port
                >
                > address translation.  No problem - this is a Forwarded-NPDU so we can
                > look at the true originating
                >
                > address in there.
                >
                >
                >
                > The foreign device concludes that device 100 is reachable via B/IP
                > address 0xC0A815C9BB94
                >
                > (on the "local" network, no routing necessary).
                >
                >
                >
                > Then the foreign device sends an Original-Unicast-NPDU to
                > 192.168.21.201:48020 (=0xC0A815C9BB94),
                >
                > containing a ReadProperty requesting a property from the device object
                > (model-name, in my case).
                >
                >
                >
                > Then device 100 responds with another Original-Unicast-NPDU back to
                > address 192.168.21.2:47808.
                >
                > However, once again the source UDP port of the datagram is 47801 because
                > of port address
                >
                > translation.  Since the source IP address and UDP port for this response
                > is 192.168.21.201:47801,
                >
                > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is
                > expecting, which is
                >
                > 0xC0A815C9BB94.
                >
                >
                >
                > SUMMARY OF THE PROBLEM:
                >
                >
                >
                > Foreign devices still broadcast through BBMD's but carry on unicast
                > conversations point-to-point,
                >
                > just like other BACnet/IP devices do in non-NAT situations.
                >
                >
                >
                > Note that the retracted DCM-003 solved this problem, but it requires a
                > small change to foreign
                >
                > device implementations.
                >
                >
                >
                > If anyone has a valid solution for this, please speak up!
                >
                >
                >
                > Regards,
                >
                > Dean
                >
                >
                >
                >   _____
                >
                > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
                > On Behalf Of Matsen, Dean (WA26)
                > Sent: Thursday, April 06, 2006 10:34 AM
                > To: bacnet-ip-wg@yahoogroups.com
                > Subject: RE: [bacnet-ip-wg] New Update RL-002-4
                >
                >
                >
                > Dean IP-WG
                >
                >
                >
                > I see your point from 6.5.3.  However, as far as establishing address of
                > BACnet router is concerned, one should note that the "Who-Is/I-Am"
                > method is an APP/ASE layer consideration.  All the network layer should
                > be looking at here is the NPCI, which has an "SNET" and a source MAC
                > address.  So 6.5.3 is not really very disciplined in keeping network
                > layer issues separate from higher layer issues, unless one accepts that
                > the Who-Is/I-Am causes the router to be discovered as a side effect.
                >
                >
                >
                > I guess the closest pure approximation for proper network layer
                > implementation would be to update routing information only on global
                > broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My
                > current implementation also updates the information for unicasts.  In
                > retrospect, I guess this does not agree with 6.5.3; sorry for the
                > confusion there.
                >
                >
                >
                > As far as point 7 is concerned, no it was not a security issue, it was
                > to compute the correct source port address.  Since all broadcasts should
                > come in the form of Forwarded-NPDU messages, I am thinking that only
                > updating routing information on global broadcasts may totally solve this
                > problem.  For what it's worth, I don't like point 7 very much either, so
                > I'm really happy if there is a solution that doesn't need it.
                >
                >
                >
                > Thanks, Roland!
                >
                >
                >
                >
                >
                > Dean
                >
                >
                >
                >
                >
                >   _____
                >
                > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]
                > On Behalf Of Roland Laird
                > Sent: Thursday, April 06, 2006 8:06 AM
                > To: BACnet-IP-WG@yahoogroups.com
                > Subject: [bacnet-ip-wg] New Update RL-002-4
                >
                >
                >
                >
                >
                > Dear IP-WG
                >
                > Attached is RL-002-4. I've modified a bit of wording throughout and have
                > added points 4 and 8 from RL-002-DM-1 to the NAT configuration items.
                > Yellow highlights are changes from the existing standard not previous
                > versions of RL-002. Also, I added 2 diagrams for discussion.
                >
                > Other Items in RL-002-DM-1:
                > I don't agree with the main thrust of point 2 requiring port forwarding
                > regardless of UDP port. I maintain that the mapping refered to
                > will/should only occur using F-NPDU messages which provide the correct
                > IP/Port so the UDP Port does not need to be excluded. In the standard
                > 6.5.3  it refers to 4 methods for establishing the address of a BACnet
                > router. 1) Manual config, 2) Who-is/I-am, 3)
                > Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in
                > request/directed response. Only the 4th method will not work with B/IP
                > and PAT. This 4th method is not a good idea anyhow and its use should be
                > discouraged. At any rate normal directed communications should never
                > cause a router to update its routing table and it is only these directed
                > communications that the correct port (to use for future requests to the
                > source network) is undeterminable.
                >
                > I accept that a NAT Router may modify the source port as stated in point
                > 7, but I don't understand why the need for only processing messages that
                > come from sources in the BDT. Is this for security or am I missing the
                > point?
                >
                >
                >
                > Roland
                > <<RL-002-4.doc>>
                >
                >
                >
                >
                >
                >   _____
                >
                > YAHOO! GROUPS LINKS
                >
                >
                >
                > *      Visit your group "bacnet-ip-wg
                > <http://groups.yahoo.com/group/bacnet-ip-wg> " on the web.
                >
                > *      To unsubscribe from this group, send an email to:
                >       bacnet-ip-wg-unsubscribe@yahoogroups.com
                > <mailto:bacnet-ip-wg-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                >
                > *      Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                > Service <http://docs.yahoo.com/info/terms/> .
                >
                >
                >
                >   _____
                >
                >



              • Buddy Lott
                I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons ... First, how common is source address verification on
                Message 7 of 14 , Apr 10 1:14 PM
                • 0 Attachment

                  I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons …

                   

                  First, how common is source address verification on responses? Is this required by the standard? If so, where? As long as you are verifying source addresses, then NAT/PAT is going to be really ugly.

                   

                  Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                   

                  1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path.

                  2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address?

                   

                   

                  Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                   

                  I don’t see how any of these issues are addressed in RL-002-4.

                   

                   

                   

                   

                   

                   

                  *******************************************************************

                   

                  Buddy Lott

                  Firmware Design Engineer

                  19476 Industrial Dr .

                  New Paris , IN 46553

                  574.831.5250 x 197

                  blott@...

                   

                  *******************************************************************

                  ________________________________________

                  From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott

                  Sent: Saturday, April 08, 2006 10:29 PM

                  To: bacnet-ip-wg@yahoogroups.com

                  Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                   

                  Hi Roland,

                   

                  I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

                   

                  I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

                   

                   

                   

                  *******************************************************************

                   

                  Buddy Lott

                  Firmware Design Engineer

                  19476 Industrial Dr .

                  New Paris , IN 46553

                  574.831.5250 x 197

                  blott@...

                   

                  *******************************************************************

                  ________________________________________

                  From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...

                  Sent: Friday, April 07, 2006 11:13 PM

                  To: bacnet-ip-wg@yahoogroups.com

                  Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                   

                   

                  Hi Buddy,

                   

                  I understood the device to be part of the BBMD, and residing on the global

                  BACnet network that the FD joins, otherwise we would not have this problem

                  at all, because the source address would be taken from the network layer.

                  It's only at the BACnet TSM level that we have to verify the source

                  address is the one we used in the request. In this case the source address

                  is taken directly from the IP and UDP headers (because of not being

                  routed).

                   

                  I suspect the problem that Dean is seeing is specific to the particular

                  NAT Router that he is using. At least I hope so - I have never seen this

                  behaviour before.

                   

                  Of course, the problem could be eliminated by placing the device on the

                  router side of the BBMD (all in the same device) assuming there is also an

                  integral router in the device.

                   

                  Roland.

                   

                   

                  > All,

                  >  

                  >  

                  >  

                  > I am a little confused by the description of the BBMD & Bacnet-IP

                  > device. Are they part of the same hardware? Is 102.168.20.100:47801 the

                  > address of the BBMD & BIP device?

                  >  

                  >  

                  >  

                  > If they are, then failure here is depending on the FD confirming that

                  > the source of the response came from the destination of request. Is this

                  > common practice? If it is, then this really surprises me.

                  >  

                  >  

                  >  

                  > If they are not, then we have violated one of the most important

                  > assumptions: there are no BIP devices using the BBMD. The BBMD is part

                  > of router the routes to another logical BIP network.

                  >  

                  >  

                  >  

                  > Thanks

                  >  

                  >  

                  >  

                  > *******************************************************************

                  >  

                  >  

                  >  

                  > Buddy Lott

                  > Firmware Design Engineer

                  > 19476 Industrial Dr .

                  > New Paris , IN 46553

                  > 574.831.5250 x 197

                  > blott@...

                  >  

                  >  

                  >  

                  > *******************************************************************

                  >  

                  >   _____

                  >  

                  > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                  > On Behalf Of Matsen, Dean (WA26)

                  > Sent: Thursday, April 06, 2006 8:34 PM

                  > To: bacnet-ip-wg@yahoogroups.com

                  > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                  >  

                  >  

                  >  

                  > Dear IP-WG:

                  >  

                  >  

                  >  

                  > Ok, I have implemented RL-002-4 as described, and there is still a

                  > subtle problem.  It is not a specific

                  >  

                  > problem with this iteration of RL-002, it was always there, although I

                  > missed it in my testing.

                  >  

                  >  

                  >  

                  > I have pointed out previously that foreign devices are the bane of

                  > BACnet/IP with NAT.  I

                  >  

                  > promised Buddy Lott that I would come up with an example where it breaks

                  > down.

                  >  

                  > This is not a made up example, I have BAS-O-Matic sniffer traces of the

                  > transaction

                  >  

                  > described below.

                  >  

                  >  

                  >  

                  > SETUP:

                  >  

                  >  

                  >  

                  > Suppose you have a NAT-enabled BBMD + B/IP device at address

                  > 192.168.20.100, UDP port 47801, behind a firewall.

                  >  

                  > The BBMD is configured to think its public IP address is 192.168.21.201,

                  > port 48020.  The

                  >  

                  > device instance of the B/IP device is 100.

                  >  

                  >  

                  >  

                  > The firewall's public address is 192.168.21.201, and it forwards port

                  > 48020 to 192.168.20.100:47801.

                  >  

                  > It's not important to this example, but the firewall's internal address

                  > is 192.168.20.254.

                  >  

                  >  

                  >  

                  > A foreign device is outside the firewall at 192.168.21.2, and it listens

                  > on port 47808 (BAC0).

                  >  

                  >  

                  >  

                  > TRANSACTIONS:

                  >  

                  >  

                  >  

                  > The foreign device registers with the NAT-enabled BBMD, using address

                  > 192.168.21.201 and port 48020,

                  >  

                  > the public address of the NAT-enabled BBMD.

                  >  

                  >  

                  >  

                  > The foreign device then emits a "Who-Is 100" request, sending the

                  > request via "Distribute Broadcast

                  >  

                  > to Network" to address 192.168.21.201 port 48020.

                  >  

                  >  

                  >  

                  > The BBMD distributes the broadcast as needed, the broadcast gets into

                  > the B/IP device, the B/IP

                  >  

                  > device responds "I-Am 100", and the BBMD repeats this broadcast.

                  >  

                  >  

                  >  

                  > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of

                  > Originating

                  >  

                  > Device" containing the address 192.168.21.201:48020 (the BBMD's public

                  > address).  The

                  >  

                  > source UDP port for the datagram containing this response is actually

                  > 47801 because of port

                  >  

                  > address translation.  No problem - this is a Forwarded-NPDU so we can

                  > look at the true originating

                  >  

                  > address in there.

                  >  

                  >  

                  >  

                  > The foreign device concludes that device 100 is reachable via B/IP

                  > address 0xC0A815C9BB94

                  >  

                  > (on the "local" network, no routing necessary).

                  >  

                  >  

                  >  

                  > Then the foreign device sends an Original-Unicast-NPDU to

                  > 192.168.21.201:48020 (=0xC0A815C9BB94),

                  >  

                  > containing a ReadProperty requesting a property from the device object

                  > (model-name, in my case).

                  >  

                  >  

                  >  

                  > Then device 100 responds with another Original-Unicast-NPDU back to

                  > address 192.168.21.2:47808.

                  >  

                  > However, once again the source UDP port of the datagram is 47801 because

                  > of port address

                  >  

                  > translation.  Since the source IP address and UDP port for this response

                  > is 192.168.21.201:47801,

                  >  

                  > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is

                  > expecting, which is

                  >  

                  > 0xC0A815C9BB94.

                  >  

                  >  

                  >  

                  > SUMMARY OF THE PROBLEM:

                  >  

                  >  

                  >  

                  > Foreign devices still broadcast through BBMD's but carry on unicast

                  > conversations point-to-point,

                  >  

                  > just like other BACnet/IP devices do in non-NAT situations.

                  >  

                  >  

                  >  

                  > Note that the retracted DCM-003 solved this problem, but it requires a

                  > small change to foreign

                  >  

                  > device implementations.

                  >  

                  >  

                  >  

                  > If anyone has a valid solution for this, please speak up!

                  >  

                  >  

                  >  

                  > Regards,

                  >  

                  > Dean

                  >  

                  >  

                  >  

                  >   _____

                  >  

                  > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                  > On Behalf Of Matsen, Dean (WA26)

                  > Sent: Thursday, April 06, 2006 10:34 AM

                  > To: bacnet-ip-wg@yahoogroups.com

                  > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                  >  

                  >  

                  >  

                  > Dean IP-WG

                  >  

                  >  

                  >  

                  > I see your point from 6.5.3.  However, as far as establishing address of

                  > BACnet router is concerned, one should note that the "Who-Is/I-Am"

                  > method is an APP/ASE layer consideration.  All the network layer should

                  > be looking at here is the NPCI, which has an "SNET" and a source MAC

                  > address.  So 6.5.3 is not really very disciplined in keeping network

                  > layer issues separate from higher layer issues, unless one accepts that

                  > the Who-Is/I-Am causes the router to be discovered as a side effect.

                  >  

                  >  

                  >  

                  > I guess the closest pure approximation for proper network layer

                  > implementation would be to update routing information only on global

                  > broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My

                  > current implementation also updates the information for unicasts.  In

                  > retrospect, I guess this does not agree with 6.5.3; sorry for the

                  > confusion there.

                  >  

                  >  

                  >  

                  > As far as point 7 is concerned, no it was not a security issue, it was

                  > to compute the correct source port address.  Since all broadcasts should

                  > come in the form of Forwarded-NPDU messages, I am thinking that only

                  > updating routing information on global broadcasts may totally solve this

                  > problem.  For what it's worth, I don't like point 7 very much either, so

                  > I'm really happy if there is a solution that doesn't need it.

                  >  

                  >  

                  >  

                  > Thanks, Roland!

                  >  

                  >  

                  >  

                  >  

                  >  

                  > Dean

                  >  

                  >  

                  >  

                  >  

                  >  

                  >   _____

                  >  

                  > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                  > On Behalf Of Roland Laird

                  > Sent: Thursday, April 06, 2006 8:06 AM

                  > To: BACnet-IP-WG@yahoogroups.com

                  > Subject: [bacnet-ip-wg] New Update RL-002-4

                  >  

                  >  

                  >  

                  >  

                  >  

                  > Dear IP-WG

                  >  

                  > Attached is RL-002-4. I've modified a bit of wording throughout and have

                  > added points 4 and 8 from RL-002-DM-1 to the NAT configuration items.

                  > Yellow highlights are changes from the existing standard not previous

                  > versions of RL-002. Also, I added 2 diagrams for discussion.

                  >  

                  > Other Items in RL-002-DM-1:

                  > I don't agree with the main thrust of point 2 requiring port forwarding

                  > regardless of UDP port. I maintain that the mapping refered to

                  > will/should only occur using F-NPDU messages which provide the correct

                  > IP/Port so the UDP Port does not need to be excluded. In the standard

                  > 6.5.3  it refers to 4 methods for establishing the address of a BACnet

                  > router. 1) Manual config, 2) Who-is/I-am, 3)

                  > Who-Is-Router-To-Network/I-Am-Router-To-Network, and 4) Broadcast MAC in

                  > request/directed response. Only the 4th method will not work with B/IP

                  > and PAT. This 4th method is not a good idea anyhow and its use should be

                  > discouraged. At any rate normal directed communications should never

                  > cause a router to update its routing table and it is only these directed

                  > communications that the correct port (to use for future requests to the

                  > source network) is undeterminable.

                  >  

                  > I accept that a NAT Router may modify the source port as stated in point

                  > 7, but I don't understand why the need for only processing messages that

                  > come from sources in the BDT. Is this for security or am I missing the

                  > point?

                  >  

                  >  

                  >  

                  > Roland

                  > <<RL-002-4.doc>>

                  >  

                  >  

                  >  

                  >  

                  >  

                  >   _____

                  >  

                  > YAHOO! GROUPS LINKS

                  >  

                  >  

                  >  

                  > *     

                  (Message over 64 KB, truncated)

                • Matsen, Dean (WA26)
                  Exactly. It does get ugly around certain issues. RL-002 handles this mostly by making it so that it doesn t matter what the previous hop MAC address is,
                  Message 8 of 14 , Apr 10 1:53 PM
                  • 0 Attachment

                    Exactly.  It does get ugly around certain issues.

                     

                    RL-002 handles this mostly by making it so that it doesn't matter what the "previous hop" MAC address is, because in

                    most cases there is a DNET embedded in the message, and regardless of where the message comes from, the

                    message needs to be forwarded on to that DNET anyway.  In that sense, the immediate source address doesn't

                    matter, and in fact it is usually wrong, but the router doesn't look at it.

                     

                    Because BBMD's talk to each other using Forwarded-NPDU, and since they only talk to each other in the

                    case of broadcasts, the BBMDs correct for the translation by embedding their public addresses.

                     

                    Roland makes a good point, though, that routers are not supposed to "learn networks" from processing

                    unicast traffic.  I have re-implemented my network layer to update its routing information while

                    processing global broadcasts, but never on unicasts.  This causes it to pick up Who-Is and I-Am messages

                    (without actually decoding them as such).  Who-Is and I-Am messages will be handled by the BBMD via

                    Forwarded-NPDU, which conveys the correct "B/IP Address of Originating Device".

                     

                    It is really only direct communication between two NAT-enabled BBMD+B/IP implementations, or between

                    a NAT-enabled BBMD+B/IP and a registered foreign device, that there is a problem for handling BACnet

                    APDUs. 

                     

                    More ugliness arises with more detailed analysis of the handling of "Read-BDT", "Read-BDT-ACK"

                    "Register-FDT-ACK", et al.  Fortunately, my implementation knows it's waiting for a specific reply

                    TYPE, but it doesn't get picky about the source address of the reply.  Since the BACnet/IP

                    requests have nothing similar to the "Invoke ID" of an APDU, one is forced into a rather crude

                    implementation to handle such messages anyway.

                     

                     

                    Now that there is some agreement that a stronger solution is necessary, should I

                    resurrect DCM-003?  (With changes to accommodate the discussion that has occurred since

                    I originally posted it, of course).

                     

                    Regards,

                    Dean

                     


                    From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
                    Sent: Monday, April 10, 2006 1:14 PM
                    To: bacnet-ip-wg@yahoogroups.com
                    Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                     

                    I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons …

                     

                    First, how common is source address verification on responses? Is this required by the standard? If so, where? As long as you are verifying source addresses, then NAT/PAT is going to be really ugly.

                     

                    Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                     

                    1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path.

                    2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address?

                     

                     

                    Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                     

                    I don’t see how any of these issues are addressed in RL-002-4.

                     

                     

                     

                     

                     

                     

                    *******************************************************************

                     

                    Buddy Lott

                    Firmware Design Engineer

                    19476 Industrial Dr .

                    New Paris , IN 46553

                    574.831.5250 x 197

                    blott@...

                     

                    *******************************************************************

                    ________________________________________

                    From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott

                    Sent: Saturday, April 08, 2006 10:29 PM

                    To: bacnet-ip-wg@yahoogroups.com

                    Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                     

                    Hi Roland,

                     

                    I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

                     

                    I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

                     

                     

                     

                    *******************************************************************

                     

                    Buddy Lott

                    Firmware Design Engineer

                    19476 Industrial Dr .

                    New Paris , IN 46553

                    574.831.5250 x 197

                    blott@...

                     

                    *******************************************************************

                    ________________________________________

                    From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...

                    Sent: Friday, April 07, 2006 11:13 PM

                    To: bacnet-ip-wg@yahoogroups.com

                    Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                     

                     

                    Hi Buddy,

                     

                    I understood the device to be part of the BBMD, and residing on the global

                    BACnet network that the FD joins, otherwise we would not have this problem

                    at all, because the source address would be taken from the network layer.

                    It's only at the BACnet TSM level that we have to verify the source

                    address is the one we used in the request. In this case the source address

                    is taken directly from the IP and UDP headers (because of not being

                    routed).

                     

                    I suspect the problem that Dean is seeing is specific to the particular

                    NAT Router that he is using. At least I hope so - I have never seen this

                    behaviour before.

                     

                    Of course, the problem could be eliminated by placing the device on the

                    router side of the BBMD (all in the same device) assuming there is also an

                    integral router in the device.

                     

                    Roland.

                     

                     

                    > All,

                    >  

                    >  

                    >  

                    > I am a little confused by the description of the BBMD & Bacnet-IP

                    > device. Are they part of the same hardware? Is 102.168.20.100:47801 the

                    > address of the BBMD & BIP device?

                    >  

                    >  

                    >  

                    > If they are, then failure here is depending on the FD confirming that

                    > the source of the response came from the destination of request. Is this

                    > common practice? If it is, then this really surprises me.

                    >  

                    >  

                    >  

                    > If they are not, then we have violated one of the most important

                    > assumptions: there are no BIP devices using the BBMD. The BBMD is part

                    > of router the routes to another logical BIP network.

                    >  

                    >  

                    >  

                    > Thanks

                    >  

                    >  

                    >  

                    > *******************************************************************

                    >  

                    >  

                    >  

                    > Buddy Lott

                    > Firmware Design Engineer

                    > 19476 Industrial Dr .

                    > New Paris , IN 46553

                    > 574.831.5250 x 197

                    > blott@...

                    >  

                    >  

                    >  

                    > *******************************************************************

                    >  

                    >   _____

                    >  

                    > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                    > On Behalf Of Matsen, Dean (WA26)

                    > Sent: Thursday, April 06, 2006 8:34 PM

                    > To: bacnet-ip-wg@yahoogroups.com

                    > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                    >  

                    >  

                    >  

                    > Dear IP-WG:

                    >  

                    >  

                    >  

                    > Ok, I have implemented RL-002-4 as described, and there is still a

                    > subtle problem.  It is not a specific

                    >  

                    > problem with this iteration of RL-002, it was always there, although I

                    > missed it in my testing.

                    >  

                    >  

                    >  

                    > I have pointed out previously that foreign devices are the bane of

                    > BACnet/IP with NAT.  I

                    >  

                    > promised Buddy Lott that I would come up with an example where it breaks

                    > down.

                    >  

                    > This is not a made up example, I have BAS-O-Matic sniffer traces of the

                    > transaction

                    >  

                    > described below.

                    >  

                    >  

                    >  

                    > SETUP:

                    >  

                    >  

                    >  

                    > Suppose you have a NAT-enabled BBMD + B/IP device at address

                    > 192.168.20.100, UDP port 47801, behind a firewall.

                    >  

                    > The BBMD is configured to think its public IP address is 192.168.21.201,

                    > port 48020.  The

                    >  

                    > device instance of the B/IP device is 100.

                    >  

                    >  

                    >  

                    > The firewall's public address is 192.168.21.201, and it forwards port

                    > 48020 to 192.168.20.100:47801.

                    >  

                    > It's not important to this example, but the firewall's internal address

                    > is 192.168.20.254.

                    >  

                    >  

                    >  

                    > A foreign device is outside the firewall at 192.168.21.2, and it listens

                    > on port 47808 (BAC0).

                    >  

                    >  

                    >  

                    > TRANSACTIONS:

                    >  

                    >  

                    >  

                    > The foreign device registers with the NAT-enabled BBMD, using address

                    > 192.168.21.201 and port 48020,

                    >  

                    > the public address of the NAT-enabled BBMD.

                    >  

                    >  

                    >  

                    > The foreign device then emits a "Who-Is 100" request, sending the

                    > request via "Distribute Broadcast

                    >  

                    > to Network" to address 192.168.21.201 port 48020.

                    >  

                    >  

                    >  

                    > The BBMD distributes the broadcast as needed, the broadcast gets into

                    > the B/IP device, the B/IP

                    >  

                    > device responds "I-Am 100", and the BBMD repeats this broadcast.

                    >  

                    >  

                    >  

                    > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of

                    > Originating

                    >  

                    > Device" containing the address 192.168.21.201:48020 (the BBMD's public

                    > address).  The

                    >  

                    > source UDP port for the datagram containing this response is actually

                    > 47801 because of port

                    >  

                    > address translation.  No problem - this is a Forwarded-NPDU so we can

                    > look at the true originating

                    >  

                    > address in there.

                    >  

                    >  

                    >  

                    > The foreign device concludes that device 100 is reachable via B/IP

                    > address 0xC0A815C9BB94

                    >  

                    > (on the "local" network, no routing necessary).

                    >  

                    >  

                    >  

                    > Then the foreign device sends an Original-Unicast-NPDU to

                    > 192.168.21.201:48020 (=0xC0A815C9BB94),

                    >  

                    > containing a ReadProperty requesting a property from the device object

                    > (model-name, in my case).

                    >  

                    >  

                    >  

                    > Then device 100 responds with another Original-Unicast-NPDU back to

                    > address 192.168.21.2:47808.

                    >  

                    > However, once again the source UDP port of the datagram is 47801 because

                    > of port address

                    >  

                    > translation.  Since the source IP address and UDP port for this response

                    > is 192.168.21.201:47801,

                    >  

                    > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is

                    > expecting, which is

                    >  

                    > 0xC0A815C9BB94.

                    >  

                    >  

                    >  

                    > SUMMARY OF THE PROBLEM:

                    >  

                    >  

                    >  

                    > Foreign devices still broadcast through BBMD's but carry on unicast

                    > conversations point-to-point,

                    >  

                    > just like other BACnet/IP devices do in non-NAT situations.

                    >  

                    >  

                    >  

                    > Note that the retracted DCM-003 solved this problem, but it requires a

                    > small change to foreign

                    >  

                    > device implementations.

                    >  

                    >  

                    >  

                    > If anyone has a valid solution for this, please speak up!

                    >  

                    >  

                    >  

                    > Regards,

                    >  

                    > Dean

                    >  

                    >  

                    >  

                    >   _____

                    >  

                    > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                    > On Behalf Of Matsen, Dean (WA26)

                    > Sent: Thursday, April 06, 2006 10:34 AM

                    > To: bacnet-ip-wg@yahoogroups.com

                    > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                    >  

                    >  

                    >  

                    > Dean IP-WG

                    >  

                    >  

                    >  

                    > I see your point from 6.5.3.  However, as far as establishing address of

                    > BACnet router is concerned, one should note that the "Who-Is/I-Am"

                    > method is an APP/ASE layer consideration.  All the network layer should

                    > be looking at here is the NPCI, which has an "SNET" and a source MAC

                    > address.  So 6.5.3 is not really very disciplined in keeping network

                    > layer issues separate from higher layer issues, unless one accepts that

                    > the Who-Is/I-Am causes the router to be discovered as a side effect.

                    >  

                    >  

                    >  

                    > I guess the closest pure approximation for proper network layer

                    > implementation would be to update routing information only on global

                    > broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My

                    > current implementation also updates the information for unicasts.  In

                    > retrospect, I guess this does not agree with 6.5.3; sorry for the

                    > confusion there.

                    >  

                    >  

                    >  

                    > As far as point 7 is concerned, no it was not a security issue, it was

                    > to compute the correct source port address.  Since all broadcasts should

                    > come in the form of Forwarded-NPDU messages, I am thinking that only

                    > updating routing information on global broadcasts may totally solve this

                    > problem.  For what it's worth, I don't like point 7 very much either, so

                    > I'm really happy if there is a solution that doesn't need it.

                    >  

                    >  

                    >  

                    > Thanks, Roland!

                    >  

                    >  

                    >  

                    >  

                    >  

                    > Dean<

                    (Message over 64 KB, truncated)

                  • Buddy Lott
                    Section 6.5.3 paragraph 2 method 4 allows routers to learn router addresses through unicast traffic (specifically responses).
                    Message 9 of 14 , Apr 11 4:26 AM
                    • 0 Attachment

                      Section 6.5.3 paragraph 2 method 4 allows routers to learn router addresses through unicast traffic (specifically responses).

                       

                       

                      *******************************************************************

                       

                      Buddy Lott
                      Firmware Design Engineer
                      19476 Industrial Dr .
                      New Paris , IN 46553
                      574.831.5250 x 197
                      blott@...

                       

                      *******************************************************************


                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
                      Sent: Monday, April 10, 2006 4:53 PM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                       

                      Exactly.  It does get ugly around certain issues.

                       

                      RL-002 handles this mostly by making it so that it doesn't matter what the "previous hop" MAC address is, because in

                      most cases there is a DNET embedded in the message, and regardless of where the message comes from, the

                      message needs to be forwarded on to that DNET anyway.  In that sense, the immediate source address doesn't

                      matter, and in fact it is usually wrong, but the router doesn't look at it.

                       

                      Because BBMD's talk to each other using Forwarded-NPDU, and since they only talk to each other in the

                      case of broadcasts, the BBMDs correct for the translation by embedding their public addresses.

                       

                      Roland makes a good point, though, that routers are not supposed to "learn networks" from processing

                      unicast traffic.  I have re-implemented my network layer to update its routing information while

                      processing global broadcasts, but never on unicasts.  This causes it to pick up Who-Is and I-Am messages

                      (without actually decoding them as such).  Who-Is and I-Am messages will be handled by the BBMD via

                      Forwarded-NPDU, which conveys the correct "B/IP Address of Originating Device".

                       

                      It is really only direct communication between two NAT-enabled BBMD+B/IP implementations, or between

                      a NAT-enabled BBMD+B/IP and a registered foreign device, that there is a problem for handling BACnet

                      APDUs. 

                       

                      More ugliness arises with more detailed analysis of the handling of "Read-BDT", "Read-BDT-ACK"

                      "Register-FDT-ACK", et al.  Fortunately, my implementation knows it's waiting for a specific reply

                      TYPE, but it doesn't get picky about the source address of the reply.  Since the BACnet/IP

                      requests have nothing similar to the "Invoke ID" of an APDU, one is forced into a rather crude

                      implementation to handle such messages anyway.

                       

                       

                      Now that there is some agreement that a stronger solution is necessary, should I

                      resurrect DCM-003?  (With changes to accommodate the discussion that has occurred since

                      I originally posted it, of course).

                       

                      Regards,

                      Dean

                       


                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
                      Sent: Monday, April 10, 2006 1:14 PM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                       

                      I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons …

                       

                      First, how common is source address verification on responses? Is this required by the standard? If so, where? As long as you are verifying source addresses, then NAT/PAT is going to be really ugly.

                       

                      Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                       

                      1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path.

                      2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address?

                       

                       

                      Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                       

                      I don’t see how any of these issues are addressed in RL-002-4.

                       

                       

                       

                       

                       

                       

                      *******************************************************************

                       

                      Buddy Lott

                      Firmware Design Engineer

                      19476 Industrial Dr .

                      New Paris , IN 46553

                      574.831.5250 x 197

                      blott@...

                       

                      *******************************************************************

                      ________________________________________

                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott

                      Sent: Saturday, April 08, 2006 10:29 PM

                      To: bacnet-ip-wg@yahoogroups.com

                      Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                       

                      Hi Roland,

                       

                      I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

                       

                      I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

                       

                       

                       

                      *******************************************************************

                       

                      Buddy Lott

                      Firmware Design Engineer

                      19476 Industrial Dr .

                      New Paris , IN 46553

                      574.831.5250 x 197

                      blott@...

                       

                      *******************************************************************

                      ________________________________________

                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...

                      Sent: Friday, April 07, 2006 11:13 PM

                      To: bacnet-ip-wg@yahoogroups.com

                      Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                       

                       

                      Hi Buddy,

                       

                      I understood the device to be part of the BBMD, and residing on the global

                      BACnet network that the FD joins, otherwise we would not have this problem

                      at all, because the source address would be taken from the network layer.

                      It's only at the BACnet TSM level that we have to verify the source

                      address is the one we used in the request. In this case the source address

                      is taken directly from the IP and UDP headers (because of not being

                      routed).

                       

                      I suspect the problem that Dean is seeing is specific to the particular

                      NAT Router that he is using. At least I hope so - I have never seen this

                      behaviour before.

                       

                      Of course, the problem could be eliminated by placing the device on the

                      router side of the BBMD (all in the same device) assuming there is also an

                      integral router in the device.

                       

                      Roland.

                       

                       

                      > All,

                      >  

                      >  

                      >  

                      > I am a little confused by the description of the BBMD & Bacnet-IP

                      > device. Are they part of the same hardware? Is 102.168.20.100:47801 the

                      > address of the BBMD & BIP device?

                      >  

                      >  

                      >  

                      > If they are, then failure here is depending on the FD confirming that

                      > the source of the response came from the destination of request. Is this

                      > common practice? If it is, then this really surprises me.

                      >  

                      >  

                      >  

                      > If they are not, then we have violated one of the most important

                      > assumptions: there are no BIP devices using the BBMD. The BBMD is part

                      > of router the routes to another logical BIP network.

                      >  

                      >  

                      >  

                      > Thanks

                      >  

                      >  

                      >  

                      > *******************************************************************

                      >  

                      >  

                      >  

                      > Buddy Lott

                      > Firmware Design Engineer

                      > 19476 Industrial Dr .

                      > New Paris , IN 46553

                      > 574.831.5250 x 197

                      > blott@...

                      >  

                      >  

                      >  

                      > *******************************************************************

                      >  

                      >   _____

                      >  

                      > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                      > On Behalf Of Matsen, Dean (WA26)

                      > Sent: Thursday, April 06, 2006 8:34 PM

                      > To: bacnet-ip-wg@yahoogroups.com

                      > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                      >  

                      >  

                      >  

                      > Dear IP-WG:

                      >  

                      >  

                      >  

                      > Ok, I have implemented RL-002-4 as described, and there is still a

                      > subtle problem.  It is not a specific

                      >  

                      > problem with this iteration of RL-002, it was always there, although I

                      > missed it in my testing.

                      >  

                      >  

                      >  

                      > I have pointed out previously that foreign devices are the bane of

                      > BACnet/IP with NAT.  I

                      >  

                      > promised Buddy Lott that I would come up with an example where it breaks

                      > down.

                      >  

                      > This is not a made up example, I have BAS-O-Matic sniffer traces of the

                      > transaction

                      >  

                      > described below.

                      >  

                      >  

                      >  

                      > SETUP:

                      >  

                      >  

                      >  

                      > Suppose you have a NAT-enabled BBMD + B/IP device at address

                      > 192.168.20.100, UDP port 47801, behind a firewall.

                      >  

                      > The BBMD is configured to think its public IP address is 192.168.21.201,

                      > port 48020.  The

                      >  

                      > device instance of the B/IP device is 100.

                      >  

                      >  

                      >  

                      > The firewall's public address is 192.168.21.201, and it forwards port

                      > 48020 to 192.168.20.100:47801.

                      >  

                      > It's not important to this example, but the firewall's internal address

                      > is 192.168.20.254.

                      >  

                      >  

                      >  

                      > A foreign device is outside the firewall at 192.168.21.2, and it listens

                      > on port 47808 (BAC0).

                      >  

                      >  

                      >  

                      > TRANSACTIONS:

                      >  

                      >  

                      >  

                      > The foreign device registers with the NAT-enabled BBMD, using address

                      > 192.168.21.201 and port 48020,

                      >  

                      > the public address of the NAT-enabled BBMD.

                      >  

                      >  

                      >  

                      > The foreign device then emits a "Who-Is 100" request, sending the

                      > request via "Distribute Broadcast

                      >  

                      > to Network" to address 192.168.21.201 port 48020.

                      >  

                      >  

                      >  

                      > The BBMD distributes the broadcast as needed, the broadcast gets into

                      > the B/IP device, the B/IP

                      >  

                      > device responds "I-Am 100", and the BBMD repeats this broadcast.

                      >  

                      >  

                      >  

                      > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of

                      > Originating

                      >  

                      > Device" containing the address 192.168.21.201:48020 (the BBMD's public

                      > address).  The

                      >  

                      > source UDP port for the datagram containing this response is actually

                      > 47801 because of port

                      >  

                      > address translation.  No problem - this is a Forwarded-NPDU so we can

                      > look at the true originating

                      >  

                      > address in there.

                      >  

                      >  

                      >  

                      > The foreign device concludes that device 100 is reachable via B/IP

                      > address 0xC0A815C9BB94

                      >  

                      > (on the "local" network, no routing necessary).

                      >  

                      >  

                      >  

                      > Then the foreign device sends an Original-Unicast-NPDU to

                      > 192.168.21.201:48020 (=0xC0A815C9BB94),

                      >  

                      > containing a ReadProperty requesting a property from the device object

                      > (model-name, in my case).

                      >  

                      >  

                      >  

                      > Then device 100 responds with another Original-Unicast-NPDU back to

                      > address 192.168.21.2:47808.

                      >  

                      > However, once again the source UDP port of the datagram is 47801 because

                      > of port address

                      >  

                      > translation.  Since the source IP address and UDP port for this response

                      > is 192.168.21.201:47801,

                      >  

                      > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is

                      > expecting, which is

                      >  

                      > 0xC0A815C9BB94.

                      >  

                      >  

                      >  

                      > SUMMARY OF THE PROBLEM:

                      >  

                      >  

                      >  

                      > Foreign devices still broadcast through BBMD's but carry on unicast

                      > conversations point-to-point,

                      >  

                      > just like other BACnet/IP devices do in non-NAT situations.

                      >  

                      >  

                      >  

                      > Note that the retracted DCM-003 solved this problem, but it requires a

                      > small change to foreign

                      >  

                      > device implementations.

                      >  

                      >  

                      >  

                      > If anyone has a valid solution for this, please speak up!

                      >  

                      >  

                      >  

                      > Regards,

                      >  

                      > Dean

                      >  

                      >  

                      >  

                      >   _____

                      >  

                      > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                      > On Behalf Of Matsen, Dean (WA26)

                      > Sent: Thursday, April 06, 2006 10:34 AM

                      > To: bacnet-ip-wg@yahoogroups.com

                      > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                      >  

                      >  

                      >  

                      > Dean IP-WG

                      >  

                      >  

                      >  

                      > I see your point from 6.5.3.  However, as far as establishing address of

                      > BACnet router is concerned, one should note that the "Who-Is/I-Am"

                      > method is an APP/ASE layer consideration.  All the network layer should

                      > be looking at here is the NPCI, which has an "SNET" and a source MAC

                      > address.  So 6.5.3 is not really very disciplined in keeping network

                      > layer issues separate from higher layer issues, unless one accepts that

                      > the Who-Is/I-Am causes the router to be discovered as a side effect.

                      >  

                      >  

                      >  

                      > I guess the closest pure approximation for proper network layer

                      > implementation would be to update routing information only on global

                      > broadcasts (which

                      (Message over 64 KB, truncated)

                    • Buddy Lott
                      Btw. I realize this may be a little off topic, but since we have been dealing with router path updates issues I thought this was somewhat relevant. Section
                      Message 10 of 14 , Apr 11 5:06 AM
                      • 0 Attachment

                        Btw. I realize this may be a little off topic, but since we have been dealing with router path updates issues I thought this was somewhat relevant.

                         

                        Section 6.5.3 paragraph 2 method 2 says a router can learn paths via I-AM APDU messages.

                         

                        Although I admit that it is common practice to global broadcast I-AM messages in response to Who-Is messages, section 16.10.4 allows for local and remote broadcast. Local broadcast would not provide routing information. What about remote broadcast? Should a router update its routing table when a remote broadcast is routed? Assuming more than 1 hop between the source and destination network, the routers between treat the remote broadcast as a unicast message.

                         

                        From section 16.10.4:

                         

                        … “If the I-am is being broadcast in response to a previously received Who-Is, then the I-Am shall be broadcast in such a manner that the BACnet-User that sent the Who-Is will receive the resulting I-AM.” …   

                         

                        I find this sentence entertaining. The intent seems to be to “limit” the scope of the I-am during certain discovery scenarios. After all, why should everyone suffer because a new tool is trying to discover the network? Does unicasting the I-AM back to the requester honor this requirement or its intent? If unicasting an I-am is allowed, can the router learn a new route via the “unicast” message?

                         

                        I have plenty of other question regarding this section … which I think I might post the BACnet-L newsgroup.

                         

                         

                        *******************************************************************

                         

                        Buddy Lott
                        Firmware Design Engineer
                        19476 Industrial Dr .
                        New Paris , IN 46553
                        574.831.5250 x 197
                        blott@...

                         

                        *******************************************************************


                        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
                        Sent: Tuesday, April 11, 2006 7:26 AM
                        To: bacnet-ip-wg@yahoogroups.com
                        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                         

                        Section 6.5.3 paragraph 2 method 4 allows routers to learn router addresses through unicast traffic (specifically responses).

                         

                         

                        *******************************************************************

                         

                        Buddy Lott
                        Firmware Design Engineer
                        19476 Industrial Dr .
                        New Paris , IN 46553
                        574.831.5250 x 197
                        blott@...

                         

                        *******************************************************************


                        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
                        Sent: Monday, April 10, 2006 4:53 PM
                        To: bacnet-ip-wg@yahoogroups.com
                        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                         

                        Exactly.  It does get ugly around certain issues.

                         

                        RL-002 handles this mostly by making it so that it doesn't matter what the "previous hop" MAC address is, because in

                        most cases there is a DNET embedded in the message, and regardless of where the message comes from, the

                        message needs to be forwarded on to that DNET anyway.  In that sense, the immediate source address doesn't

                        matter, and in fact it is usually wrong, but the router doesn't look at it.

                         

                        Because BBMD's talk to each other using Forwarded-NPDU, and since they only talk to each other in the

                        case of broadcasts, the BBMDs correct for the translation by embedding their public addresses.

                         

                        Roland makes a good point, though, that routers are not supposed to "learn networks" from processing

                        unicast traffic.  I have re-implemented my network layer to update its routing information while

                        processing global broadcasts, but never on unicasts.  This causes it to pick up Who-Is and I-Am messages

                        (without actually decoding them as such).  Who-Is and I-Am messages will be handled by the BBMD via

                        Forwarded-NPDU, which conveys the correct "B/IP Address of Originating Device".

                         

                        It is really only direct communication between two NAT-enabled BBMD+B/IP implementations, or between

                        a NAT-enabled BBMD+B/IP and a registered foreign device, that there is a problem for handling BACnet

                        APDUs. 

                         

                        More ugliness arises with more detailed analysis of the handling of "Read-BDT", "Read-BDT-ACK"

                        "Register-FDT-ACK", et al.  Fortunately, my implementation knows it's waiting for a specific reply

                        TYPE, but it doesn't get picky about the source address of the reply.  Since the BACnet/IP

                        requests have nothing similar to the "Invoke ID" of an APDU, one is forced into a rather crude

                        implementation to handle such messages anyway.

                         

                         

                        Now that there is some agreement that a stronger solution is necessary, should I

                        resurrect DCM-003?  (With changes to accommodate the discussion that has occurred since

                        I originally posted it, of course).

                         

                        Regards,

                        Dean

                         


                        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
                        Sent: Monday, April 10, 2006 1:14 PM
                        To: bacnet-ip-wg@yahoogroups.com
                        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                         

                        I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons …

                         

                        First, how common is source address verification on responses? Is this required by the standard? If so, where? As long as you are verifying source addresses, then NAT/PAT is going to be really ugly.

                         

                        Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                         

                        1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path.

                        2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address?

                         

                         

                        Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                         

                        I don’t see how any of these issues are addressed in RL-002-4.

                         

                         

                         

                         

                         

                         

                        *******************************************************************

                         

                        Buddy Lott

                        Firmware Design Engineer

                        19476 Industrial Dr .

                        New Paris , IN 46553

                        574.831.5250 x 197

                        blott@...

                         

                        *******************************************************************

                        ________________________________________

                        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott

                        Sent: Saturday, April 08, 2006 10:29 PM

                        To: bacnet-ip-wg@yahoogroups.com

                        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                         

                        Hi Roland,

                         

                        I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

                         

                        I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

                         

                         

                         

                        *******************************************************************

                         

                        Buddy Lott

                        Firmware Design Engineer

                        19476 Industrial Dr .

                        New Paris , IN 46553

                        574.831.5250 x 197

                        blott@...

                         

                        *******************************************************************

                        ________________________________________

                        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rlaird@...

                        Sent: Friday, April 07, 2006 11:13 PM

                        To: bacnet-ip-wg@yahoogroups.com

                        Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                         

                         

                        Hi Buddy,

                         

                        I understood the device to be part of the BBMD, and residing on the global

                        BACnet network that the FD joins, otherwise we would not have this problem

                        at all, because the source address would be taken from the network layer.

                        It's only at the BACnet TSM level that we have to verify the source

                        address is the one we used in the request. In this case the source address

                        is taken directly from the IP and UDP headers (because of not being

                        routed).

                         

                        I suspect the problem that Dean is seeing is specific to the particular

                        NAT Router that he is using. At least I hope so - I have never seen this

                        behaviour before.

                         

                        Of course, the problem could be eliminated by placing the device on the

                        router side of the BBMD (all in the same device) assuming there is also an

                        integral router in the device.

                         

                        Roland.

                         

                         

                        > All,

                        >  

                        >  

                        >  

                        > I am a little confused by the description of the BBMD & Bacnet-IP

                        > device. Are they part of the same hardware? Is 102.168.20.100:47801 the

                        > address of the BBMD & BIP device?

                        >  

                        >  

                        >  

                        > If they are, then failure here is depending on the FD confirming that

                        > the source of the response came from the destination of request. Is this

                        > common practice? If it is, then this really surprises me.

                        >  

                        >  

                        >  

                        > If they are not, then we have violated one of the most important

                        > assumptions: there are no BIP devices using the BBMD. The BBMD is part

                        > of router the routes to another logical BIP network.

                        >  

                        >  

                        >  

                        > Thanks

                        >  

                        >  

                        >  

                        > *******************************************************************

                        >  

                        >  

                        >  

                        > Buddy Lott

                        > Firmware Design Engineer

                        > 19476 Industrial Dr .

                        > New Paris , IN 46553

                        > 574.831.5250 x 197

                        > blott@...

                        >  

                        >  

                        >  

                        > *******************************************************************

                        >  

                        >   _____

                        >  

                        > From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ]

                        > On Behalf Of Matsen, Dean (WA26)

                        > Sent: Thursday, April 06, 2006 8:34 PM

                        > To: bacnet-ip-wg@yahoogroups.com

                        > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                        >  

                        >  

                        >  

                        > Dear IP-WG:

                        >  

                        >  

                        >  

                        > Ok, I have implemented RL-002-4 as described, and there is still a

                        > subtle problem.  It is not a specific

                        >  

                        > problem with this iteration of RL-002, it was always there, although I

                        > missed it in my testing.

                        >  

                        >  

                        >  

                        > I have pointed out previously that foreign devices are the bane of

                        > BACnet/IP with NAT.  I

                        >  

                        > promised Buddy Lott that I would come up with an example where it breaks

                        > down.

                        >  

                        > This is not a made up example, I have BAS-O-Matic sniffer traces of the

                        > transaction

                        >  

                        > described below.

                        >  

                        >  

                        >  

                        > SETUP:

                        >  

                        >  

                        >  

                        > Suppose you have a NAT-enabled BBMD + B/IP device at address

                        > 192.168.20.100, UDP port 47801, behind a firewall.

                        >  

                        > The BBMD is configured to think its public IP address is 192.168.21.201,

                        > port 48020.  The

                        >  

                        > device instance of the B/IP device is 100.

                        >  

                        >  

                        >  

                        > The firewall's public address is 192.168.21.201, and it forwards port

                        > 48020 to 192.168.20.100:47801.

                        >  

                        > It's not important to this example, but the firewall's internal address

                        > is 192.168.20.254.

                        >  

                        >  

                        >  

                        > A foreign device is outside the firewall at 192.168.21.2, and it listens

                        > on port 47808 (BAC0).

                        >  

                        >  

                        >  

                        > TRANSACTIONS:

                        >  

                        >  

                        >  

                        > The foreign device registers with the NAT-enabled BBMD, using address

                        > 192.168.21.201 and port 48020,

                        >  

                        > the public address of the NAT-enabled BBMD.

                        >  

                        >  

                        >  

                        > The foreign device then emits a "Who-Is 100" request, sending the

                        > request via "Distribute Broadcast

                        >  

                        > to Network" to address 192.168.21.201 port 48020.

                        >  

                        >  

                        >  

                        > The BBMD distributes the broadcast as needed, the broadcast gets into

                        > the B/IP device, the B/IP

                        >  

                        > device responds "I-Am 100", and the BBMD repeats this broadcast.

                        >  

                        >  

                        >  

                        > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of

                        > Originating

                        >  

                        > Device" containing the address 192.168.21.201:48020 (the BBMD's public

                        > address).  The

                        >  

                        > source UDP port for the datagram containing this response is actually

                        > 47801 because of port

                        >  

                        > address translation.  No problem - this is a Forwarded-NPDU so we can

                        > look at the true originating

                        >  

                        > address in there.

                        >  

                        >  

                        >  

                        > The foreign device concludes that device 100 is reachable via B/IP

                        > address 0xC0A815C9BB94

                        >  

                        > (on the "local" network, no routing necessary).

                        >  

                        >  

                        >  

                        > Then the foreign device sends an Original-Unicast-NPDU to

                        > 192.168.21.201:48020 (=0xC0A815C9BB94),

                        >  

                        > containing a ReadProperty requesting a property from the device object

                        > (model-name, in my case).

                        >  

                        >  

                        >  

                        > Then device 100 responds with another Original-Unicast-NPDU back to

                        > address 192.168.21.2:47808.

                        >  

                        > However, once again the source UDP port of the datagram is 47801 because

                        > of port address

                        >  

                        > translation.  Since the source IP address and UDP port for this response

                        > is 192.168.21.201:47801,

                        >  

                        > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is

                        > expecting, which is

                        >  

                        > 0xC0A815C9BB94.

                        >  

                        >  

                        >  

                        > SUMMARY OF THE PROBLEM:

                        >  

                        >  

                        >  

                        > Foreign devices still broadcast through BBMD's but carry on unicast

                        > conversations point-to-point,

                        >  

                        > just like other BACnet/IP devices do in non-NAT situations.

                        >  

                        >  

                        >  

                        > Note that the retracted DCM-003 solved this problem, but it requires a

                        (Message over 64 KB, truncated)

                      • Roland Laird
                        Dean, I put my comments in the body of your email. Roland _____ From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy
                        Message 11 of 14 , Apr 12 12:13 PM
                        • 0 Attachment
                          Dean,
                          I put my comments in the body of your email.
                          Roland 
                           
                           

                          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
                          Sent: Monday, April 10, 2006 1:14 PM
                          To: bacnet-ip-wg@yahoogroups.com
                          Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                          I finally have my thoughts together on this, and I think the situation gets ugly for a couple reasons …

                           

                          First, how common is source address verification on responses? Is this required by the standard? If so, where? As long as you are verifying source addresses, then NAT/PAT is going to be really ugly.

                           

                          In section 5.4 of the standard it states:

                          When a PDU is received from the network layer, the PDU type, the source and destination BACnetAddresses, and the Invoke ID (if any) of the PDU shall be examined to determine the type (requesting BACnet-user or responding BACnet-user) and the identity of the TSM to which the PDU shall be passed. If no such TSM exists, one shall be created.

                           

                           

                           

                          Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                           

                          1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path. 

                           

                              If this is a I-am-to-router message the router table will be updated with the Address of Originating Device from the F-NPDU.

                           

                          2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address? 

                          All responses simply go back to the source of the request. If the routers didn't  allow a open return path based on the source ip and port, I think many internet applications would fail.

                           

                           

                          Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                           

                          I also ran into this on PTP as well (likely the same manufacturer) and made an exception for PTP to handle this. It is bad enough for a PTP half-router, but we simply cannot allow a B/IP router to not respond to who-is-router-to-network.

                           

                          I don’t see how any of these issues are addressed in RL-002-4.

                           

                          I still think RL-002 works - at least it does for us.  

                          The only restriction (which I should add to RL-002) is that you must provide a static global IP/Port mapping to the local IP/Port of the BBMD/Router. Note that this does not consume a global IP for BACnet purposes only. It is just one port on one global IP. I think this is very reasonable.

                           

                           

                           

                           

                          *******************************************************************

                           

                          Buddy Lott

                          Firmware Design Engineer

                          19476 Industrial Dr .

                          New Paris , IN 46553

                          574.831.5250 x 197

                          blott@...

                           

                          *******************************************************************

                          ________________________________________

                          From:bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com ] On Behalf OfBuddy Lott

                          Sent: Saturday, April 08, 2006 10:29 PM

                          To:bacnet-ip-wg@yahoogroups.com

                          Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                           

                          Hi Roland,

                           

                          I was thinking along the same lines as you are then I realized that there is a subtle interaction here that may mean that this would not work EVEN if the device was on the router side of the BBMD.

                           

                          I have not read the latest document so I am not sure if my concern is already handled. I want to wait to voice my concerns until I have had a chance to play with the problem.

                           

                           

                           

                          *******************************************************************

                           

                          Buddy Lott

                          Firmware Design Engineer

                          19476 Industrial Dr .

                          New Paris , IN 46553

                          574.831.5250 x 197

                          blott@...

                           

                          *******************************************************************

                          ________________________________________

                          From:bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com ] On Behalf Ofrlaird@...

                          Sent: Friday, April 07, 2006 11:13 PM

                          To:bacnet-ip-wg@yahoogroups.com

                          Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                           

                           

                          Hi Buddy,

                           

                          I understood the device to be part of the BBMD, and residing on the global

                          BACnet network that the FD joins, otherwise we would not have this problem

                          at all, because the source address would be taken from the network layer.

                          It's only at the BACnet TSM level that we have to verify the source

                          address is the one we used in the request. In this case the source address

                          is taken directly from the IP and UDP headers (because of not being

                          routed).

                           

                          I suspect the problem that Dean is seeing is specific to the particular

                          NAT Router that he is using. At least I hope so - I have never seen this

                          behaviour before.

                           

                          Of course, the problem could be eliminated by placing the device on the

                          router side of the BBMD (all in the same device) assuming there is also an

                          integral router in the device.

                           

                          Roland.

                           

                           

                          > All,

                          >  

                          >  

                          >  

                          > I am a little confused by the description of the BBMD & Bacnet-IP

                          > device. Are they part of the same hardware? Is 102.168.20.100:47801 the

                          > address of the BBMD & BIP device?

                          >  

                          >  

                          >  

                          > If they are, then failure here is depending on the FD confirming that

                          > the source of the response came from the destination of request. Is this

                          > common practice? If it is, then this really surprises me.

                          >  

                          >  

                          >  

                          > If they are not, then we have violated one of the most important

                          > assumptions: there are no BIP devices using the BBMD. The BBMD is part

                          > of router the routes to another logical BIP network.

                          >  

                          >  

                          >  

                          > Thanks

                          >  

                          >  

                          >  

                          > *******************************************************************

                          >  

                          >  

                          >  

                          >Buddy Lott

                          > Firmware Design Engineer

                          >19476 Industrial Dr .

                          > New Paris , IN 46553

                          > 574.831.5250 x 197

                          > blott@...

                          >  

                          >  

                          >  

                          > *******************************************************************

                          >  

                          >   _____

                          >  

                          > From:bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com ]

                          > On Behalf Of Matsen, Dean (WA26)

                          > Sent: Thursday, April 06, 2006 8:34 PM

                          > To:bacnet-ip-wg@yahoogroups.com

                          > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                          >  

                          >  

                          >  

                          > Dear IP-WG:

                          >  

                          >  

                          >  

                          > Ok, I have implemented RL-002-4 as described, and there is still a

                          > subtle problem.  It is not a specific

                          >  

                          > problem with this iteration of RL-002, it was always there, although I

                          > missed it in my testing.

                          >  

                          >  

                          >  

                          > I have pointed out previously that foreign devices are the bane of

                          > BACnet/IP with NAT.  I

                          >  

                          > promisedBuddy Lott that I would come up with an example where it breaks

                          > down.

                          >  

                          > This is not a made up example, I have BAS-O-Matic sniffer traces of the

                          > transaction

                          >  

                          > described below.

                          >  

                          >  

                          >  

                          > SETUP:

                          >  

                          >  

                          >  

                          > Suppose you have a NAT-enabled BBMD + B/IP device at address

                          > 192.168.20.100, UDP port 47801, behind a firewall.

                          >  

                          > The BBMD is configured to think its public IP address is 192.168.21.201,

                          > port 48020.  The

                          >  

                          > device instance of the B/IP device is 100.

                          >  

                          >  

                          >  

                          > The firewall's public address is 192.168.21.201, and it forwards port

                          > 48020 to 192.168.20.100:47801.

                          >  

                          > It's not important to this example, but the firewall's internal address

                          > is 192.168.20.254.

                          >  

                          >  

                          >  

                          > A foreign device is outside the firewall at 192.168.21.2, and it listens

                          > on port 47808 (BAC0).

                          >  

                          >  

                          >  

                          > TRANSACTIONS:

                          >  

                          >  

                          >  

                          > The foreign device registers with the NAT-enabled BBMD, using address

                          > 192.168.21.201 and port 48020,

                          >  

                          > the public address of the NAT-enabled BBMD.

                          >  

                          >  

                          >  

                          > The foreign device then emits a "Who-Is 100" request, sending the

                          > request via "Distribute Broadcast

                          >  

                          > to Network" to address 192.168.21.201 port 48020.

                          >  

                          >  

                          >  

                          > The BBMD distributes the broadcast as needed, the broadcast gets into

                          > the B/IP device, the B/IP

                          >  

                          > device responds "I-Am 100", and the BBMD repeats this broadcast.

                          >  

                          >  

                          >  

                          > The I-Am comes from the BBMD in a Forwarded-NPDU, with "B/IP Address of

                          > Originating

                          >  

                          > Device" containing the address 192.168.21.201:48020 (the BBMD's public

                          > address).  The

                          >  

                          > source UDP port for the datagram containing this response is actually

                          > 47801 because of port

                          >  

                          > address translation.  No problem - this is a Forwarded-NPDU so we can

                          > look at the true originating

                          >  

                          > address in there.

                          >  

                          >  

                          >  

                          > The foreign device concludes that device 100 is reachable via B/IP

                          > address 0xC0A815C9BB94

                          >  

                          > (on the "local" network, no routing necessary).

                          >  

                          >  

                          >  

                          > Then the foreign device sends an Original-Unicast-NPDU to

                          > 192.168.21.201:48020 (=0xC0A815C9BB94),

                          >  

                          > containing a ReadProperty requesting a property from the device object

                          > (model-name, in my case).

                          >  

                          >  

                          >  

                          > Then device 100 responds with another Original-Unicast-NPDU back to

                          > address 192.168.21.2:47808.

                          >  

                          > However, once again the source UDP port of the datagram is 47801 because

                          > of port address

                          >  

                          > translation.  Since the source IP address and UDP port for this response

                          > is 192.168.21.201:47801,

                          >  

                          > the B/IP address is 0xC0A815C9BAB9, not what the foreign device is

                          > expecting, which is

                          >  

                          > 0xC0A815C9BB94.

                          >  

                          >  

                          >  

                          > SUMMARY OF THE PROBLEM:

                          >  

                          >  

                          >  

                          > Foreign devices still broadcast through BBMD's but carry on unicast

                          > conversations point-to-point,

                          >  

                          > just like other BACnet/IP devices do in non-NAT situations.

                          >  

                          >  

                          >  

                          > Note that the retracted DCM-003 solved this problem, but it requires a

                          > small change to foreign

                          >  

                          > device implementations.

                          >  

                          >  

                          >  

                          > If anyone has a valid solution for this, please speak up!

                          >  

                          >  

                          >  

                          > Regards,

                          >  

                          > Dean

                          >  

                          >  

                          >  

                          >   _____

                          >  

                          > From:bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com ]

                          > On Behalf Of Matsen, Dean (WA26)

                          > Sent: Thursday, April 06, 2006 10:34 AM

                          > To:bacnet-ip-wg@yahoogroups.com

                          > Subject: RE: [bacnet-ip-wg] New Update RL-002-4

                          >  

                          >  

                          >  

                          > Dean IP-WG

                          >  

                          >  

                          >  

                          > I see your point from 6.5.3.  However, as far as establishing address of

                          > BACnet router is concerned, one should note that the "Who-Is/I-Am"

                          > method is an APP/ASE layer consideration.  All the network layer should

                          > be looking at here is the NPCI, which has an "SNET" and a source MAC

                          > address.  So 6.5.3 is not really very disciplined in keeping network

                          > layer issues separate from higher layer issues, unless one accepts that

                          > the Who-Is/I-Am causes the router to be discovered as a side effect.

                          >  

                          >  

                          >  

                          > I guess the closest pure approximation for proper network layer

                          > implementation would be to update routing information only on global

                          > broadcasts (which includes Who-Is/I-Am), but never on unicasts.  My

                          > current implementation also updates the information for unicasts.  In

                          > retrospect, I guess this does not agree with 6.5.3; sorry for the

                          > confusion there.

                          >  

                          >  

                          >  

                          > As far as point 7 is concerned, no it was not a security issue, it was

                          > to compute the correct source port address.  Since all broadcasts should

                          > come in the form of Forwarded-NPDU messages, I am thinking that only

                          > updating routing information on global broadcasts may totally solve this

                          > problem.  For what it's worth, I don't like point 7 very much either, so

                          > I'm really happy if there is a solution that doesn't need it.

                          >  

                          >  

                          >  

                          > Thanks, Roland!

                          >  

                          >  

                          >  

                          >  

                          >  

                          > Dean

                          >  

                          >  

                          >  

                          >  

                          >  

                          >   _____

                          >  

                          > From:bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com ]

                          > On Behalf Of Roland Laird

                          > Sent: Thursday, April 06, 2006 8:06 AM

                          > To: BACnet-IP-WG@yahoogroups.com

                          > Subject: [bacnet-ip-wg] New Update RL-002-4

                          >  

                          >  

                          >  

                          >  

                          >  

                          > Dear IP-WG



                          (Message over 64 KB, truncated)

                        • Buddy Lott
                          Roland, I think you put your comments in the bottom of my email. I hope Dean doesn t take it as an insult that you mistook my writing for his. :-) I take it a
                          Message 12 of 14 , Apr 12 1:13 PM
                          • 0 Attachment

                            Roland,

                             

                            I think you put your comments in the bottom of my email. I hope Dean doesn’t take it as an insult that you mistook my writing for his. J I take it a compliment. J

                             

                            I have embedded my comments too your comments below.

                             

                             [Buddy Lott>] ************************************************************************************

                            In section 5.4 of the standard it states:

                             

                            When a PDU is received from the network layer, the PDU type, the source and destination BACnetAddresses, and the Invoke ID (if any) of the PDU shall be examined to determine the type (requesting BACnet-user or responding BACnet-user) and the identity of the TSM to which the PDU shall be passed. If no such TSM exists, one shall be created.

                             

                            [Buddy Lott> Ah. Yet another state machine I have to understand.

                             

                             

                            Second, Dean’s scenario is a specific case of a more general problem. If we assume that port forwarding is unidirectional (which is true according to my sys admin) and that NAT is working, then the BIP device can be addressed in two different ways. One address is specified by the port forwarding. The second is a little more subtle. *IF* dynamic NAT is used and the BIP Device (102.168.20.100:47801) INITIATES a request or network layer message, the NAT router can added a new “translation rule” that changes the source address of the outbound packet to 192.168.21.201:48021 ands waits for the response. The response will then be forwarded to 192.168.20.100:47801. Now we have 2 public addresses being forwarded to the same private address. We run into two cases:

                             

                            1)                            If this happens to be a I-am-router-to-network message, what should a receiving router do? Does it update for the source address in the packet or the “port forwarded address”? The same kind of issue can arise with static NAT/PAT, if care is not taken to make sure the combination of NAT & port forwarding yields a bi-directional path. 

                             

                                If this is a I-am-to-router message the router table will be updated with the Address of Originating Device from the F-NPDU.

                            [Buddy Lott>] Hm. I realize a mistake I made here. If the BBMD is part of a router, will the I-Am-Router-To-Network message be sent as a “Forwarded-NPDU” or as an “Original-Broadcast”. All the implementations I have seen, send it as a “Forwarded-NPDU” which means the Originating-Device address would be correct.

                             

                            2)                            If this is a “request”, should the responder reply to the port forwarded address or the “NAT-ed” address? 

                            All responses simply go back to the source of the request. If the routers didn't  allow a open return path based on the source ip and port, I think many internet applications would fail.

                             

                            [Buddy Lott>] This is the confusing part of NAT/PAT. For TCP/IP connections, NAT/PAT keeps the return-path open for as long as the session is connected. For UDP/IP, it is usually timeout based and sometimes “need” based . If the path is idle for “too long” (the definition of too long is a “local matter” J ), the NAT/PAT router can (and does) close the return path. If the NAT/PAT router runs out of entries, it can close and reopen an old one. The next time the “public side” of the path is opened, the private side could point to the same device or a different device. Thus traffic may only work intermittently.

                             

                            Third (I think this was addressed in some other emails), what happens to routers that “learn networks” through routed APDUs? I ran into a PTP implementation that did not send I-Am-Router-To-Network messages and routes HAD to be learned through the APDUs. Eliminating this possibility from BIP seems both necessary and non-customer friendly.

                             

                            I also ran into this on PTP as well (likely the same manufacturer) and made an exception for PTP to handle this. It is bad enoughfor a PTP half-router, but we simply cannot allow a B/IP router to not respond to who-is-router-to-network.

                             

                            I don’t see how any of these issues are addressed in RL-002-4.

                             

                            I still think RL-002 works - at least it does for us. 

                            Theonly restriction (which I should add to RL-002) is that you must provide a static global IP/Port mapping to the local IP/Port of the BBMD/Router. Note that this does not consume a global IP for BACnet purposes only. It is just one port on one global IP. I think this is very reasonable.

                             

                            [Buddy Lott>] That is the nasty part of all of this. Far too many configurations partially work. I worked in our test network a month or more before I noticed the problem. All it took for me find the problem, was to move my laptop from one subnet to another. I also agree (not much choice reall) that one static mapping is very reasonable. I think you are going to have make the static mapping bi-directionlal (basically, eliminate the possibility of dynamic NAT/PAT). I just don’t see a way around that.

                             

                             

                             

                            Thanks.

                             

                            *******************************************************************

                             

                            Buddy Lott
                            Firmware Design Engineer
                            19476 Industrial Dr .
                            New Paris , IN 46553
                            574.831.5250 x 197
                            blott@...

                             

                            *******************************************************************


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