Subject: (NAT) WG last call on "DNS-ALG" draft

From: [email-masked] (Pyda Srisuresh)
Date: Wed, 17 Feb 1999 07:08:49 -0800 (PST)

This is a NAT working group last call for comments on advancing the
following document into RFC.

	Title           : DNS extensions to Network Address Translators 
			  (DNS_ALG)
	Author(s)       : P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan
	Filename        : draft-ietf-nat-dns-alg-01.txt
	Pages           : 27
	Date            : 23-Oct-98
	Category 	: Informational

Please send substantive comments to the nat mailing list, and minor
editorial comments to the authors. This last call period will end two
weeks from today on March 3, 1999.

Cheers,
suresh & Matt
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Feb 1999 11:19:41 -0500

I have a lot of difficulty with the security considerations section.

   8. Security considerations.
  
      DNS packets must not be encrypted in order for DNS_ALG to be able 
      to perform payload modifications. 

DNS itself doesn't include provisions for encrypting payloads.  Are
you referring to IPSEC here?  If so, you should say so; if not, what
are you talking about?  

If you're talking about IPSEC, what about the use of AH or ESP with
the NULL encryption algorithm, which isn't strictly speaking
"encryption", but which will still prevent payloads modified in-flight
by the gateway from being accepted by the destination system.
	
      Alternately, if packets must be 
      encrypted in a routing realm, DNS_ALG will need to hold the 
      secret key to decrypt payload before forwarding packets to a  
      different realm. 

In the previous sentance you said that DNS packets must not be
encrypted; now you say they can be, if the application-layer gateway
has the key.  How exactly is the ALG supposed to get the key?

					- Bill
-

---

From: [email-masked] (Pyda Srisuresh)
Date: Sat, 20 Feb 1999 10:27:57 -0800 (PST)

> I have a lot of difficulty with the security considerations section.

Hope the following responses will ease that.

> you referring to IPSEC here?  If so, you should say so; if not, what
IPsec is certainly one option. There could be others at transport or DNS
application level. The text in the document certainly does not preclude
IPsec. 

> by the gateway from being accepted by the destination system.

Ah, I see what you are saying. How about I replace the word "encrypted" 
with "preserved" or "encrypted/authenticated". 

> has the key.  How exactly is the ALG supposed to get the key?

It is not unlikely for NAT, DNS-ALG and IPsec gateway (that provides
secure tunneling service) to be resident on the same device. In such a
case, the ALG will have access to the security association keys.

> 					- Bill

Thanks for your comments.

cheers,
suresh
-