Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 595
    • Issues 595
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 62
    • Merge requests 62
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • KeaKea
  • Issues
  • #2406
Closed
Open
Issue created May 12, 2022 by Peter Davies@peterdDeveloper

GSS-TSIG make GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG optional

MS DNS servers appear to employ a very strict replay protection algorithm in the GSS layer (using sequence numbers). From the observable behavior, it seems to require the sequence number monotonically increase one by one (without any missing or reordering sequence), and return "broken response" (but with RCODE being REFUSED) if it detects a violation of this requirement (see #2405 (closed)).
Further, once this happens any subsequent DDNS requests would result in REFUSED (in the form of broken response), probably because the request of the "next expected sequence number" was effectively dropped and never arrives.

This can happen not only because of the real missing or reordered requests, but also (apparently) because of prerequisite failures (in this case, it looks like the MS server doesn't even bother to check the TSIG RR, and returns the broken response). So it can happen quite easily in practice.

So, it simply doesn't make sense to enable the GSS level replay protection with a MS DNS server. If we disabled it by omitting GSS_C_REPLAY_FLAG from TKeyExchange::TKEY_EXCHANGE_FLAGS defined in tkey_exchange.cc, this problem didn't (seem to) happen.

I'd suggest making GSS_C_REPLAY_FLAG optional that can be enabled/disabled in config. Note that TSIG has its own generic (algorithm-independent) replay protection, so even if we disable the GSS-level replay protection, we'd still have some level of defense. And, in any case, this hook is simply unusable with a MS server as long as we include this flag.

see RT #20795

Edited Jun 30, 2022 by Tomek Mrugalski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking