Subject: RE: [Seamoby] comments on CAR Discovery Requirements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 01:02:00 +0100

Hi, 

I have some brief general comments on the 
draft and some minor specific ones. I'm afraid
my old comment still applies. See below:

General comments: 

1. I think (somewhere in the intro or a dedicated
section) that there should be some description
of the entities participating in the CAR
discovery, without getting into a solution. 
I still think the requirements are vague because
they don't explain which entities are affected 
by these requirements. They are on such a high level, 
that they could apply to anything. 

2. The security requirements are noon-existent
as James said, and I don't think one requirement
is enough, several issues need to be addressed:
- Authorisation
- DoS attacks
- Replay protection 
....etc
There needs to be a separate security section. 
And again, detailing these requirements will show
who/which part of the protocol is affected by it. 

Requirement 3.3 seems to mix site-local/private
addresses with IPv4/IPv6 and is a bit vague. 
This area is quite large and some proposals are
already on the table in ngtrans. Can you be a bit 
specific with what is actually required?

Sorry (in advance) if I don't reply quickly.

Hesham

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 01:02:00 +0100

Hi, 

General comments: 

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 13 Mar 2002 20:40:39 -0500

Hello Hesham,
Thanks for your comments.
My responses are inline.
Regards,
Govind.

>that they could apply to anything.

[Govind] ASAIK, the requirements were designed for ANY protocol
involved in CAR discovery irrespective what entities may actually
be part of in a solution. It might be difficult to anticipate
every solution and prepare requirements for different entities
probably in the solution.
However, could you provide a paragraph to the WG so
that we can then understand your concern more clearly. I remember
you saying that you will be sending in some text but we never got it.

>who/which part of the protocol is affected by it.

[Govind] I guess James has proposed a requirement and
we are discussing this in a separate thread. May be
you can post your requirement there along with the justification
text there so that we don't have to deal with
two threads dealing with this topic.

>specific with what is actually required?

[Govind] The requirement is very simple. It is
  attempting to look into a situation wherein APs
adjacent to each other may be
connected to ARs not directly reachable from each other.
Again if this is not clear, could you send in text which
more appropriately describes what you have in mind.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 13 Mar 2002 20:40:39 -0500

Hello Hesham,

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 02:55:22 +0100

> involved in CAR discovery

=> This is the problem. The requirements are on such
high level, that makes it hard to address any 
issues in detail.

 irrespective what entities may actually
  > probably in the solution.

=> We know the entities already don't we? 
The MN, The AR and one or more GAARs. There is 
nothing more is there ?

  > you saying that you will be sending in some text but we 

=> OK

  > two threads dealing with this topic.

=> OK, but this is not about a single requirement, 
you need to have a few of them.

  > connected to ARs not directly reachable from each other.

=> The entire CAR discovery problem looks at
this scenario, but how does IPv4/v6, Site-local
issues come into this?

  > more appropriately describes what you have in mind.

=> I'll try, but I can't guarantee it. It doesn't
make the comments less valid though.

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 10:36:21 -0500

Hello Hesham,
Comments inline,
Regards,
Govind.

>issues in detail

[Govind] OK. please feel free to add some statements to the requirements
and send it over to the mailing list.

>The MN, The AR and one or more GAARs. There is

[Govind] "Nothing more" is a very blanket statement which may not be
true. I think it is solution dependent. I am not saying that the entities 
you mention will not be involved.

>   > you saying that you will be sending in some text but we

[Govind] Thanks.

>you need to have a few of them.

[Govind] Feel free to add as many relevant requirements as you want.

>this scenario, but how does IPv4/v6, Site-local
[Govind] I don't understand your question. As I explained before,
the point is just to introduce the "practical scenario" of having
ARs belonging to private domains ending up as GAARs.

>make the comments less valid though.

[Govind] Ofcourse, but unless you post your ideas one cant make any 
progress.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 10:36:21 -0500

Hello Hesham,
Comments inline,
Regards,
Govind.

[Govind] Thanks.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 23:06:41 +0100

> Re. the comments on security, maybe we need a more 
  > comprehensive threat
  > analysis such as Claude did for paging?
  > The requirement I did was pretty generic.

=> Agreed. No need for a separate doc. This
is what I was hinting at when I said 'I can try'.
Because this is something that will take time.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 23:04:02 +0100

Hi Govind,

  > ARs belonging to private domains ending up as GAARs.

=> There is a big difference between:

- Handover from private IPv4 to public IPv4 domains
- Handover from IPv6 to IPv4 domains
- Handover from one IPv6 site to another.

Totally different solutions would be needed. 
That's why I'm puzzled about putting them together
without explicitly stating the exact requirement
for each case.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Mar 2002 23:04:02 +0100

Hi Govind,

Hesham

---

From: [email-masked]
Date: Thu, 14 Mar 2002 17:14:25 -0500

Hesham,

see inline...
-----Original Message-----
From: ext Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 5:04 PM
To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] comments on CAR Discovery Requirements

