Subject: [Mip6] WGLC: Review of draft-ietf-mip6-bootstrapping-integrated-dhc-02

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 2 Mar 2007 02:17:30 -0800

Hi,
Some comments on the draft:

1. The title of the document should be changed to reflect the real
solution provided - something along the lines of "Dynamic MIP6 Home
Agent Discovery using AAA and DHCP" would be more appropriate. The
current title seems to indicate that the document is providing a
complete MIP6 bootstrapping solution, which is not the case. Also, this
solution does not function without AAA, hence, it is not a solution that
employs DHCP alone. 

2. The assumptions made by this solution must be stated in a separate
section (perhaps under introduction?). I think Kilian had a reasonable
list in one of his emails. The assumptions are currently scattered
throughout the document and this is not entirely clear. So, collectively
listing that would be good. 

3. The method by which the DHCP Relay maintains the mapping of the Home
Agent and corresponding mobile node is unclear. At the end of network
access authentication, it is assumed that the HA address is sent to the
NAS/DHCP Relay. Subsequently, when the MN attempts to use DHCP to obtain
the HA address, the Relay agent must be able to associate the incoming
request with the appropriate HA that was assigned. There is no
assumption on the client ID used in the DHCP message to be of any use in
this respect and that makes sense. However, the use of a link layer
address to maintain such a mapping is problematic. For one, link layer
addresses may be easily spoofed, causing the wrong HA address to be sent
to the MN. Further, link visibility at the NAS, while feasible
sometimes, may not be always available. 

4. The security considerations section is confusing to me. In
particular: 

   - The first paragraph states "No new security considerations are
imposed by the usage of this document.  The security mechanisms provided
by [RFC2865] and [RFC3588] are applicable and provide adequate security
for this purpose." This indicates that the requirements for AAA
transport security are the same as that for MIP6 HA discovery. This is
not quite true - depending on what information is transported in AAA and
the sensitivity of it, the requirements are different. For instance,
keys transported using AAA will need to be encrypted and integrity
protected, while, HA information may only need integrity protection.
Hence, first stating the requirements and then stating that RADIUS
and/or Diameter security is sufficient would be good. 

   - The next paragraph states "The communication between the NAS/DHCP
relay agent to the DHCP server must be authenticated, integrity and
replay protected.  Deployments MAY either rely on lower-layer security,
(i.e., physical or link layer security), or rely on security mechanisms
specifically defined for DHCPv6, such as [RFC4030]." The first sentence
seems to be inconsistent with the next one. For one, it is necessary to
state if the protection needed is end-to-end between the relay agent and
the server. Next, I don't see how physical security can provide
authentication or replay protection. 

   - The following paragraph states a similar requirement between the
DHCP client and server. But then it goes on to say that either
link-layer security or DHCP security may be used. Link-layer security in
this case, is incapable of providing the stated security "between the
DHCP client and server". It would only provide the security between the
client and the access enforcement point. Also, I'm not sure what it
means to say that such security is "required". For instance, if a
particular technology decided to use no message authentication at the
link layer, can this method of bootstrapping not be used? I don't think
that is the intention, but, it needs to be clarified. 

   - The next paragraph states, "An adversary that is able to modify
home agent information can force the mobile node to use a different home
agent than intended by the MSA.  However, this type of attack can be
detected by the security mechanism between the mobile node and the home
agent." I'm not sure how this attack is detectable by the security
mechanism between the MN and HA - it may be detectable if IKEv2 PSKs are
used between the MN and HA. If IKEv2 with EAP is used, as long as the HA
is able to act as an EAP authenticator and get the MN authenticated via
the AAA server and obtain an MSK, it doesn't seem to be detectable. In
that case, the AAA server wouldn't be able to tell the difference
between this and any other EAP exchange. It is then only detectable if
the AAA server policy prevents use of that HA as an authenticator. 

   - The section currently states, "If the home agent selected by the
mobile node is local or nearby, (as in section 3.2.2), disclosing the
mobile node's home address (e.g., by updating the mobile node's FQDN in
the DNS) has the potential to expose some information about the mobile
node's location." I don't understand the intended implication here. How
is this different from an HA in the MSP performing the DNS update? 

   - The next paragraph states, "...For instance, if an attacker knows
