Subject: RE: Re: PAA Discovery

From: <[email-masked]>
Date: Wed, 13 Feb 2002 19:07:48 -0600

I think we are going around in circles now with the PAA discovery
thread.
My opinion is that PAA discovery is an important enough aspect for the
WG to consider. What mechanism(s) will assist in PAA discovery are
something that we can discuss and at this time I would not rule out
the options. However the discussion of PAA discovery becomes relevant
only after we have a framework for PANA in place. The next step for the
WG is to develop a framework. Once we have that we could jump into 
solutions that are best suited for the elements in the framework. 

I think we are jumping ahead of what needs to be done in the WG. So
maybe if we could focus on the framework for PANA, that would be more
productive.

-Basavaraj

> 
> George, James,
> 
> > Tema: Re: Re: PAA Discovery
> > 
> >  As I have previously said, I don't think Router 
> Advertisements are the
> > right place for this.
> 
> 
> Fine with me. I would like to hear George's opinion on this 
> first, however.
> 
> Paal
> 
> 
> > 
> > For the rest,  I think they should be examined.
> > 
> >         jak
> > 
> > 
> > 
> > > >
> > > > 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: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 13 Feb 2002 18:16:28 -0800

> maybe if we could focus on the framework for PANA, that would be more

Yes please! This thread is about solutions... not even about full-solutions,
it's
about part of some generic solutions. We cannot just talk about one
component of any possible solutions and rule out some mechanisms... Let's
discuss this later (and until then please prepare your answer to "what is
wrong with authenticating router discovery?" :)

alper