Re: [Pana] PANA relay draft

["Alper Yegin" <[e-mail]>]

Hi Rafa,

> > One way to look at this is the NAS is composed of the PRE and the
> PAA.
> > Or, think of it as the NAS has to IP interfaces, one with the IP
> address of
> > PRE, the other with the IP address of PAA.
> 
> [Rafa] I think if that is the view I believe it should be reflected
> somehow. The reason is that until now in the I-D it seems the PRE is a
> completely different entity from the PAA. In other words, they do not
> part of the same NAS. In fact, the PaC will have a PANA session where
> the "IP address and UDP port number of the PAA" which is actually the
> "IP address and UDP port number of the PRE."
> 
> 
> >
> > Which channel binding solution are you considering that'd have a
> problem
> > with this?
> 
> [Rafa] Basically, what I am thinking is that the PAA would send its IP
> address for example to the AAA server as part of channel binding
> parameter. The PaC however sees the IP address of the PRE. If the AAA
> informs to the PaC that PAA sent as channel binding parameter PAA's IP
> address, the PaC will contrast this parameter with what the PaC saw
> (the PRE IP address) which basically does not match. If we follow the
> idea of that PRE is an interface of the PAA, most probably what the PAA
> would have to send to the AAA is the PRE's IP address as channel
> binding parameter.

Rafa, which specific channel binding solution are you referring to here?
And your proposed remedy above can handle the situation.
My point is, whatever the channel binding solution is, it can handle this
situation (which would also arise in the very simple case where a simple PAA
were using two different IP addresses -- one facing the PaC and the one
facing the PAA). 


> >> What about allowing the PAA to answer the PaC (through the
> >> PRE) with the PAA's IP address? The PCI sent by the PaC will not
> carry
> >> that IP address but the PaC would see a PAR coming from a PAA and it
> >> would engage the PANA authentication with it.
> >
> > PRE sourcing IP packets with PAA's IP address, and accepting IP
> packets
> > destined to PAA, and PaC using its link-local address to communicate
> with
> > the PAA's global IP address... these are not trivial.
> >
> > I'd think a NAS with two IP addresses and using one at one phase and
> another
> > at a latter phase is not such a problem.
> >
> > We could have the same issue in another simpler case: consider PaC
> being
> > authenticated on one interface of PAA, and later PaC attaches to
> another
> > interface of the PAA. PAA may have two different IP addresses on each
> > interface. Yet, the same PANa sessions shall be available thru both
> > interfaces.
> 
> [Rafa] But the PANA session has to change in the attribute "IP address
> and UDP port number of the PAA" and that change (I believe this is
> related with the recent Yoshi's e-mail) must happen in the PaC. 

We can mention that in the I-D.

> In the
> RFC 5191 it is said: "In order to maintain the PANA session, the PAA
> needs to be notified about the change of PaC address." I would expect
> the same in the PaC (I will answer Yoshi's e-mail about this).

If you are suggesting this be changed on PANA RFC 5191, I don't think this
is necessary.
A mention of that in the relay I-D makes sense.

Regards,

Alper


> 
> Best regards.
> 
> >
> > Alper
> >
> >
> >>
> >>>
> >>> Best Regards,
> >>> Yoshihiro Ohba
> >>>
> >>
> >> -------------------------------------------------------
> >> Rafael Marin Lopez, PhD
> >> Dept. Information and Communications Engineering (DIIC)
> >> Faculty of Computer Science-University of Murcia
> >> 30100 Murcia - Spain
> >> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> >> -------------------------------------------------------
> >>
> >>
> >
> >
> 
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
> 
>