Subject: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 11 Oct 2005 15:09:34 +0200

Hello Francis,

starting the discussions about your draft:

- Section A.3 lists threats and countermeasures for the DNS-based
procedure if no authentication of the DNS server by the client or of the
client by the server is done. E.g., the IKEv2 transaction with a bogus
HA address (obtained from an attacker during DHAAD) would fail because
the HA has to present a certificate to MN during IKEv2 transaction and
the IKE_AUTH message is protected by an authenticator calculated using
the public key in the certificate. Why are the described countermeasures
not sufficient to secure the bootstrapping procedure if no
authentication of the DNS server by the client or of the client by the
server is done, i.e., why is DNSSEC or TSIG/TKEY additionally needed? 

- Do the same countermeasures also apply to the anycast-based DHAAD? If
so, is the anycast-based DHAAD still considered harmful? Is there an
implicit assumption that it is easier for an attacker to setup a bogus
HA with a certificate which seems trustworthy to the MN than to setup a
bogus DNS server with DNSSEC or TSIG/TKEY which seems trustworthy to the
MN? 

- Assuming that no authentication of the DNS server by the client or of
the client by the server is done, is there any benefit in terms of
security of using the DNS-based procedure instead of using the
anycast-based DHAAD procedure, i.e., are there any threats specific to
the anycast-based procedure?

Assuming that the anycast-based DHAAD procedure is not considered
harmful (I guess the assumption is wrong when I look at the title of
your draft ;), I think one should carefully think about pros and cons of
both procedures, e.g.,

- A benefit of the anycast-based procedure (which is not realted to
security) is that load conditions can faster be considered for load
balancing. Of course, load balancing can also be achieved by other
means, e.g., by informing the MN to bootstrap with another HA after it
has bootstrapped with a heavily loaded HA, but I think one should again
carefully consider pros and cons of such solutions.

- A benefit of the DNS-based solution is that the prefix of the HA does
not need to be pre-configured on the MN. 

One approach to get both benefits would be to combine both solutions,
i.e., the MN obtains the HA prefix from DNS and discovers the HA address
via anycast. In this case it may be beneficial to standardize both
procedures. What do you think?

Regards,

Kilian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Francis Dupont
> Sent: Montag, 10. Oktober 2005 11:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Mip6] Timeslot requests for MIP6 WG agenda at IETF64 
> 
>  In your previous mail you wrote:
> 
>    If you need a timeslot on the MIP6 WG agenda, please send
>    a request to the chairs with the following information:
>    
>    1. I-D title
> 
> => draft-dupont-mip6-dhaadharmful-00.txt
> (to summary current Dynamic Home Agent Address Discovery can be made
> secure so I propose to replace it by the DNS SRV RR of
> draft-ietf-mip6-bootstrapping-split-00.txt).
> 
>    2. Amount of time requested
> 
> => 5 mn of discussion about the idea (adopt or not, if yes how
> to proceed). I strongly suggest to begin on the mailing list.
> 
>    3. Is the I-D within the scope of the WG charter? If not why is it
>    important to discuss this at the WG meeting?
>    
> => current DHAAD is in RFC 3775 so the I-D is in the scope.
> 
> Thanks
> 
> [email-masked]
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Oct 2005 15:16:18 -0700

>From a deployment standpoint, there are two issues with DHAAD:

- it uses ICMP across the Internet. The trend has been to turn off ICMP 
except for local link communications, to avoid convenient vehicles for DoS. 
I know that one can theoretically configure the firewall to filter on the 
ICMP message type field, but it is easier just to drop it at the firewall 
than to try to figure out what ICMP is good and what is bad.

- AFIK, there is no way currently standardized to securely update anycast 
routing except to manually insert host routes into the subnet router 
handling the anycast address. So maintaining an anycast address would 
require extra maintenance effort, manually inserting and deleting the routes 
when HAs are added or deleted.

            jak

----- Original Message ----- 
From: "Kilian Weniger" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 11, 2005 6:09 AM
Subject: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

