Subject: [Mip4] Shepherd writeup for draft-ietf-mip4-dsmipv4

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 06 Feb 2008 14:54:01 +0100

Hi,

I'm currently doing the document shepherd writeup for this draft.

My impression is that all issues raised during the WG last call
has been addressed in -05; if this is not the case, please speak
up now.

Best,

	Henrik
-- 
Mip4 mailing list: [email-masked]
    Web interface: http://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Feb 2008 15:16:22 +0100

Henrik Levkowetz wrote:
> My impression is that all issues raised during the WG last call has 
> been addressed in -05; if this is not the case, please speak up now.

Well, since you ask - I do support this draft.

There's however a security nit that I've tried to discuss several times
in both DSMIPv4 and DSMIPv6 contexts, if I remember correctly.  Those
two protocols don't seem to use a Prefix Table at HA but do use NEMO
extensions (prefixes in reg/bu messages).  This may have some security
issues: how is HA sure that the IPv6 prefix it received in a RegReq is
allowed for this Mobile Router?  An attacker MR could put the prefix of
a legitimate MR in there and obtain its traffic.

But frankly speaking I don't remember the conclusions of our prior
discussions on this topic.  If that was agreed at that time then I don't
oppose.  If we need to discuss it further we can start with the
following textual nit:

draft-ietf-mip4-dsmipv4-05.txt:
> 5.  Security Considerations
> 
> This specification operates in the security constraints and 
> requirements of [RFC3344].  It extends the operations defined in 
> [RFC3344] for IPv4 home addresses to cover home IPv6 addresses 
> prefixes [...]

Addresses _and_ prefixes?  Addressed prefixes?  Or?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-- 
Mip4 mailing list: [email-masked]
    Web interface: http://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 6 Feb 2008 07:47:17 -0800 (PST)

> a legitimate MR in there and obtain its traffic.

I agree, prefix authorization is required. The draft needs to state
that a given prefix that a mobile is claiming is indeed authorized
to be assigned for that mobile (if the draft is not saying that
currently). Probably few lines stating the same should be sufficient ?

Sri

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 06 Feb 2008 17:48:30 +0100

Hi,

> currently). Probably few lines stating the same should be sufficient ?

Mph.  The draft extends 3344, it does not extend the MIPv4 network mobility
extensions.

I think it would be more appropriate to leave MR operation with DSMIP
for discussion in the network mobility drafts, and express operation with
and restrictions on MN-owned prefixes only here.

But what does the authors say?

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 6 Feb 2008 08:57:09 -0800 (PST)

Hi Henrik,

> and restrictions on MN-owned prefixes only here.

But, the draft is allowing prefix allocations and that is beyond 3344.
So, there needs to be some guidance on how HA should behave when
there is a RRQ containing a prefix that belongs to some other MN.
I think a simple statement on prefix authorization should be sufficient.
Not sure, if Alex has some other approach in mind.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Feb 2008 18:03:41 +0100

Sri Gundavelli wrote:
>> Mph.  The draft extends 3344, it does not extend the MIPv4 network 
>> mobility extensions.
>> 
>> I think it would be more appropriate to leave MR operation with 
>> DSMIP for discussion in the network mobility drafts, and express 
>> operation with and restrictions on MN-owned prefixes only here.
> 

In addition to prefix allocation it clearly states that "The [DSMIPv4]
solution supports the registration of IPv6 home address(es) and/or
prefix(s) in addition to regular IPv4 home address registration."

> there is a RRQ containing a prefix that belongs to some other MN. I 
> think a simple statement on prefix authorization should be 
> sufficient. Not sure, if Alex has some other approach in mind.

I agree, one could write a statement like "HA should make sure it
authorizes the prefix, with a method outside the scope of this document"
or it could define a Prefix Table holding pairs of prefix-homeaddress
and describe how HA checks the prefix received in the regreq.

But I'm not sure what authors think about this aspect.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Feb 2008 18:12:13 +0100

> and describe how HA checks the prefix received in the regreq.

Or one could eliminate all use of IPv6 prefixes from DSMIPv4 RegReq and 
refer to NEMOv6 encapsulated in IPv4 instead.  Just another alternative.

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Feb 2008 13:03:38 +1000

Hi Henrik,

 > But what does the authors say?

