Subject: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information

From: JinHyeock Choi <[email-masked]>
Date: Thu, 19 Aug 2004 16:50:52 +0900

Dear DNA WG 
 
This is an attempt to resolve this issue:
 
Issue 3 
Jim Bound proposed to remove 
Sub-sec 3.2. Inadequacies in RA information
 
Suggested resolution  

At San Diego meeting, WG agreed to remove Sub-sec 3.2, so we reduced 
Sub-sec 3.2 to just present the difficulty for a single RA message to 
indicate a link change. We propose to change Sub-sec 3.2 (after we remove 
Sec 2, this will be Sub-sec 2.2) as below. 

3.2  Link identity detection with a single RA

Usually a host gets the information necessary for IP configuration 
from RA messages. Based on the current definition [ND], it's difficult 
for a host to check for link change upon a single RA reception. 

To detect link identity, a host may compare the informations in an RA, 
for example router address or prefixes, with the existing ones.  

The host may use a router address to check for link change. But the 
router address in the source address field of an RA is link-local 
scope, so its uniqueness is not guaranteed out side of a link. So if it 
happens that two different router interfaces have the same link-local 
address, the host can't detect that it has moved from one interface 
to another by checking the router address in RA messages.

Or the host may check whether an incoming RA includes the currently 
stored prefix. But an unsolicited RA message can omit some prefixes 
for convenience [4]. Hence, the host can't be sure that the existing 
prefix is not supported on the currently attached link, even though the 
prefix is not contained in a received RA.

The set of all the global prefixes assigned to a link can represent a link 
identity. But it's not easy for a host to attain and retain all the prefixes 
with certainty, so the prefix list based DNA scheme needs further 
investigation [CPL].

Please register your opinion if you have any comments, otherwise 
we'll update the goals draft accordingly and move it forward.
 
Thanks to Greg's kind work, we now have the issue list at 
 
http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals
 
Thanks for your kind consideration. 
 
Best Regards
 
JinHyeock

---

From: Brett Pentland <[email-masked]>
Date: Thu, 19 Aug 2004 18:22:13 +1000

Hi JinHyeock,

> with certainty, so the prefix list based DNA scheme needs further

This last paragraph seems more like a potential solution than a goal.
The set of all the global prefixes assigned to a link can represent
a link identity, but there are other ways.  I don't think that the
goals document should specify this. I would suggest just removing it.

Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 19 Aug 2004 17:49:18 +0900

> goals document should specify this. I would suggest just removing it.

The paragraph is intended to present the limitation of prefix list based 
approach at current stage. It's not my intention to suggest prefix list 
based approach as the solution.  

Best Regards

JinHyeock

---

From: Brett Pentland <[email-masked]>
Date: Thu, 19 Aug 2004 20:43:40 +1000

> based approach as the solution.  
The previous paragraph already states that RAs don't necessarily carry a
complete list of prefixes.  This paragraph seems out of place to me.

Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 23 Aug 2004 13:22:09 +0900

Dear Brett

Thanks for your helpful feedback that clarified my thoughts.  

> complete list of prefixes.  This paragraph seems out of place to me.

'Omission of prefix' is not the only limitation of prefix based approach. 
Moreover I found that 'the omission of prefix' is about not so much 
'detect link identity' as 'validate IP address'. So I incorporate the last 
two paragraphs to update the 3.2. as below. 

Kindly give your opinions. 

Best Regards

JinHyeock 

------------------------------------------------------------------------
3.2  Link identity detection with a single RA
 
Usually a host gets the information necessary for IP configuration from 
RA messages. Based on the current definition [ND], it's difficult for 
a host to check for link change upon a single RA reception. 

To detect link identity, a host may compare the informations in an RA, 
such as router address or prefixes, with the existing ones.
 
The host may use a router address to try to check for link change. 
The router address in the source address field of an RA is of link-local 
scope, however, so its uniqueness is not guaranteed outside of a link. 
If it happens that two different router interfaces on different links
have the same link-local address, the host can't detect that it has 
moved from one link to another by checking the router address in 
RA messages.