Hello Francis,

Regards,

Kilian

---

From: Francis Dupont <[email-masked]>
Date: Sun, 16 Oct 2005 22:39:31 +0200

=> in fact I'd like to raise some questions:
 - is a dynamic home agent address discovery mechanism a good thing?
   (I am serious: I know that some people prefer a home agent assignment
    mechanism)
 - is it possible to make the current mechanism secure? (IMHO no but
   any counter-example is wellcome)
 - is the insecurity of the current mechanism enough to phase it out?
   (I am not alone to think so, at least the bootstrap DT shares this
    opinion)
 - is the DNS SRV RR the best candidate to replace the current mechanism?
   (today it is the only candidate... IMHO we can't phase out something
    without proposing a better solution)

=> note that sections A.x are from the bootstrapping I-D so if you'd like
to discuss them for themselves this is not the right place (i.e., right
mailing list but wrong message subject).

   the public key in the certificate.

=> this is an explanation of why the current mechanism is not a security
disaster, not how it is secure.

   Why are the described countermeasures
   not sufficient to secure the bootstrapping procedure if no
   authentication of the DNS server by the client or of the client by the
   server is done, i.e., why is DNSSEC or TSIG/TKEY additionally needed? 
   
=> DNSSEC is needed to make it secure: this provides an extra property,
not necessary but very wellcome.

   - Do the same countermeasures also apply to the anycast-based DHAAD?

=> yes.

   If so, is the anycast-based DHAAD still considered harmful?

=> yes because it can't be made secure, even its intrinsic property is
not a disaster (note that if it was the IESG should have rejected it
before RFC 3775 publication).

   Is there an
   implicit assumption that it is easier for an attacker to setup a bogus
   HA with a certificate which seems trustworthy to the MN

=> everyday experience with SSL/TLS shows certificates are too enough
misused so it is better to have a secure mechanism than a fully insecure
mechanism the results should be checked and never trusted.

   than to setup a bogus DNS server with DNSSEC or TSIG/TKEY which
   seems trustworthy to the MN?
   
=> this is the advantage of DNS over X.500: both are directories but
nobody still argues that X.500 is simpler than DNS. And with DNSSEC
you have still the certificate check.

=> I believe you don't understand DNSSEC (I recommend the intro I-D)

=> yes, DNSSEC is mainly about the authentication of values, not servers.
Both are not possible with anycast.

=> if you don't propose a way to make the anycast-based DHAAD procedure
secure you are simply wasting our time.

=> perhaps but this is a better argument if you apply it to assignment.

   via anycast.

=> this is what is implemented by some of us but operators don't like
the current mechanism: some want to change it for something which can be
made secure, some want to change it for an assignment mechanism. Of course
some are in the middle because assignment won't be available in all cases.

   In this case it may be beneficial to standardize both
   procedures. What do you think?
   
=> two procedures to do the same thing are not the right solution.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Oct 2005 02:45:01 -0700

>    (I am not alone to think so, at least the bootstrap DT shares this

I dont the bootstrap DT ever expressed this opinion. for
running DHAAD, the MN needs to be configured with the home
prefix. we wanted a solution with minimal configuration on
the MN. thats why DNS was picked. not just because DHAAD
is not secure.

I anyway dont have illusions about secure DNS being used.
in most cases the security for DNS based HA lookup and
running DHAAD to obtain a list of home agents might be the
same.

now, back to your discussions. :)

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Oct 2005 10:35:47 +0200

