Subject: RE: Re: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Wed, 6 Feb 2002 8:01:46 +0100

Hesham, James.

That is a good idea, Hesham. 

To push our discussion on this thread forward I have tried to make a brief summary of that draft. 

According to that draft, we have the following discovery mechanisms:

1)Transport Mechanisms

a)Anycast discovery of PAAs
b)Anycasted authentication request
c)Multicasting, using local-/link- scope etc.

2)Extensions to existing protocols

a)DHCP
b)RA
c)SLP
d)DNS

James did not only say we should not use extensions to RA. If I understood his comment correctly we should also refrain from developping protocol-specific mechanisms.  I expect this warning includes most of the transport mechansms. Did I understand you correctly, James?  
- Perhaps with exception of Anicasted Authentication request?

I am still concerned with the security aspects of the remaining alternatives; SLP, DNS, and DHCP. I assume that security aspects will be especially important criteria for PANA.

I think the assumptions that you referred to, Hesham, is the evaluation criterias. Right? In the PANA environment, I expect these to include:

- Security
- Time to deploy
- Standardization required
- Response times (and overhead)
- Scenarios (localization of PAA, interworking with mobility mechanisms, address filtering, etc.)
- Convergence times after failure
- Fate sharing

Are there more?

I assume most of the pros and cons in the DNS draft also applies to PANA.

Could this be a starting point for the discussion?
Comments?

Paal

