Subject: RE: [Pana] IP address configuration

From: Soliman Hesham <[email-masked]>
Date: Mon, 1 Dec 2003 04:00:48 -0500

> >=> I think this might be treading in unchartered items ;)
 > >I mean, is securing ND really part of the PANA charter?
 > 
 > If I have a secure channel between the two end-points,
 > I'd try yo carry as much of my communication as possible
 > inside this channel, unless this creates additional unjustified
 > complexity. This is where I'm coming from... I don't think
 > this solves 100% of the problems associated with securing
 > ND and router discovery, but I think it can help...

=> ok. It's worth considering the impacts on the IP stack and
the communication media (multicast with IPsec) though. I
was hoping that PANA can be independent of the IP stack
implementation as much as possible for ease of deployment.
In any case since this does not solve the major problems
with ND (DAD and NAs) there is likely to be a need to have SEND
anyway for those links that need it. So doubling the security
of the RA might not be that worthwhile given the impacts 
on all the other ND messages. 

 > The outer address is only needed to shuttle
 > real data packets to the EP. Also,  from the PANA perspective,
 > it'd be a much cleaner architecture if there is only one IP 
 > address visible
 > and it is used as the device ID. Filters on the EP are only 
 > aware of this
 > address. And there is no reason to change this address in 
 > time... These
 > all say "link-local" to me...
 > On the other hand, do you see any issues with using a 
 > link-local address
 > as ther outer address of the IPsec tunnel?

=> Not really, I just didn't think we needed to assume 
that the outer address is different from the inner one.
The requirements listed above can be met with any 
IP address that doesn't have to change too often. Of course
when L2 security is available the DI can just be a MAC
address. 

Hesham

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

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 1 Dec 2003 04:00:48 -0500

Hesham

---

From: [email-masked]
Date: Mon, 1 Dec 2003 08:40:58 -0800

>When configuration of post-PANA address occurs before IKE/IKEv2,
>it might be difficult to support the ISP selection model over shared
media.
>So supporting this case only would be a limitation.

I presume by "ISP selection" you are referring to the ability to allocate
an IP address from the address pool of the selected ISP.

Yes, the IPsec tunnel is bound to the PANA session, hence it implies
the selected ISP. As such, this can be leveraged during the address
allocation to identify the right address pool, ISP, etc.

But this is not the only way. Even if the address configuration takes
place outside the IPsec tunnel, some other identifier that is bound
to the PANA session can be used during the process. For example,
the source address of DHCP request (the DI of PaC) or the client
ID field set to PANA session ID might help.

I believe that DHCP should occur over the routing context where the address
is actually used.
When DHCP is performed outside the IPsec tunnel, the address assigned by
the DHCP server is
intended for the use outside the IPsec tunnel. RFC3456 is a special case in
which DHCP
for inner address allocation is allowed to run outside the IPsec tunnel,
with an assumption that the DHCP SA in RFC3456 is tightly associated with
the subsequently
created IPsec SA.

>When configuration of post-PANA address occurs inside the IPsec tunnel
>or inside IKE/IKEv2, it would be able to support the ISP selection model
>over shared media.  At least post-PANA address configuration is supported
>inside IKEv2 with Configuration Payload exchange. Post-PANA address
>configuration with DHCPv4 inside IPsec tunnel is supported by IKE +
>RFC3456. I am not really sure if there is no problem
>with other schemes for post-PANA address configuration inside IPsec
tunnel.

>I have a concern on allowing a PaC to specify wildcard address range in
>IPsec SA negotiation for the purpose of running Neighbor Discovery inside
>the IPsec tunnel, especially when the PaC is also a router,
>it could totally affect routing behavior.

Could you please elaborate on this....

Allowing PaC to specify wildcard address range as traffic selector means
that
any traffic can be forwarded to the PaC. Traffic selector is used for
constructing
SPD but sometimes also used for creating routing table when the IPsec
tunnel is associated
with a dedicated logical IP interface (such as ipsec0, ipsec1,... in
Linux). As a consequence,
I think it is possible that EP forwards all packets that are received from
ISPs or
other PaCs to the PaC that specified wildcard address range as traffic
selector.
If the PaC itself is a router and has another interface to the Internet, it
could totally
change the routing behavior.  This would be an extreme case, but I believe
it is not a
good idea in general to rely on a solution that uses wildcard address range
as traffic selector
for PaC.

Yoshihiro Ohba

Alper

_________________________________________________________________
>From the hottest toys to tips on keeping fit this winter, you値l find a
range of helpful holiday info here.
http://special.msn.com/network/happyholidays.armx

---

From: [email-masked]
Date: Mon, 1 Dec 2003 08:40:58 -0800

media.

tunnel.

Yoshihiro Ohba

Alper