Metadata exchanged by CM during/after provisioning

[RadLys]

Hello everyone,
As specified in the subject, I would like to know exactly what data, that may be uesd to identify my modem, is sent to CMTS when it is registering or in operation. I am perfectly aware of BPI+ and it's security scheme but I suspect there may be other ways for ISPs to do that (like software version mabe?), chaiend to the DOCSIS specs. I don't mind anything above Layer 2 OSI (aka Docsis) like SNMP or TR-069, because I can drop them using a firewall.

Off-topic question: does CVC value apply only to firmware or config files as well? It is checked by the modem, am I correct?

EDIT:
Well, sorry, I meant I don't care about anything above Layer 2 when the CM is in operation, and nothing except the WAN packets are sent to CMTS. When it is registering, I care about everything. BTW is there anything sent to ISPs inner-network AFTER being accepted?

[occalifornia]

it will depend on the isp but they can pull pretty much anything.. mac, serial, certs, config, cvc values for certs / bpi / config, sw version, etc. you arent anonymous.

[RadLys]

Ok, thanks for info, although my goal isn't make my modem invisible or anonymous to ISP. It's the opposite, actually. Unfortunatelly, I don't live in US or Germany, where ISPs allow to connect your own modem. There are only 3 supported, which in my opinion is a big mistake, due to enormous security flaws, which are present in every modem, because they use identical firmware. Example: Alcatel OLTs' flashes were fully erased (along with bootloader), resulting in major internet inaccesibility, because that was one of TWO supported models for comms in GPoN. I can't change the MAC, CVC, nor serial without having the right private key, but I DO have it. So I think the proper question to ask is: can I force the forceWare (Hm... Interesting expression) to send the DOCSIS data, which I have access to (phisycally, I can dump the ISP moemd's flash)? As I understand, the ISP can check this info only when authenticating (DHCP and TFTP req) and later (after provisioning) using SNMP over their internal network, which I can simply block. Is this correct?

[coldfusion]

Lots. Read the following chapters.

https://www.google.com/url?sa=t&source=w...La2__myvs0

[RadLys]

I've read the doc @coldfusion has provided and this is what I understand:
-CMTS can identify modem by anything associated with BPI+ (MAC and Vendor)
-CMTS can identify modem by sysDescr string returned by modem in REG_REQ
-CMTS can make DOCSIS queries ONLY about SNR (can't identify using this)
-CMTS can make queries about devices connected to modem(!) and list their MACs  <- How is this possible, if all devices are (should be) behind the modem's NAT (when not operating as briged interface)?
-NOTHING else (according to this doc) can be used.

(-)When sending config file to modem EAE is used to encrpyt transmission, shared secret and MIC response to authenticate source of the config and if it was altered. Please, help me understand how it is supposed to protect anything if we can recive the file, calulate hash, discard it, use another file and when MIC is supposed to be sent just inject calculated hash. It works, when we are MITMing the file and altering it or using replay attack but what if we have full control over the modem (like forceWare has)? Am I missing something here?

PS: Please confirm if my interpetation of the document is correct.

EDIT:
I asked the question about config just out of interest not because I am going to do anything with it.

EDIT2:
Also, the CMTS knows about the configs (name and contents) only because it provides them to CMs. It can't do any queries to CMs about it, except MIC (again, according to this doc). Is this also correct?

[0xff]

I've read the doc @coldfusion has provided and this is what I understand:
-CMTS can identify modem by anything associated with BPI+ (MAC and Vendor)
-CMTS can identify modem by sysDescr string returned by modem in REG_REQ
-CMTS can make DOCSIS queries ONLY about SNR (can't identify using this)
-CMTS can make queries about devices connected to modem(!) and list their MACs  <- How is this possible, if all devices are (should be) behind the modem's NAT (when not operating as briged interface)?
-NOTHING else (according to this doc) can be used.

(-)When sending config file to modem EAE is used to encrpyt transmission, shared secret and MIC response to authenticate source of the config and if it was altered. Please, help me understand how it is supposed to protect anything if we can recive the file, calulate hash, discard it, use another file and when MIC is supposed to be sent just inject calculated hash. It works, when we are MITMing the file and altering it or using replay attack but what if we have full control over the modem (like forceWare has)? Am I missing something here?

PS: Please confirm if my interpetation of the document is correct.

EDIT:
I asked the question about config just out of interest not because I am going to do anything with it.

EDIT2:
Also, the CMTS knows about the configs (name and contents) only because it provides them to CMs. It can't do any queries to CMs about it, except MIC (again, according to this doc). Is this also correct?

I'm not a specialist in the subject, I'm not an engineer in networks, but I've done more than 16 years of testing, and from what I've seen these years, answering some of what I remember your questions I can say the following:

If you can send the modified information that you think you have, you can be an identical clone, however the dhcp will recognize the clone because you will be the last one to connect, in addition you will connect from another node, then the dhcp will verify that the hfc mac is associated with an ip different from the one you are. This generates records in the cmts identifying the clones, although they are provisioned, the record remains in the IOS. Another point that you should think is that the high modem is connected before you, even if you have an exact information of the original. If there are 2 modems with the same mac in a compatible dhcp, always but always the last one that connects requests provisioning will be clone, then when restarting the first one, the snmp port will change, while the second does not, so it identifies you. In MTAs, the provisioning process is more complex than a CM, here, in addition to the above, there is a complex snmp process that I do not remember now, when I remember, I mention it.

There you see 2 different detection processes, one is by registration when you check from where you are connecting and another by port change snmp, since you will always connect after the high modem.

You overlook something that is key, and it has to do with the modem when it sends the first message, not directly to the cmts, to the dhcp server. This one makes a query to the cmts database and that would be it. The config file is only as a measure of QoS (then here it is the same cvc, cmmic and all those crap).

If you look, it depends a lot on each isp and its security. For example there is isp that use a protocol that regulates the cpe, like tr-069, then I think they are very aware of the traffic rather than the provisioning of the devices, they can even have bpi deactivated, then their logic does not happen because the modem, but the cpe traffic.

[RadLys]

Thank you for very valuable anwsers. So, there is still A LOT to check, because of specifics of every ISP using cable. Well, I am going to modify forceWare a bit, so that i'll do mirroring of all packets to eth and then check the exact procedure of modem provisioning (pre and post docsis authentication). Since I have the private key, I can decrypt captured traffic later. In addition to that, I'm going to read full specs of D3 to make as few mistakes as posiible. Anyway, thank you all again for attention and your time.

@0xff: I'm not going to have both modems online at the same time, so the 1. case you described is not going to be a problem, I think. But thanks for pointing out what to take into consideration, and thanks @coldfusion for the doc.

----This thread can be considered as closed.