> 
> Fra: "Hesham Soliman (ERA)" <[email-masked]>
> Dato: 2002/02/05 Tue AM 11:14:58 CET
> Til: Paal Engelstad <[email-masked]>, 
>    James Kempf
> 	 <[email-masked]>, 
>    George Tsirtsis <[email-masked]>,  [email-masked]
> Tema: RE: Re: PAA Discovery
> 
> Folks, 
> 
> There is an analysis of several possible ways 
> of discovering the DNS and the pros and cons
> of each mechanism. You can find a WG draft on 
> the IPv6 WG web page.
> I suggest we read this at least and draft 
> some assumptions so we can discuss which 
> way is better. Arguing about solutions 
> without stating assumptions is pointless. 
> 
> BTW SLP was not the highest preference because
> it required multicast routing. The team was
> not sure whether this will be widely available
> given the IPv4 situation. 
> 
> Hesham
> 
>   > -----Original Message-----
>   > From: Paal Engelstad [mailto:[email-masked]]
>   > Sent: Saturday, February 02, 2002 9:08 PM
>   > To: James Kempf; George Tsirtsis; [email-masked]
>   > Subject: Re: Re: PAA Discovery
>   > 
>   > 
>   > James,
>   > 
>   > I appreciate your concern, and I agree with you. In my opinion:
>   > 
>   > 1) SLP: This is generally a sound and preferable protocol 
>   > for service discovery. The PANA protocol accommodates 
>   > authentication service, which should be discovered as such.
>   > 
>   > 2) DHCP: This is a good nr. 2. We should probably avoid 
>   > getting in a situation where all services are discovered by 
>   > DHCP. However, the Authentication Service IS special in 
>   > that it is one of the few services that unauthenticated 
>   > host will be granted access to.  The wide deployment of 
>   > DHCP may also be beneficial, considering that we are aiming 
>   > to have a solution ready shortly. 
>   > 
>   > 3) AR: We need good arguments to deviate from the 
>   > fundamental principle that ICMP is intended for error and 
>   > control messages related to routing. However, it turns out 
>   > that people are arguing for strong coupling between ICMP 
>   > and the PANA authentication service. Thus, I do not think 
>   > we should rule this option out before we have discussed 
>   > those proposals.
>   > 
>   > BUT:
>   > 
>   > 4) The PANA protocol should work well in both roaming and 
>   > fixed environments. In a fixed environment, I think SLP 
>   > might not be a bad choice, but I am not sure with respect 
>   > to a roaming environment:
>   > 
>   > a) Overhead and delay:
>   > 
>   > - First of all, SLP WILL require more messaging, bandwidth 
>   > and - most importantly - yield more delay, than for example DHCP.
>   > 
>   > b) Confidentiality of Network and Services:
>   > 
>   > - Un-authenticated hosts should not be able to discover 
>   > services on the network, apart from perhaps the PANA 
>   > authentication service. If SLP is to be used, it MUST be 
>   > able to securely distinguish between authenticated and 
>   > un-authenticated hosts. Do you think it would be a good 
>   > solution to require PAAs being co-located with SAs/DAs?Are 
>   > there other ways to solve this problem?
>   > 
>   > c) Denial-of-Service and other security attacks:
>   > 
>   > - Un-authenticated hosts should get as little access to the 
>   > network as possible to prevent them from consuming network 
>   > resources and launching DoS attacks. The more the access 
>   > network is opened, the more it will be exposed. Since there 
>   > is no way to secure SLP as far as UAs of roaming hosts are 
>   > concerned, would not SLP be easily exposed to DoS attacks? 
>   > I expect flooding attacks, malicious nodes posing as DAs, 
>   > and so forth, would be hard to prevent? (Moreover, allowing 
>   > un-authenticated hosts to multicast may also be ruled out 
>   > by the same argument...?)
>   > 
>   > Due to 1), I would like to add SLP into the draft, but I 
>   > have not yet had time to look into the problems in 4). 
>   > 
>   > Some directions - "directly from the horse's mouth" - on 
>   > how you see SLP being used in the PANA environment would be 
>   > more than welcome!!!
>   > 
>   > Paal
>   > 
>   > 
>   > > 
>   > > Fra: "James Kempf" <[email-masked]>
>   > > Dato: 2002/02/02 Sat AM 12:29:55 CET
>   > > Til: "George Tsirtsis" <[email-masked]>,  
>   > <[email-masked]>
>   > > Tema: Re: PAA Discovery
>   > > 
>   > > George,
>   > > 
>   > > There are 4 suggested mechanisms, two use DHCP, two use router
>   > > advertisements. It's the latter two
>   > > I am complaining about. Router advertisements are not the 
>   > place to put
>   > > service discovery information.
>   > > 
>   > >             jak
>   > > 
>   > > 
>   > > ----- Original Message -----
>   > > From: "George Tsirtsis" <[email-masked]>
>   > > To: "'James Kempf'" <[email-masked]>;
>   > > <[email-masked]>
>   > > Sent: Friday, February 01, 2002 2:53 PM
>   > > Subject: RE: PAA Discovery
>   > > 
>   > > 
>   > > > James,
>   > > >
>   > > > Did you look at Paal's draft at all? He is actually discussing a
>   > > couple of
>   > > > ways including one based on DHCP....but as he says he 
>   > is missing SLP
>   > > which
>   > > > may also be considered.
>   > > >
>   > > > I think you are correct about the fact that there is no 
>   > need for yet
>   > > another
>   > > > protocol ...an extension of something that already 
>   > exists should do
>   > > the
>   > > > trick, I also think Paal will agree with this statement 
>   > since his
>   > > draft does
>   > > > not discuss any "new" approaches...just extensions.
>   > > >
>   > > > George
>   > > > -----Original Message-----
>   > > > From: James Kempf [mailto:[email-masked]]
>   > > > Sent: Friday, February 01, 2002 10:12 PM
>   > > > To: Paal Engelstad; [email-masked]
>   > > > Subject: Re: PAA Discovery
>   > > >
>   > > >
>   > > > > I recently submitted a draft proposing a mechanism 
>   > for discovering
>   > > > IP-addresses of PAAs. It is a lightweight and straightforeward
>   > > solution
>   > > > based on extensions to RAs and/or to DHCP messages.
>   > > > >
>   > > > > There are naturally other alternatives:
>   > > > > More heavyweight discovery: SLP
>   > > >
>   > > > I'll dispute this assertion. The SLP implementers group 
>   > is currently
>   > > > working to take SLP to draft standard and has 
>   > eliminated a number of
>   > > > mechanisms that were either not implemented or were 
>   > deemed to be too
>   > > > heavyweight.
>   > > > Check draft-guttman-rfc2608bis-01.txt.
>   > > >
>   > > > Furthermore, I would like to argue strongly against a 
>   > "roll your own"
>   > > > discovery technique approach. If you
>   > > > don't like SLP try:
>   > > >
>   > > > 1) DHCP
>   > > >
>   > > > 2) DNS/mDNS
>   > > >
>   > > > 3) LDAP
>   > > >
>   > > > Unless you are talking about something like routing, there is
>   > > absolutely
>   > > > no reason to come up with
>   > > > a new discovery technique. I've spent the last two 
>   > years going around
>   > > to
>   > > > working groups who
>   > > > argue that their protocol is so "different" and 
>   > "unique" that they
>   > > must
>   > > > invent a new discovery protocol.
>   > > > The problem with this is that it is another special, 
>   > one off discovery
>   > > > protocol that must be administered
>   > > > Not only that, but somebody has to implement the tools 
>   > to administer
>   > > the
>   > > > discovery protocol. Imagine what it would be like if 
>   > every WG decided
>   > > > they wanted to implement their own transport protocol, 
>   > or name service
>   > > > protocol, or <pick a currently used protocol for a standard
>   > > architecural
>   > > > element>. Unfortunately, the IAB/IESG hasn't yet seen
>   > > > fit to try to enforce architectural consistency on 
>   > service discovery,
>   > > > since it is in some sense, not
>   > > > perceived as a serious enough problem. But for the 
>   > people who have to
>   > > > implement the tools and
>   > > > administer it, it sure enough is.
>   > > >
>   > > > We don't need a special purpose discovery protocol for 
>   > PANA, let's
>   > > just
>   > > > figure out what the right existing protocol is and how 
>   > to use that.
>   > > >
>   > > >                 jak
>   > > >
>   > > >
>   > > >
>   > > 
>   > > 
>   > 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 10:00:31 -0800

> James did not only say we should not use extensions to RA. If I
understood his comment correctly we should also refrain from developping
protocol-specific mechanisms.  I expect this warning includes most of
the transport mechansms. Did I understand you correctly, James?

Yes, that is correct.

> - Perhaps with exception of Anicasted Authentication request?

If someone wants to propose an anycast mechanism, then I think they
better be able to make a good case for it.
It is another protocol-specific method.

> I am still concerned with the security aspects of the remaining
alternatives; SLP, DNS, and DHCP. I assume that security aspects will be
especially important criteria for PANA.

I'm still not clear why there are any additional security problems here
beyond those involved in using EAP
over PPP or 802.1x. Actually, it seems like the security would be better
since a preconfigured IPSEC
security association could kick in as soon as the IP traffic with the
PAA came up. Naturally, if such
a SA didn't exist, it becomes more tricky.

            jak