Subject: [DNA] RE: draft-ietf-dna-link-information-03

From: Alper Yegin <[email-masked]>
Date: Wed, 24 May 2006 22:46:11 -0700

CC: DNA WG ML.

Thanks Jari for your review and comments.

Please see my inlined response below.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Monday, May 22, 2006 10:29 AM
> To: [email-masked]
> Cc: Greg Daley; [email-masked]; [email-masked]
> Subject: Re: draft-ietf-dna-link-information-03
> 
> Here are my initial AD review comments. I'm not
> completely done yet, because I want to re-read
> the IAB link indications document to see if there's
> something else that should be taken into account.
> 
> Btw, Bernard reviewed this document at some
> point. Where is that review, and did you implement
> all of his suggestions?

We had done done per his earlier review. I'll respond to his new review
comments as well.

> Substantial:
> 
> >    Two basic link-layer events are considered potentially useful to DNA
> >    process: link up and link down.  Both of these events are
> >    deterministic, and their notifications are provided to IP-layer after
> >    the events successfully conclude.
> 
> I wonder how deterministic these events are in a wireless
> network.

I think it is best if we hadn't used that term. I'd rewrite:

Two basic link-layer events are considered potentially useful to DNA
process: link up and link down.  Associated notifications can be
provided to the IP-layer after the events conclude successfully.

> >    A GPRS MT that wants to establish IP-level connections MUST first
> >    perform a GPRS attach to the SGSN.  This MUST be followed by a
> 
> This reads like normative language for the implementation of
> GPRS L2 operations. I would suggest that such language be
> left to the SDOs in question. (May apply to other parts of
> the document, too. Go over the MUSTs and SHOULDs and check
> that they apply only to the up/down indications, not the
> rest of the L2 operation.)

I'll take care of them all.

> 
> >    A GPRS MT that wants to establish IP-level connections MUST first
> >    perform a GPRS attach to the SGSN.  This MUST be followed by a
> >    request to the GPRS network to settle the necessary soft state
> >    mechanism (GPRS tunneling protocol) between its serving SGSN and the
> >    GGSN.  The soft state maintained between the MT, the SGSN and the
> >    GGSN is called a PDP Context.  It is used for guaranteeing a
> >    negotiated quality of service for the IP flows exchanged between the
> >    GPRS MT and an external Packet Data Network such as Internet.
> 
> Hmm... there's more to a PDP context than QoS state. I would simply
> replace the entire text above with:
> 
> "A GPRS MT that wants to establish IP connectivity establishes
> first a connection to the GPRS network and one or more PDP
> Context associations between the MT and the GGSN."

Sounds reasonable to me. Unless Eric, the author of that text, has any
comments, I'd go with your suggestion.

> 
> >    An MT has the possibility to establish a secondary PDP Context while
> >    re-using the IP configuration acquired from a previously established
> >    and active PDP Context.  Establishment of a secondary PDP Context
> >    does not provide additional information to IP-layer.  Such a second
> >    PDP Context would basically have a different QoS profile so that a
> >    different type of application can be served.  In that case,
> >    activation of the secondary PDP Context MUST NOT generate another
> >    link up event notification.  However, a secondary PDP Context
> >    establishment that triggers a new IP configuration is to be treated
> >    from the IP layer as indicated above.
> 
> Rewrite as
> 
>  "An MT has the possibility to establish a secondary PDP Context while
>    re-using the IP configuration acquired from a previously established
>    and active PDP Context.  Such a secondary PDP Context
>    does not provide additional information to IP-layer and only
>    allows another QoS profile to be used.  The activiation of a such
>    secondary PDP Context MUST NOT generate another
>    link up event notification.  However, other additional PDP Context
>    activiations are to be treated as indicated earlier."

My response is same as the previous one.

> 
> >    In a WiFi network that supports Robust Secure Network (RSN
> >    [IEEE-802.11i]), successful completion of 4-way handshake between the
> >    STA and AP commences the availability of IP service.
> 
> Presumably mere support is not the key factor here -- the question
> is whether the RSN operation has been turned on or not; my RSN-capable
> network works fine even without 4-way handshake.

