Subject: Re: [Pana] IP address configuration

From: [email-masked]
Date: Fri, 21 Nov 2003 18:51:44 -0800

With regard to the inner address assignment through IKE or IKEv2,
just use the method(s) available for tunnel mode SA.

I don't think we have to support IP-in-IP transport mode SA just because a
particular address configuration
method may not be supported by tunnel mode SA.

Yoshihiro Ohba

                      "Mohan                                                                                                    
                      Parthasarathy"           To:      "Alper Yegin" <[email-masked]>, <[email-masked]>               
                      <mohanp@sbcgloba         cc:      "Jari Arkko" <[email-masked]>, "Bernard Aboba"                    
                      l.net>                   <[email-masked]>, "James Kempf" <[email-masked]>                  
                      Sent by:                 Subject: Re: [Pana] IP address configuration                                     
                      pana-admin@ietf.                                                                                          
                      org                                                                                                       

                      2003/11/21 17:38                                                                                          

 >
> >
> >> the PANA-Bind-Request message. PaC should attempt this configuration
> > inside
> >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless
address
> >> autoconfiguration or DHCP can be used.
> >>
> > As i clarified in my other email, you don't setup the IPsec selectors
until
> > you have
> > acquired the "routeable" (inner) address. And these addresses are used
as
> > selectors
> > in the SPD.
> >
> >> Both pre-PANA and post-PANA addresses are used by the PaC at the same
> > time,
> >> though post-PANA addresses only appear inside the tunnel. A post-PANA
> >> address has no significance for the PANA session or access control.
> >>
> > For tunnel mode SA, the outer addresses are not significant for access
> > control.
> > The inner addresses are used for access control. SPD selectors are
inner
> > addresses.
>
> Apparently I was still thinking in terms of IP-IP transport mode (the
older
> version of the draft).
Yes. The older version of the draft used just the link-local address as
selectors.
So, it is possible to do IPsec as soon as you are done with PANA.

> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's
phase
> 2 identity, so that the inner IP addresses can be anything. And run
address
> autoconfiguration or DHCP inside the tunnel.
>
I am not sure whether the EP would accept the range. EP may just accept
only
one address as it lets any authenticated nodes spoof each other very
easily.
I have only seen ranges used by VPN gateways and not sure whether any
host uses it or not. Again, if we can fix this in other ways e.g. using
IP-IP transport mode, we should do that.

>
> >
> >> If pre-PANA and post-PANA addresses are the same, they will be used
both
> >> inside and outside the tunnel (any issues with IPsec processing?).
This
> > can
> >
> > Some implementations have problem with this when the packets are
destined to
> > the tunnel end point address itself.
>
> Does this have anyting to do with the specification, or the intended use
of
> it? Or, is this simple a shortcoming or a bug in some implementations?
>
It is just an implementation artefact. I send packets to "DEST", route
lookup
returns a tunnel interface, which in turn encapsulated with outer header
"DEST" , re-enters IP and loops again. This comes as a side effect of
implementing IPsec tunnel mode SA as an "interface". This is not
a real issue here as we can always bypass IPsec for messages sent
to EP.

-mohan

> > Here, these will be PANA messages
> > which will anway be bypassed (mentioned in the draft) i.e no IPsec for
PANA
> > messages flowing between PaC and PAA/EP.
>
>
>
> Alper
>
>
> >
> >> be the case when the client has a static IP address, or the DHCP
address
> >> assignment does not depend on the client identity.
> >>
> >> Comments?
> >>
> >> Alper
> >>
> > mohan
> >
> >>
> >>
> >> _______________________________________________
> >> Pana mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/pana
> >
> >
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> >
>
>
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

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

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 24 Nov 2003 12:59:45 -0800

I'm trying to figure out how we can:
- just maintain one DI for the PaC, and that is used as the local end-point
of the IPsec tunnel (when IPsec-based access control is used)
- any other IP address can be configured inside this tunnel. Router
discovery, ND, and DHCP can be run inside the tunnel. These IP addresses
should not be used as PANA DI.

I think supporting DHCP-based or autoconf based address configuration is
required. Additional methods, like IKE-based address config, is nice to
have. This is so that the impact of PANA on the access network architecture
is minimal. 

It sounds like both IP-in-IP transport mode SA and tunnel mode SA with
wildcard phase 2 identities support these...

Alper

>                     Parthasarathy"           To:      "Alper Yegin"
> <[email-masked]>, <[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 24 Nov 2003 12:59:45 -0800

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 Nov 2003 17:52:35 -0800

Alper,

Comments below..
> should not be used as PANA DI.
If you are using IPsec based access control,  the functionality of EP is
different
on how it is configured. If EP and the access router are different boxes,
then
EP acts as a layer 3 router forwarding packets from the access router to the
clients.
This implies decrementing ttl for all packets which won't work with ND/RD
messages
that are sent from the access router to the PaCs. If EP and access router
are the same
 box, then the ttl is not decremented for locally sourced packets e.g.
ND/RD, as the
packets are not forwarded anymore, just locally sourced.  The picture in
draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated
and hence bypasses all ND/RD.

> wildcard phase 2 identities support these...
See above.

-mohan

> >                     l.net>                   <[email-masked]>,
"James
> > Kempf" <[email-masked]>
> >                     Sent by:                 Subject: Re: [Pana] IP
address
> > configuration

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 Nov 2003 17:52:35 -0800

Alper,

Comments below..

See above.

-mohan

"James
address

---

From: Alper Yegin <[email-masked]>
Date: Tue, 25 Nov 2003 12:07:58 -0800

> EP acts as a layer 3 router forwarding packets from the access router to the

That means, actually the "EP" is the "access router" from IP perspective.
Maybe we should treat these as a "colocated EP and AR" case. Relying on AR
for DHCP messaging, ND, and router discovery while relying on the EP as the
"default gateway" basically splits one link into two (PaC<===>EP, and
PaC<-->AR). How does this impact the complexity? Or, what do we lose if we
mark the EP as "AR" as well?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 25 Nov 2003 12:07:58 -0800

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 26 Nov 2003 11:36:31 -0800

> mark the EP as "AR" as well?
To keep it simple, we should co-locate AR and EP together. If we are going
to
use L2 mechanisms for enforcement, then it makes sense to have the
separation.
I don't think it makes much sense to keep them separate for Ipsec access
control.
I will merge them together in my next revision.

-mohan

> >>> I don't think we have to support IP-in-IP transport mode SA just
because
> > a

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 26 Nov 2003 11:36:31 -0800

-mohan

because