The set of all the global prefixes assigned to a link can represent 
a link identity. The host may compare the prefixes in an incoming 
RA with the currently stored ones. An unsolicited RA message, 
however, can omit some prefixes for convenience [4] and it's not 
easy for a host to attain and retain all the prefixes with certainty. 
Hence, neither the absence of a previously known prefix nor 
the presence of a previously unknown prefix in the RA guarantees 
that link change has occurred.

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 25 Aug 2004 17:09:41 +0900

Dear DNA WG 

Issue 5 
Jim Bound proposed as an additional DNA goal, 
To analyze the case of the host hearing both links with respect to seamless mobility 

Suggested resolution: We propose to accept this and add to goals list 

 G10  Hosts with multiple interfaces or in particular wireless
       environments may perceive routers reachable on different
       links. DNA schemes should take into consideration
       the case where a host is attached to more than one link
       at the same time.

 

Best Regards
 
JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 25 Aug 2004 17:16:00 +0900

Dear DNA WG 

Issue 6 
Jim Bound proposed as an additional DNA goal, 
To describe the L2 properties with respect to routing and link detection 

Suggested resolution: We propose to reject this. 

It's our opinion that it would be better for this work to be done 
at link-layer notification or BCP. 

 

Best Regards
 
JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 25 Aug 2004 17:03:53 +0900

Dear DNA WG 

Issue 4 
Jim Bound proposed as an additional DNA goal, 
To investigate a way for a host to attain and retain all prefixes with certainty. 

G1 states that 'DNA schemes should detect the identity of the currently 
attached link'. Right now, there are two candidates to achieve G1, 
the complete prefix list and an explicit link identifier. We think it may be 
premature for WG to state the particular way to achieve the G1 as a goal.  
It's our opinion that it's better for WG  to investigate how DNA schemes 
would achieve G1, whether with the complete prefix list or with an explicit 
link identifier, in solution work.    

 

Best Regards
 
JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 25 Aug 2004 22:55:18 +0900

Dear DNA WG 

Issue 7 
Jari Arkko proposed to clarify G7. 

G7. DNA schemes should be compatible with security schemes such as 
     Secure Neighbour Discovery [8] and IPSec [7].

  "I understand the SEND part. Not sure I understand the IPsec
   part. ... perhaps you could clarify what your requirement is"   

Suggested resolution: We propose to remove IPSec part as below.

   G7. DNA schemes should be compatible with security schemes such as
      Secure Neighbour Discovery [7].

Because DNA will be based on ND, SEND will be sufficient and, 
as Jari commented, IPsec part can cause unnecessary ambiguities 
with little benefit. 

 

Best Regards
 
JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 25 Aug 2004 23:03:56 +0900

Dear DNA WG 

Issue 8 
Jari Arkko proposed to modify Security Consideration 
 
   "You may want to add something like what Bernard wrote in his DNAv4 
   document about not trusting the DNA procedures to turn on/off your personal 
    firewall based on "recognizing" your home network."

Suggested resolution: We propose  to modify Security Considerations as belows. 
 
   Because DNA schemes are based on Neighbor Discovery, its trust models
   and threats are similar to the ones presented in [9].  Nodes
   connected over wireless interfaces may be particularly susceptible to
   jamming, monitoring and packet insertion attacks.

   As a result, when Neighbor Discovery is not secured, it is
   inadvisable for a host to adjust its security based on which network
   it believes it is attached to.  For example, it would be
   inappropriate for a host to disable its personal firewall based on
   the belief that it had connected to a home network.

   Use of [7] to secure Neighbor Discovery is important in achieving
   reliable detecting network attachment.  DNA schemes SHOULD
   incorporate the solutions developed in IETF SEND WG if available,
   where assessment indicates such procedures are required.

