Subject: Re: FW: comments on send-ipsec-00

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Apr 2003 09:14:00 +0300

Alper,

Alper Yegin wrote:
> I have sent my comments/questions twice on the SEND ML and they are still
> not answered. ...

> My question #2 is answered by Jari Arkko on the ML, and #4 was answered
> during the IETF meeting. Others are still open questions.

Many of your questions are still more or less open ones, being
discussed at the Design Team.  In particular, I am personally
unhappy with the currently proposed transition scheme, as I
earlier wrote on the mailing list.  However, some other people
at the Design Team consider the proposed API between AH and ND
layers too demanding to implement.  Based on my limited implementation
experience with KAME I dont' agree with that; in KAME implementing
such an API would be fairly easy.  However, since I have no
implementation experience on other IPsec implementations I
have no other chance but to beleive what the others say.

Anyway, please allow me to try to briefly answer to your
remaining questions.

>> - This is a simple, and possibly a dumb question: In what type of networks are
>> we concerned about unauthorized nodes sending bogus router advertisements?
>> Possibly in public access networks, right? Couldn't we simply prevent client
>> hosts from sending RAs by installing filters on the enforcement points (like
>> APs in WLAN hotspots)? Any RA sent on the radio network can be dropped. Sure
>> it is none of the business of the L2 bridge to do that from an architectural
>> point of view, but from a practical point of view......

IMHO such an approach might work, but it is clearly outside the scope
of the working group charter.  I vaguely remember that we already
discussed this at some point of time, didn't we?

>> - "If (DAD) clashes are detected
>>  after three tries, the node is probably under attack, so it should
>>  shut down and report the situation to an administrator."
>>
>> Isn't DAD mechanism protected by CGAs as well? How can the attacker produce
>> the right cryptographic information to claim 3 different IP addresses in a
>> row?

As you note above, this was answered by Jari Arkko.  To briefly repeat
the current situation, it may not be possible to protect DAD with CGA,
since AH based CGA requires that the source address is the CGA address.
The Design Team is still trying to find the best solution to this.

>> - Can the routers still send unsolicited advertisements that can be verified
>> by hosts with different Trusted Roots? Or, do they have to unicast a different
>> advertisement to each host?

As far as I understand the currently proposed design, there are no
changes in respect to the functionality here.  So, the routers can
still send unsolicitated advertisements.

>> - "One effect of this is that secure hosts can not communicate with
>> insecure hosts using link-local addresses, and vice versa." Can an insecure
>> host and SEND-secured host still detect DAD collision on their link-local
>> addresses? If not, then we end up duplicate link-local addresses on the same
>> link, and this is a no good.

As you note above, this was discussed at the San Francisco meeting.
However, this is still partially an open problem.  The Design Team
is looking for a good answer, but the discussion is still ongoing.

>> - "An attacker may still be able to
>>  prevent valid responses or requests from reaching the intended
>>  recipient.  As a result both participants are forced to believe that
>>  no address collision exists, when there in fact is."
>>
>>  How can the attacker do that? Is it a MitM physically separating victims?

I don't remember the context of the quoted paragraph above.  However,
if it refers to the transition scheme, it is quite possible that the
current design will change.

In general, I think your questions are very good and to the point.
However, it may take time before we have proper answers to all of
them.

The current goal is to have an -01 version of the draft out fairly
soon, probably in early May.

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Apr 2003 21:05:22 +0300

Alper,

The DT made some progress wrt. your questions today.  See below.

>>> - "If (DAD) clashes are detected after three tries, the node is
>>> probably under attack, so it should shut down and report the
>>> situation to an administrator."
>>> 
>>> Isn't DAD mechanism protected by CGAs as well? How can the
>>> attacker produce the right cryptographic information to claim 3
>>> different IP addresses in a row?

We revised the current design.  In the new design all ND
messages are protected with AH, including Neighbor Solicitations
that are used during DAD.  To do that, AH protected DAD messages
are sent with the tentative address as the source address.
This requires small changes on both sending and receiving
DAD messages.  However, it is fully backwards compatible since
non-SEND nodes will ignored the AH protected NS messages.

In the new design an attacker cannot produce the right
cryptographic information, unless it is able to break
public key cryptography.

>>> Can an insecure host and SEND-secured host still detect DAD
>>> collision on their link-local addresses? If not, then we end up
>>> duplicate link-local addresses on the same link, and this is a no
>>> good.

Our new suggestion is that SEND nodes listen to multicast
NS messages from unspecified source address, and if they
receive such NS messages that contain their address as the
target address, they reply with a similar NS message, i.e.
with an NS that has an unspecified source address.  If the
non-SEND host conforms to the current specifications, it
will think that there is a DAD collision, and selects another
address.

