Subject: RE: NA(P)T, Proxies and PANA

From: George Tsirtsis <[email-masked]>
Date: Wed, 23 Jan 2002 18:24:34 -0500

All,

My personal opinion (I think also shared with most of the group) is that
NATs maybe PANA clients (i.e.: PANA may run between a NAT and a PAA). What
happens beyond NATs is not of PANA's concerns.

Still in the context of *requirements* the current position of the
requirements team is as follows. We have no language in the requirements wrt
NATs and yet we state nothing that would render a solution that deals with
NATs invalid. In other words we DO NOT place a requirement for solutions to
work over NAT but we do not disallow solution from doing so either... and we
currently think this is good enough. 

People will have to be a bit patient until they see the agreed requirements,
but Reinaldo (and some of the rest of us) wanted to see if there is interest
beyond what I state above above towards solving the NAT problem by the
larger group.

Regards
George

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 8:43 PM
To: George Tsirtsis; [email-masked];
[email-masked]
Subject: NA(P)T, Proxies and PANA

Hello,

I understand that this issue was discussed some time
on this list, but since the subject arose on the
design team, I would like to post some comments here
to hear some feedback.

1)

NAT, proxies, etc are out there we like it or not. 

I believe (but can be convinced otherswise) that not
dealing with this issue might limit the applicability
of PANA. sometimes you can have several PANA clients
behind a NAPT or Proxy, which will make identification
difficult to happen. 

Several groups are working to make SIP, IPsec, etc
work through NAT/NAPT, saying that PANA will not deal
with seems like living in denial, but again, since
this is rough consensus I leave the decision to the
list. 

My position is that we should not say that PANA will
not work in these kind of environments but make the
requirements/protocol flexible enough so it can. Then
somebody can write a draft/ extension to make it work.

2)

A similar issue is that I advocate that the
identification of the device (IP address, MAC address,
etc) that the client is using should be carried in
PANA protocol if needed. My argument is that in the
current Internet we cannot assume that a packet will
arrive untouched on the PAA server so that you can
infer the MAC/IP address from the packet itself. 
There are NAT, NAPT, Proxies, VPNs, all kinds of
tunneling, etc out there.

Since this is rough consensus I'll not bring this
issue again if people say that there are not
NAT/proxies out there and/or we should provide
flexibility in the protocol to deal with them.

regards,

Reinaldo 

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 24 Jan 2002 04:52:51 -0500

-----Original Message-----
From: MORAND Lionel FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Thursday, January 24, 2002 9:40 AM
To: 'George Tsirtsis'; 'Reinaldo Penno'; [email-masked]
Subject: RE: NA(P)T, Proxies and PANA

Hi,

Since that NATs or proxies are not transparent for the signaling path
between the user/device and the PAA, I don't understand how it could be
possible to not define some specific requirements for PANA in this case.
Saying that a NAT/proxy could be a PANA client, Does it mean that there will
be no way to identify the user/device beyond the NAT/proxy using PANA? Maybe
this point could be clarified before any decision.

GT> Yes, that was my *personal* opinion. Still the requirements team is
currently mute on this. i.e.: We have left the door open for implementations
to be proposed that work between clients and PAAs that are located at either
side of a NAT. Although we "have left the door open" WE DO NOT currently
have a requirement that says anything like "PANA MUST/SHOULD/MAY work over
NATs/Firewalls/Proxies". Do let me know if the above is not clear.

Regards
George
-----Message d'origine-----
De : George Tsirtsis [mailto:[email-masked]]
Envoyé : jeudi 24 janvier 2002 00:25
À : 'Reinaldo Penno'; [email-masked]
Objet : RE: NA(P)T, Proxies and PANA

All,

Regards
George

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 8:43 PM
To: George Tsirtsis; [email-masked];

Hello,

1)

2)

regards,

Reinaldo

---

From: MORAND Lionel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 24 Jan 2002 10:40:24 +0100

Hi,

Regards,

Lionel

-----Message d'origine-----
De : George Tsirtsis [mailto:[email-masked]]
Envoyé : jeudi 24 janvier 2002 00:25
À : 'Reinaldo Penno'; [email-masked]
Objet : RE: NA(P)T, Proxies and PANA

All,

