[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6ops-nat64-pb-statement-req: DNSSEC requirement

Thomas Narten escribió:

marcelo bagnulo braun <marcelo@it.uc3m.es> writes:


Thomas Narten escribió:

marcelo bagnulo braun <marcelo@it.uc3m.es> writes:
if the verification is performed before the synthesis of the RR and there is a trsut relationship betwen the receiver and the node that has performed the verification and synthesis, this should do it. 
Well, yes, but there are an awful lot of ifs in the above. Certainly
more than are appropriate for the original MUST requirement.
but what i was describing here is a solution the describe that this is possible and so it makes sense to keep the requirement 
there may be other solutions that also satisfy the requirement,


Sorry, but no. if you have a simple MUST as a requirement, you can't
have the solution involve a bunch of ifs that will not be true in
general, and/or that change the meaning of meeting the requirement.

DNSSEC is about e2e security. The recipient of the data (the DNS
querier), using DNSSEC, is able to verify that the data has not been
modified. This is no longer true in the solution outline you proposed
above.


How is that?
Suppose we have node H6 that is a v6 only node.
Suppose that node H6 wants to perform DNSSec validation
Suppose that it wants to initiate a communication with a node H4 that is v4 only Suppose that node H6 makes a AAAA RR query for H4 and gets nothing and then it makes a A RR query and gets an IPv4 address. Upon the recpetion of the A RR, it also obtains DNSec information to validate the A RR. Node H6 then performs the DNSsec validation and then translates the H4 address into an IPv6 address by prepending a /96 prefix. Node H6 then sends IPv6 packet towards H4 which are translated into IPv4 in a nat64 box soemwhere along the way
AFAIU, in this approach, DNSSec validation works e2e and we can state that this solution fulfills the proposed requirement to keep DNSSec working.
However, i don't think it is possible to make dnssec to work in the opposite direction, where the initiator is a v4 node. Hence my suggestion to separate the v4 intiiated communication requirements from the v6 intiiated communication requirement. (If what you are saying is that we cannot find a solution that would dnssec work for v4 initiated communications and that should be removed, i certianly agree)
In any case, many people expressed that a nat64 mechanism should not prevent dnssec from working (it is also true that these same people also expressed that for them having v4 intiiated communications was not a requirement) 
The requirement contained in the draft is an attempt to express that
I am all for rewriting it in a better way, do you have any suggestion?


Hence, the requirement needs to significantly expanded upon and/or
clarified. Otherwise, people will assume it means X, when others
assume it actually means Y.
right, again, my proposal is to split the reqs one for v4 initiated and another list for v6 initiated, do you think this would do it? 
other proposal for text?


In particular, if everything happens at the end node, we are in
business, right?  (i.e. the v6 end node asks for the A RR, perfomrs
the dnssec validation and then internally generates the v6 address)

Ahem. If the end node is doing this, why isn't it just doing dual
stack? After all, it (or rather the embedded translator) is sending
out IPv4...
cause the main scenario that we are targeting here is the case where the source node has no v4 address configured in its stack, so it cannot send v4 packets. 

What exactly is the difference between a node that has no IPv4 address
configured (so that it can not just use dual stack) and that same node
with an embedded translator attached to it that does send out IPv4
(after translation - and hence, has to have an IPv4 address
configured)?

mmm, this is not what i described
What i described is a v6 node that locally generates the v6 address that maps the v4 address locally, but still sends only v6 packets. 
The translation of packets is done on a different box


 From what I can see, in both cases the node has an IPv4
addresss and the directly attached network is IPv4 enabled. In that
case, dual-stack seems like the obvious thing to use. I certainly
wouldn't think a translater is needed here...
i think we are talking about different cases here. I hope my description of what i had in mind above makes things clearer
I am lately thinking that we need two different lists of requirements one for v4 initiated communications and another one for v6 initiated communications especially for dealing with dns requirements. In v4 initiated communications the state in the nat box has close relationship with the RR synthesis, while in v6 initiated communication they are completely decoupled, which makes possible to satisfy most of the dns requirements. 

If the requirements are different in the two directions, then yes, two
separate requirments are needed. You can't have a general requirement
(that implicitely implies a solution in both directions) when a
solution in one direction can't be made to work.


that is what i think, but i would like to see if people agree with me.
For me the requirement that cannot be meet in the 46 direction (and that can be meet in the 64 direction) are those related to DNS. 
In particular, DNSSec cannot work with 46 direction and

  R4: DNS semantics preservation

  Any modifications to DNS responses associated with translation MUST
  NOT violate standard DNS semantics.  This includes in particular that
  a DNS response (that has been modified by the translator mechanism)
  should not be invalid if it ends up in the wrong context, i.e.
  traversing a non expected part of the topology.


can't work neither cause the dns responses in the 46 cases are very context dependent cause the dns response contains the information associated to the nat46 state

regards, marcelo
PS: i am planning to send a mail describing the changes of the two req list in a moment


Thomas