The reason for this design is that it can be implemented
without changing SPD implementations.  The SPD would contain
PASS (don't use IPsec) entries for NS with unspecified source
address, and require AH for all other NS/NA messages.

There is still one case where this will lead to duplicate
link-local addresses.  That is, if first a non-SEND node
arrives to the link and takes an address into use, and then
a SEND node arrives and takes the same address, the non-SEND
node will not see the AH protected DAD messages, and the
SEND node will not detect the non-SEND node.

In the first look one might think that if the arriving SEND
node would also send unprotected DAD NS messages, that would
solve the problem.  Unfortunately it doesn't, for two reasons.
Firstly, the SEND node would not be able to receive the
unprotected NA messages that the non-SEND node would be
sending as replies.  Secondly, if the SEND node would listen
to those messages, it would become to the DAD DoS attack.
Thus, even if it received the unprotected NA messages, it would
not be able to act upon them.  Thus, there is no harm done
if it doesn't even solicit for them.

Thus, a collision of link local addresses is possible in
this specific scenario.  Given the tradeoffs, we think
that this is acceptable.

--Pekka Nikander

---

From: Alper Yegin <[email-masked]>
Date: Thu, 24 Apr 2003 11:37:38 -0700

Hi Pekka,

...

> discussed this at some point of time, didn't we?

I understand this is not the type of solution this WG is looking for. But if
we think the problem can be simply and adequately solved that way, does this
still leave something that needs to be solved? After all, the ultimate goal
is to "solve the problem." If there are scenarios where this approach is not
sufficient, it'd be good to understand them. [I had run this by few people
face2face, but I don't remember it being discussed in the WG...]

...

> still send unsolicitated advertisements.

Sorry, I couldn't understand your answer. So, can a router send an
unsolicited advertisement that can be verified by hosts with varying trusted
domains? If two hosts have a completely independent chain of trust which
leads to different trusted roots, how can the router sign the message that
will verify at both hosts?

...

> current design will change.

This quote is from section 12.1 of the draft. I'm trying to undertstand
under what conditions we think an attacker can prevent delivery of packets.

Alper

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Apr 2003 22:27:07 +0300

Alper Yegin wrote:
>>>> ... Couldn't we simply prevent client

AFAIK, IETF is a standardization organization.  In this particular
case, I don't see how IETF could standardize this, since this seems
to cross the IETF/IEEE standardization border.  If you see how to
proceed with this idea, please go ahead.  I'd like to see the idea
implemented.

In the other hand, if vendors do implement RA filtering, it does
not remove the need from doing something at SEND.  Firstly, having
multiple independent layers of defence doesn't usually hurt.
Secondly, the currently planned SEND RA security scheme allows
the hosts to authenticate the server.  That provides additional
assurance that the hosts are connected to the "right" network.

> will verify at both hosts?

If there are two independent certificate chains that lead to
the same router key, yes.  And yes, I think that it can be easily done.

> under what conditions we think an attacker can prevent delivery of packets.

I don't remember why that specific text was added to the draft,
but multi-link subnets and MLD spoofing come to my mind.

--Pekka Nikander

---

From: Alper Yegin <[email-masked]>
Date: Thu, 24 Apr 2003 12:59:31 -0700

> to cross the IETF/IEEE standardization border.

I'm not suggesting standardizing this method. I don't see why it has to be a
IETF or IEEE standard either. It's a simple, standalone method. My question
is if there is a problem left behind for IETF to tackle in the presence of
such methods? If yes, we should identify the scenarios and work on them.

> If you see how to

As far as I understand, many current access point products already do some
sort of filtering. Maybe exactly this type of filtering, maybe not. But I
don't see a technical challenge that prevents anyone from doing this.

> assurance that the hosts are connected to the "right" network.

This additional benefit is not really in the scope of this WG. This is for
network access authentication protocols (e.g., PANA, 802.1x) to deal with.
I'm not sure if SEND can provide an adequate solution for network access
authentication.

> the same router key, yes.  And yes, I think that it can be easily done.

Which router key is that?

Alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Apr 2003 14:00:04 -0700

Alper,

> I'm not sure if SEND can provide an adequate solution for network
access

Security of Router Advertisments is in the SEND charter and is a hole
in the RFC 2461 specification of security. Therefore, it will be part
of SEND. Such security is not part of PANA's charter either, or are
you proposing that it be made part of PANA's charter as . key
distribution recently was?

            jak

---

From: Alper Yegin <[email-masked]>
Date: Thu, 24 Apr 2003 15:21:46 -0700

James,

> distribution recently was?

Here is the "additional benefit" being discussed (which is missing in your
message):

"Secondly, the currently planned SEND RA security scheme allows
the hosts to authenticate the server.  That provides additional
assurance that the hosts are connected to the "right" network."

Checking whether a client is connected to the right network, i.e., clients
authenticating the network, is in the scope of PANA of course. There is a
lot more to it than just verifying if a router is authorized to send any
advertisements or authorized to advertise a prefix.

No, I'm not suggesting PANA solve router advertisement security problem. At
best PANA might help by bootstraping a trust relation, but this is not what
we are discussing here anyways...

Alper