Good news! You can have this already. Go run Linux.
On June 1, 2017 8:42:45 PM EDT, Tinker <tinkr@openmailbox.org> wrote:
>Ah - having an interface name naming scheme that, instead of just being
>
>a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical
>slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot:
>
>17 + address: 4 = "cdceur0s17a4", would do the job too.
>
>On 2017-06-02 00:24, Tinker wrote:
>> Hi,
>>
>> What I meant was, it's fairly easy for interface numbers (e.g. NIC A
>> as CDCE0 and NIC B as CDCE1) to become exchanged.
>>
>> With lots of unluck, there could be mechanical stress on USB ports so
>> that they would rearrange spontaneously so NIC B would become CDCE0
>> and NIC A would become CDCE1.
>>
>> Or more probable, an ignorant user would intentionally replug his
>> devices but the change of order of interfaces would be unintentional
>> to him, and then when he ifconfig/dhclient:s his interfaces, very bad
>> things could happen.
>>
>> This is not a big deal, but it does add one more thing to think
>about,
>> and in extreme corner cases it could be a security problem - God
>> forbid you'd have a public network on CDCE0 and a private network on
>> CDCE1 and then a little mistake causes everyone's medical records
>etc.
>> to be leaked on the Internet.
>>
>>
>> The same would apply to USB serial ports (UART:s) and probably some
>> other hardware -
>>
>> I was talking to someone who was worried that it (unintended device
>> ordering) could happen even to PCI devices though I guess that's
>> overkill.
>>
>> His solution is to enforce device names by using different hardware,
>> though that kind of illustrates the problem rather than resolve it,
>> doesn't it.
>>
>>
>> OpenBSD leaves IP configuration as manual work to the user so OpenBSD
>> itself won't mess it up for you, so this is not a per-se OpenBSD
>> problem.
>>
>> But maybe OpenBSD could help people do it right. Interface number
>> hard-binding to a particular device descriptor (MAC/USB serial etc.)
>> would solve it.
>>
>> Interface name aliasing would work too (hardbound to descriptor).
>>
>>
>> Anyhow I just wanted to bring up the potential problem.
>>
>> (Also Peter - this is not specifically a PF problem, however, how
>> would you use egress as part of the solution?)
>>
>> Thanks,
>> Tinker
>>
>> On 2017-05-30 07:04, Peter Hessler wrote:
>>> On 2017 May 29 (Mon) at 02:13:57 +0000 (+0000), Tinker wrote:
>>> :Hi misc@,
>>> :
>>> :For pluggable devices such as USB NIC:s, is there any way to make
>>> OpenBSD
>>> :bind a particular device based on its MAC or USB serial number or
>the
>>> like
>>> :variable, to a particular interface or device filename?
>>> :
>>> :E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external
>
>>> USB
>>> :harddrive with serial number Z as /dev/sd0 and the one with serial
>>> number A
>>> :as /dev/sd1 (and plugging in other devices would automatically).
>>> :
>>> :(For storage devices there's the DUID-based mounting already
>though,
>>> so I
>>> :guess those are a non-issue.)
>>> :
>>> :Some things in the OS are specified per interface/device name, e.g.
>
>>> PF rules
>>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1
>..",
>>> "match
>>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having
>the
>>> :interface numbers garbled on replug may be an unnecessary reason to
>
>>> reboot?
>>> :
>>> :Would be happy to learn any best practice here, thanks,
>>> :Tinker
>>> :
>>>
>>> match out on egress from 192.168.0.0/16 to any nat-to (egress)
>>> ^^^^^^ ^^^^^^^^
>>>
>>> the interface group "egress" is added to the interface a default
>route
>>> uses. Wrapping that with (), will ensure that interface is updated
>>> when
>>> the default routes uses a different interface.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
No comments:
Post a Comment