Regards
George

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 8:43 PM
To: George Tsirtsis; [email-masked];

Hello,

1)

2)

regards,

Reinaldo

---

From: MORAND Lionel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 24 Jan 2002 14:06:05 +0100

Hi George,

I agree that it may be not useful to mention explicitly NAT or any other
"middle boxes" sould be supported by PANA. But you have to be sure that the
case of "middle boxe traversal" can be covered by the "generic" requirements
because 1)PANA must be generic enough to supported over most of access
networks, 2) it is likely that NAT/Firewal/proxy will be present in various
access networks, 3) there is no assumption on the location of the user and
the PAA.

About the possibility of having NAT as PANA client, how to deal with user
info exchange in PANA without any requirement on the NAT itself? But maybe
here I missed something?

Regards,

Lionel

-----Message d'origine-----
De : George Tsirtsis [mailto:[email-masked]]
Envoyé : jeudi 24 janvier 2002 10:53
À : 'MORAND Lionel FTRD/DAC/ISS'; [email-masked]
Objet : RE: NA(P)T, Proxies and PANA

-----Original Message-----

Hi,

Regards
George
-----Message d'origine-----
De : George Tsirtsis [mailto:[email-masked]]
Envoyé : jeudi 24 janvier 2002 00:25
À : 'Reinaldo Penno'; [email-masked]
Objet : RE: NA(P)T, Proxies and PANA

All,

Regards
George

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 8:43 PM
To: George Tsirtsis; [email-masked];

Hello,

1)

2)

regards,

Reinaldo

---

From: "Wang, Cliff" <[email-masked]>
Date: Thu, 24 Jan 2002 18:59:54 -0000

From that aspect, this looks to me a NAT ALG issue, where NAT box or some
other middle box needs to be aware of the PANA exchange, extract the
necessary session info, do the needed translation, and build a state for the
PANA client. PANA should stay transparent, and maybe designed as NAT
friendly (eg, not encrypting/integrity protecting critical field), instead
of finding a solution for NAT.

-----Original Message-----
From: Wang, Cliff [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 12:51 PM
To: 'Yoshihiro Ohba'; Hesham Soliman (ERA)
Cc: 'George Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS';
Subject: 

The real NATP issue is that in order to support NAT traversal, both the PAA
and NAT box need to be aware of the binding between the PANA client and
pre-NAT address. Based on that NAT can allow or deny NAT translation. If the
PANA client is authenticated, NAT will be allowed.

I don't see how port binding will work. The traffic from PANA client can use
any port. So is the NAT translated port. There could be multiple sessions at
the same time as well. Neither PANA nor NAT box has the capability to
control the binding between port(s) and client.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 10:06 AM
To: Hesham Soliman (ERA)
Cc: 'George Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS';
[email-masked]
Subject: Re: NA(P)T, Proxies and PANA

On Thu, Jan 24, 2002 at 02:46:58PM +0100, Hesham Soliman (ERA) wrote:
> => I think this is fine, mandating NAT support is
> extreme IMHO. For IPv4 NATs, I definitely don't think
> we should mandate supporting them. This is a disease
> that should be cured by IPv6. As for NAT-PT, I don't
> see real scenarios where NAT-PT would cause problems
> or require special consideration, but I might be 
> missing something. 
> 
> Hesham
> 

The following text is my personal understanding of PANA problem with NA(P)T,
which is copy-and-pasted from the internal mail discussion among the members
of the terminology/requirements team.

Note that the following may not apply to newer NAT-based technology 
such as "Real Specific IP".   

Yoshihiro Ohba

-------------------------------------------------
It is easy to make a binding for access control between IP address of a
device and the PANA client, since the IP address always appears in the
source IP address field of IP headers carrying PANA messages.  

On the other hand, it would be difficult to make a binding for access
control between port number (plus IP address) of a device and the PANA
client.  There are two reasons why it is difficult.

The first reason is that to make a binding between port 
number and the PANA client, the NAPT must have such a capability.

For instance, assume that there are two devices connected to 
a NAPT router with different PANA client IDs.

[email-masked]
    (device A)-----+
                   |
                   |
           [internal network]--(NAPT router)---(PAA)
                   |
[email-masked]  |
    (device B)-----+
                    
When a NAPT router receives a TCP SYN packet 
from a device with destination port number = 80 (http), how 
can the NAPT router distinguish 
which client the TCP SYN packet belongs to?  I think it is 
generally difficult.

The second reason is that to make a binding between port number and the PANA
client, the PAA must have such a capability, too.  To achieve this, PANA
client must have capability to inform the PAA of the mapping between the
port number and the client identifier either on demand (when a new TCP
connection request is received at NAPT router) or during the initial
authentication phase.  However, since the port number is translated at the
NAPT router, the PANA client behind the NAPT does not have a knowledge about
which port number is actually used at the ISP side.

---

From: MORAND Lionel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 24 Jan 2002 20:27:55 +0100

Hi,

Following this point, it is clear that, even if a global or specific
solution must not be based on middle boxes traversal issues, this point
implies anyway some requirements on the PANA solution itself to achieve this
level of transparency.
The point till now is not to state if PANA must or must not support this
specific issue but to not forget it during the protocol design
consideration. I think that it should be one of the objectives of the
requirements draft to cover the whole scope of main access network
configurations.

Regards

Lionel

-----Message d'origine-----
De : Wang, Cliff [mailto:[email-masked]]
Envoyé : jeudi 24 janvier 2002 20:00
À : 'Yoshihiro Ohba'; Hesham Soliman (ERA)
Cc : 'George Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS';
[email-masked]
Objet : RE: Re: NA(P)T, Proxies and PANA

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 10:06 AM
To: Hesham Soliman (ERA)
Cc: 'George Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS';

Yoshihiro Ohba

[email-masked]
    (device A)-----+
                   |
                   |

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 25 Jan 2002 4:29:11 +0100

Alper,

I agree that we should keep NATs outside the requirement draft. 

However, I think the NAT issue probably will be resolved "by itself":

1) IMO, PANA must assure a binding between a host's application layer identifier (e.g. the NAI) and its lower-layer identifiers (e.g. its IP-address) as part of the authentication process. Otherwise, how can access control be enforced? You cannot expect the host to append its NAI to each and every packet! (IMO, this binding is the "hook" that PANA is looking for.)

