Subject: Re: Re: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Wed, 13 Feb 2002 20:32:19 +0100

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 13:21:10 -0800

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.

            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

> 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.)
> 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.