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

RE: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

Expand Messages
  • Matsen, Dean (WA26)
    NEW! Improved! Attachment included! ________________________________ From: Matsen, Dean (WA26) Sent: Wednesday, March 29, 2006 4:20 PM To:
    Message 1 of 10 , Mar 29, 2006
    • 0 Attachment

      NEW! Improved!  Attachment included!

       

       


      From: Matsen, Dean (WA26)
      Sent: Wednesday, March 29, 2006 4:20 PM
      To: 'bacnet-ip-wg@yahoogroups.com'
      Subject: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

       

       

      I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

      it also does not have some of the foreign device registration problems.

       

      I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

       

       

      Dean Matsen

        Software Architect

        Honeywell Automation and Control Systems

        Alerton

       

       

    • Buddy Lott
      IMHO: Three incorrect assumptions that a lot of proposals make are: 1) Assuming that there is only one layer of NAT. In fact, it is far more common that 2
      Message 2 of 10 , Mar 30, 2006
      • 0 Attachment

        IMHO:

         

        Three incorrect assumptions that a lot of proposals make are:

        1)      Assuming that there is only one layer of NAT. In fact, it is far more common that 2 or more layers of NAT are at play in any communication. PPP is a great example.

        2)      Assuming NAT is only an issue of going from the private network into the public. I took a Cisco training class several years ago, where the instructor pointed out that some “lazy” administrators have reversed this because they used “public” address for a private network and then had to connect to the public network and where too lazy to do it “right”.

        3)      Assuming that NAT/PAT is static. NAT/PAT is dynamic almost everywhere. This is less work the administrator and makes better use of the IT equipment.

         

        I like the idea of a “NAT” support mode for BBMDs.

         

        I am not sure you really mean multicast. Most IT people I know absolutely forbid Gobal Broadcast (255.255.255.255), hate subnet broadcast (remote and local), dislike multicast (but acknowledge its usefulness) and like unicast. I have even been asked by IT people why BACnet (Especially BBMDs) do not make use of Multicasting.

         

        I would be interested in hearing about the Foreign Device Scenario you mentioned. The only one I have come up that would not work with rules I mentioned would violate one of the rules.

         

          

         

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

         

        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, March 30, 2006 1:33 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

         

        Ugh... I've not seen an example of translation on incoming packets.  That's a bother.  Thanks for pointing that out, I didn't know that could happen.

         

        You are right about the "local subnet" broadcast – it's not needed.  Except: the B/IP implementation at least needs to virtually broadcast to the BBMD implementation, even if it never actually gets on the wire.  Handling it this way allows the BBMD and B/IP implementations to remain separate.  FYI, in my implementation, that broadcast never gets out on the wire when in NAT support mode.

         

        Yes, one-hop is deprecated with respect to NAT.  In fact, it ought to be deprecated entirely.  I can't think of one IT administrator that wouldn't blow a fuse over using multicasts on his network.  And it surely isn't going to work over the internet.  So, just make sure mask is always 255.255.255.255, and then everyone is using two-hop.  This can be handled by documentation and usage policy.

         

        It is not explicitly stated in the document, but in order to support a local BACnet/IP network and also a NAT-enabled BACnet/IP network, you really need two separate BACnet/IP implementations, both linked by BACnet routing.  In other words, a NAT-enabled BBMD can't talk to local devices (this is between the lines by requiring them to be on separate subnets).

         

        As far as whether or not it is sufficient to just relax the requirement of having the BDTs all the same, I can assure you it is not sufficient for all cases.  It does, however work for most cases, especially if one has the two BACnet/IP implementations with the BACnet routing between them.  

        HOWEVER: all the proposals I have seen so far gloss over the impact of foreign device registration -- Including DCM-003, which I had to retract because of one subtle and unexpected scenario.  Supporting foreign device registration must be considered carefully, especially considering the fact that the foreign devices must sometimes register with a NAT-enabled BBMD through the firewall, etc.

         

         

        Regards,

        Dean

         


        From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
        Sent: Thursday, March 30, 2006 9:02 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

         

        I have a lot of the same issues that I have had with previous suggestions. Unfortunately, I have been unable to come up with a solution to these issues other than to say that there is evidence that NAT routers are moving to fix this problem.

         

        Here are my comments in relationship to the document at hand:

         

        j.2.5 Determining the return address is where the problem is. When going thru a NAT router, you may not always be able to determine return address, because you may be going thru 1 or more NAT routers on any given communication path. One or more of those routers will probably be cycling thru a list of address & ports that will change at the worse of times.

         

        J.4.3 I think this is a step in the right direction but it requires more data management from the installer/end-use. Do they really want or need these hassles?

         

        J.7.2

                    1) This will only work if the BBMD is part of a router (which is mentioned later, but should probably be mentioned here). Although it is not typically, you have to remember that NAT is bi-directional. It can be applied to source, destination or both for any given communication. If the source address of an inbound packet is being NATed instead of the destination, we could still have a problem. I actually have this setup in my office and it causes some major headaches. Luckily it is a test setup.

                    2) NAT is not as popular these days as PAT. Few if any campuses are going to want or have enough public IPAddress to assign a particular public IP address to a BBMD. They will have more than enough IP/Port address combinations to assign one to a BBMD and this is a reasonable expectation. IT departments do this for web servers so it shouldn’t be a big deal for BBMDs (although they do want to minimize this). Since the BBMD will be part of a BACnet router, this should not be a big headache.

                    3) I have read this three times and still not sure what it is saying. Assuming this is related to BBMD broadcast forwarding: 1-HOP BBMD will most likely NEVER be used to cross NAT/PAT boundaries. It is too easy of a mechanism to use for DOS attacks and the nature of BACnet means the DOS attack detection would be difficult.

                    4) If we assume that the BBMD is part of router (which it sounds like is being required) then I am not sure what is being provided here. All traffic (directed and broadcast) will be “routed” by the BBMD eliminating the use of the Originating address.

                    5) This strikes me as kind of interesting. In the context of what we are talking about, this means that the BBMD broadcast to the “local subnet” is a wasted effort (all the devices are on a different “logical network”). So why require it?

                    6) I think this is wrong. By requiring the BBMD/router combination to be a gateway past the NAT router and previous rules, we really have alleviated the BBMD from needing to know its own global address.

                    7) I think port forwarding takes care of this problem. I can’t think of a realistic configuration where it wouldn’t.

         

         

        IMHO: Requiring the BBMD/Router combination. Forbidding “multiple BBMDs from NATed side of NAT router”. Forbidding FDR from the same side of the NAT. Relaxing the all “BDT are the same” requirement is enough to get BACNet/IP useable in most of the case. We can certainly come up with some cases where it will break, but clever configuration will solve most of those.

         

         

         

         

         

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

         

        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: Wednesday, March 29, 2006 7:40 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

         

        Sorry – previous message did not have the attachment.  I re-sent it, but it never arrived.  Dunno why.

         

        I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

        it also does not have some of the foreign device registration problems.

         

        I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

         

         

        Dean Matsen

          Software Architect

          Honeywell Automation and Control Systems

          Alerton

         

         

         

      • Matsen, Dean (WA26)
        Before I spend time trying to document an example, which implementation do you want a counterexample for? I assume you mean just allowing BDTs to be
        Message 3 of 10 , Mar 30, 2006
        • 0 Attachment

          Before I spend time trying to document an example, which implementation do you want a counterexample for?  I assume you mean just allowing BDTs to be different, but not implementing the "B/IP Address of Originating Device" address stuffing as described in RL-002 (including the changes I made thereof).  Mind you, RL-002 does not have any known (to me) issues after my modifications (which are highlighted in light blue).

           

          Properly describing a scenario is enough work I want to make sure I show one that is relevant.

           

          Regards,

          Dean

           


          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
          Sent: Thursday, March 30, 2006 12:41 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

           

          IMHO:

           

          Three incorrect assumptions that a lot of proposals make are:

          1)      Assuming that there is only one layer of NAT. In fact, it is far more common that 2 or more layers of NAT are at play in any communication. PPP is a great example.

          2)      Assuming NAT is only an issue of going from the private network into the public. I took a Cisco training class several years ago, where the instructor pointed out that some “lazy” administrators have reversed this because they used “public” address for a private network and then had to connect to the public network and where too lazy to do it “right”.

          3)      Assuming that NAT/PAT is static. NAT/PAT is dynamic almost everywhere. This is less work the administrator and makes better use of the IT equipment.

           

          I like the idea of a “NAT” support mode for BBMDs.

           

          I am not sure you really mean multicast. Most IT people I know absolutely forbid Gobal Broadcast (255.255.255.255), hate subnet broadcast (remote and local), dislike multicast (but acknowledge its usefulness) and like unicast. I have even been asked by IT people why BACnet (Especially BBMDs) do not make use of Multicasting.

           

          I would be interested in hearing about the Foreign Device Scenario you mentioned. The only one I have come up that would not work with rules I mentioned would violate one of the rules.

           

            

           

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

           

          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, March 30, 2006 1:33 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

           

          Ugh... I've not seen an example of translation on incoming packets.  That's a bother.  Thanks for pointing that out, I didn't know that could happen.

           

          You are right about the "local subnet" broadcast – it's not needed.  Except: the B/IP implementation at least needs to virtually broadcast to the BBMD implementation, even if it never actually gets on the wire.  Handling it this way allows the BBMD and B/IP implementations to remain separate.  FYI, in my implementation, that broadcast never gets out on the wire when in NAT support mode.

           

          Yes, one-hop is deprecated with respect to NAT.  In fact, it ought to be deprecated entirely.  I can't think of one IT administrator that wouldn't blow a fuse over using multicasts on his network.  And it surely isn't going to work over the internet.  So, just make sure mask is always 255.255.255.255, and then everyone is using two-hop.  This can be handled by documentation and usage policy.

           

          It is not explicitly stated in the document, but in order to support a local BACnet/IP network and also a NAT-enabled BACnet/IP network, you really need two separate BACnet/IP implementations, both linked by BACnet routing.  In other words, a NAT-enabled BBMD can't talk to local devices (this is between the lines by requiring them to be on separate subnets).

           

          As far as whether or not it is sufficient to just relax the requirement of having the BDTs all the same, I can assure you it is not sufficient for all cases.  It does, however work for most cases, especially if one has the two BACnet/IP implementations with the BACnet routing between them.  

          HOWEVER: all the proposals I have seen so far gloss over the impact of foreign device registration -- Including DCM-003, which I had to retract because of one subtle and unexpected scenario.  Supporting foreign device registration must be considered carefully, especially considering the fact that the foreign devices must sometimes register with a NAT-enabled BBMD through the firewall, etc.

           

           

          Regards,

          Dean

           


          From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
          Sent: Thursday, March 30, 2006 9:02 AM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

           

          I have a lot of the same issues that I have had with previous suggestions. Unfortunately, I have been unable to come up with a solution to these issues other than to say that there is evidence that NAT routers are moving to fix this problem.

           

          Here are my comments in relationship to the document at hand:

           

          j.2.5 Determining the return address is where the problem is. When going thru a NAT router, you may not always be able to determine return address, because you may be going thru 1 or more NAT routers on any given communication path. One or more of those routers will probably be cycling thru a list of address & ports that will change at the worse of times.

           

          J.4.3 I think this is a step in the right direction but it requires more data management from the installer/end-use. Do they really want or need these hassles?

           

          J.7.2

                      1) This will only work if the BBMD is part of a router (which is mentioned later, but should probably be mentioned here). Although it is not typically, you have to remember that NAT is bi-directional. It can be applied to source, destination or both for any given communication. If the source address of an inbound packet is being NATed instead of the destination, we could still have a problem. I actually have this setup in my office and it causes some major headaches. Luckily it is a test setup.

                      2) NAT is not as popular these days as PAT. Few if any campuses are going to want or have enough public IPAddress to assign a particular public IP address to a BBMD. They will have more than enough IP/Port address combinations to assign one to a BBMD and this is a reasonable expectation. IT departments do this for web servers so it shouldn’t be a big deal for BBMDs (although they do want to minimize this). Since the BBMD will be part of a BACnet router, this should not be a big headache.

                      3) I have read this three times and still not sure what it is saying. Assuming this is related to BBMD broadcast forwarding: 1-HOP BBMD will most likely NEVER be used to cross NAT/PAT boundaries. It is too easy of a mechanism to use for DOS attacks and the nature of BACnet means the DOS attack detection would be difficult.

                      4) If we assume that the BBMD is part of router (which it sounds like is being required) then I am not sure what is being provided here. All traffic (directed and broadcast) will be “routed” by the BBMD eliminating the use of the Originating address.

                      5) This strikes me as kind of interesting. In the context of what we are talking about, this means that the BBMD broadcast to the “local subnet” is a wasted effort (all the devices are on a different “logical network”). So why require it?

                      6) I think this is wrong. By requiring the BBMD/router combination to be a gateway past the NAT router and previous rules, we really have alleviated the BBMD from needing to know its own global address.

                      7) I think port forwarding takes care of this problem. I can’t think of a realistic configuration where it wouldn’t.

           

           

          IMHO: Requiring the BBMD/Router combination. Forbidding “multiple BBMDs from NATed side of NAT router”. Forbidding FDR from the same side of the NAT. Relaxing the all “BDT are the same” requirement is enough to get BACNet/IP useable in most of the case. We can certainly come up with some cases where it will break, but clever configuration will solve most of those.

           

           

           

           

           

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

           

          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: Wednesday, March 29, 2006 7:40 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

           

          Sorry – previous message did not have the attachment.  I re-sent it, but it never arrived.  Dunno why.

           

          I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

          it also does not have some of the foreign device registration problems.

           

          I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

           

           

          Dean Matsen

            Software Architect

            Honeywell Automation and Control Systems

            Alerton

           

           

           

        • Buddy Lott
          I was originally interested in the scenario you were referring to when you mentioned all the proposals I have seen so far gloss over the impact of foreign
          Message 4 of 10 , Mar 30, 2006
          • 0 Attachment

            I was originally interested in the scenario you were referring to when you mentioned “all the proposals I have seen so far gloss over the impact of foreign device registration -- Including DCM-003, which I had to retract because of one subtle and unexpected scenario“.

             

            Now I am interested in any scenario where “As far as whether or not it is sufficient to just relax the requirement of having the BDTs all the same, I can assure you it is not sufficient for all cases.”  is true.

             

            Basics are fine. I should be able to piece together all the details.

             

             

             

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

             

            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, March 30, 2006 4:35 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

             

            Before I spend time trying to document an example, which implementation do you want a counterexample for?  I assume you mean just allowing BDTs to be different, but not implementing the "B/IP Address of Originating Device" address stuffing as described in RL-002 (including the changes I made thereof).  Mind you, RL-002 does not have any known (to me) issues after my modifications (which are highlighted in light blue).

             

            Properly describing a scenario is enough work I want to make sure I show one that is relevant.

             

            Regards,

            Dean

             


            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
            Sent: Thursday, March 30, 2006 12:41 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

             

            IMHO:

             

            Three incorrect assumptions that a lot of proposals make are:

            1)      Assuming that there is only one layer of NAT. In fact, it is far more common that 2 or more layers of NAT are at play in any communication. PPP is a great example.

            2)      Assuming NAT is only an issue of going from the private network into the public. I took a Cisco training class several years ago, where the instructor pointed out that some “lazy” administrators have reversed this because they used “public” address for a private network and then had to connect to the public network and where too lazy to do it “right”.

            3)      Assuming that NAT/PAT is static. NAT/PAT is dynamic almost everywhere. This is less work the administrator and makes better use of the IT equipment.

             

            I like the idea of a “NAT” support mode for BBMDs.

             

            I am not sure you really mean multicast. Most IT people I know absolutely forbid Gobal Broadcast (255.255.255.255), hate subnet broadcast (remote and local), dislike multicast (but acknowledge its usefulness) and like unicast. I have even been asked by IT people why BACnet (Especially BBMDs) do not make use of Multicasting.

             

            I would be interested in hearing about the Foreign Device Scenario you mentioned. The only one I have come up that would not work with rules I mentioned would violate one of the rules.

             

              

             

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

             

            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, March 30, 2006 1:33 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

             

            Ugh... I've not seen an example of translation on incoming packets.  That's a bother.  Thanks for pointing that out, I didn't know that could happen.

             

            You are right about the "local subnet" broadcast – it's not needed.  Except: the B/IP implementation at least needs to virtually broadcast to the BBMD implementation, even if it never actually gets on the wire.  Handling it this way allows the BBMD and B/IP implementations to remain separate.  FYI, in my implementation, that broadcast never gets out on the wire when in NAT support mode.

             

            Yes, one-hop is deprecated with respect to NAT.  In fact, it ought to be deprecated entirely.  I can't think of one IT administrator that wouldn't blow a fuse over using multicasts on his network.  And it surely isn't going to work over the internet.  So, just make sure mask is always 255.255.255.255, and then everyone is using two-hop.  This can be handled by documentation and usage policy.

             

            It is not explicitly stated in the document, but in order to support a local BACnet/IP network and also a NAT-enabled BACnet/IP network, you really need two separate BACnet/IP implementations, both linked by BACnet routing.  In other words, a NAT-enabled BBMD can't talk to local devices (this is between the lines by requiring them to be on separate subnets).

             

            As far as whether or not it is sufficient to just relax the requirement of having the BDTs all the same, I can assure you it is not sufficient for all cases.  It does, however work for most cases, especially if one has the two BACnet/IP implementations with the BACnet routing between them.  

            HOWEVER: all the proposals I have seen so far gloss over the impact of foreign device registration -- Including DCM-003, which I had to retract because of one subtle and unexpected scenario.  Supporting foreign device registration must be considered carefully, especially considering the fact that the foreign devices must sometimes register with a NAT-enabled BBMD through the firewall, etc.

             

             

            Regards,

            Dean

             


            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
            Sent: Thursday, March 30, 2006 9:02 AM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

             

            I have a lot of the same issues that I have had with previous suggestions. Unfortunately, I have been unable to come up with a solution to these issues other than to say that there is evidence that NAT routers are moving to fix this problem.

             

            Here are my comments in relationship to the document at hand:

             

            j.2.5 Determining the return address is where the problem is. When going thru a NAT router, you may not always be able to determine return address, because you may be going thru 1 or more NAT routers on any given communication path. One or more of those routers will probably be cycling thru a list of address & ports that will change at the worse of times.

             

            J.4.3 I think this is a step in the right direction but it requires more data management from the installer/end-use. Do they really want or need these hassles?

             

            J.7.2

                        1) This will only work if the BBMD is part of a router (which is mentioned later, but should probably be mentioned here). Although it is not typically, you have to remember that NAT is bi-directional. It can be applied to source, destination or both for any given communication. If the source address of an inbound packet is being NATed instead of the destination, we could still have a problem. I actually have this setup in my office and it causes some major headaches. Luckily it is a test setup.

                        2) NAT is not as popular these days as PAT. Few if any campuses are going to want or have enough public IPAddress to assign a particular public IP address to a BBMD. They will have more than enough IP/Port address combinations to assign one to a BBMD and this is a reasonable expectation. IT departments do this for web servers so it shouldn’t be a big deal for BBMDs (although they do want to minimize this). Since the BBMD will be part of a BACnet router, this should not be a big headache.

                        3) I have read this three times and still not sure what it is saying. Assuming this is related to BBMD broadcast forwarding: 1-HOP BBMD will most likely NEVER be used to cross NAT/PAT boundaries. It is too easy of a mechanism to use for DOS attacks and the nature of BACnet means the DOS attack detection would be difficult.

                        4) If we assume that the BBMD is part of router (which it sounds like is being required) then I am not sure what is being provided here. All traffic (directed and broadcast) will be “routed” by the BBMD eliminating the use of the Originating address.

                        5) This strikes me as kind of interesting. In the context of what we are talking about, this means that the BBMD broadcast to the “local subnet” is a wasted effort (all the devices are on a different “logical network”). So why require it?

                        6) I think this is wrong. By requiring the BBMD/router combination to be a gateway past the NAT router and previous rules, we really have alleviated the BBMD from needing to know its own global address.

                        7) I think port forwarding takes care of this problem. I can’t think of a realistic configuration where it wouldn’t.

             

             

            IMHO: Requiring the BBMD/Router combination. Forbidding “multiple BBMDs from NATed side of NAT router”. Forbidding FDR from the same side of the NAT. Relaxing the all “BDT are the same” requirement is enough to get BACNet/IP useable in most of the case. We can certainly come up with some cases where it will break, but clever configuration will solve most of those.

             

             

             

             

             

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

             

            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: Wednesday, March 29, 2006 7:40 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: [bacnet-ip-wg] RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

             

            Sorry – previous message did not have the attachment.  I re-sent it, but it never arrived.  Dunno why.

             

            I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

            it also does not have some of the foreign device registration problems.

             

            I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

             

             

            Dean Matsen

              Software Architect

              Honeywell Automation and Control Systems

              Alerton

             

             

             

          • Carl Neilson
            I am assuming that the blue changes are the ones applicable to this revision. Point 2 appears to be redundant (but more clearly stated) than point 5. But I
            Message 5 of 10 , Apr 3, 2006
            • 0 Attachment
               
              I am assuming that the blue changes are the ones applicable to this revision.
               
               
              Point 2 appears to be redundant (but more clearly stated) than point 5. But I could be mis-reading point 5.
               
              Point 4 is a clarification. The standard already requires this functionality (except for the use of the global address which is required by point 3).
               
              Point 8 appears to be redundant with point 2.
               
              That leaves point 7 as the only fundamental change.
              I must prefix this with the statement that I am not a NAT/PAT box guru. I can only indicate the experience that we have with them. We have implemented essentially this proposal with the exception of J.7.2 point 7. In our experience NAT boxes do not screw with the source port of UDP connections when port forwarding is enabled on the port. The result is that when the BBMD sends a message it will retain port BAC0 on the outside of the NAT box. Any receiving NAT box will not diddle the source port either. Thousands of installations exist that use this solution and as far as we are aware none have failed in the field due to a NAT/PAT box that diddles the source port.
               
              The ports are usually only changed when there is no static port mapping. This applies to Foreign devices behind NAT boxes. As long as the BBMD accepts Foreign Registration requests with any source port, and forwards back to the specific port (and not the network's defined port) then the Foreign device can reside behind a NAT box (it must have a sufficiently short registration interval to keep the same port through the NAT box open).
               
               
              Are we experiencing something different from everyone else when it comes to NAT/PAT boxes?
               
               
              Regards,
              Carl
               
               


              From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Matsen, Dean (WA26)
              Sent: Wednesday, March 29, 2006 4:21 PM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: [bacnet-ip-wg] RE: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

              NEW! Improved!  Attachment included!

               

               


              From: Matsen, Dean (WA26)
              Sent: Wednesday, March 29, 2006 4:20 PM
              To: 'bacnet-ip-wg@yahoogroups.com'
              Subject: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

               

               

              I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

              it also does not have some of the foreign device registration problems.

               

              I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

               

               

              Dean Matsen

                Software Architect

                Honeywell Automation and Control Systems

                Alerton

               

               

            • Matsen, Dean (WA26)
              during my tests, I have seen NAT routers do both. The BAC0 port being retained outside the NAT box does occur, usually. In my case, if there is also a static
              Message 6 of 10 , Apr 3, 2006
              • 0 Attachment

                during my tests, I have seen NAT routers do both.  The BAC0 port being retained outside the NAT box does occur, usually.  

                 

                In my case, if there is also a static forwarding from port BAC0 to something inside the firewall, then the UDP port will not be retained when the BBMD sends a message – the NAT router seems to "go around" the static mapping and use BAC1 (or some other random assignment).  I am not sure exactly why, but I get the feeling the NAT implementation doesn't want to assume that the incoming forwarding has anything to do with the outgoing traffic.  Perhaps the NAT RFC explains a scenario where it is important to treat it as such.

                 

                In any case, yes, I am in fact seeing the port getting modified (frequently, but not always) on outbound packets.

                 

                Dean

                 


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Carl Neilson
                Sent: Monday, April 03, 2006 11:45 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] RE: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

                 

                 

                I am assuming that the blue changes are the ones applicable to this revision.

                 

                 

                Point 2 appears to be redundant (but more clearly stated) than point 5. But I could be mis-reading point 5.

                 

                Point 4 is a clarification. The standard already requires this functionality (except for the use of the global address which is required by point 3).

                 

                Point 8 appears to be redundant with point 2.

                 

                That leaves point 7 as the only fundamental change. I must prefix this with the statement that I am not a NAT/PAT box guru. I can only indicate the experience that we have with them. We have implemented essentially this proposal with the exception of J.7.2 point 7. In our experience NAT boxes do not screw with the source port of UDP connections when port forwarding is enabled on the port. The result is that when the BBMD sends a message it will retain port BAC0 on the outside of the NAT box. Any receiving NAT box will not diddle the source port either. Thousands of installations exist that use this solution and as far as we are aware none have failed in the field due to a NAT/PAT box that diddles the source port.

                 

                The ports are usually only changed when there is no static port mapping. This applies to Foreign devices behind NAT boxes. As long as the BBMD accepts Foreign Registration requests with any source port, and forwards back to the specific port (and not the network's defined port) then the Foreign device can reside behind a NAT box (it must have a sufficiently short registration interval to keep the same port through the NAT box open).

                 

                 

                Are we experiencing something different from everyone else when it comes to NAT/PAT boxes?

                 

                 

                Regards,

                Carl

                 

                 

                 


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
                Sent: Wednesday, March 29, 2006 4:21 PM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: [bacnet-ip-wg] RE: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

                NEW! Improved!  Attachment included!

                 

                 


                From: Matsen, Dean (WA26)
                Sent: Wednesday, March 29, 2006 4:20 PM
                To: ' bacnet-ip-wg@yahoogroups.com '
                Subject: RFC: Modifications to RL-002 that [seem to] resolve issues previously discussed

                 

                 

                I have found out how to implement RL-002 in such a way that it does not have the varying B/IP address problem, AND

                it also does not have some of the foreign device registration problems.

                 

                I also checked the "has been verified by implementation", since I have implemented (but not really exhaustively tested yet) the solution.

                 

                 

                Dean Matsen

                  Software Architect

                  Honeywell Automation and Control Systems

                  Alerton

                 

                 

                 

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