I'd rewrite this as:

In a WiFi network that uses Robust Secure Network (RSN
[IEEE-802.11i]), successful completion of 4-way handshake between the
STA and AP commences the availability of IP service.

> 
> > 2.3  IEEE 802.11/WiFi
> 
> Does the document provide any guidance on what the link up/down
> events should be for preauthentication or fast handoff (802.11r)
> situations? Or is it too early to specify these?

It does not. I am not inclined to get into those areas, unless there is
popular demand :-)

> > 4.  Security Considerations
> >
> >    A faked link-layer event notification can be used to launch a
> >    denial-of service attack on the node and the associated network.
> >    Secure generation and delivery of these notifications MUST be
> >    ensured.  This is a subject for link-layer and network stack designs
> >    and therefore it is outside the scope of this document.
> 
> This paragraph appears to define a MUST requirement for
> something that is commonly not available. It would be useful
> to describe the vulnerability and discuss in turn each
> mitigating mechanism. You may also wish to take a look
> at Section 5.4,  Spoofing Network Connectivity Indications,
> in draft-ietf-mobike-protocol-08.txt.
> 
> For instance, the mitigating mechanisms include
> - link layer security (but should note that it can never fully
>   protect against DoS-type attacks, and link-down could
>   still be generated)
> - security mechanisms in the IP layer configuration,
>   including DHCP security and SEND security for ND/RD;
>   these can be used by
> 
> And yes, there's no complete protection today for this.

I think it is best if we didn't get into solving this problem in this
document. I am not sure if we can really get away with few lines of text to
suggest some solutions. A thorough solution (set) is likely to be pretty
comprehensive -- possible an I-D on its own. 

I think acknowledging the threat and declaring its solution out-of scope is
what we should be doing. 

As for the "MUST", I understand that there are currently deployed systems
that do not deploy appropriate security to handle this threat. That fact
should not take anything away from what a secure system MUST be doing. I
think that fact just makes them insecure in this sense, hence vulnerable to
spoofed link ups and downs. For that, I'm inclined to keep the MUST in
there. 

> 
> Editorial:
> 
> >    accomodate implementations that desire to indicate the link is up but
> 
> Typo.
> 
> >               specific ations - Media access control (MAC) Bridges"
> 
> Typo.
> 
> Line 355 has weird spacing: '...ss, but  the i...'
> 
> Missing Reference: [DNA4] is mentioned on line 404, but not defined
> 
> >   Certain network access technologies are capable of providing various
> >   link-layer status information to IP.
> 
> Maybe s/various// or s/various/various types of/
> 
> 
> >   layer cannot make a determination about the faith of these packets,
> 
> s/faith/fate/
> 
> >   GPRS is an enhancement to the GSM data transmission architecture and
> >   capabilities, designed to allow for packet switching in user data
> >   transmission within the GPRS network as well as for higher quality of
> >   service for the IP traffic of Mobile Terminals with external Packets
> >   Data Networks such as the Internet or corporate LANs [GPRS][GPRS-
> >   LINK].
> 
> I would replace this complicated sentence with this:
> 
> "GSM Packet Radio System (GPRS) provides packet switched data transmission
> over a cellular network."

Thanks for catching these as well.

Alper

> --Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 May 2006 23:14:40 -0700

>situations? Or is it too early to specify these?

EAP pre-authentication can only occur if the host is already connected (e.g. 
link is in the "up" state), so this is not relevant to DNA.  IEEE 802.11r is 
a somewhat complicated because initial authentication uses the 802.11i model 
(e.g. no IP connectivity prior to post-EAP handshake completion), but 
handoffs are more like the original 802.11 model ("link up" on completion of 
authenticated re-association).  Given that 11r isn't done yet, it is 
probably best not to try to cover it in this document.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 25 May 2006 07:03:13 -0700 (PDT)