that the mobile node's home agent selection policy is to bootstrap with
a new local home agent whenever entering a new network (e.g., because
the mobile node wants to improve routing efficiency in Bi-directional
Tunneling mode), the attacker can track the mobile node's movement if it
is aware of the mobile node's current home addresses." The MN's movement
is tracked by the attacker using what? The HoAs are changing with every
new HA in every local network. If anything, this should make tracking
the MN more difficult. I don't follow the discussion in that paragraph
or the conclusion. 

   - Finally, the last paragraph states, "Consequently, if a high level
of location privacy is desired, a mobile node should not switch to local
home agents in an eager manner or should not reveal its home address to
untrusted nodes. Furthermore, the disclosure of policy information that
can help locating the mobile node should be carefully considered." Given
that this is first discussion of privacy in the document, what does
"high level of location privacy" mean? If there is such a thing, what is
then a "lower level of location privacy" and how is that achieved?
Further, it is not clear as to what element of privacy is needed or
which elements the privacy is needed from. This text is recommending
against using local home agents - is this to provide privacy from the
local network? If this is only about providing privacy from
correspondent and other observing nodes, I don't understand the
difference made by local or remote HAs. Also, I don't follow the
disclosure of policy information - this document is only discussing HA
bootstrapping; is there such policy information that may be disclosed
leading to this privacy concern? 

5. I noticed a discussion based on Kilian's comments to include the HoA
allocation via DHCP as a possible option. If we decide to include that,
it would be important to talk about how that HoA gets tied to the SA
created between the MN and HA. If the HoA is assinged via IKEv2, IKEv2
takes care of such a binding. If not, we need to describe how the
address is bound to the SA. The use of DHCP to assign anything requiring
particular security values is tricky to handle and I suggest that we
don't get into that in this draft. 

6. In general, a number of the security considerations revolving around
packet modification attacks apply equally to the DHCP and DNS solutions.
However, in the DNS case, the use of DNSSEC between the DNS client and
server is the only thing needed to ensure protection against such
attacks. In this case, the security solution needed relies on several
transitive trust relationships - trust between AAA parties, DHCP Relay
Agent and Server, and DHCP client and server. This is not unreasonable,
but, probably worth mentioning. 

Thanks,
Vidya

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 2 Mar 2007 13:25:59 +0200

Hi Vidya,

Thank you for the review and feedback.

> solution does not function without AAA, hence, it is not a solution that

The complete solution also includes IKEv2.
So, either we should state all components of the solution in the title, or
none. I think "none" is better, along the lines of what we did for the split
scenario.

> listing that would be good.

Good idea.

> sometimes, may not be always available.

This is a generic issue with the RFC4014, which we are simply using not
defining. We can discuss this on a separate thread in DHC mailing list if
you like.

> and/or Diameter security is sufficient would be good.

Good idea.

> seems to be inconsistent with the next one. 

You are right. It should read "MUST", not "MAY".

> For one, it is necessary to
> the server. 

Yes it is. And we can state that.

> Next, I don't see how physical security can provide

I don't think use of RFC 4030 is mandatory. Deployments are free to use
physical security instead of RFC 4030. This, again, is not a specific issue
for our I-D. If you like, we can discuss this under another thread.

> that is the intention, but, it needs to be clarified.

I think trying to explain DHCP security is getting us into trouble. I would
really want to say in this document "DHCP is secured however it is secured"
:-) People can start discussing DHCP security in general. But that does not
take anything away from the use of DHCP, especially the way we are using --
standard. 

Would you agree we should reduce this whole discussion about DHCP security?

> the AAA server and obtain an MSK, it doesn't seem to be detectable. 

Not "any" HA on the Internet can act as a pass-through authenticator and
talk to the home AAA server of the MN. We shall clarify that in the text.

> In

Yes, and it should. A AAA server would not be passing MSKs to any one how
happens to forward EAP traffic.

> is this different from an HA in the MSP performing the DNS update?

I'd not mind removing this text.

> the MN more difficult. I don't follow the discussion in that paragraph

I think you have a valid point, and I don't mind removing this text.

> leading to this privacy concern?

I personally don't mind removing this text either.

> don't get into that in this draft.

I'll leave this to Kuntal. 

> but, probably worth mentioning.

Sure we can mention that. And that's what RFC 4014 is built upon. We are
simply using that model, not introducing anything new.

Thanks again, these are very useful comments.

Alper

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 2 Mar 2007 13:45:16 +0100

Hi Vidya,

