Opened 23 months ago

Last modified 22 months ago

#5510 new enhancement

KEA DhcpV6 confirm & Cisco IPv6 Verify Source : fail

Reported by: Julzor Owned by:
Priority: medium Milestone: Kea1.x
Component: Unclassified Version: 1.2.0
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Hi,

I encountered a problem with KEA when using the IPv6 Verify Source protection on my switches (Cisco).

When a full DHCP transaction occurs, everything goes fine.

But sometimes, computers only send a "DHCP Confirm" (and NOT a Renew). In this case the protection doesn't work.

After some discussions with Cisco, it looks like KEA sends back the address (IAA) in the "Reply" to the "Renew" requests.
But in the "Reply" to a "Confirm" request, the IP Address is not included in the packet, and the switches need to glean this information for layer 2 securities.

Is there a way to change this behaviour and to make it works?

(Cisco told me that the server is supposed to include the IAA in the reply, even if the request is a "Confirm").

Thank you.

Subtickets

Change History (7)

comment:1 Changed 23 months ago by fdupont

This is not what the RFC 3315 says in its section 18.2.2 and BTW
the Confirm was designed to just deal with the onlink / offlink status
so there is no reason to include an IA_NA in the reply.

I recommend to go upper in the Cisco support.

PS: the DHC IETF WG has a mailing list but IMHO it is to Cisco to
discuss on it in the case they disagree about spec interpretation.

comment:2 Changed 23 months ago by fdupont

Note the RFC 7513 "Source Address Validation Improvement (SAVI) Solution for DHCP" describes how the provide a verify source protection by spoofing DHCP. In its text there is the way to handle Confirm/Reply? exchange with for instance:
(RFC 7513 6.4.2. Initial State: INIT_BIND (state after Confirm) 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received, paragraph 2 (the status code is "Success") B (there is no IA option) -- Page 24)

Otherwise, the DHCP Reply message is in response to a Confirm
message. The state of the binding entries with a matched TID
is changed to BOUND. Because [RFC3315] does not require the
lease time of addresses to be contained in the Reply message,
...

comment:3 Changed 22 months ago by tomek

Also note this behavior is not expected to change in the upcoming DHCPv6bis. See here: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10#section-18.3.3.

comment:4 Changed 22 months ago by tomek

Julzor, feel free to contact me privately if you want to talk about this. I can point you to specific people at Cisco that will confirm Kea behavior is correct. Sadly, you didn't specify any email when registering. You can reach me at tomek (at) isc (dot) org.

comment:5 Changed 22 months ago by Julzor

Thank you very much for all the replies.

I will continue to dialogue with Cisco on the issue.

I still don't know how to fix that (on either side).

Why would a computer send only a "Confirm", even after being unplugged for 4 or 5 minutes (which in this case is enough to be cleared from the switches binding table).

I hope i will find a way to make it work :-)

Feel free to give me any ressource (documentation, RFC, contacts, ...) that might help me.

comment:6 Changed 22 months ago by tomek

Just to summarize an offline discussion so far:

I can only speculate what's going on the Cisco switch, but it is possible that the switch has SAVI (RFC7513) implemented. According to RFC7513, Section 6.4.2.1, when the device gets a Reply for Confirm message, it should send Leasequery message to the server. Kea doesn't support Leasequery yet, so there is no meaningful answer being sent back.

This theory will hopefully be checked by Julzor. If there is no leasequery message being sent, it looks like a misconfiguration or a bug in the relay. If the leasequery message is sent, Kea will report an unknown message type being received, not understood and dropped.

If this is indeed a case, we can talk about a feature request for Kea to implement a leasequery mechanism.

comment:7 Changed 22 months ago by tomek

  • Milestone changed from Kea-proposed to Kea1.x

There are no obvious actionable things here in 1.4 timeframe. However, we'd like to keep an eye on this. As such moving to 1.x milestone.

Note: See TracTickets for help on using tickets.