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

       

       

    • Matsen, Dean (WA26)
      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
      Message 2 of 10 , Mar 29, 2006
      • 0 Attachment

        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 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
        Message 3 of 10 , Mar 30, 2006
        • 0 Attachment

          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)
          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
          Message 4 of 10 , Mar 30, 2006
          • 0 Attachment

            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
            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 5 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 6 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 7 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 8 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 9 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.