I'll comment on your questions about the location privacy issue
described in the security considerations section, since the text was
provided by James and me. However, the initial text was longer, maybe we
cut too much and need to add some more text again to make the issue
clear. 

I don't agree with removing the text as Alper suggested. IMHO, the text
describes a valid security issue that that implementors should be aware
of and that can be avoided when following the recommendations in the
text. Thus, the text is important IMHO.

The issue is the following:

A HoA anchored at a local HA (henceforth called local HoA) has a prefix
belonging to the access network the MN is currently attached to.
Consequently, a local HoA contains some location information. If any
entity  
1. knows the MN's HoA and 
2. knows that the corresponding HA is currently a *local* HA, 
it can infer the MN's location from the local HoA prefix.

The attacker (any node that is not authorized to get the MN's location)
can get the MN's location if

1. If the attacker can obtain the MN's local HoA, e.g., by monitoring
the DNS entry (in case the MN's DNS entry is always updated after
bootstrapping) or by initiating communication with the MN (if the MN
will use the local HoA for optimized communication) or by eavesdropping
the MN's traffic.

2. If the attacker knows that the HoA obtained in 1 is local. This is
possible under certain circumstances, e.g., when a MN's or an operator's
policy is that the MN shall always try to bootstrap with a local HA when
entering an ASP's network (this may make sense for routing efficiency
reasons) and the attacker is aware of this policy.

See some more comments inline.

> is this different from an HA in the MSP performing the DNS update? 

If a HA is not local, the corrsponding HoA prefix does not contain
location information and the issue described above doesn't exist. Maybe
we should add something like "A local HoA contains location information,
since the prefix is linked to the MN's current access network.".

> the MN more difficult. I don't follow the discussion in that paragraph

If the attacker monitors the DNS entry of the MN and if the DNS entry of
the MN is always updated with a new local HoA after bootstrapping with a
new local HA, the attacker can track the MN's movement to some extent.

> "high level of location privacy" mean? If there is such a 

The "level of location privacy" refers to the granularity of disclosed
location information. For some users it may be acceptable to disclose
the prefix of the current access network, while it is not acceptable to
disclose the current AR. Such "access network-level" of location privacy
can, e.g., be achieved with localized MM, where a MN's MIPv6 CoA is
equal to the MN's PMIP-HoA anchored at a local PMIP-HA. In this case, an
attacker acting as correspondent node could at most learn the MN's
current access network (from the MN's CoA in MIPv6 route optimization
mode).

For other people this "level" of location privacy is not acceptable.
They have stronger requirements on location privacy, where the attacker
cannot figure out the current access network. For instance, some users
don't want that it is possible to find out that they are on a business
trip or on vacation in another country (e.g., to prevent that someone
uses this information for a burglary). This was referred to as "high
level" of location privacy. Maybe we need to add some text about this.

> thing, what is

The policy information refers to the MN's policy to eagerly bootstrap
with a local HA and updating the HoA when entering a new network.

Regards,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 19:13:56 -0800

Hi Alper,
Please see inline.  

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 3:26 AM
> To: Narayanan, Vidya; 'Mobile IPv6 Mailing List'
> Subject: RE: [Mip6] WGLC: Review 
> ofdraft-ietf-mip6-bootstrapping-integrated-dhc-02
> 
> Hi Vidya,
> 
> > complete MIP6 bootstrapping solution, which is not the case. Also, 
> > this solution does not function without AAA, hence, it is not a 
> > solution that employs DHCP alone.
> 
> So, either we should state all components of the solution in 
> the title, or none. I think "none" is better, along the lines 
> of what we did for the split scenario.
> 

It was just a suggestion. I see your point about the split scenario
document also. In a way, both documents could be titled more
appropriately I guess :)

> > throughout the document and this is not entirely clear. So, 
> > collectively listing that would be good.
> 
> Good idea.
> 
> 
> > 
> > 3. The method by which the DHCP Relay maintains the mapping of the 
> > Home Agent and corresponding mobile node is unclear. At the end of 
> > network access authentication, it is assumed that the HA address is 
> > sent to the NAS/DHCP Relay. Subsequently, when the MN 
> attempts to use 
> > DHCP to obtain the HA address, the Relay agent must be able to 
> > associate the incoming request with the appropriate HA that was 
> > assigned. There is no assumption on the client ID used in the DHCP 
> > message to be of any use in this respect and that makes sense. 
> > However, the use of a link layer address to maintain such a 
> mapping is 
> > problematic. For one, link layer addresses may be easily spoofed, 
> > causing the wrong HA address to be sent to the MN. Further, link 
> > visibility at the NAS, while feasible sometimes, may not be 
> always available.
> 
> This is a generic issue with the RFC4014, which we are simply 
> using not defining. We can discuss this on a separate thread 
> in DHC mailing list if you like.
> 