Hi Govind,

[DOT] ...which is not of interest during the requirements definition...

[DOT] Right now, the requirement states "...CAR discovery protocols MUST be able 
to identify GAARs and their capabilities when moving in and out of private 
and site-local address spaces.".

[DOT] Apart from your separation of different handover scenarios, is it possible 
for you that you provide said 'exact' wording for a requirement (or even so strongly
suggested set of requirements) that would satifies said cases. Not only
is this the constructive way of providing input to this discussion, it
would also allow all of us to see how these requirements would be different
from each other and different from the one that is already in the document.
Basically, the best way to 'explicitly state the exact requirement' is to send
it to the list rather than just asking for an 'exact' requirement.

Regards,

Dirk

---

From: [email-masked]
Date: Thu, 14 Mar 2002 17:14:25 -0500

Hesham,

see inline...
-----Original Message-----
From: ext Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 5:04 PM
To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] comments on CAR Discovery Requirements

Hi Govind,

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 14 Mar 2002 23:00:37

Hi James:

Rather than starting from scratch again in Minneapolis, may I propose that 
we start from the following baseline text for security requirements. I think 
this text very clearly and explicitly brings out the security issues 
involved. If any additional statements are needed we can fill them in. Sorry 
to repeat this, but I did not see any reference to earlier discussion on 
this text in Hesham's email.

"Solution to CAR discovery  MUST address the security concerns involved in 
the various aspects such as GAAR discovery, capability exchange and CAR 
selection. In particular,

a) The solution MUST provide means for an AR to to verify that another AR 
claiming to be its GAAR is genuine. In other words, the other AR is indeed a 
GAAR and it is an authentic router. The authenticity of a router MAY mean 
that it is authorized to act as an access router by the jurisdiction of the 
environment (operator network, organizatoinal LAN, home network etc.) that 
the router resides in.

b)It MUST provide means for secure capability exchange between an AR and its 
GAAR.

c)It MUST provide secure means for the expression of MN requirements to CAR 
selection algorithms."

Regards,
Hemant

>From: "James Kempf" <[email-masked]>
>To: "Hesham Soliman \(ERA\)" <[email-masked]>,        
>"'Govind Krishnamurthi'" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] comments on CAR Discovery Requirements
>Date: Thu, 14 Mar 2002 14:34:29 -0800
>
>Hesham,
>
>Good, let's talk about this in the Minne-apple.
>Maybe we can get together a small group
>of volunteers to help. It should
>not take much time, and I agree that we
>don't need a separate document, but
>I think we need something more than
>we have now.
>
>             jak
>
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 18:08:17 -0500

Hello Hesham,
Please take a look at some of the requirements which came in this afternoon 
(from Hemant and James). Please see whether they satisfy
all the security issues. I look forward to seeing your comments on these. I 
also agree with you about not needing a separate document.

Best regards,
Govind.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 18:08:17 -0500

Hello Hesham,

Best regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 18:03:42 -0500

Hi Hesham,

>- Handover from one IPv6 site to another.

[Govind] I agree with this but from a CAR discovery
requirement point of view isn't it just the ability of these happening
which is important? Anyways, if you will supply the requisite wording that 
you deem necessary I will be happy to add it if there is WG concensus.

>Totally different solutions would be needed.

[Govind] Again totally different solutions being needed is again
a statement we don't need to go into now, as this would take us into
solution space.

Best regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 14 Mar 2002 18:03:42 -0500

Hi Hesham,

Best regards,
Govind.

---

From: [email-masked]
Date: Fri, 15 Mar 2002 09:32:47 -0500

James,

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 6:41 PM
To: Hemant Chaskar; [email-masked]
Subject: Re: [Seamoby] comments on CAR Discovery Requirements

Hemant,

I think it would be useful to have a threat analysis. The threat
analysis that was done for paging was extremely useful in uncovering
necessary security requirements. What you have listed below are fairly
high level goals. A more detailed threat analysis with these goals in
mind might turn up some more specific requiremnts.

[DOT]frankly speaking, I have my doubts that the output would be more
than now. What we are targetting right now is the clear and complete statement of 
security issues, and we are having progress in this. Plainly raising concerns 
without providing input is not what I see as a threat analysis. I don't 
see that any new process, called threat analysis or whatever, would bring 
more than the process now. 
If people are not willing to provide proper input (and that's what we 
need) now, why should they in a newly created threat analysis. It
simply creates a new process, and therefore new overhead without
guaranteeing any increased output.

Hesham has indicted some interest in participating, 

[DOT] Frankly, Hesham has been indicating his interest in participating
for quite a while, and several people, including myself, strongly invited
him to do so. Apart from raising concerns, other input has not been 
provided, only the promise to do so. If we want to have progress with
CAR discovery, we have to do the work rather than promising to do the
job. 

...perhaps you would like to as well?