>    (I am not alone to think so, at least the bootstrap DT shares this
   
   I dont the bootstrap DT ever expressed this opinion.

=> not explicitely but there should be a good reason to propose
the DNS SRV RR mechanism.

   for running DHAAD, the MN needs to be configured with the home
   prefix.

=> or with its name as it was proposed first many years ago by
someone working for Digital (then Compaq and now HP).

   we wanted a solution with minimal configuration on
   the MN. thats why DNS was picked. not just because DHAAD
   is not secure.
   
=> this is a minor reason so I believed the security was the main one.

=> I agree secure DNS is today only potential but current DHAAD has
not this potential. And I worked on DNSSEC so I believe in its
future even I understand many don't.

=> IMHO the only strong objection against my proposal can come from
the HA assignment: if someone finds a nice general HA assignment
mechanism any DHAAD will lose interest...

Thanks

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 14:00:25 +0200

Hello to dhaad-harmful contributors and supporters.

James Kempf wrote:

> except for local link communications, to avoid convenient vehicles for
> DoS. I know that one can theoretically configure the firewall to filter
> on the ICMP message type field, but it is easier just to drop it at the
> firewall than to try to figure out what ICMP is good and what is bad.

I think the argument 'some protocol may be blocked by some firewalls'
for considering some protocol harmful and support other protocols
instead, is probably a little bit flawed.

In a sense, the strongest firewalls of some operators block all that is
not HTTP, and I imagine they can even block HTTP-tunnelled traffic.
Which would suggest that only a cleartext HTTP-based HA Discovery may
have the highest chances of getting through.

In another sense, if some operators will open ports (and import SRV
records in their DNS, and provide _full_ DNS service to MNs) because
some IETF Document says so, then the proposed DNS-based HAD scheme may
indeed work and I support its idea.

> - AFIK, there is no way currently standardized to securely update
> anycast routing except to manually insert host routes into the subnet
> router handling the anycast address. So maintaining an anycast address
> would require extra maintenance effort, manually inserting and deleting
> the routes when HAs are added or deleted.

I think the IPsec shortcoming with respect to anycast, and the inability
to securely update anycast routes may not play an important role in
discarding the current DHAAD.

For example, I wonder whether the following normal DHAAD procedure would
be secure enough:

-MN sends DHAAD Request to the anycast address and has SA with that
 anycast address (which is prefix:fdff:ffff:ffff:fffe/128).
-only one HA replies back to MN, IP packet having
 src=prefix:fdff:ffff:ffff:fffe/128
-the HAs communicate with each other with RAs and collaboratively build
 a coherent list of HAs ordered with some priority.

With that scheme I think there is no need to manually insert or delete
routes when HAs are added or deleted.

Would this be secure enough?  Would IPsec allow SAs whose IP address is
an anycast address?

Sorry if I overlook something obvious,

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 14:26:51 +0200

=> unfortunately ICMP is commonly blocked so it is a real operational
issue. Look at draft-davies-v6ops-icmpv6-filtering-bcp-00.txt...

=> BTW DNS is not filtered out.

=> DNS-based HAD scheme has many advantages. For some (including me)
it can be made secure, for some others it is the ICMP filtering, etc...

   > the routes when HAs are added or deleted.
   
=> the routing stuff is in order to make the anycast destination a known
and stable box.

   

=> currently it is not possible to establish a symmetric IPsec SA
pair with an anycast address.

   
   Would this be secure enough?

=> it is a matter of state: an unsecure DHAAD doesn't give a security
disaster...

   Would IPsec allow SAs whose IP address is an anycast address?

=> no because an anycast can't be used as a source address.

=> the two questions are:
 - should we keep a DHAAD mechanism or HA assignment is the right thing
   to do?
 - is the DNS-based DHAAD mechanism better enough to replace the ICMP-base
   one?

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 15:44:23 +0200

> issue. Look at draft-davies-v6ops-icmpv6-filtering-bcp-00.txt...

Thanks, I've looked over the draft.  It provides BCP advice to firewalls
admins as to which ICMPv6 type messages to filter or not, based on an
evaluation of the risks associated with each.

> => BTW DNS is not filtered out.

Well, depends.

In a WiFi deployment, DNS content is filtered (only one IP address is
resolved) prior to payment.  In other WiFi deployment, even after
payment, only the http access is allowed, with a proxy.  In that, the
http proxy performs name resolution for the MN and the MN is not allowed
to perform locally name resolution.  Meaning a DNS-based HAD won't work,
only and http-based HAD would.

Some other operator forces the MN to use a local DNS Server and forbid
the use of a DNS server outside that operator's domain.

I'd go as far as to say that if an operator forces the MN into a local
DNS Server then it may as well force the MN into a local HA as well,
i.e. forbiding the MN to use HAs outside that operator's domain.

I would agree that DNS "is not filtered out" in general but I'd also say
there are many exceptions to that.

> => no because an anycast can't be used as a source address.

And if it could, would the DHAAD be considered as IPsec-secureable?

I imagine that as the HA-anycast address has been reserved, there may be
a possibility to reserve a "HA-discovery" address in the form
prefix:feff:ffff:ffff:fffe that would be an IP address anycast-like but
not quite anycast, such as to be accepted by IPsec.

>  - should we keep a DHAAD mechanism or HA assignment is the right thing

Both ideas have appeal to me.  Both could be supported by some
argumentation.  I have implemented one of them and that's why I tend to
support it (but it won't be the first time I implement something in an
RFC only to see it discarded later :-).

>  - is the DNS-based DHAAD mechanism better enough to replace the ICMP-base

Right, that is a good question.  As presented until now, the DNS-based
seems to have some better aspects than the ICMP-based.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 16:43:52 +0200

Well, depends.
   
   In a WiFi deployment, DNS content is filtered (only one IP address is
   resolved) prior to payment.

=> usually it is only partially filtered because the purpose is to
redirect first HTTP connection, not to make it to fail.

   In other WiFi deployment, even after
   
=> proxy only doesn't work well with HTTPS... and HTTP-based HAD
is not very computer oriented (as HTTP is user oriented).

=> it doesn't matter if the local DNS server is recursive (if it is not
it can't offer an useful service).

=> we speak about Internet service, not on-line services connected
to the Internet, even the Internet service can be pretty bad (spurious
filtering, etc).

=> so this is a disgression, isn't it?

   
=> no because the responder should be stable too.

   argumentation.

=> this is why we should have this discussion.

   I have implemented one of them and that's why I tend to
   support it (but it won't be the first time I implement something in an
   RFC only to see it discarded later :-).
   
=> IMHO HA assignement is far better but there is not yet a mechanism
providing it *and* applicable in the general case.

   >  - is the DNS-based DHAAD mechanism better enough to replace the ICMP-base
   
   Right, that is a good question.

=> thanks

   As presented until now, the DNS-based
   seems to have some better aspects than the ICMP-based.
   
=> so you seem to support the idea developed in the I-D.
   
Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 16:59:19 +0200

Francis Dupont wrote:

>> In a sense, the strongest firewalls of some operators block all
>> that is not HTTP, and I imagine they can even block HTTP-tunnelled
>> traffic. Which would suggest that only a cleartext HTTP-based HA
>> Discovery may have the highest chances of getting through.
>> 
> In other WiFi deployment, even after payment, only the http access is
> allowed, with a proxy.  In that, the http proxy performs name
> resolution for the MN and the MN is not allowed to perform locally
> name resolution.  Meaning a DNS-based HAD won't work, only and
> http-based HAD would.
> 
> => proxy only doesn't work well with HTTPS... and HTTP-based HAD is
> not very computer oriented (as HTTP is user oriented).
> 
> Some other operator forces the MN to use a local DNS Server and
> forbid the use of a DNS server outside that operator's domain.
> 
> => it doesn't matter if the local DNS server is recursive (if it is
> not it can't offer an useful service).
> 
> I'd go as far as to say that if an operator forces the MN into a
> local DNS Server then it may as well force the MN into a local HA as
> well, i.e. forbiding the MN to use HAs outside that operator's
> domain.
> 
> => we speak about Internet service, not on-line services connected to
> the Internet, even the Internet service can be pretty bad (spurious 
> filtering, etc).
> 
> I would agree that DNS "is not filtered out" in general but I'd also
> say there are many exceptions to that.
> 

Well, I don't necessarily intend to deviate discussion.  I think I
intended to say that relying on DNS because ICMP is usually filtered is
probably not a useful argument.

An argument in support of DNS-based HAD could be that it does not
require HA to implement DHAAD, and probably few MIP6 implementations do
DHAAD.

> => no because the responder should be stable too.

Well, IPsec works for MN and HA right?  So if all HAs on same link have
a common IPsec-friendly anycast-like IPv6 address (in addition to their
unique global IPv6 address) then IPsec for DHAAD may work too, no?

>> => the two questions are: - should we keep a DHAAD mechanism or HA
>> assignment is the right thing to do?
> 
> I have implemented one of them and that's why I tend to support it
> (but it won't be the first time I implement something in an RFC only
> to see it discarded later :-).
> 

I agree with that.

>> - is the DNS-based DHAAD mechanism better enough to replace the
>> ICMP-base one?
> 
> As presented until now, the DNS-based seems to have some better
> aspects than the ICMP-based.
> 

Provided that there is no interest in IPsec-friendly non-anycast DHAAD -
yes I support the idea developped in this I-D.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 17:12:49 +0200

> => no because the responder should be stable too.
   
   Well, IPsec works for MN and HA right?

=> yes even if some people tried to change that (:-).

   So if all HAs on same link have
   a common IPsec-friendly anycast-like IPv6 address (in addition to their
   unique global IPv6 address) then IPsec for DHAAD may work too, no?
   
 => this is more an argument for HA-switch (another way to provide
HA assignment)...
The issue with the anycast-like address is the responder must be always
the same box in order to use correctly IPsec. IMHO the best way to
protect current DHAAD is per exchange and not per communication
but the real issue is the effort doesn't worth it.

=> if you remove the anycast aspect something like the HA-switch will
be better.

=> thanks

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 17:42:35 +0200

Francis Dupont wrote:

> So if all HAs on same link have a common IPsec-friendly anycast-like
> IPv6 address (in addition to their unique global IPv6 address) then
> IPsec for DHAAD may work too, no?
> 
> => this is more an argument for HA-switch (another way to provide HA
> assignment)...

Thanks, where is HA-switch discussed, drafted?

> The issue with the anycast-like address is the responder must be
> always the same box in order to use correctly IPsec.

I don't buy into that.  It's like saying that because of IPsec two boxes
aren't allowed to have same IPv6 address.  It's also ignoring that the
"unique IP address per box" concept no longer exists since "server farms
and blades", "IP over VIA" and "modem connected to PDA" got widespread use.

> IMHO the best way to protect current DHAAD is per exchange and not
> per communication but the real issue is the effort doesn't worth it.

exchange vs. communication?

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 18:10:02 +0200

=> draft-haley-mip6-ha-switch-00.txt and (more general)
draft-devarapalli-mip6-nemo-local-haha-00.txt

I believe one of these I-Ds was proposed for the MIPv6 agenda.

   
=> multiple sources don't work well when two of the security services
are "source origin authentication" and "anti-replay". IPsec is just
not the right protocol here.

   
=> exchange := request/reply, communication:= stream of exchanges.
IPsec or SSL/TLS are stream/session oriented, an exchange oriented
security protocol should use per message signature and similar ideas,
not a session key with an anti-replay mechanism.
The problem here is the standard security protocol (IPsec) is not
convenient and to add security from scratch is known to be hard,
so it is better to use something more suitable, DNSSEC is fine because
it has both (in an exchange oriented style BTW) transaction and data
protections...

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 20:20:31 +0200

> not the right protocol here.

I intuitively agree.  I was thinking we may look at msec WG results for
help securing DHAAD, but if solution is not immediately available then
jus use some other 'group' address for the HAs instead of the anycast
address.  I would also look at e.g. SEND, because ND normally uses
groups a lot.

> it has both (in an exchange oriented style BTW) transaction and data

Ok, let try to parse that...

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Oct 2005 16:32:45 -0700

> instead, is probably a little bit flawed.

I agree with Alex.

I think it is easy opening your firewall to allow some
specific ICMPv6 messages.

Vijay