Thanks for the reference here. I quickly scanned RFC4014 and it seems to
have no description of how the attributes received via RADIUS may be
linked with the DHCP request coming from a client. Did I miss it? In any
case, I agree that we need to discuss this in the context of RFC4014,
but, I'm concerned about ambiguity caused by the reference not having
sufficient information. 

> > imposed by the usage of this document.  The security mechanisms 
> > provided by [RFC2865] and [RFC3588] are applicable and provide 
> > adequate security for this purpose." This indicates that the 
> > requirements for AAA transport security are the same as 
> that for MIP6 
> > HA discovery. This is not quite true - depending on what 
> information 
> > is transported in AAA and the sensitivity of it, the 
> requirements are 
> > different. For instance, keys transported using AAA will need to be 
> > encrypted and integrity protected, while, HA information 
> may only need integrity protection.
> > replay protected.  Deployments MAY either rely on lower-layer 
> > security, (i.e., physical or link layer security), or rely 
> on security 
> > mechanisms specifically defined for DHCPv6, such as [RFC4030]." The 
> > first sentence seems to be inconsistent with the next one.
> 
> > state if the protection needed is end-to-end between the 
> relay agent 
> > and the server.
> 
> I don't think use of RFC 4030 is mandatory. Deployments are 
> free to use physical security instead of RFC 4030. This, 
> again, is not a specific issue for our I-D. If you like, we 
> can discuss this under another thread.
> 

Well, if we say that use of RFC4030 is not mandatory, we should then not
be mandating channel security, right? Or, perhaps I am misunderstanding
what you mean by "physical security"...  

> > link-layer security or DHCP security may be used. 
> Link-layer security 
> > in this case, is incapable of providing the stated security 
> "between 
> > the DHCP client and server". It would only provide the security 
> > between the client and the access enforcement point. Also, I'm not 
> > sure what it means to say that such security is "required". For 
> > instance, if a particular technology decided to use no message 
> > authentication at the link layer, can this method of 
> bootstrapping not 
> > be used? I don't think that is the intention, but, it needs 
> to be clarified.
> 
> I think trying to explain DHCP security is getting us into 
> trouble. I would really want to say in this document "DHCP is 
> secured however it is secured"
> :-) People can start discussing DHCP security in general. But 
> that does not take anything away from the use of DHCP, 
> especially the way we are using -- standard. 
> 

More or less, yes :) If the additional information that we want DHCP to
carry is more sensitive compared to the normal DHCP attributes, then, it
is fine to say that DHCP security may or may not be used depending on
the deployment and that is fine. In the case of HA assignment, I think
that is true. So, we should not make a statement that implies that some
kind of security between the DHCP client and server is "required". 

> > home agent information can force the mobile node to use a different 
> > home agent than intended by the MSA.  However, this type of 
> attack can 
> > be detected by the security mechanism between the mobile 
> node and the 
> > home agent." I'm not sure how this attack is detectable by the 
> > security mechanism between the MN and HA - it may be detectable if 
> > IKEv2 PSKs are used between the MN and HA. If IKEv2 with 
> EAP is used, 
> > as long as the HA is able to act as an EAP authenticator 
> and get the 
> > MN authenticated via the AAA server and obtain an MSK, it 
> doesn't seem to be detectable.
> 
> Not "any" HA on the Internet can act as a pass-through 
> authenticator and talk to the home AAA server of the MN. We 
> shall clarify that in the text.
> 

Okay. 

> Yes, and it should. A AAA server would not be passing MSKs to 
> any one how happens to forward EAP traffic.
> 

Yes, but, this would still mean that the AAA server cannot tell the
difference between a HA it explicitly meant to assign and a different HA
that is also allowed to be an EAP authenticator. In other words, there
is no check here to see if the EAP authenticator is the same as the HA
that the AAA meant to assign to the MN. This may lead to the AAA server
assuming that the MN is served by one HA, when, it is really served by a
different HA. 