=> I think the issue being raised is not a security issue. It's an
implementation guidline for ensuring prefix authorisation. The prefix table
is just a conceptual data structure used by nemo. So, simply stating that
the HA should delegate prefixes to authorise MRs is sufficient, it's an
editorial issue whether we have to state that the HA should use a conceptual
data structure called the prefix table or not. 

Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 07 Feb 2008 09:48:57 +0100

Hi Hesham,

On 2008-02-07 04:03 Hesham Soliman said the following:
> I think the issue being raised is not a security issue. It's an
> is just a conceptual data structure used by nemo.

Agreed.  We shouldn't make the language in this draft dependent on that
particular way of expressing things, but should make clear what we require
of the HA.

> So, simply stating that

Right. Could you propose some text?

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Feb 2008 19:52:34 +1000

> Right. Could you propose some text?

=> I walked into this one :) sure, I'll send some text.

Hesham

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 7 Feb 2008 09:41:14 +0000

Hi all,

With respect to how "authorized" prefixes are allocated, I am a bit
reluctant to be too prescribing in the specification. The spec
indicates that the MN MAY request an address/prefix and the HA MAY
provide an address/prefix. Do we really need to say much about how the
HA makes the decision? At most we could add something like this:

"How a home agent decides to provide, or accept, an IPv6 home address
or prefix to a given mobile node, is out of scope of this
specification. Local configuration or external authorization via
RADIUS/DIAMETER or other mechanisms may be used to make such
determination."

How is that?

George

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 07 Feb 2008 11:23:28 +0100

Hi George,

> RADIUS/DIAMETER or other mechanisms may be used to make such

Works for me.  

Editorially, I think I'd prefer s/prefix to a given/prefix for a given/.

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Feb 2008 21:32:30 +1000

Works for me too.

Hesham 

 > -----Original Message-----
 > From: George Tsirtsis [mailto:[email-masked]] 
 > Sent: Thursday, February 07, 2008 7:41 PM
 > To: Hesham Soliman
 > Cc: Henrik Levkowetz; Alexandru Petrescu; MIP4 Mailing list; 
 > Henrik Levkowetz; Sri Gundavelli
 > Subject: Re: [Mip4] Shepherd writeup for draft-ietf-mip4-dsmipv4
 > 
 > Hi all,
 > 
 > >      Charter page: 
 > http://www.ietf.org/html.charters/mip4-charter.html

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 7 Feb 2008 11:21:49 +0000

Henrik,

Could you clarify the editorial change you are suggesting....I am not
sure I understand what you are saying.

Aslo, do you want me to produce a new version now or shall I handle
this together with any AD comments?

George

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 07 Feb 2008 12:27:28 +0100

Hi George,

> sure I understand what you are saying.

I'd prefer:

"How a home agent decides to provide, or accept, an IPv6 home address
or prefix for a given mobile node, is out of scope of this
specification. Local configuration or external authorization via
RADIUS/DIAMETER or other mechanisms may be used to make such
determination."

> this together with any AD comments?

Let's hold off a little bit, to see if anything else comes up.  I also
have to complete my shepherd's read-through of the document as it is
now (a requirement for the writeup); there could be minor change
suggestions from that.

	Henrik

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 7 Feb 2008 11:37:23 +0000

ok, thanks.
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Feb 2008 14:55:29 +0100

George Tsirtsis wrote:
> provide an address/prefix. Do we really need to say much about how 
> the HA makes the decision? At most we could add something like this:
> 
> specification.

One should at least say that the HA MUST decide/accept on that prefix,
and that this draft does not offer a means to do so.  If the draft
doesn't say HA MUST decide then this is a security issue.

Alex

> Local configuration or external authorization via RADIUS/DIAMETER or 
> other mechanisms may be used to make such determination."
> 
> How is that?
> 
> George
> 
> 
> 
>>> Agreed.  We shouldn't make the language in this draft dependent 
>>> on that particular way of expressing things, but should make 
>>> clear what we require of the HA.
>>> 
>>>> So, simply stating that the HA should delegate prefixes to 
>>>> authorise MRs is
>>> sufficient, it's an
>> -- Mip4 mailing list: [email-masked] Web interface: 
>> http://www.ietf.org/mailman/listinfo/mip4 Charter page: 
>> http://www.ietf.org/html.charters/mip4-charter.html Supplemental 
>> site: http://www.mip4.org/
>> 
>