Re: [time-nuts] DHS Resilient PNT Conformance Framework
Poul-Henning, On 2020-12-22 10:55, Poul-Henning Kamp wrote: > > Magnus Danielson writes: > >> In the end, if this takes off, what it does is that it creates a market >> for devices to meet these requirements. [...] > Sorry Magnus but I don't belive a word of it. > > This is simply a clever ploy from your side, to get tons of perfectly > fine GPSDO's dumped cheaply onto eBay because "they no longer comply > with government regulations" :-) Haha! Actually, that was not my secret goal. :) Rather, I want to make multi-band, multi-system GNSS receivers cheap by creating a market for them. So we can enjoy higher precision at a more affordable price. The rest is... added benefit. ;-) (To be honest, I can't fit much more new GPSDOs here) > Merry X-mas, and stay safe everybody! > > Poul-Henning > Merry X-mas and a Happy New Year! Stay safe, stay locked and keep them oscillators running! Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Magnus Danielson writes: > In the end, if this takes off, what it does is that it creates a market > for devices to meet these requirements. [...] Sorry Magnus but I don't belive a word of it. This is simply a clever ploy from your side, to get tons of perfectly fine GPSDO's dumped cheaply onto eBay because "they no longer comply with government regulations" :-) Merry X-mas, and stay safe everybody! Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Bob, Sure, but I think some of these requirements will be met for fairly cheap devices soon enough. Another aspect we also discussed is that while a module on its own may not do all the things needed to meet a level, if it has sufficient of capabilities to support additional checks and then those is performed outside, the system they form may achieve the higher level requiring the function. So, with sufficiently open interface to key state to monitor things, as we know several receiver has, then they can achieve that. Now, nothing have been detailed as to what to monitor and when to judge go/no-go, for any system, the framework is there to say that such mechanisms should be described, eventually. That may end up being a fun discussion. In the end, if this takes off, what it does is that it creates a market for devices to meet these requirements. In doing so, the intention is to make sure that there is a high level of commonality between the requirements for the different sectors of the same level. So, not that everyone invent their wheel, but rather they indicate their subset needing extra attention and jot down critical performance numbers for it to fit their environment. Having common threats/scenarios to test for among sectors have been discussed. Having common model for state-analysis of receivers have also been mentioned. Nothing decided. All there is, is to convey the general concepts and see if there is any takers to follow up. I think most importantly that a lot is achieved by trying to build a common ground like this. The framework as it stands is still vague, as little specifics is there. I expect more to come in the future. Cheers, Magnus On 2020-12-22 02:29, Bob kb8tq wrote: > Hi > > Well, we’re not talking about $9 parts here. Typical prices in the $500 to > $2,000 in > quantity would be a better description. That said, the OEM’s normally saw the > field > upgrade process as a bigger risk than not getting involved in it ….. > > Bob > >> On Dec 21, 2020, at 7:51 PM, Magnus Danielson wrote: >> >> Hi Bob, >> >> Yes, there is even receivers with no know way of upgrade in the field. >> But this framework was not meant to make all receivers meet the >> requirements, rather the opposite, the unofficial class of level 0 is >> most of those receivers. If level 1 or higher is needed for critical >> infrastructure of any kind, vendors aiming to sell to that market needs >> to adapt. Getting a 9 USD module from some obscure vendor just won't cut >> it. Also, if there is a way to clear the NV memory on the module, the >> way the module is wrapped into another device must maintain the ability >> to clear the NV. So would be true for the ability to upgrade for those >> needing to meet that requirement. >> >> I take some pride in the upgrade requirement. It ripples over from the >> NASPI TSTF report where I contributed such formulations. I also >> advocated for it in this work. It comes from bitter experience. Very >> bitter. Luckily for me, I did not have to do the major part of >> suffering, but I was there to see the troubles on multiple times. >> >> For the reset thing, that came from another source, where jamming caused >> some mobile phones to loose capability, which was a kind of bitter >> experience considering they where meant to illustrate the problem, not >> to brick peoples devices. So that was also bitter experience. Especially >> the air-safety folks was very keen to have a way to make devices go back >> to well behaved maner after the event, and by manual methods in the >> field. I think it is a wise way of reasoning. >> >> Also, this is a framework, and these are the common minimum requirement. >> This is not ruling out that for some application the requirements may be >> more detailed and stricter in some sense. For instance, the actual >> performance may differ, or the time to recovery from factory default >> restart or time to fix in normal setting. While Time To Fix had lots of >> focus initially, we concluded that it was actually not the parameter of >> greatest importance here, as that has already improved a lot, but other >> properties may dominate. >> >> Cheers, >> Magnus >> >> On 2020-12-21 20:08, Bob kb8tq wrote: >>> Hi >>> >>> I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them >>> had >>> *major* concerns about field upgrades. Their take was that supporting them >>> had >>> always turned into a disaster. No matter how clear the instructions, a >>> significant >>> number of systems went down / stayed down while sub assemblies were being >>> upgraded ….. >>> >>> Pretty much the universal approach: Return the device to the factory and do >>> any >>> needed upgrades there. Test it / verify it works and send it back. Having >>> sat through >>> several of those exercises, I do not remember a single device that >>> “bricked” when >>> done that way. >>> >>> Bob >>> On Dec 21, 2020, at 9:56 AM, Magnus Danielson wrote: Hi, >>
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Well, we’re not talking about $9 parts here. Typical prices in the $500 to $2,000 in quantity would be a better description. That said, the OEM’s normally saw the field upgrade process as a bigger risk than not getting involved in it ….. Bob > On Dec 21, 2020, at 7:51 PM, Magnus Danielson wrote: > > Hi Bob, > > Yes, there is even receivers with no know way of upgrade in the field. > But this framework was not meant to make all receivers meet the > requirements, rather the opposite, the unofficial class of level 0 is > most of those receivers. If level 1 or higher is needed for critical > infrastructure of any kind, vendors aiming to sell to that market needs > to adapt. Getting a 9 USD module from some obscure vendor just won't cut > it. Also, if there is a way to clear the NV memory on the module, the > way the module is wrapped into another device must maintain the ability > to clear the NV. So would be true for the ability to upgrade for those > needing to meet that requirement. > > I take some pride in the upgrade requirement. It ripples over from the > NASPI TSTF report where I contributed such formulations. I also > advocated for it in this work. It comes from bitter experience. Very > bitter. Luckily for me, I did not have to do the major part of > suffering, but I was there to see the troubles on multiple times. > > For the reset thing, that came from another source, where jamming caused > some mobile phones to loose capability, which was a kind of bitter > experience considering they where meant to illustrate the problem, not > to brick peoples devices. So that was also bitter experience. Especially > the air-safety folks was very keen to have a way to make devices go back > to well behaved maner after the event, and by manual methods in the > field. I think it is a wise way of reasoning. > > Also, this is a framework, and these are the common minimum requirement. > This is not ruling out that for some application the requirements may be > more detailed and stricter in some sense. For instance, the actual > performance may differ, or the time to recovery from factory default > restart or time to fix in normal setting. While Time To Fix had lots of > focus initially, we concluded that it was actually not the parameter of > greatest importance here, as that has already improved a lot, but other > properties may dominate. > > Cheers, > Magnus > > On 2020-12-21 20:08, Bob kb8tq wrote: >> Hi >> >> I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them >> had >> *major* concerns about field upgrades. Their take was that supporting them >> had >> always turned into a disaster. No matter how clear the instructions, a >> significant >> number of systems went down / stayed down while sub assemblies were being >> upgraded ….. >> >> Pretty much the universal approach: Return the device to the factory and do >> any >> needed upgrades there. Test it / verify it works and send it back. Having >> sat through >> several of those exercises, I do not remember a single device that “bricked” >> when >> done that way. >> >> Bob >> >>> On Dec 21, 2020, at 9:56 AM, Magnus Danielson wrote: >>> >>> Hi, >>> >>> On 2020-12-21 09:02, Poul-Henning Kamp wrote: Bob kb8tq writes: > I have seen cases of “goes away until power cycled”. I have not seen any > cases of > “goes away forever” other than the obvious ( = feed it an insane almanac > that prevents > if from ever locking up ). Even with that said, I have not seen an > example ot that sort of > thing living through a hard reset … ( which isn’t quite the same thing as > a power cycle ). I have: An corrupt alamanac in NV storage contained something which made a particular GPS receiver divide by zero, shit its pants and wedge during startup. The post mortem report said that the alamanac passed the "technical consistency checks", by which I suppose they mean the Hamming code, but it still caused a divide by zero. This incident is the reasons why GPS receivers in some critical applications are not allowed to have NV storage for "operational purposes" and get the almanac downloaded from the attached systems at startup. >>> With this new language, they would be required to be Level 1 compliant, >>> at which it would always be a way for the user to reset corrupt data in >>> the field. We never even discussed the possibility of prohibiting the >>> NV, rather we focused on the ability to recover in the field. NV has >>> it's upsides to boot quickly etc. but as any cache, it needs to be >>> clearable. >>> >>> In a similar sense, we also had a good discussion about being able to >>> upgrade the receiver. Several of us was driving hard to ensure that >>> receivers can be upgradeable in the field, so that bugs can be removed >>> continuously throughout the operational lifetime. In fact, I pointed out >>> t
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Bob, Yes, there is even receivers with no know way of upgrade in the field. But this framework was not meant to make all receivers meet the requirements, rather the opposite, the unofficial class of level 0 is most of those receivers. If level 1 or higher is needed for critical infrastructure of any kind, vendors aiming to sell to that market needs to adapt. Getting a 9 USD module from some obscure vendor just won't cut it. Also, if there is a way to clear the NV memory on the module, the way the module is wrapped into another device must maintain the ability to clear the NV. So would be true for the ability to upgrade for those needing to meet that requirement. I take some pride in the upgrade requirement. It ripples over from the NASPI TSTF report where I contributed such formulations. I also advocated for it in this work. It comes from bitter experience. Very bitter. Luckily for me, I did not have to do the major part of suffering, but I was there to see the troubles on multiple times. For the reset thing, that came from another source, where jamming caused some mobile phones to loose capability, which was a kind of bitter experience considering they where meant to illustrate the problem, not to brick peoples devices. So that was also bitter experience. Especially the air-safety folks was very keen to have a way to make devices go back to well behaved maner after the event, and by manual methods in the field. I think it is a wise way of reasoning. Also, this is a framework, and these are the common minimum requirement. This is not ruling out that for some application the requirements may be more detailed and stricter in some sense. For instance, the actual performance may differ, or the time to recovery from factory default restart or time to fix in normal setting. While Time To Fix had lots of focus initially, we concluded that it was actually not the parameter of greatest importance here, as that has already improved a lot, but other properties may dominate. Cheers, Magnus On 2020-12-21 20:08, Bob kb8tq wrote: > Hi > > I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them had > *major* concerns about field upgrades. Their take was that supporting them > had > always turned into a disaster. No matter how clear the instructions, a > significant > number of systems went down / stayed down while sub assemblies were being > upgraded ….. > > Pretty much the universal approach: Return the device to the factory and do > any > needed upgrades there. Test it / verify it works and send it back. Having sat > through > several of those exercises, I do not remember a single device that “bricked” > when > done that way. > > Bob > >> On Dec 21, 2020, at 9:56 AM, Magnus Danielson wrote: >> >> Hi, >> >> On 2020-12-21 09:02, Poul-Henning Kamp wrote: >>> >>> Bob kb8tq writes: >>> I have seen cases of “goes away until power cycled”. I have not seen any cases of “goes away forever” other than the obvious ( = feed it an insane almanac that prevents if from ever locking up ). Even with that said, I have not seen an example ot that sort of thing living through a hard reset … ( which isn’t quite the same thing as a power cycle ). >>> I have: An corrupt alamanac in NV storage contained something which >>> made a particular GPS receiver divide by zero, shit its pants and >>> wedge during startup. >>> >>> The post mortem report said that the alamanac passed the "technical >>> consistency checks", by which I suppose they mean the Hamming code, >>> but it still caused a divide by zero. >>> >>> This incident is the reasons why GPS receivers in some critical >>> applications are not allowed to have NV storage for "operational >>> purposes" and get the almanac downloaded from the attached systems >>> at startup. >>> >> With this new language, they would be required to be Level 1 compliant, >> at which it would always be a way for the user to reset corrupt data in >> the field. We never even discussed the possibility of prohibiting the >> NV, rather we focused on the ability to recover in the field. NV has >> it's upsides to boot quickly etc. but as any cache, it needs to be >> clearable. >> >> In a similar sense, we also had a good discussion about being able to >> upgrade the receiver. Several of us was driving hard to ensure that >> receivers can be upgradeable in the field, so that bugs can be removed >> continuously throughout the operational lifetime. In fact, I pointed out >> that the operational lifetime should be limited by how long you can >> maintain the receiver updated. The whole life cycle aspect is important >> in that as you loose support on receivers, they should go out of service >> for critical things. You should also make sure there is contracts on how >> long they will be maintained. >> >> Cheers, >> Magnus >> >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> T
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them had *major* concerns about field upgrades. Their take was that supporting them had always turned into a disaster. No matter how clear the instructions, a significant number of systems went down / stayed down while sub assemblies were being upgraded ….. Pretty much the universal approach: Return the device to the factory and do any needed upgrades there. Test it / verify it works and send it back. Having sat through several of those exercises, I do not remember a single device that “bricked” when done that way. Bob > On Dec 21, 2020, at 9:56 AM, Magnus Danielson wrote: > > Hi, > > On 2020-12-21 09:02, Poul-Henning Kamp wrote: >> >> Bob kb8tq writes: >> >>> I have seen cases of “goes away until power cycled”. I have not seen any >>> cases of >>> “goes away forever” other than the obvious ( = feed it an insane almanac >>> that prevents >>> if from ever locking up ). Even with that said, I have not seen an example >>> ot that sort of >>> thing living through a hard reset … ( which isn’t quite the same thing as a >>> power cycle ). >> I have: An corrupt alamanac in NV storage contained something which >> made a particular GPS receiver divide by zero, shit its pants and >> wedge during startup. >> >> The post mortem report said that the alamanac passed the "technical >> consistency checks", by which I suppose they mean the Hamming code, >> but it still caused a divide by zero. >> >> This incident is the reasons why GPS receivers in some critical >> applications are not allowed to have NV storage for "operational >> purposes" and get the almanac downloaded from the attached systems >> at startup. >> > With this new language, they would be required to be Level 1 compliant, > at which it would always be a way for the user to reset corrupt data in > the field. We never even discussed the possibility of prohibiting the > NV, rather we focused on the ability to recover in the field. NV has > it's upsides to boot quickly etc. but as any cache, it needs to be > clearable. > > In a similar sense, we also had a good discussion about being able to > upgrade the receiver. Several of us was driving hard to ensure that > receivers can be upgradeable in the field, so that bugs can be removed > continuously throughout the operational lifetime. In fact, I pointed out > that the operational lifetime should be limited by how long you can > maintain the receiver updated. The whole life cycle aspect is important > in that as you loose support on receivers, they should go out of service > for critical things. You should also make sure there is contracts on how > long they will be maintained. > > Cheers, > Magnus > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi, On 2020-12-21 09:02, Poul-Henning Kamp wrote: > > Bob kb8tq writes: > >> I have seen cases of “goes away until power cycled”. I have not seen any >> cases of >> “goes away forever” other than the obvious ( = feed it an insane almanac >> that prevents >> if from ever locking up ). Even with that said, I have not seen an example >> ot that sort of >> thing living through a hard reset … ( which isn’t quite the same thing as a >> power cycle ). > I have: An corrupt alamanac in NV storage contained something which > made a particular GPS receiver divide by zero, shit its pants and > wedge during startup. > > The post mortem report said that the alamanac passed the "technical > consistency checks", by which I suppose they mean the Hamming code, > but it still caused a divide by zero. > > This incident is the reasons why GPS receivers in some critical > applications are not allowed to have NV storage for "operational > purposes" and get the almanac downloaded from the attached systems > at startup. > With this new language, they would be required to be Level 1 compliant, at which it would always be a way for the user to reset corrupt data in the field. We never even discussed the possibility of prohibiting the NV, rather we focused on the ability to recover in the field. NV has it's upsides to boot quickly etc. but as any cache, it needs to be clearable. In a similar sense, we also had a good discussion about being able to upgrade the receiver. Several of us was driving hard to ensure that receivers can be upgradeable in the field, so that bugs can be removed continuously throughout the operational lifetime. In fact, I pointed out that the operational lifetime should be limited by how long you can maintain the receiver updated. The whole life cycle aspect is important in that as you loose support on receivers, they should go out of service for critical things. You should also make sure there is contracts on how long they will be maintained. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Bob kb8tq writes: > I have seen cases of “goes away until power cycled”. I have not seen any > cases of > “goes away forever” other than the obvious ( = feed it an insane almanac > that prevents > if from ever locking up ). Even with that said, I have not seen an example ot > that sort of > thing living through a hard reset … ( which isn’t quite the same thing as a > power cycle ). I have: An corrupt alamanac in NV storage contained something which made a particular GPS receiver divide by zero, shit its pants and wedge during startup. The post mortem report said that the alamanac passed the "technical consistency checks", by which I suppose they mean the Hamming code, but it still caused a divide by zero. This incident is the reasons why GPS receivers in some critical applications are not allowed to have NV storage for "operational purposes" and get the almanac downloaded from the attached systems at startup. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
martin.fl...@compdecon.org said: > Question: is is there a citable example / test case that a GPS can > a) be rendered inoperable (bricked) by an external signal? > b) not recoverable upon power cycling or other end-user accessible process? Not citable, but I have memories of a Garmin GPS-18 going useless and power cycling or anything else I could think of didn't fix it. It did recover after sitting around for a month or 3. I assume it has a supercap rather than a battery. I think I was sending it stuff on the serial/usb port rather than it was attacked by nasty RF signals. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi I have seen cases of “goes away until power cycled”. I have not seen any cases of “goes away forever” other than the obvious ( = feed it an insane almanac that prevents if from ever locking up ). Even with that said, I have not seen an example ot that sort of thing living through a hard reset … ( which isn’t quite the same thing as a power cycle ). Bob > On Dec 20, 2020, at 5:59 PM, Martin Flynn wrote: > > Read the document, send it up the food chain for an HVA. > > Question: is is there a citable example / test case that a GPS can > > a) be rendered inoperable (bricked) by an external signal? > > b) not recoverable upon power cycling or other end-user accessible process? > > Martin > >>> On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: >>> >>> Fellow time-nuts, >>> >>> DHS just published the work on Resilient PNT Conformance Framework, that >>> has been in the works since last year. This is intended to be the >>> framework for which multiple sectors align their standards, and a wide >>> range of interest was involved. >>> >>> Hope it can be interesting reading for you. >>> >>> https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework >>> >>> Cheers, >>> Magnus >>> >>> there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Read the document, send it up the food chain for an HVA. Question: is is there a citable example / test case that a GPS can a) be rendered inoperable (bricked) by an external signal? b) not recoverable upon power cycling or other end-user accessible process? Martin On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: Fellow time-nuts, DHS just published the work on Resilient PNT Conformance Framework, that has been in the works since last year. This is intended to be the framework for which multiple sectors align their standards, and a wide range of interest was involved. Hope it can be interesting reading for you. https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework Cheers, Magnus there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi > On Dec 19, 2020, at 8:34 AM, Magnus Danielson wrote: > > Hi Bob, > > On 2020-12-19 00:15, Bob kb8tq wrote: >> Hi >> >> You can always cycle the power … :) > Comes to no relief for some cases, as they store state that keeps them > "killed". If it was as easy of cycle the power, it would not have been > an issue we discussed. >> === >> >> There also are the basic issues of 50 db gain antennas being attached to >> 20 db compatible modules. RF rich environments (even without Lightspeed …) >> will always be a challenge. Site design *is* part of this “mess”. > For sure. At the same time, we find sites which has numerous GPSes, each > installed in a separate install campaign by different vendors/companies > and "good enough" for that contract which didn't go into detail, so > there is that too. That is for sure part of the problem the cross-hair > is on. >> === >> >> At least from what I saw, *most* modules did a pretty good job of handling >> the >> stuff they saw. You could always jam them if you had enough power. Most of >> them recovered from that and went back to running correctly. >> >> Indeed, a device that provided timing on a per band / per system basis would >> probably have taken care of all the issues I saw. Back in the day, those >> devices >> …. not what you got in your low cost module …. > > It's not necessarily of doing per band or per system receivers increase > your PNT capability. It could in fact reduce it as you can not use > remaining signals and combine them. I made this very point that it would > be unwise to limit in such ways. That was also the result of an > IT-security analysis gone wrong, without considering some basic facts > and low-hanging fruit in making that more robust. If the “per system / per band” timing information is all supplied up to the smarts in the unit, you would have 3 bands x 4 systems = 12 somewhat independent sources of timing to evaluate as part of your decision making process. Nothing is lost unless the decision making process rejects it. Bob > > Cheers, > Magnus > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Bob, On 2020-12-19 00:15, Bob kb8tq wrote: > Hi > > You can always cycle the power … :) Comes to no relief for some cases, as they store state that keeps them "killed". If it was as easy of cycle the power, it would not have been an issue we discussed. > === > > There also are the basic issues of 50 db gain antennas being attached to > 20 db compatible modules. RF rich environments (even without Lightspeed …) > will always be a challenge. Site design *is* part of this “mess”. For sure. At the same time, we find sites which has numerous GPSes, each installed in a separate install campaign by different vendors/companies and "good enough" for that contract which didn't go into detail, so there is that too. That is for sure part of the problem the cross-hair is on. > === > > At least from what I saw, *most* modules did a pretty good job of handling > the > stuff they saw. You could always jam them if you had enough power. Most of > them recovered from that and went back to running correctly. > > Indeed, a device that provided timing on a per band / per system basis would > probably have taken care of all the issues I saw. Back in the day, those > devices > …. not what you got in your low cost module …. It's not necessarily of doing per band or per system receivers increase your PNT capability. It could in fact reduce it as you can not use remaining signals and combine them. I made this very point that it would be unwise to limit in such ways. That was also the result of an IT-security analysis gone wrong, without considering some basic facts and low-hanging fruit in making that more robust. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi You can always cycle the power … :) === There also are the basic issues of 50 db gain antennas being attached to 20 db compatible modules. RF rich environments (even without Lightspeed …) will always be a challenge. Site design *is* part of this “mess”. === At least from what I saw, *most* modules did a pretty good job of handling the stuff they saw. You could always jam them if you had enough power. Most of them recovered from that and went back to running correctly. Indeed, a device that provided timing on a per band / per system basis would probably have taken care of all the issues I saw. Back in the day, those devices …. not what you got in your low cost module …. Bob > On Dec 18, 2020, at 10:44 AM, Magnus Danielson wrote: > > Hi, > > Yeah, so that is why from bitter experience, that needs to be > recoverable by users in the field. To put it mildly, a pilot flying a > plane will for sure like to be able to restart a malfunctioning device > for sure. Sure, it can take a few minutes, but being able to recover to > a known state with a known command (similar enough to the three-finger > salute of Ctrl-Alt-Del) is worth plenty. Loosing the capability to > navigate for the rest of the flight and in fact ground the plane until > unit can be replaced is something they want to avoid for sure. > > I think we all are happy that then do not think it's a good idea to take > an instrument out, attach JTAG and reprogram it with a flimsy Windows > laptop mid-flight. Right? Right. > > Cheers, > Magnus > > > On 2020-12-17 23:55, Bob kb8tq wrote: >> Hi >> >> Gee, GPS modules that go nuts and stay nuts after getting hit with this or >> that. >> I haven’t seen any of that since I retired …. :) >> >> Bob >> >>> On Dec 17, 2020, at 5:30 PM, Magnus Danielson wrote: >>> >>> Hi Bob, >>> >>> Yes, there is that too. NIST insisted to have me involved, so I got >>> involved. >>> >>> This is pretty high level, because it was needed, but many low-level >>> details was discussed and then we backed out with that common ground. >>> Some of the IT-security approaches does not really work on the >>> RF-interface. It's not that it can't be hacked, but it works so >>> differently and with much lower bit-rate... and one-way, that the >>> security analysis becomes quite different about how attacks can be done. >>> After that we concluded it's good to mention, but this is not relevant >>> for all interfaces. :) >>> >>> There is many ways to achieve the different levels, but we wanted to >>> make a number of key rules to sort things out, they form a form of >>> minimum set of requirements. Normal receivers achieve level 0. >>> >>> Some receivers "hang" after being upset by some input. "hang" to the >>> level it needs vendor intervention. So one learning is that the user >>> must be able to force the receiver into a "known state". >>> >>> Cheers, >>> Magnus >>> >>> On 2020-12-17 19:50, Bob kb8tq wrote: Hi Pretty suspicious looking list of contributors. Very much so about half way down the list :) …. congratulations !!! ( I guess …) Bob > On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: > > Fellow time-nuts, > > DHS just published the work on Resilient PNT Conformance Framework, that > has been in the works since last year. This is intended to be the > framework for which multiple sectors align their standards, and a wide > range of interest was involved. > > Hope it can be interesting reading for you. > > https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework > > Cheers, > Magnus > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. >>> ___ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@li
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi, Yeah, so that is why from bitter experience, that needs to be recoverable by users in the field. To put it mildly, a pilot flying a plane will for sure like to be able to restart a malfunctioning device for sure. Sure, it can take a few minutes, but being able to recover to a known state with a known command (similar enough to the three-finger salute of Ctrl-Alt-Del) is worth plenty. Loosing the capability to navigate for the rest of the flight and in fact ground the plane until unit can be replaced is something they want to avoid for sure. I think we all are happy that then do not think it's a good idea to take an instrument out, attach JTAG and reprogram it with a flimsy Windows laptop mid-flight. Right? Right. Cheers, Magnus On 2020-12-17 23:55, Bob kb8tq wrote: > Hi > > Gee, GPS modules that go nuts and stay nuts after getting hit with this or > that. > I haven’t seen any of that since I retired …. :) > > Bob > >> On Dec 17, 2020, at 5:30 PM, Magnus Danielson wrote: >> >> Hi Bob, >> >> Yes, there is that too. NIST insisted to have me involved, so I got >> involved. >> >> This is pretty high level, because it was needed, but many low-level >> details was discussed and then we backed out with that common ground. >> Some of the IT-security approaches does not really work on the >> RF-interface. It's not that it can't be hacked, but it works so >> differently and with much lower bit-rate... and one-way, that the >> security analysis becomes quite different about how attacks can be done. >> After that we concluded it's good to mention, but this is not relevant >> for all interfaces. :) >> >> There is many ways to achieve the different levels, but we wanted to >> make a number of key rules to sort things out, they form a form of >> minimum set of requirements. Normal receivers achieve level 0. >> >> Some receivers "hang" after being upset by some input. "hang" to the >> level it needs vendor intervention. So one learning is that the user >> must be able to force the receiver into a "known state". >> >> Cheers, >> Magnus >> >> On 2020-12-17 19:50, Bob kb8tq wrote: >>> Hi >>> >>> Pretty suspicious looking list of contributors. Very much so about half way >>> down the list :) …. congratulations !!! ( I guess …) >>> >>> Bob >>> On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: Fellow time-nuts, DHS just published the work on Resilient PNT Conformance Framework, that has been in the works since last year. This is intended to be the framework for which multiple sectors align their standards, and a wide range of interest was involved. Hope it can be interesting reading for you. https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. >>> ___ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Gee, GPS modules that go nuts and stay nuts after getting hit with this or that. I haven’t seen any of that since I retired …. :) Bob > On Dec 17, 2020, at 5:30 PM, Magnus Danielson wrote: > > Hi Bob, > > Yes, there is that too. NIST insisted to have me involved, so I got > involved. > > This is pretty high level, because it was needed, but many low-level > details was discussed and then we backed out with that common ground. > Some of the IT-security approaches does not really work on the > RF-interface. It's not that it can't be hacked, but it works so > differently and with much lower bit-rate... and one-way, that the > security analysis becomes quite different about how attacks can be done. > After that we concluded it's good to mention, but this is not relevant > for all interfaces. :) > > There is many ways to achieve the different levels, but we wanted to > make a number of key rules to sort things out, they form a form of > minimum set of requirements. Normal receivers achieve level 0. > > Some receivers "hang" after being upset by some input. "hang" to the > level it needs vendor intervention. So one learning is that the user > must be able to force the receiver into a "known state". > > Cheers, > Magnus > > On 2020-12-17 19:50, Bob kb8tq wrote: >> Hi >> >> Pretty suspicious looking list of contributors. Very much so about half way >> down the list :) …. congratulations !!! ( I guess …) >> >> Bob >> >>> On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: >>> >>> Fellow time-nuts, >>> >>> DHS just published the work on Resilient PNT Conformance Framework, that >>> has been in the works since last year. This is intended to be the >>> framework for which multiple sectors align their standards, and a wide >>> range of interest was involved. >>> >>> Hope it can be interesting reading for you. >>> >>> https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework >>> >>> Cheers, >>> Magnus >>> >>> >>> ___ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Bob, Yes, there is that too. NIST insisted to have me involved, so I got involved. This is pretty high level, because it was needed, but many low-level details was discussed and then we backed out with that common ground. Some of the IT-security approaches does not really work on the RF-interface. It's not that it can't be hacked, but it works so differently and with much lower bit-rate... and one-way, that the security analysis becomes quite different about how attacks can be done. After that we concluded it's good to mention, but this is not relevant for all interfaces. :) There is many ways to achieve the different levels, but we wanted to make a number of key rules to sort things out, they form a form of minimum set of requirements. Normal receivers achieve level 0. Some receivers "hang" after being upset by some input. "hang" to the level it needs vendor intervention. So one learning is that the user must be able to force the receiver into a "known state". Cheers, Magnus On 2020-12-17 19:50, Bob kb8tq wrote: > Hi > > Pretty suspicious looking list of contributors. Very much so about half way > down the list :) …. congratulations !!! ( I guess …) > > Bob > >> On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: >> >> Fellow time-nuts, >> >> DHS just published the work on Resilient PNT Conformance Framework, that >> has been in the works since last year. This is intended to be the >> framework for which multiple sectors align their standards, and a wide >> range of interest was involved. >> >> Hope it can be interesting reading for you. >> >> https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework >> >> Cheers, >> Magnus >> >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Pretty suspicious looking list of contributors. Very much so about half way down the list :) …. congratulations !!! ( I guess …) Bob > On Dec 17, 2020, at 12:52 PM, Magnus Danielson wrote: > > Fellow time-nuts, > > DHS just published the work on Resilient PNT Conformance Framework, that > has been in the works since last year. This is intended to be the > framework for which multiple sectors align their standards, and a wide > range of interest was involved. > > Hope it can be interesting reading for you. > > https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework > > Cheers, > Magnus > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] DHS Resilient PNT Conformance Framework
Fellow time-nuts, DHS just published the work on Resilient PNT Conformance Framework, that has been in the works since last year. This is intended to be the framework for which multiple sectors align their standards, and a wide range of interest was involved. Hope it can be interesting reading for you. https://www.dhs.gov/publication/st-resilient-pnt-conformance-framework Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