> > mobile node's home address (e.g., by updating the mobile 
> node's FQDN 
> > in the DNS) has the potential to expose some information about the 
> > mobile node's location." I don't understand the intended 
> implication 
> > here. How is this different from an HA in the MSP 
> performing the DNS update?
> 

That would be fine. 

> > that the mobile node's home agent selection policy is to bootstrap 
> > with a new local home agent whenever entering a new network (e.g., 
> > because the mobile node wants to improve routing efficiency in 
> > Bi-directional Tunneling mode), the attacker can track the mobile 
> > node's movement if it is aware of the mobile node's current home 
> > addresses." The MN's movement is tracked by the attacker 
> using what? 
> > The HoAs are changing with every new HA in every local network. If 
> > anything, this should make tracking the MN more difficult. I don't 
> > follow the discussion in that paragraph or the conclusion.
> 

I would support removing this text - I'll respond to Kilian separately
on this topic. 

> 
> > 
> >    - Finally, the last paragraph states, "Consequently, if a high 
> > level of location privacy is desired, a mobile node should 
> not switch 
> > to local home agents in an eager manner or should not 
> reveal its home 
> > address to untrusted nodes. Furthermore, the disclosure of policy 
> > information that can help locating the mobile node should 
> be carefully 
> > considered." Given that this is first discussion of privacy in the 
> > document, what does "high level of location privacy" mean? 
> If there is 
> > such a thing, what is then a "lower level of location 
> privacy" and how is that achieved?

Again, I'll respond to Kilian on the privacy topic in general... 

> 
> > 
> > 5. I noticed a discussion based on Kilian's comments to include the 
> > HoA allocation via DHCP as a possible option. If we decide 
> to include 
> > that, it would be important to talk about how that HoA gets tied to 
> > the SA created between the MN and HA. If the HoA is assinged via 
> > IKEv2, IKEv2 takes care of such a binding. If not, we need 
> to describe 
> > how the address is bound to the SA. The use of DHCP to 
> assign anything 
> > requiring particular security values is tricky to handle 
> and I suggest 
> > that we don't get into that in this draft.
> 
> > 6. In general, a number of the security considerations revolving 
> > around packet modification attacks apply equally to the 
> DHCP and DNS solutions.
> > Agent and Server, and DHCP client and server. This is not 
> > unreasonable, but, probably worth mentioning.
> 
> Sure we can mention that. And that's what RFC 4014 is built 
> upon. We are simply using that model, not introducing anything new.
> 

Agreed. 

Thanks,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 19:30:57 -0800

Hi Kilian,
I must say that I'm still confused :) Specifically,
 
1. What privacy are we talking about here and who is the attacker? For
instance, are we talking about privacy of the HoA/CoA from CNs (here, CN
would be the potential attacker)? Or, are we talking about entities on
path between the MN and HA being able to know the HoA-CoA mapping? Or,
are we just generally talking about even an off-path entity being able
to obtain the MN's HoA (say, via DNS or something)? It seems to me like
you are talking about the last one, but, I'm not sure. 

2. Why is an MN that is interested in privacy updating the DNS record
with its HoA? That seems counter-intuitive to me. Updating DNS with an
address is as good as publishing the address on a public website (or an
intranet, when DNSSEC is used) :) So, it sounds to me like if an MN
wants to keep its HoA location private, it would not be updating the DNS
record with its HoA. Or, if the MN needs to get its DNS record updated
and if the MN's policy is to get a local HA for optimal routing, the MN
is clearly not interested in such privacy. Alternately, if the operator
policy is to assign a local HA, the MN must either choose to not publish
its HoA using DNS (if it wants such privacy) or accept that there is no
privacy. It simply cannot be both ways :) 

3. If you meant any disclosure of HoA/CoA mapping to entities, that is a
problem that is unrelated to any DNS updates. However, such a problem
exists regardless of the HA location, since the CoA is the one that
really discloses the current location of the MN and that topologically
identifies the location irrespective of where the HoA is anchored. 