Hi Alper,
  It seems like this whole document is related to IEEE 802.21 D.01 standard on Media Independent Handover (MIH). Link Up and Link Down are among the Link Events defined in 802.21 which are part of the Event Services (ES). 802.21 also treats mappings from individual link layers like 802.11, 3GPP, etc. like you have it in your draft.
  My question is if you have any new message that 802.21 does not have? 
My suggestion is at least to reference this document.

Regards,

Behcet

---

From: Greg Daley <[email-masked]>
Date: Thu, 25 May 2006 15:15:45 -0400

Hi Behcet,

I think you've got it the other way around ;)

802.21 linke layer notifications are related
to this.

But seriously,  this is about guidance for
network layer components, for classes of events.
802.21 provides a particularly rich and
media independent set of features for this
purpose, but we'll need these hints for DNA
even on devices which do not support 802.21.

An informative reference is an option.

Greg

Behcet Sarikaya wrote:
> Hi Alper,
>   It seems like this whole document is related to IEEE 802.21 D.01 
> standard on Media Independent Handover (MIH). Link Up and Link Down are 
> among the Link Events defined in 802.21 which are part of the Event 
> Services (ES). 802.21 also treats mappings from individual link layers 
> like 802.11, 3GPP, etc. like you have it in your draft.

---

From: David Hunter <[email-masked]>
Date: Thu, 25 May 2006 15:58:17 -0700

Agree with Bernard on the antecedents, but not on the 
conclusions.  Bad news:  to work with 802.11, 802.21 is going to have 
to accommodate 802.11r (just a fact of the market).   Good 
news:  802.11r is much further along than 802.21.  *If* no major 
glitches happen, 802.11r will be complete and passed through as a 
standard by the time 802.21 hits sponsor ballot.  So it's pretty safe 
to include 802.11r accommodations in a document that is also trying 
to take 802.21 into account.

Hunter

At 11:14 PM 5/24/2006, Bernard Aboba wrote:
>EAP pre-authentication can only occur if the host is already 
>connected (e.g. link is in the "up" state), so this is not relevant 
>to DNA.  IEEE 802.11r is a somewhat complicated because initial 
>authentication uses the 802.11i model (e.g. no IP connectivity prior 
>to post-EAP handshake completion), but handoffs are more like the 
>original 802.11 model ("link up" on completion of authenticated 
>re-association).  Given that 11r isn't done yet, it is probably best 
>not to try to cover it in this document.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 May 2006 19:02:58 -0700

I didn't realize this document was trying to take 802.21 into account.   I 
had assumed that it was targeting a relatively short-term completion date, 
so that it was not feasible to wait until 802.11r completed sponsor ballot 
later this year. But given that the gears of the IETF grind slowly indeed, 
perhaps there is little reason not to add new text.

>From: David Hunter <[email-masked]>
>To: Bernard Aboba <[email-masked]>,[email-masked], 
>[email-masked]
>CC: [email-masked],[email-masked], 
>[email-masked],[email-masked],[email-masked]
>Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03
>Date: Thu, 25 May 2006 15:58:17 -0700
>
>Agree with Bernard on the antecedents, but not on the conclusions.  Bad 
>news:  to work with 802.11, 802.21 is going to have to accommodate 802.11r 
>(just a fact of the market).   Good news:  802.11r is much further along 
>than 802.21.  *If* no major glitches happen, 802.11r will be complete and 
>passed through as a standard by the time 802.21 hits sponsor ballot.  So 
>it's pretty safe to include 802.11r accommodations in a document that is 
>also trying to take 802.21 into account.
>
>Hunter
>
>>EAP pre-authentication can only occur if the host is already connected 
>>(e.g. link is in the "up" state), so this is not relevant to DNA.  IEEE 
>>802.11r is a somewhat complicated because initial authentication uses the 
>>802.11i model (e.g. no IP connectivity prior to post-EAP handshake 
>>completion), but handoffs are more like the original 802.11 model ("link 
>>up" on completion of authenticated re-association).  Given that 11r isn't 
>>done yet, it is probably best not to try to cover it in this document.
>
>