Subject: (NAT) draft-ietf-nat-app-guide-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 13 Apr 1999 13:17:40 -0400

Doing a quick scan, I didn't see the following issue covered in the
document. What does the WG think is the right behavior?

draft-ietf-pppext-l2tp-13.txt says:

> 8.1 L2TP over UDP/IP
> 
>    L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP
>    packet, including payload and L2TP header, is sent within a UDP
>    datagram. The initiator of an L2TP tunnel picks an available source
>    UDP port (which may or may not be 1701), and sends to the desired
>    destination at port 1701.  The recipient picks a free port on its own
>    system (which may or may not be 1701), and sends its reply to the
>    initiator's UDP port, setting its own UDP source port to the free
>    port it found. Once the source and destination ports are established,
>    they MUST remain static for the life of the tunnel.

The specific issue I see pertains to the reply message, in which the
responder is free to choose an aribitrary source port, as opposed to
using 1701, the port number the request was sent to.

Thomas
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: [email-masked] (Pyda Srisuresh)
Date: Tue, 13 Apr 1999 11:06:20 -0700 (PDT)

Thomas,

This is similar to how the TFTP file transfer program (another UDP based
application) works as well. In fact, even the IP address the respondent 
selects as its source neednt be the same as the destinatination IP address
used by the UDP session initiator [Ref: RFC 1123].

So, when a L2TP session is initiated from Src to Dest, the session 
will have the following parameters:
	(Src IP , src UDP-PORT, Dest IP, 1701)

The Reply packet will have the parameters:
       (Dest-IP-may-be-different(if multi-homed), Dest-UDP-Port,
	src IP, src UDP-PORT)

NAT routers cannot fix the session state until the UDP response comes back.
This is a generic problem with UDP sessions - the problem is exacerbated
by applications/protocols such as TFTP and L2TP which alter their source
port (to be different from the destination port used in the request packet), 
even as they use the destination address in the original packet as the
source in their response.

regards,
suresh

-

---

From: Thomas Narten <[email-masked]>
Date: Tue, 13 Apr 1999 14:40:58 -0400

>        (Dest-IP-may-be-different(if multi-homed), Dest-UDP-Port,

I believe that the above behavior is not general, and varies on a
protocol-by-protocol basis. I suspect (and just sent a note asking)
that DNS is not so liberal.

> source in their response.

Sounds like life is simpler for NAT if responses are required to
simply reverse the source/destination addresses and ports when
responding. That was the context of looking in the app-guide document
for guidance on this point. I.e., other issues aside, what does it
recommend be done?

Also, the above point on NAT session state should be mentioned
in one of the documents, if it hasn't been already.

Thomas
-

---

From: Daniel Senie <[email-masked]>
Date: Tue, 13 Apr 1999 15:25:31 -0400

Since draft-ietf-pppext-l2tp-14.txt (-14 seems to be the latest) is
still a draft and has not been published as a proposed standard, I sent
a note to the authors of the draft asking that they reconsider the issue
of the receiving station changing UDP ports. As you're an AD overseeing
this WG, I'd like to see this resolved before the draft is approved for
publication as a Proposed Standard.

In one of your messages, you mentioned something about IP addresses
changing as well. I don't see anything in the L2TP document about that.
In multi-homed cases, the end-node should ALWAYS respond with the IP
address on which it was contacted. This is clearly spelled out in Router
Requirements (RFC 1812) for example, when talking about processing of
ICMP Echo packets. It is in general unreasonable to expect a sending
station to recognize and correlate a response from a different IP
address. Indeed, doing so would likely open a system up to some
interesting hijacking attacks.

I asked a few folks at a recent IETF if there should be a NAT and
Firewalls Considerations section in all protocol RFCs. In essence, such
a section would require folks to think about these issues, and ask the
questions needed to develop protocols which can survive in the real
world. Anyone think this would be a good idea? It would be a good idea
if someone with firewall and NAT knowledge reviewed drafts being
considered for publication as Proposed Standards.

Depending on the response I get to my message to the authors of the L2TP
draft, I'll entertain adding some text to the app guide draft on the
subject.

Daniel Senie

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Steve Deering <[email-masked]>
Date: Tue, 13 Apr 1999 16:25:29 -0700

At 3:25 PM -0400 4/13/99, Daniel Senie wrote:
>                 ...for example, when talking about processing of
>address.

Daniel,

If a request packet (e.g., ICMP Echo message) can be sent to a
multicast destination address (as can an ICMP Echo message), then
the requestor *must* be able to recognize and correlate a response from
a source address that differs from the request's destination address
(because multicast addresses are not permitted to appear in the source
address field).

Steve

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Tue, 13 Apr 1999 17:25:59 -0700 (PDT)

> that DNS is not so liberal.

That may be so. I was merely pointing out that, barring individual protocol
restrictions, the UDP tranpsort layer does not mandate strict reciprocity
behaviour.

> responding. 

Yes. Doing that would make life simpler for IPsec Gateways and firewalls 
as well.  For example, it is hard for an IPsec gateway to define a packet 
policy that preserves the L2TP packets alone, unless a vendor policy requires 
that (a) responses are always sent back from port 1701 (or some other
pre-determined port) or (b) all UDP packets are preserved using the same
Security association parameters.

>             That was the context of looking in the app-guide document
Good point. I dont recall seeing a clear recommendation specifically
addressing this for UDP sessions in the draft. I am sure, Daniel is
going to include this in the next rev of the draft.

> in one of the documents, if it hasn't been already.

The general unsafe aspect of UDP sessions - namely, responses to a 
datagram could come from an address different from the target address
used by sender  - is mentioned in the "NAT terminology and 
considerations" draft under the "security considerations" section.

> 'unsubscribe nat' in the body of the message.

cheers,
suresh
-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Apr 1999 09:56:17 +0100

Daniel Senie wrote:
...
> considered for publication as Proposed Standards.

It should be NAT, firewall and IPv6 considerations, but this is
certainly something that we should be looking out for. Whether
it justifies a mandatory document section is another issue.

     Brian
-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Apr 1999 21:28:05 -0400

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:
    Daniel> I asked a few folks at a recent IETF if there should be a
    Daniel> NAT and Firewalls Considerations section in all protocol
    Daniel> RFCs. In essence, such a section would require folks to

  Not if you ask me.

  The products of this working group needs to go to RFC status before
anything like that should even be considered. 

]    Have encryption. Am travelling... wish it were by train... |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-