Thanks,
Vidya

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 4:45 AM
> To: Narayanan, Vidya
> Cc: Mobile IPv6 Mailing List; Alper Yegin
> I'll comment on your questions about the location privacy 
> issue described in the security considerations section, since 
> the text was provided by James and me. However, the initial 
> text was longer, maybe we cut too much and need to add some 
> more text again to make the issue clear. 
> 
> I don't agree with removing the text as Alper suggested. 
> IMHO, the text describes a valid security issue that that 
> implementors should be aware of and that can be avoided when 
> following the recommendations in the text. Thus, the text is 
> important IMHO.
> 
> A HoA anchored at a local HA (henceforth called local HoA) 
> has a prefix belonging to the access network the MN is 
> currently attached to.
> Consequently, a local HoA contains some location information. 
> If any entity 1. knows the MN's HoA and 2. knows that the 
> corresponding HA is currently a *local* HA, it can infer the 
> MN's location from the local HoA prefix.
> 
> The attacker (any node that is not authorized to get the MN's 
> location) can get the MN's location if
> 
> 1. If the attacker can obtain the MN's local HoA, e.g., by 
> monitoring the DNS entry (in case the MN's DNS entry is 
> always updated after
> bootstrapping) or by initiating communication with the MN (if 
> the MN will use the local HoA for optimized communication) or 
> by eavesdropping the MN's traffic.
> 
> 2. If the attacker knows that the HoA obtained in 1 is local. 
> This is possible under certain circumstances, e.g., when a 
> MN's or an operator's policy is that the MN shall always try 
> to bootstrap with a local HA when entering an ASP's network 
> (this may make sense for routing efficiency
> If a HA is not local, the corrsponding HoA prefix does not 
> contain location information and the issue described above 
> doesn't exist. Maybe we should add something like "A local 
> HoA contains location information, since the prefix is linked 
> to the MN's current access network.".
> 
> > 
> If the attacker monitors the DNS entry of the MN and if the 
> DNS entry of the MN is always updated with a new local HoA 
> after bootstrapping with a new local HA, the attacker can 
> track the MN's movement to some extent.
> 
> > 
> > such a
> The "level of location privacy" refers to the granularity of 
> disclosed location information. For some users it may be 
> acceptable to disclose the prefix of the current access 
> network, while it is not acceptable to disclose the current 
> AR. Such "access network-level" of location privacy can, 
> e.g., be achieved with localized MM, where a MN's MIPv6 CoA 
> is equal to the MN's PMIP-HoA anchored at a local PMIP-HA. In 
> this case, an attacker acting as correspondent node could at 
> most learn the MN's current access network (from the MN's CoA 
> in MIPv6 route optimization mode).
> 
> They have stronger requirements on location privacy, where 
> the attacker cannot figure out the current access network. 
> For instance, some users don't want that it is possible to 
> find out that they are on a business trip or on vacation in 
> another country (e.g., to prevent that someone uses this 
> information for a burglary). This was referred to as "high 
> The policy information refers to the MN's policy to eagerly 
> bootstrap with a local HA and updating the HoA when entering 
> a new network.
> 
> Regards,
> 
> Kilian
> 
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 6 Mar 2007 16:52:29 +0100

Hi Vidya, 

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Dienstag, 6. März 2007 04:31
> To: Kilian Weniger

There are multiple possible scenarios. The point is that the attacker only needs to know the MN's HoA (as opposed to the CoA) to find out the MN's location, if the MN uses a local HA and the attacker knows that. This is especially a problem, since the attacker can be off-path. Such attacker can learn the local HoA by monitoring the MN's DNS entry (assuming the MN updates DNS with its local HoA) or by acting as CN, e.g., by initiating a SIP session with the MN. An on-path attacker could find out the HoA by eavesdropping the traffic. 

Of course, the attacker must additionally be able to associate the learned HoA (which is typically dynamically assigned to the MN) with a specific MN, i.e., it must know an associated identity. This may, e.g., be possible:
- with the FQDN for the scenario where the attacker monitors the MN's DNS entry and the MN updates its DNS entry with a local HoA 
- with information from higher layers (e.g., SIP URI, voice/answering machine in case of voice call, etc) for the scenario where the attacker acts as CN (or eavesdrops the traffic to/from the MN).

> its HoA using DNS (if it wants such privacy) or accept that 

This is exactly what the text in the security section is about. The purpose of the text is to raise awareness of the privacy issue that a local HoA contains location information (as opposed to a HoA that is non-local, which is the typical case in MIPv6). The text basically recommends that, if location privacy is required by the MN, the MN should either not reveal the local HoA (i.e., no DNS updates for local HoA and not use a local HoA for sessions with untrusted CNs) or hide the fact that the HoA is local. The latter may be out of control of the MN, e.g., if local HA assignment is enforced by the operator's policy.

> privacy. It simply cannot be both ways :) 

