Subject: Re: Re: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Wed, 13 Feb 2002 23:12:22 +0100

> 
> Sorry, what I meant was, that I agreed it was too
> early to say.
> 
> Perhaps we need to have a discussion about the
> benefits and drawbacks of various mechanisms.

Definitely. However, I hope we do not need to form an PAA discovery design team (like for DNS discovery).

Rather, I hope we are able to temporarily dismiss some proposals early in the process and focus on a few alternatives.

Just from the top of my head, it could be simple statements like this:

- Anycast request seems superior to anycast discovery - let's focus on anycast request first.
- Site-scoped multicast seems like a bad choice. It opens the access network, and there might be a tradeoff between message overhead and latency. Let's focus on site-scoped multicast first.
- Site-scoped multicast with router-assist seems inferior to site-scoped multicast with router-only replies in the PANA case. Let's focus on the latter first.
- Router Advertisement seems like a good alternative wrt security. Un-authenticated PaCs does not get more information than required. Tuning the system wrt solicitations and periodic advertisements seems like a good way to deal with DoS. If we also gets an ICMP based solution with PAA located on AR, this could be an interesting option. Let's take a closer look at it.
- SLP, DNS and DHCP all opens the network to un-authenticated hosts - perhaps too much. However, some will use DHCP anyway to allocate addresses to un-authenticated nodes. Let's take a closer look at DHCP. (Let's alternatively take a look at SLP later.)

If we can do such a rudimentary analysis first, we could end up studying only the alternatives that seems most interesting.

With my example above, we would end up with analysing only:
- DHCP (IPv4 and IPv6)
- Router Adverisement (IPv4 and IPv6)
- Anycasted request (IPv6)

(which actually reflects the status of our PAA discussions so far.)

Then we could add new protocols to the analysis later.

My intention is not having to go through a too tedious process. Hopefully we will end up with a PANA protocol that gives some flexibility wrt discovery.

Comments?
Paal

>             jak
> 
> ----- Original Message -----
> From: "Paal Engelstad" <[email-masked]>
> To: "James Kempf" <[email-masked]>; "Hesham Soliman "ERA""
> <[email-masked]>; "Paal Engelstad"
> <[email-masked]>; "George Tsirtsis" <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, February 13, 2002 11:32 AM
> Subject: Re: Re: PAA Discovery
> 
> 
> > Hesham, James,
> >
> > I disagree, and think you might be jumping to conclusions.
> >
> > Comments below.
> >
> > Paal
> >
> > >
> > > Fra: "James Kempf" <[email-masked]>
> > > Dato: 2002/02/13 Wed PM 05:52:52 CET
> > > Til: "Hesham Soliman \(ERA\)" <[email-masked]>,
> > >    "Paal Engelstad" <[email-masked]>,
> > >    "George Tsirtsis" <[email-masked]>,
> <[email-masked]>
> > > Tema: Re: Re: PAA Discovery
> > >
> > >
> > > >   > Are you proposing anycasting the PANA message itself or the
> > > >   > discovery
> > > >   > request? If the former, I have no
> > > >   > objections, in fact, it looks like an interesting use of
> anycast.
> > > >
> > > > => It's too early to tell. We have to first
> > > > look at the final solution, see what security
> > > > assumptions it makes about the request, what
> > > > transport layer is being used ...etc
> > > > When we have that we can see whether anycast
> > > > fits in or not.
> > > >
> > > > Th idea of anycasting the request is nice for
> > > > something like a DNS request, but when state
> > > > is kept, this is a different issue.
> > > >
> > >
> > > Agree!
> > >
> >
> > I think you might be jumping to conclusions, - it's way too early to
> dismiss anycast as a discovery mechanism!
> >
> > Your argument is based on the general opinion that anycast does not go
> well together with stateless communication. (I agree to that.)
> >
> > That is fine, but concider for example an EAP-based PANA protocol: In
> the anycast case, (and in the PaC initated version) it would probably
> start with a PaC anycasting an Identity Request. The PAA returns an
> Idenity Response containing the NAI of the PAA. The PaC reads the
> IP-address from the IP-header (or we allow it to be incorporated into
> the Identity Response payload to avoid/reduce layering violation).
> >
> > At this point of time, it does not need to be any state established by
> the PAA. (I would expect rather the opposite: we would try to avoid it
> due to the DoS threat.)
> >
> > The client would then continue with the stateful authentication method
> towards the PAA.
> >
> > Hesham and James, please explain to me why this is a bad discovery
> mechanism that we should dismiss right away. My problem is, I cannot see
> where your "stateful communcation" argument fits into the scenario I
> discribed above.
> >
> > Paal
> >
> >
> > >             jak
> > >
> > >
> >
> >
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 14:47:13 -0800

As I have previously said, I don't think Router Advertisements are the
right place for this.

For the rest,  I think they should be examined.

        jak

----- Original Message -----
From: "Paal Engelstad" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Hesham Soliman "ERA""
<[email-masked]>; "George Tsirtsis"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, February 13, 2002 2:12 PM
Subject: Re: Re: PAA Discovery

> Rather, I hope we are able to temporarily dismiss some proposals early
in the process and focus on a few alternatives.
> - Site-scoped multicast seems like a bad choice. It opens the access
network, and there might be a tradeoff between message overhead and
latency. Let's focus on site-scoped multicast first.
> - Site-scoped multicast with router-assist seems inferior to
site-scoped multicast with router-only replies in the PANA case. Let's
focus on the latter first.
> - Router Advertisement seems like a good alternative wrt security.
Un-authenticated PaCs does not get more information than required.
Tuning the system wrt solicitations and periodic advertisements seems
like a good way to deal with DoS. If we also gets an ICMP based solution
with PAA located on AR, this could be an interesting option. Let's take
a closer look at it.
> - SLP, DNS and DHCP all opens the network to un-authenticated hosts -
perhaps too much. However, some will use DHCP anyway to allocate
addresses to un-authenticated nodes. Let's take a closer look at DHCP.
(Let's alternatively take a look at SLP later.)
>
> If we can do such a rudimentary analysis first, we could end up
studying only the alternatives that seems most interesting.
> My intention is not having to go through a too tedious process.
Hopefully we will end up with a PANA protocol that gives some
flexibility wrt discovery.