2) Most NAT traversal techniques is based on having a host discovering its own global IP address (NAT address) - for simplicity I've kept port translation out of this discussion .

Therefore, in cases where NATs are present between a host and a PAA, the host must naturally first discover its global NAT address. Furthermore, it must ensure that it is this global NAT address that is "bound" to its NAI, as far as the PANA protocol is concerned.

Paal

> 
> Fra: "Alper Yegin" <[email-masked]>
> Dato: 2002/01/24 Thu PM 11:08:23 CET
> Til: "Hesham Soliman \(ERA\)" <[email-masked]>,
>    "'George Tsirtsis'" <[email-masked]>,
>    "'MORAND Lionel FTRD/DAC/ISS'" <[email-masked]>,
>    <[email-masked]>
> Tema: Re: NA(P)T, Proxies  and PANA
> 
> 
> 
> I agree with Hesham. Shall we have a "NAT considerations"
> section in every end2end protocol design? Do we have
> to complicate every new protocol to make it work accross
> a NAT box? I hope not! :)
> 
> One possibility is that in the final PANA the PAA is
> the first hop router, and then NAT is not an issue at all.
> 
> alper
> 
> 
> 
>

---

From: Tomas Goldbeck-Löwe (ERA)<[email-masked]>
Date: Fri, 25 Jan 2002 11:38:10 +0100

Paal,

> From: Paal Engelstad [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 4:29 AM
> To: Alper Yegin; Hesham Soliman "ERA"; 'George Tsirtsis'; 
> 'MORAND Lionel
> FTRD/DAC/ISS'; [email-masked]
> Subject: Re: Re: NA(P)T, Proxies and PANA
> 
> 
> Alper,
> 
> 1) IMO, PANA must assure a binding between a host's 
> application layer identifier (e.g. the NAI) and its 
> lower-layer identifiers (e.g. its IP-address) as part of the 
> authentication process. Otherwise, how can access control be 
> enforced? You cannot expect the host to append its NAI to 
> each and every packet! (IMO, this binding is the "hook" that 
> PANA is looking for.)

I agree that we need this hook. And that PANA should do this.
But still, the problem of stealing an already authenticated IP address must be dealt with. Or is that out of scope? 