Right. With the current mechanisms, a MN basically has to choose between optimized routing and location privacy. Mobopts is working on solutions to achieve both simultaneously.

> identifies the location irrespective of where the HoA is anchored. 

I agree, but the problem of disclosing the HoA/CoA mapping (e.g., in MIPv6 route optimization mode) is not related to this specific issue. The privacy issue I was talking about is due to a HoA that contains location information, and that is only the case for a local HoA.

Hope this resolves the confusion.

Regards,

Kilian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Mar 2007 16:22:30 -0800

> > difference between a HA it explicitly meant to assign and a 
> different 
> > HA that is also allowed to be an EAP authenticator. In other words, 
> > there is no check here to see if the EAP authenticator is 
> the same as 
> > the HA that the AAA meant to assign to the MN. This may lead to the 
> > AAA server assuming that the MN is served by one HA, when, it is 
> > really served by a different HA.
> 
> AAA server can check that. It can compare the IP address of 
> the AAA client that forwarded the EAP auth with the IP 
> address of the assigned HA. But....
> this is a bit tricky. The two may not be the same. The AAA 
> server may need to maintain a table matching a HA IP address 
> to one or more AAA client IP address(es). This is doable, if 
> AAA server seeks such a feature.
> 

I agree it is doable, but, tricky :) That is what I was trying to get
at.. So, we can perhaps just add a couple of sentences about this and
leave it at that. 

Vidya

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Mar 2007 01:42:02 +0200

> assuming that the MN is served by one HA, when, it is really served by a

AAA server can check that. It can compare the IP address of the AAA client
that forwarded the EAP auth with the IP address of the assigned HA. But....
this is a bit tricky. The two may not be the same. The AAA server may need
to maintain a table matching a HA IP address to one or more AAA client IP
address(es). This is doable, if AAA server seeks such a feature.

Alper

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 14 Mar 2007 00:10:29 -0400

Hi Kilian, Vidya,

I don't see a convergence on this location privacy issue with local HA assignment. I will mark this as an open issue for now.

-Kuntal

> Sent: Tuesday, March 06, 2007 9:52 AM
> To: Narayanan, Vidya
> Cc: Mobile IPv6 Mailing List
> Subject: RE: [Mip6] WGLC: Reviewofdraft-ietf-mip6-bootstrapping-
> integrated-dhc-02
> 
> Hi Vidya,
> 
> There are multiple possible scenarios. The point is that the attacker only
> needs to know the MN's HoA (as opposed to the CoA) to find out the MN's
> location, if the MN uses a local HA and the attacker knows that. This is
> especially a problem, since the attacker can be off-path. Such attacker
> can learn the local HoA by monitoring the MN's DNS entry (assuming the MN
> updates DNS with its local HoA) or by acting as CN, e.g., by initiating a
> SIP session with the MN. An on-path attacker could find out the HoA by
> eavesdropping the traffic.
> 
> Of course, the attacker must additionally be able to associate the learned
> HoA (which is typically dynamically assigned to the MN) with a specific
> MN, i.e., it must know an associated identity. This may, e.g., be
> possible:
> - with the FQDN for the scenario where the attacker monitors the MN's DNS
> entry and the MN updates its DNS entry with a local HoA
> - with information from higher layers (e.g., SIP URI, voice/answering
> machine in case of voice call, etc) for the scenario where the attacker
> acts as CN (or eavesdrops the traffic to/from the MN).
> 
> >
> This is exactly what the text in the security section is about. The
> purpose of the text is to raise awareness of the privacy issue that a
> local HoA contains location information (as opposed to a HoA that is non-
> local, which is the typical case in MIPv6). The text basically recommends
> that, if location privacy is required by the MN, the MN should either not
> reveal the local HoA (i.e., no DNS updates for local HoA and not use a
> local HoA for sessions with untrusted CNs) or hide the fact that the HoA
> is local. The latter may be out of control of the MN, e.g., if local HA
> assignment is enforced by the operator's policy.
> 
> Right. With the current mechanisms, a MN basically has to choose between
> optimized routing and location privacy. Mobopts is working on solutions to
> achieve both simultaneously.
> 
> >
> I agree, but the problem of disclosing the HoA/CoA mapping (e.g., in MIPv6
> route optimization mode) is not related to this specific issue. The
> privacy issue I was talking about is due to a HoA that contains location
> information, and that is only the case for a local HoA.
>