Section 18.1.2 of RFC 3315 (DHCPv6 spec) says:
Whenever a client may have moved to a new link, the prefixes from the
addresses assigned to the interfaces on that link may no longer be
appropriate for the link to which the client is attached. Examples
of times when a client may have moved to a new link include:
o The client reboots.
o The client is physically connected to a wired connection.
o The client returns from sleep mode.
o The client using a wireless technology changes access points.
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs assigned to the interface that may have moved to a
new link, along with the addresses associated with those IAs, in its
Confirm message. Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.
So, it seems as if DHCP already defines a DNA procedure. We have been so
focussed on stateless address configuration that we seem to have lost track
of this case.
Since an important goal is to reduce the signaling volume upon link change,
the first question is: could a host eliminate the DNA procedure that we're
trying to define in favor of DHCP's DNA procedure? The problem is that the
host cannot know a priori whether the new link supports stateful address
configuration or not. Thus, if the host used DHCP's DNA procedure and it has
moved from a statefully configured link to a statelessly configured one, it
may not get back a reply because there is no DHCP server on the link. So it
seems as if the DNA procedure we're defining is in some sense more generic
since the RA will definitively indicate if the link is statefully configured
and therefore should be done in any case.
Given that, the next question is why should a host have to do a DHCP CONFIRM
if the RA comes back as "no, you have not moved"? If a DHCP assigned address
was valid on the previous access point, should it be valid on the current
one if the two are on the same IP link? The only reason I can think not is
that the host went down for some long period of time and came up after the
lease expired. In that case, it should perform DHCP reconfiguration anyway.
If the RA comes back "yes, you have changed link" then the host must perform
a new DHCP configuration anyway, so there's no point in doing the CONFIRM.
My conclusion from this is that the DHCP procedure is redundant and
unnecessary in a host that implements DNA.
Should we put something to this effect into the spec? Thoughts? Have I
missed something?
jak
Jim - Your conclusion (DHCP DNA is redundant) is correct if we can assume routers are (in a sense) guranteed to be present on the link, while DHCP servers are not. Which IMHO is a reasonable assumption. But, even if routers are present on the link, is it true that they WILL respond with RA messages. My read of the AdvSendAdvertisements flag in 2461 seems to imply that you could configure routers to not send any RA messages. Also, in 2462, section 4: there is a line that 'If no routers are present, stateful autoconfiguration should be invoked.' Combining these two lines (my interpretation of them), its not clear to me that RA message WILL always be available to answer your question, so I don't know if our DNA solution is more generic. We should probably say something to extent of, if your current address is a stateful address, send DHCP CONFIRM to do DNA, and if your current address is a stateless address, do DNAv6 solution. If no responses for your message, try the other. I don't know - just thinking out loud. Or, do you think it is reasonable to assume routers will be configured to respond with RA messages? If that is the case, we can conclude DHCP DNA is redundant. thanks, Sathya
James Kempf wrote: > My conclusion from this is that the DHCP procedure is redundant and > unnecessary in a host that implements DNA. Agreed. The only odd case (which RFC 2461 does not prohibit) is when the routers don't advertise any prefixes, in which case DHCP confirm would work but not what we've proposed. But I think nobody would operate a network that way. But mentioning this and saying "nobody does that" might be good for completeness. > Should we put something to this effect into the spec? Thoughts? Have I > missed something? Yes, we need to say something both for the BCP/CPL and the solution. Erik
Erik Nordmark wrote: > James Kempf wrote: > >> My conclusion from this is that the DHCP procedure is redundant and >> unnecessary in a host that implements DNA. > > > > Agreed. > The only odd case (which RFC 2461 does not prohibit) is when the routers don't advertise any prefixes, in which case DHCP confirm would work but not what we've proposed. But I think nobody would operate a network that way. But mentioning this and saying "nobody does that" might be good for completeness. We could also say this in the 'routers-bcp' - that atleast one router on the link must be configured to do router advertisements. Sathya
Yes, I think we need to do that. I think we also ought to have something in
the protocol spec mentioning that:
- routers need to be configured to advertise with prefixes
- if stateful addrconf is done, then the CONFIRM need not be done when DNA
is used.
Also, RFC 3315 doesn't let the CONFIRM be turned off, I think maybe we also
ought to talk with Ralph about it. I think RFC 3315 is still PS so there
might be an opportunity to introduce a configuration variable to turn it off
if DNA is used.
jak
----- Original Message -----
From: "Sathya Narayanan" <sathya@research.panasonic.com>
To: "Erik Nordmark" <erik.nordmark@sun.com>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au>
Sent: Thursday, May 19, 2005 11:47 AM
Subject: Re: [DNA-DT] DHCPv6 CONFIRM
>> Erik Nordmark wrote:
>>
>
>>> > James Kempf wrote:
>>> >
>>
>>>> >> My conclusion from this is that the DHCP procedure is redundant and
>>>> >> unnecessary in a host that implements DNA.
>>
>>> >
>>> >
>>> > Agreed.
>>> > The only odd case (which RFC 2461 does not prohibit) is when the
>>> > routers don't advertise any prefixes, in which case DHCP confirm would
>>> > work but not what we've proposed. But I think nobody would operate a
>>> > network that way. But mentioning this and saying "nobody does that"
>>> > might be good for completeness.
>
>>
>> We could also say this in the 'routers-bcp' - that atleast one router on
>> the link must be configured to do router advertisements.
>>
>> Sathya
Dear James >> Since an important goal is to reduce the signaling volume upon link change, >> the first question is: could a host eliminate the DNA procedure that we're >> trying to define in favor of DHCP's DNA procedure? The problem is that the >> host cannot know a priori whether the new link supports stateful address >> configuration or not. Thus, if the host used DHCP's DNA procedure and it has >> moved from a statefully configured link to a statelessly configured one, it >> may not get back a reply because there is no DHCP server on the link. So it >> seems as if the DNA procedure we're defining is in some sense more generic >> since the RA will definitively indicate if the link is statefully configured >> and therefore should be done in any case. Our DNA procedure will be much faster. In the example you gave, I expect that handoff delay would be the magnitude of seconds. Also, while DHCP only verifies the existing IP address, the DNA procedure also provides other IP configuration information, such as default router address. >> My conclusion from this is that the DHCP procedure is redundant and >> unnecessary in a host that implements DNA. agree. >> Yes, I think we need to do that. I think we also ought to have something in >> the protocol spec mentioning that: >> >> - routers need to be configured to advertise with prefixes >> - if stateful addrconf is done, then the CONFIRM need not be done when DNA >> is used. >> >> Also, RFC 3315 doesn't let the CONFIRM be turned off, I think maybe we also >> ought to talk with Ralph about it. I think RFC 3315 is still PS so there >> might be an opportunity to introduce a configuration variable to turn it off >> if DNA is used. ok. Best Regards JinHyeock
>-----Original Message----- >> From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >> dt@ecselists.eng.monash.edu.au] On Behalf Of Erik Nordmark >> Sent: 19. toukokuuta 2005 21:12 >> To: James Kempf >> Cc: dna-dt@eng.monash.edu.au >> Subject: Re: [DNA-DT] DHCPv6 CONFIRM >> >> James Kempf wrote: >> > >>> > My conclusion from this is that the DHCP procedure is redundant and >>> > unnecessary in a host that implements DNA. > >> >> Agreed. >> The only odd case (which RFC 2461 does not prohibit) is when the routers >> don't advertise any prefixes, in which case DHCP confirm would work but >> not what we've proposed. But I think nobody would operate a network that >> way. But mentioning this and saying "nobody does that" might be good for >> completeness. True. It also sounds to me a little weird to have networks without routers advertising prefixes. However, is there a special need to have RAs (DNA excluded) if stateful autoconfiguration is applied? Tero >> Erik
>-----Original Message----- >> From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >> dt@ecselists.eng.monash.edu.au] On Behalf Of Tero Kauppinen (JO/LMF) >> Sent: 20. toukokuuta 2005 12:26 >> To: dna-dt@eng.monash.edu.au >> Subject: RE: [DNA-DT] DHCPv6 CONFIRM >> > >>> > -----Original Message----- >>> > From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >>> > dt@ecselists.eng.monash.edu.au] On Behalf Of Erik Nordmark >>> > Sent: 19. toukokuuta 2005 21:12 >>> > To: James Kempf >>> > Cc: dna-dt@eng.monash.edu.au >>> > Subject: Re: [DNA-DT] DHCPv6 CONFIRM >>> > >>> > James Kempf wrote: >>> > >> >>>> > > My conclusion from this is that the DHCP procedure is redundant and >>>> > > unnecessary in a host that implements DNA. >> >>> > >>> > Agreed. >>> > The only odd case (which RFC 2461 does not prohibit) is when the > >> routers > >>> > don't advertise any prefixes, in which case DHCP confirm would work > >> but > >>> > not what we've proposed. But I think nobody would operate a network > >> that > >>> > way. But mentioning this and saying "nobody does that" might be good > >> for > >>> > completeness. > >> >> True. It also sounds to me a little weird to have networks without >> routers advertising prefixes. However, is there a special need to have >> RAs (DNA excluded) if stateful autoconfiguration is applied? Found this on an MS web :) page (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ ServerHelp/5a528933-a78d-4588-8aa1-b158957ba2d5.mspx): "Included in the Router Advertisement message is an indication of whether a stateful address configuration protocol should be used." and "If no Router Advertisement messages are received, then the host uses a stateful address configuration protocol to obtain addresses and other configuration parameters." So maybe my question should be if stateful autoconfiguration is applied, is there a special need to include prefixes in RAs (DNA excluded)? In the case of stateless DHCPv6 indeed, but with stateful DHCPv6 I don't know why. Tero
>-----Original Message----- >> From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >> dt@ecselists.eng.monash.edu.au] On Behalf Of Tero Kauppinen (JO/LMF) >> Sent: 20. toukokuuta 2005 12:26 >> To: dna-dt@eng.monash.edu.au >> Subject: RE: [DNA-DT] DHCPv6 CONFIRM >> > >>> > -----Original Message----- >>> > From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >>> > dt@ecselists.eng.monash.edu.au] On Behalf Of Erik Nordmark >>> > Sent: 19. toukokuuta 2005 21:12 >>> > To: James Kempf >>> > Cc: dna-dt@eng.monash.edu.au >>> > Subject: Re: [DNA-DT] DHCPv6 CONFIRM >>> > >>> > James Kempf wrote: >>> > >> >>>> > > My conclusion from this is that the DHCP procedure is redundant and >>>> > > unnecessary in a host that implements DNA. >> >>> > >>> > Agreed. >>> > The only odd case (which RFC 2461 does not prohibit) is when the > >> routers > >>> > don't advertise any prefixes, in which case DHCP confirm would work > >> but > >>> > not what we've proposed. But I think nobody would operate a network > >> that > >>> > way. But mentioning this and saying "nobody does that" might be good > >> for > >>> > completeness. > >> >> True. It also sounds to me a little weird to have networks without >> routers advertising prefixes. However, is there a special need to have >> RAs (DNA excluded) if stateful autoconfiguration is applied? Found this on an MS web :) page (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ ServerHelp/5a528933-a78d-4588-8aa1-b158957ba2d5.mspx): "Included in the Router Advertisement message is an indication of whether a stateful address configuration protocol should be used." and "If no Router Advertisement messages are received, then the host uses a stateful address configuration protocol to obtain addresses and other configuration parameters." So maybe my question should be if stateful autoconfiguration is applied, is there a special need to include prefixes in RAs (DNA excluded)? In the case of stateless DHCPv6 indeed, but with stateful DHCPv6 I don't know why. Tero
>If the routers don't advertise any on-link prefixes, then the hosts will
>> have to send all packets to a router (even when the destination is on
>> the local link). RFC 2461 does have a redirect message which the routers
>> can use in this case to tell a host "the destination is on link - at
>> this L2 address". But for a normal broadcast medium, having the hosts
>> know the on-link prefixes and using NS/NA to find the L2 addresses is
>> more efficient.
>>
Modulo location privacy.
If an attacker knows that another host is on link, then the attacker has a
significant amount of information about the host's location. Exactly how
useful this information is depends on the geography to subnet topology
mapping, and the ability of the attacker to construct that map. If the cells
in the subnet cover a city (or, worse, an entire country as is the case with
DoCoMo's 3G network in Japan), the attacker can't do anything in real time
to harm the victim. On the other hand, if the subnet covers a floor of a
building or a single room, then there is a real risk that an attacker could
harm the victim.
jak
-------- Original Message -------- Date: Mon, 23 May 2005 08:02:39 -0400 From: Ralph Droms <rdroms@cisco.com> Subject: Re: DNAv6 interaction with DHCPv6 In-reply-to: <428E9069.8020206@eng.monash.edu.au> To: Brett Pentland <brett.pentland@eng.monash.edu.au> Cc: dna-dt@eng.monash.edu.au Brett - if I understand the discussion correctly, the application of DNAv6 to DHCP would be to use DNAv6 to replace the Confirm/Reply message. If DNAv6 indicates that the host has moved to a new link, the host would immediately use a Solicit/Advertise/Request/Reply message exchange. In principle, using DNAv6 sounds like a good idea. I have a small concern in that using the RS/RA mechanism for DHCP might require coordination between the DHCP service and the prefix advertisements in routers. I'll have to read the draft more carefully and think about whether there is a scenario in which DNA might give different advice about link attachment than a Confirm/Reply message exchange. - Ralph On Sat, 2005-05-21 at 11:35 +1000, Brett Pentland wrote: > Hello Ralph, > > I'm coordinating the design team for the DNA working group, > and we've just recently submitted a proposal to the group. > Yesterday, James Kempf (on the DT) noticed that Section 18.1.2 > of RFC 3315 has a DNA procedure in it that overlaps with what we are > proposing. We have been discussing it on the DT list and the > discussion can be seen at: > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue017 > > If you have time, do you have any comment on this interaction, > and the best way for us to deal with it? > > The full DNA proposal can be seen at: > > http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-00.txt > > A synopsis of the proposal is: > > - An RS/RA exchange is used for DNA. > - Routers on a link listen to each others' advertisements, and keep > a record of any that they aren't advertising themselves. > - Hosts include a prefix they believe to be on their current link > in a new option (Landmark Option) in the RS. > - The semantic of this is a question: "Is this prefix being advertised > on this link?" > - Routers would normally unicast a response including the Landmark > Option with a yes or no flag to answer the question. > - If it is not possible to send a unicast response, either because of > of insufficient information in the RS, or because of the rate > limiting put in place in the proposal, then the question is > ignored, and a multicast response is scheduled that instead includes > all configured PIOs plus another new option that includes all of the > learned prefixes. > > There is also a procedure to allow an immediate response but that's not > really all that important to the current question. > > It would be great, if you've got time, to hear your thoughts on this > issue. > > Cheers, > Brett.
James Kempf wrote: > Modulo location privacy. > > If an attacker knows that another host is on link, then the attacker has a > significant amount of information about the host's location. Exactly how > useful this information is depends on the geography to subnet topology > mapping, and the ability of the attacker to construct that map. If the cells > in the subnet cover a city (or, worse, an entire country as is the case with > DoCoMo's 3G network in Japan), the attacker can't do anything in real time > to harm the victim. On the other hand, if the subnet covers a floor of a > building or a single room, then there is a real risk that an attacker could > harm the victim. Perhaps I don't understand the privacy point in this context. Let me take an example. Assume A has an address P1::Y. (P1 is a 64 bit prefix.) We assume an attacker somehow knows A's IP address (otherwise I think the issue doesn't exist at all). An attacker is on the link P1 as well (with address P1::X). In this case I don't think it makes much of a difference whether the router advertises P1::/64 as on-link or not; even if it doesn't the attacker can presumably that since it's been assigned P1::X as its own address (stateless or DHCP), that all of that /64 is on-link. While a host shouldn't make that assumption, an attacker can operate differently than a normal host. Erik
>Perhaps I don't understand the privacy point in this context.
>>
>> Let me take an example. Assume A has an address P1::Y. (P1 is a 64 bit
>> prefix.)
>>
>> We assume an attacker somehow knows A's IP address (otherwise I think
>> the issue doesn't exist at all).
>> An attacker is on the link P1 as well (with address P1::X).
>>
>> In this case I don't think it makes much of a difference whether the
>> router advertises P1::/64 as on-link or not; even if it doesn't the
>> attacker can presumably that since it's been assigned P1::X as its own
>> address (stateless or DHCP), that all of that /64 is on-link.
>> While a host shouldn't make that assumption, an attacker can operate
>> differently than a normal host.
>>
It sounds like what you are saying is that the attacker will simply assume
that the victim is on link if the address prefix is the same, regardless of
whether the on-link flag is set or not. And that the address will be on link
regardless, right?
So, in that case, what use is the on-link flag? If a host can deduce that
another is on link by simply looking at the prefix, the flag really doesn't
provide any additional functionality.
jak
James Kempf wrote: >> While a host shouldn't make that assumption, an attacker can operate >> differently than a normal host. >> > > > It sounds like what you are saying is that the attacker will simply assume > that the victim is on link if the address prefix is the same, regardless of > whether the on-link flag is set or not. And that the address will be on link > regardless, right? Most likely it will be on-link, at least the way folks are allocating IPv6 subnets today (with /64 prefixes etc) > So, in that case, what use is the on-link flag? If a host can deduce that > another is on link by simply looking at the prefix, the flag really doesn't > provide any additional functionality. See first quoted sentence above. Expanding on it: An attacker can try various things and see if it is successful. For instance, today with IPv4 viral attackers try everything in the same /16 to see if they can infect some other host. So it isn't unreasonable that an IPv6 attacker would try with the assumption that something in the same /64 is on the same link. But we want a (non-attacker) host to follow rules that work; not have to try various invalid assumptions. Erik
| Topic DNASoln1Issue017 . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More } |
|
Revision r1.4 - 24 May 2005 - 00:05 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |