Thank for clarification, Michael. I believe my confusion comes from the 
following paragraph:
"
   While subsequent connections to the same site (and subsequent packets
   in the same flow) will not be affected if the results are cached, the
   effects will be felt.  The ACL results can be cached for a period of
   time given by the TTL of the DNS results, but the lookup must be
   performed again in a number of hours to days.
"
I think keeping state to cache results is necessary for establishing subsequent 
connection the same site.
I am wondering how long the results can be cached, which factor will affect 
cache lifetime? Session state duration, TCP timeout, UDP time out?
Or DNS timeout/ TTL of DNS results.
In the below discussion, You seems to indicate session state duration is not 
affected by DNS timeout. But from what I read the above paragraph,
It seems that the cache lifetime is decided by TTL of DNS results, have nothing 
to do with session state duration, correct?
Cached results will be torn down after TTL of DNS results or Cached results 
will be updated with new IP address,
Therefore it needs another DNS lookup. 
Let me know if my understanding is correct.

-Qin
-----邮件原件-----
发件人: Michael Richardson [mailto:[email protected]] 
发送时间: 2023年11月1日 22:56
收件人: Qin Wu <[email protected]>
抄送: Eliot Lear <[email protected]>; Rob Wilton (rwilton) 
<[email protected]>; [email protected]; 
[email protected]
主题: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08


Qin Wu <[email protected]> wrote:
    > Hi Michale: If my interpretation is correct, the mapping between IP
    > address and Name is only valid for specific session or connection, when

I don't understand your comment.
The policy might say, "permit TCP port 1245 to example.com"
In order to enact this policy, the enforcement point needs a mapping from 
example.com to (e.g.,) 192.0.0.1 [%].  There are a number of ways of 
implementing the enforcement point, not all have to maintain state for the 
entire connection.  But even among those that do, the state is attached to the 
IP address, not the name.

So I don't understand how the mapping is only valid for a specific session.







[%] actually, example.com has an actual IPv4/IPv6 address which answers on
    port 80 and 443 :-).  And it's not a documentation IP.

    > the session or connection is torn down, The mapping is no longer valid
    > even though you cached the them, especially, TTL exceeds the
    > preconfigured period of time.  I am wondering whether session
    > expiration time is also cached together with the mapping as the state?

MUD does not say anything about how long the session could last.
For policy enforcement points that keep state on every session, whether or not 
that state is allowed to exceed the TTL on the name is an interesting
implementation question.   I would think carefully about whether I wanted my
enforcement point to keep so much state, and I don't think I'd kill sessions 
because the DNS name timed out.  Maybe, I'd have an upper limit on session 
state duration, but does violate the end to end principal.  Still, it happens 
all the time with NAT44.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to