[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] RE: draft-ietf-dna-link-information-03
CC: DNA WG ML.
Thanks Jari for your review and comments.
Please see my inlined response below.
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Monday, May 22, 2006 10:29 AM
> To: alper.yegin@yegin.org
> Cc: Greg Daley; Suresh.Krishnan@ericsson.com; gregdaley@ieee.org
> 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
>