[DOT] That's exactly the difference. Hemant has been participating in providing 
input in forms of requiremens for quite a while, so there is no need to invite 
him for participation. If we have to announce our interest again in providing
input, I'll do so, too.

Regards,

Dirk

----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 14, 2002 11:00 PM
Subject: Re: [Seamoby] comments on CAR Discovery Requirements

> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Mar 2002 20:19:54 +0100

> CAR discovery, we have to do the work rather than promising 

=> You need to understand the difference between 
making comments to improve the document and putting
those comments in the document. I haven't had 
time to actively participate, that doesn't make
the comments invalid. I don't have to send text 
(although I'd like to) to prove to you that the
comments are valid. Simply saying' well if you have 
comments send text or be forever silent' is 
complete nonsense. Whatever happened to trying 
to understand and discuss comments on the mailing
list!

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 16 Mar 2002 00:08:32 +0100

> One of the problems we've been having in Seamoby
  > is that people seem quite willing to contribute criticism
  > or their opinion, but when it comes time to contribute
  > some solid text, they disappear or plead lack of time.
  > This does nothing to advance the spec, because then
  > the draft editor has to guess what the complainer's
  > intent is, leading to further complaints that the guess
  > was incorrect, etc. 

=> There is no need to guess. Every draft receives 
comments from people, they are discussed on the
mailing list and the editor(s) then add them
as they see fit...

It is much more efficient to have
  > those people who have some problem with the
  > spec to come up with text for it expressing
  > what they have in mind.

=> Of course, but editors should be open 
to comments. I shouldn't have to rewrite
the draft (which is what happens when
there is a structural comment) to make
sure my comments are acceptable. If people 
agree or disagree with the comments, then
we can move forward. If the comments are
not clear at all, I'm more than happy
to clarify. But an answer of 'OK if you
see a problem send text', is just...not
helpful. Questions like: is there any 
agreement on the comments? Do they make any sense at 
all ?? ...etc should be addressed,
not just 'send text'.

Can't we spend this time discussing technical
comments?!!! Every time I comment on this draft
I get procedural answers from the authors!
Sigh

  > 
  > You have expressed a concern (which I think is quite
  > valid) about the lack of close examination in the
  > security requirements for CAR discovery. It would
  > be extremely helpful if you, Hemant, and Govind
  > could sit down for an hour at IETF and talk
  > about the issue, maybe come up with a slide
  > or two for Govind's presentation. If there is
  > not enough time at IETF, then perhaps you
  > can continue the discussion afterwards for
  > a couple weeks.
  > 
  > Does that sound doable?

=> Yes.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 16 Mar 2002 00:08:32 +0100

=> Yes.

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sat, 16 Mar 2002 22:58:50

Hi Eunsoo:

Since you think that this is "very desirable", shouldn't it be a MUST 
requirement. Also, I do not think that doing this is impossible.

Hemant

>From: "Eunsoo Shim" <[email-masked]>
>To: <[email-masked]>
>Date: Sat, 16 Mar 2002 16:05:27 -0800
>
>Hemant,
>
>I think it is very difficult to verify that the AR claiming to be a GAAR is
>indeed a GAAR even though it is very desirable. So I'd be reluctant to put
>it as a requirement.
>I have no problem about verifying the authenticity of a router.
>
> > > GAAR and it is an authentic router.
>
>Thanks.
>
>Eunsoo
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sat, 16 Mar 2002 22:58:50

Hi Eunsoo:

Hemant

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sat, 16 Mar 2002 23:03:18

Hi Eunsoo,

In the CAR case, verifying "authenticity of sender" does involve verifying 
that it is your GAAR. This is because, here sender cannot be an arbitrary IP 
device, it has to be a GAAR. Otherwise, an AR can be trapped into exchanging 
capabilities with a bunch of ARs which are not actually its GAARs. The 
non-GAARs can then overwhelm AR with their capabilities and cause DOS 
attack.

Hemant

>Date: Sat, 16 Mar 2002 18:34:43 -0800
>
>I mean the purpose of security is to verify the authenticity of the message
>sender and the integrity of the message rather than the correctness of the
>information contained in the message. I think whether the claimed GAAR is
>indeed a GAAR is about the correctness of the information.
>Thanks.
>
>Eunsoo
>Sent: Saturday, March 16, 2002 4:05 PM
> > > > a) The solution MUST provide means for an AR to to verify that 
>another
> > > AR
> > > > Rather than starting from scratch again in Minneapolis, may I 
>propose
> > > that
> > > > we start from the following baseline text for security requirements. 
>I
> > > think
> > > > involved. If any additional statements are needed we can fill them 
>in.
> > > Sorry
> > > > to repeat this, but I did not see any reference to earlier 
>discussion
> > > on
> > > > a) The solution MUST provide means for an AR to to verify that 
>another
> > > AR
> > > > environment (operator network, organizatoinal LAN, home network 
>etc.)
> > > that
> > > > the router resides in.
> > > >