Subject: [Pana] Source and Destination IP address

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Sep 2006 12:04:06 +0200

>
> 6.1.  IP and UDP Headers
>
>    Any PANA message is unicast between the PaC and the PAA.  The source
>    and destination addresses SHOULD be set to the addresses on the
>    interfaces from which the message will be sent and received,
>    respectively.
>
>   
It is nonsensical to talk about the sender of a message setting the 
destination IP address to anything other than the address that will 
eventually lead to an interface on a PAA.

As for the source address, it sounds as if you are saying that the PANA 
message SHOULD not be spoofed. I think it is very important to get this 
source address correct, particularly if the Device ID is a source IP 
address, and this same source IP address is going to be used to setup 
filters (as per our previous discussion).

>    The source port of an unsolicited PANA message MUST be set to a value
>    chosen by the sender.  The destination port MUST be set to the peer's
>    port number if it has already been discovered via earlier PANA
>    exchanges, set to the assigned PANA port (To Be Assigned by IANA)
>    otherwise.

What is meant by "earlier PANA exchanges"? If a PANA session has the 
ability to move off of a registered UDP port, I would think that this 
would only last for a given PANA session. For example, based on this 
wording one might think: "Yesterday, when contacting PAA foo I used UDP 
port number 12345. So, I must still be able to use 12345 today." Surely 
that is not correct.

If by "unsolicited" you mean the initiating PANA messages (a PCI, for 
example) then I believe it should always be sent on the IANA specified 
port number. I'm not sure why you wouldn't want to make this true for 
all PANA messages, in fact. It certainly makes implementations simpler 
if the dest port is always the same, not to mention intervening 
equipment that may need to snoop what is happening to open up filters, 
or allow just PANA messages through for a period of time, etc. (DSLAMs, 
for example, on a DSL access network, may need to do this). I would 
highly recommend sticking to ONE dest UDP port, unless you really need a 
reason to move off of it (and I'd like to know what that reason is).

- Mark

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Sep 2006 13:50:30 -0400

> filters (as per our previous discussion).

Yes.  That is why we have a mechanism to carry Device ID in protected
PBR/PBA exchange to prevent some attacker in the middle of PaC and PAA
from spoofing Device ID of PaC.  However, it does not prevent the PaC
itself to spoof Device ID (an address ownership verification mechanism
such as SEND will be required to prevent this class of Device ID
spoofing.)

> port number 12345. So, I must still be able to use 12345 today." Surely 

Sure.  "earlier PANA exchanges" should be revised to "earlier PANA
exchanges in the same session".

> reason to move off of it (and I'd like to know what that reason is).

I think that the reason for using peer's port number as destination
port when it has already been discovered is for NAT traversal.  If we
always use a particular port number for dest UDP port, then NAT would
need to open up the port for a period of time for incoming PANA
traffic to PaC.

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 30 Sep 2006 11:16:06 +0300

> such as SEND will be required to prevent this class of Device ID

I agree with Yoshi's explanation on the "source address spoofing." But let
me also clarify that, the I-D text cited above wasn't intended to imply
anything in that respect. It is stating straight forwardly how to set the
source and destination addresses of the IP packets... but yes, it is too
obvious.  

...

> need to open up the port for a period of time for incoming PANA

I personally hadn't thought of that. Use of ephemeral port numbers by a
requester connecting to a server is common (server side of course needs to
be well-known port to be reached). As for sniffing the PANA signaling, at
least one of the ports will always be IANA-assigned port, so that's not a
problem. [earlier, that was not the case and we fixed that.]

Alper