Validator discussion items

From DNSSEC-Tools Wiki

Contents 1 Validator discussion notes: 1/3/2007 2 Discussion notes for Thr 1/4/2007 2.1 Locking and pthreads 2.2 Application behavior on validation failure 3 Tabled until 1/11 3.1 Use of LD_PRELOAD 3.2 Error precedence

Validator discussion notes: 1/3/2007

1. Resolver algorithm, robustness
   • we only look at other NSs if the ones we ask don't respond - we don't ask the other NSs as long as we see some response from the server, even if this was an error condition. Assumption is that server is authoritative, so we must believe it.
   • hardaker: consider the case where one name server is broken code and the rest are good code
   • Next step: Take discussion to namedroppers, add configuration option that allows these checks to be conditionally performed
2. detection of flooding attacks
   • Summary: We are currently not detecting flood attacks; i.e. we don't wait for the correct response to appear Not a simple case to implement, because validation requires a chain of responses -- we won't know which answer is being replayed. We then have a combinatorial problem of how do we select from the responses the correct ones for the chain of trust.
   • Next Step: Sam to give examples of where breakage appears
   • rstory: this would require cooperation from the resolver... with the current tight coupling between libsres and libval, something could be done... but after a decoupling, probably not..
3. definition of trusted
   • val_istrusted()
     • trust point
     • provably unsecure
     • validation ignored
     • trusted zone
     • local answer
   • val_isvalidated()
     • trust point is reached
   • rstory: So, what do we call it when cryptography was used to determine that the zone administrator configured an insecure delegation (or nsec3 optout)?
   • Next Step: implementation of policy hook that allows you to customize is_trusted() (and is_validated?)
     • suresh: do we also need a function similar to val_istrusted() and val_isvalidated() to capture this conditon?

Discussion notes for Thr 1/4/2007

Locking and pthreads

1. • Should we create two versions, one with locking and one without?
     • Pros
       • one less pre-req (pthreads) for environments that don't need it
     • Cons
       • more complex build process

Consensus points:

• multithread support is needed
  • but should be optional
• context caching needed between threads?
  • needed for simplicity api
• should we enable configure to support mt and non-mt both?
  • no. but naming the library libval-threads when locking enabled
• should we distribute RPMs (etc) to build and install threads and non threads?
  • yes, but not high priority

Consensus on steps:

1. create configure patches to enable/disable threads
   • default to enable if possible
2. clean up of context caches
   • multiple threads can not currently share a context, but should be able to
3. rename library to include -threads
4. eventually distribute both types

Application behavior on validation failure

Summary from list: marz: I am confused by our error philosophy.... it seems return code/h_error/error/val_status can be all sorts of hings...sometimes related...sometimes one or more are valid...I wonder if there is a simpler approach

• Wes: two different decision points:
  • did the function fail? (memory, some other issue)
  • did the protocol fail? (host not found, sig failed)
• Marz: don't like mapping of error codes onto other errno numbers, etc
• Suresh will think on it
  • with input from Joe

Tabled until 1/11

Use of LD_PRELOAD

1. • related to previous item; if we silently replace exsiting functions, how do we map the plethora (thank you Three amigos) of new error codes to original functions more limited set?

Error precedence

1. • Summary : Brought up by sam during 01/03 meeting. Problem description is still unclear.