Thanks.
	--> Tomas
> 
> 2) Most NAT traversal techniques is based on having a host 
> discovering its own global IP address (NAT address) - for 
> simplicity I've kept port translation out of this discussion .
> 
> Therefore, in cases where NATs are present between a host and 
> a PAA, the host must naturally first discover its global NAT 
> address. Furthermore, it must ensure that it is this global 
> NAT address that is "bound" to its NAI, as far as the PANA 
> protocol is concerned.
> 
> Paal
> 
> >

---

From: "Wang, Cliff" <[email-masked]>
Date: Fri, 25 Jan 2002 15:09:25 -0000

Comments inline.

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 10:29 PM
To: Alper Yegin; Hesham Soliman "ERA"; 'George Tsirtsis'; 'MORAND Lionel

Alper,

1) IMO, PANA must assure a binding between a host's application layer
identifier (e.g. the NAI) and its lower-layer identifiers (e.g. its
IP-address) as part of the authentication process. Otherwise, how can access
control be enforced? You cannot expect the host to append its NAI to each
and every packet! (IMO, this binding is the "hook" that PANA is looking
for.)

2) Most NAT traversal techniques is based on having a host discovering its
own global IP address (NAT address) - for simplicity I've kept port
translation out of this discussion .

Therefore, in cases where NATs are present between a host and a PAA, the
host must naturally first discover its global NAT address. Furthermore, it
must ensure that it is this global NAT address that is "bound" to its NAI,
as far as the PANA protocol is concerned.

[cliff] I disagree that it is the client's burden to support NAT. Otherwise,
you are forcing PANA client to be NAT aware. How can a client know that a
NAT box is its path? You will have to do NAT discovery by client then. It
SHOULD be the NAT box and potentially PAA's responsibility to support NAT
traversal. The NAT box needs support PANA traffic and PAA needs to be NAT
aware, especially PAA needs to know the binding between the client NAI to
the translated address/port, so that access control can be enforced.

> I agree with Hesham. Shall we have a "NAT considerations" section in 
> every end2end protocol design? Do we have to complicate every new 
> protocol to make it work accross a NAT box? I hope not! :)
>

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 25 Jan 2002 10:41:03 -0500

NAT is supposed to be "transparent" and when it is not it uses ALG to become
transparent. It is up to NAT vendors to come up with ways to support various
protocols transparently. After all, I do not think we will have any
requirements saying the a solution MUST NOT work over NAT, although I
personally will not mind if we do :-)

We are currently mute in terms of NAT requirements, which allows designers
to work with NATs if they so desire. My suspicion is that making PANA work
with NAT will be very hard and ugly and is likely not to satisfy all the
other requirements e.g.: "both sides MUST be able to initiate
authentication" ...I do not know of any way to do this via NAPT and the way
NAT supports it (DNS-ALG) is very ugly and involves the DNS system i.e.: the
two sides need to look each other up on DNS (ouch!).

George

-----Original Message-----
From: Wang, Cliff [mailto:[email-masked]]
Sent: Friday, January 25, 2002 3:09 PM
To: 'Paal Engelstad'; Alper Yegin; Hesham Soliman "ERA"; 'George
Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS'; [email-masked]
Subject: RE: Re: NA(P)T, Proxies and PANA

Comments inline.

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 10:29 PM
To: Alper Yegin; Hesham Soliman "ERA"; 'George Tsirtsis'; 'MORAND Lionel

Alper,

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 25 Jan 2002 20:30:46 +0100

Hi Tomas,

Comments below,

> 
> Fra: Tomas Goldbeck-Löwe (ERA)
> 	 <[email-masked]>
> Dato: 2002/01/25 Fri AM 11:38:10 CET
> Til: "'Paal Engelstad'" <[email-masked]>, 
>    Alper Yegin
> 	 <[email-masked]>, 
>    "Hesham Soliman (ERA)"
> 	 <[email-masked]>,
>    "'George Tsirtsis'"
> Tema: RE: Re: NA(P)T, Proxies  and PANA
> 
> Paal,
> 
> 

This issue has been raised on the list, and most people seem to agree that the "hook" for access control is within the scope, while the actual enforcement of access control is out of scope.