* We  add something like what Bernard  wrote in DNAv4 I-D between 
   "... packet insertion attacks' and 'Use of...'

 

Best Regards
 
JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Aug 2004 18:32:08 -0700

I am not sure I understood the issue. I agree that some secure
mechanism is need to detect crossing security boundaries before
a personal firewall is turned off. but why is this tied to SEND?
I dont see anything in SEND for detecting crossing security
boundaries.

it might suffice to say, in the Security Considerations section,
that a secure mechanism is needed to detect crossing security
boundaries before taking actions like turning off personal
firewall and that DNA mechanisms might not be sufficient.

Vijay

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 26 Aug 2004 19:08:31 +0900

Vijay 

Thanks for your feedback. 

> firewall and that DNA mechanisms might not be sufficient.

Our line of thoughts are like below.

1. With SEND, we can secure Router Discovery, such as Router 
    Advertisement. 
2. With secured RA messages, we can secure DNA.  
3. With secured DNA mechanisms, a host can safely adjust its 
    security based on which network link it believe it is attached to. 
4. Without secured DNA schemes, it's inadvisable to do so.  

We think that DNA schemes can be used to detect crossing security 
boundaries indirectly and SEND can be used to secure DNA, so the 
connection.  
 
It seems, however, that the phrases need clarification. How about this? 

   With unsecured DNA schemes, it is inadvisable for a host to adjust
   its security based on which network it believes it is attached to.
   For example, it would be inappropriate for a host to disable its
   personal firewall based on the belief that it had connected to a home
   network.

I exchanged the second and the third part with slight modification to clarify 
the paragraphs. Kindly comment on it. 

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 26 Aug 2004 20:19:35 +0900

Dear DNA WG

13th Friday has passed without Jason's appearance, so I am 
filled with high hope for speedy Goals advancement. :-)

We have posted the proposed resolutions for all the existing 
issues. We ask WG to investigate and comment on them.   

Just to place a boundary on the time, we'd like to ask that 
people with comments on the proposals do so before 01:00 
UTC on the 1st of September. 
 
If you think that proposed resolutions are inacceptable or 
need improvement, kindly register your opinion during this 
period. Otherwise we'll close the issues to update the goals 
draft accordingly and move it forward.
 
The interim version of goals draft is available at 

http://math87.ensoltek.co.kr/board/files/draft-ietf-dna-goals-01int.txt 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Aug 2004 13:50:00 -0700

> 2. With secured RA messages, we can secure DNA.  

this reasoning is flawed. who said all DNA mechanisms will be
based on RA messages?

> boundaries indirectly and SEND can be used to secure DNA, so the 

that is your opinion. IMO, it doesnt belong in a Goals document.
what if I have never planned on using SEND. :)

>    personal firewall based on the belief that it had connected to a home

just delete the second paragraph. you can still convey what you
want to in the Security Considerations section without that text.

Vijay

ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756
which is reference [10]

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 27 Aug 2004 10:24:40 +0900

Vijay

> this reasoning is flawed. who said all DNA mechanisms will be

Even though, at this point, we can't be certain that DNA will be 
based on RA message, I think that's highly likely and will bet a
dinner on it. :-) Thinking it over, 'ALL' is a very hard qualitifier to 
satisfy.  

> what if I have never planned on using SEND. :)

I see your point. It may be premature to mention SEND in goals draft 
because, right now, we can't say what form DNA schemes will
take. It maybe be better for us to mention SEND in Solution drafts. 

[omitted] 
>    personal firewall based on the belief that it had connected to a home

I agree. I'll modify as you proposed. It may be better for us to include 
the second paragraph in Security Consideration of Solution drafts.  
 
> ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756

The reference number is from the new version. In it, [9] is RFC 3756.  
This comment warms my heart because it showed that you really paid 
attention. :-)  

Thanks for your kind and helpful comments. 

Best Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Aug 2004 11:29:31 -0700

thanks.

Vijay