cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3577
Views
4
Helpful
5
Replies

MacSec implementation

Maro.Cisco
Level 1
Level 1

                   Guyz i would like to ask if Macsec would offer encryption over all types of data traffic including RTP ??? so if i would sniff packets after implementation of Macsec all would be encrypted ????

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Maro,

MACsec encrypts the entire frame payload, regardless of its type. It does not matter if the frame carries an IP+UDP+RTP+G.711 voice packet or an STP BPDU. The payload portion of the frame will always be encrypted.

Have a look at the following capture of MACsec-protected frames - you can see there is a bunch of frames containing PVST+ BPDUs, CDP/VTP/DTP messages, there are even EIGRP packets there (I am curious if you are able to identify which ones they are ) but still, the contents of the frame are encrypted.

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=macsec_cisco_trunk.pcap

Indeed, if you sniffed frames on a link between two switches implementing MACsec, the frames would be encrypted just like you see here.

Best regards,

Peter

View solution in original post

5 Replies 5

Peter Paluch
Cisco Employee
Cisco Employee

Hi Maro,

MACsec encrypts the entire frame payload, regardless of its type. It does not matter if the frame carries an IP+UDP+RTP+G.711 voice packet or an STP BPDU. The payload portion of the frame will always be encrypted.

Have a look at the following capture of MACsec-protected frames - you can see there is a bunch of frames containing PVST+ BPDUs, CDP/VTP/DTP messages, there are even EIGRP packets there (I am curious if you are able to identify which ones they are ) but still, the contents of the frame are encrypted.

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=macsec_cisco_trunk.pcap

Indeed, if you sniffed frames on a link between two switches implementing MACsec, the frames would be encrypted just like you see here.

Best regards,

Peter

look at 5th packet in the pcap whose etype is 0x88e5 (MACsec).

I see its FCS is missing, why?

I am not sure if this captured packet is the same as on the wire.

Do you know a way to verify the captured packet is same as on the wire?

Thanks,

Haidi

Haidi,

Wireshark usually does not display the FCS because the network card commonly does not supply this field to upper drivers. In fact, if the FCS did not match the frame contents, the network card would drop the frame immediately, without even handing it off to its drivers. You would not even see frames with corrupt checksum in Wireshark unless the card can be forced into accepting even corrupt frames and hand them over to the upper driver including their FCS.

Whether the captured frame is the same as the one on the wire is most probably a matter of your trust into the device that provides the frame capture and diverting services. This really depends on how you actually access the wire to get your hands on the frame. You have to take into account that the MACsec itself provides for data integrity and authenticity just like IPsec does, but whether the frame has been altered is detectable only by the MACsec endpoints using their security association parameters, not by a third party. I have not yet seen a request to provide a proof of authenticity for a captured frame, though.

Best regards,

Peter

1. wireshark display FCS

wireshark does display FCS for ping traffic captured via spirent

2. both spirent and ixia have some issues with MACsec traffic.

if you capture an MACsec frame on wire with either spirent or ixia and save to a pcap file and

   replay the pcap file and capture the replayed frame again, you will notice the captured frame

   second time is different than first time, for example, different data length.

3. one way to prove the captured MACsec frame is same as the wire.

   (a) disable MACsec replay protection.

   (b) captured the frame and replay it back onto wire.

   if we see no CRC error on the receiving side that means the captured frame is exactly same as on the wire.

   if we see CRC error on the receiving side that means the captured frame is different than the one on the wire.

Haidi,

1. wireshark display FCS

wireshark does display FCS for ping traffic captured via spirent

Yes, that may be true but Spirent is a specialized device supposed to tell you more than an ordinary network card.

2. both spirent and ixia have some issues with MACsec traffic.

if you capture an MACsec frame on wire with either spirent or ixia and save to a pcap file and

   replay the pcap file and capture the replayed frame again, you will notice the captured frame

   second time is different than first time, for example, different data length.

I do not have much experience with Wireshark's ability to replay the traffic. However, if the replaying is performed on a different device than the one used to create the capture in the first place, the replay may not be identical - exactly because of the FCS field that may not be externally supplied to a common network card. You must understand that some frame processing operations are done in silicon and not all network cards or controllers allow you to have a full control over each and every step in frame processing.

3. one way to prove the captured MACsec frame is same as the wire.

   (a) disable MACsec replay protection.

   (b) captured the frame and replay it back onto wire.

   if we see no CRC error on the receiving side that means the captured frame is exactly same as on the wire.

   if we see CRC error on the receiving side that means the captured frame is different than the one on the wire.

This is correct.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card