I agree that the problem of stealing an already authenticated IP address is essential. However, it is an enforcement problem an therefore out of scope. It should be solved by other mechanisms than the PANA protocol.

Paal

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 25 Jan 2002 21:03:40 +0100

George,

Comments below.

You wrote (taken out of context):
> authentication" ...I do not know of any 
> 

I would like leave the NAT discussion, but only comment on the requirement "both sides MUST be able to initiate authentiation".

I think this would be a sound requirement, assuming an EAP-based solution, because two uni-directional EAP authentication processes comprises a mutual authentication. However, I think that "mutual authentication" is the ultimate requirement in PANA.

More importantly, I think it is important to distinguish the initial PAA discovery, and session key establishment from the sub-sequent re-authentication. Therefore, I agree to a requirement saying that "both sides MUST be able to initiate RE- (!!!)authentiation". However, it is not evident that neither both parties must be able to the initial discovery process, nor the subsequent session key establishment process.

The reason that I stress that your requirement should only span RE-authentication, is that many initial session key establishment algoritms has authentication (i.e. livelyness) as a feature build into the algorithm.

Paal

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 25 Jan 2002 21:25:27 +0100

Cliff.

Good point! I actually think we agree. The problem is that we are discussing different access scenarios.

- If the NAT is part of the access domain, I agree with you that it is PAAs burden to ensure that the NAT works transparently to attached hosts.

However, if the NAT is part of the network of a host (i.e that the host connects to the access network through a NAT that is located in the same trusted domain as the host is) it is the host's burden to ensure that the NAT works transparently to the access domain.

Right?

Paal

> 
> Fra: "Wang, Cliff" <[email-masked]>
> Dato: 2002/01/25 Fri PM 04:09:25 CET
> Til: 'Paal Engelstad' <[email-masked]>,  Alper Yegin
> 	 <[email-masked]>,  "Hesham Soliman \"ERA\""
> 	 <[email-masked]>,  'George Tsirtsis'
> 	 <[email-masked]>,  'MORAND Lionel FTRD/DAC/ISS'
> 	 <[email-masked]>,  [email-masked]

---

From: "Wang, Cliff" <[email-masked]>
Date: Fri, 25 Jan 2002 20:44:47 -0000

Yes.
In that case, only static NAT can be used where each interior host will have
a public IP address for clients to connect to. NATP won't work.

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]] 
Sent: Friday, January 25, 2002 3:25 PM
To: Wang, Cliff; Alper Yegin; Hesham Soliman "ERA"; 'George Tsirtsis';
'MORAND Lionel FTRD/DAC/ISS'; [email-masked]
Subject: RE: Re: NA(P)T, Proxies and PANA

Cliff.

Good point! I actually think we agree. The problem is that we are discussing
different access scenarios.

- If the NAT is part of the access domain, I agree with you that it is PAAs
burden to ensure that the NAT works transparently to attached hosts.

However, if the NAT is part of the network of a host (i.e that the host
connects to the access network through a NAT that is located in the same
trusted domain as the host is) it is the host's burden to ensure that the
NAT works transparently to the access domain.

Right?

Paal

> IP-address) as part of the authentication process. Otherwise, how can 
> access control be enforced? You cannot expect the host to append its 
> NAI to each and every packet! (IMO, this binding is the "hook" that 
> PANA is looking
> for.)
> 
> 2) Most NAT traversal techniques is based on having a host discovering 
> its own global IP address (NAT address) - for simplicity I've kept 
> port translation out of this discussion .
> 
> Therefore, in cases where NATs are present between a host and a PAA, 
> the host must naturally first discover its global NAT address. 
> Furthermore, it must ensure that it is this global NAT address that is 
> "bound" to its NAI, as far as the PANA protocol is concerned.
> 
> [cliff] I disagree that it is the client's burden to support NAT. 
> Otherwise, you are forcing PANA client to be NAT aware. How can a 
> client know that a NAT box is its path? You will have to do NAT 
> discovery by client then. It SHOULD be the NAT box and potentially 
> PAA's responsibility to support NAT traversal. The NAT box needs 
> support PANA traffic and PAA needs to be NAT aware, especially PAA 
> needs to know the binding between the client NAI to the translated 
> address/port, so that access control can be enforced.
> 
> 
> 
> >