I’m a big fan of Let’s Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let’s Encrypt doesn’t have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let’s Encrypt software client and the Let’s Encrypt web service.
Since the protocols that Let’s Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:
Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
Elevated privilege. At least one of the clients I saw required root permission. That’s a non starter.
I got an interesting email from Ying Lu who had read my posts on LSM:
I am curious about the Ethernet DA and codepoint used for multicast MPLS. Previously, I understand that:
– Ethernet DA is unicast MAC of nexthop of each replication leg.
– codepoint is 0x8847
However, looking at RFC5332, I am not so sure…
“Ethernet is an example of a multipoint-to-multipoint data link. Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.
Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned.
Ethertype 0x8848, formerly known as the “MPLS multicast codepoint”, is to be used only when an MPLS packet whose top label is upstream assigned is carried in a multicast ethernet frame.
Interesting question. What is the ethernet destination address (DA) and the value of the ethernet type field (codepoint) when the MPLS packet is being sent on an LSM LSP?
Getting back into the lab, I started a ping from CE1 to a group that CE3 had joined. I then ran a sniff on the segment between P and PE3.
Examining the capture shows a unicast address in the ethernet DA field and an ethernet type of 0x8847.
I started wondering if I could trick the P router into using a multicast ethernet frame so I spun up a fourth PE and attached it to the same segment that P and PE3 are on and had it join the same multicast group.
The P router continued to send unicast ethernet frames with a type of 0x8847 and just started putting two frames on the wire, one for PE3 and one for PE4. It did not, as I had hoped, put a multicast ethernet frame on the wire that would be picked up by both PEs.
So it appears that IOS — and I tested this with a version of IOS 15.4T — sends unicast ethernet frames when sending LSM packets and therefore also uses an ethernet type code of 0x8847.
Presented by: David Prall, Communications Architect, Cisco
For reference, David is the “father of IWAN”.
This session was not what I was expecting. I was expecting design and architecture, but it was all about features in IOS and IOS-XE (eg, FHRPs, talked about routing protocol timers, PfRv3, BFD). I guess I need to pay more attention to the session code (RST == routing; ARC == architecture).