Subject: [DNA] RE: Review of link-information from Pekka Savola

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Apr 2005 16:28:38 -0700

Thanks Pekka.... 
My response is inlined below...
 
>  1. 3GPP/3GPP2 network architecture discussion is very useful for the
>  uninitiated, but hopefully it has been reviewed by 3GPP/3GPP2 folks
> that
>  it's correct so that there's no need to iterate over it later?

Co-authors who contributed to the respective sections are involved with
3GPP/2 work. But of course, we wouldn't mind more reviews. We can seek
out further 3G* reviews at the latest during the WG LC.

>  2. The document's category and the approach is not clear.  The
charter
>  says Informational, but the document has MUST keywords (in an
>  inconsistant manner; some link layers use uppercase, some don't).
>  This needs to be rethought.  I personally don't have a big problem
>  with upper keywords in non-Standards track document, but in case they
>  are here, they should be used consistently and well.  There are also
a
>  few "shoulds" which should probably be musts or the like.

OK, we'll go over them and make them all uppercase. 

>  3. Does 802.1x change the situation with WiFi or wired ethernet?

IEEE 802.11i discussion covers that for WiFi. Ethernet text is not
included in the I-D yet.

>  4. Discussion of wired Ethernet would be extermely useful...

Yes, I agree. We'll be incorporating Greg's text for that.

>  5. Some implementations may also support more extensive notifications
> (e.g.,
>  about the signal strength).  Are these explicitly out of scope (might
> make
>  sense, but might also make sense to state that explicitly) ?

They are explicitly outside the scope of DNA. 

   The document limits itself to the minimum set of information that is
   necessary for solving the DNA problem [I-D.ietf-dna-goals].  A
   broader set of information may be used for other problem spaces
   (e.g., anticipation-based Mobile IP fast handovers
   [I-D.ietf-mobileip-lowlatency-handoffs-v4]
   [I-D.ietf-mipshop-fast-mipv6]).  Separate documents that are
   backward-compatible with this one can be generated to discuss further
   enhancements.

The above text meant to capture that. We can add explicit examples like
yours to make it clearer.

>  semi-editorial
>  --------------
> 
>      Node's establishment of a link-layer connection with an
attachment
>      point that signifies the availability of IP service (i.e., being
> able
>      to send and receive IP packets) between the two is considered a
> link
>      up event.
> 
>  ==> a physical link is a link which can carry any media.  Maybe you
> should
>  reword this slightly -- for example, a host does not know about
> availability
>  of IP (or anything else).  Maybe "availability of IP service" is
> specific to
>  some link types which can only carry IP service, not any L3 protocol?

Not sure if I understood this. Could you please elaborate a bit more? 

>  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 may call for a bit more analysis.  Who can forge those
> link-layer
>  notifications?  

We are not getting into these details in the text, but... in some
technologies remote nodes may be able to forge them.

> The stack itself?  

Sure, the stack can too. But this is uninteresting. I mean, if the stack
below is not trustworthy, what can you do?

> Can someone else (e.g., a
> Disassociate L2
>  message)?  Is there more than shooting yourself in the foot here?

Imo, once L2 tells L3 that the link is up or down, there is not much for
L3 to do but believe it. 

>  editorial
>  ----------

We'll take care of the editorials.

Thanks again.

Alper

---

From: [email-masked]
Date: Fri, 29 Apr 2005 19:55:17 +0300

Hi,

Some comments on the 3GPP part of this draft. I think the
text should also mention that the PDP context creation can
be network originated. Also at least since Release-99 it has
been possible to create secondary PDP contexts and more than
one primary PDP context. IMO those should be addresses.

In the case of secondary PDP context creation the MT has been
configured with a functional IP address (including the IPv6 case).
The IP address of the primary PDP context is assigned to
secondary contexts.

For additional primary PDP contexts the MT is assigned a new
additional IP address. Thus it is possible to receive link-up
notification while already being able to send/receive IP packets
through existing PDP contexts. Also vice versa for link-down
notifications.

Of course if the draft will not address anything beyond release-98
then the above notes are mostly insignificant (excluding the network
initiated PDP context creation).

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Alper Yegin
> Sent: 29. huhtikuuta 2005 2:29
> To: 'Greg Daley'; [email-masked]
> Cc: [email-masked]
> Subject: [DNA] RE: Review of link-information from Pekka Savola
> 
> 
> Thanks Pekka.... 
> > that  it's correct so that there's no need to iterate over it later?
> 
> 3GPP/2 work. But of course, we wouldn't mind more reviews. We 
> can seek out further 3G* reviews at the latest during the WG LC.
> 
> IEEE 802.11i discussion covers that for WiFi. Ethernet text 
> is not included in the I-D yet.
> 
> > (e.g.,  about the signal strength).  Are these explicitly 
> out of scope 
> > (might make  sense, but might also make sense to state that 
> > explicitly) ?
> 
> The above text meant to capture that. We can add explicit 
> examples like yours to make it clearer.
> 
> 
> >  semi-editorial
> >  --------------
> > 
> > should  reword this slightly -- for example, a host does not know 
> > about availability  of IP (or anything else).  Maybe 
> "availability of 
> > IP service" is specific to  some link types which can only carry IP 
> > service, not any L3 protocol?
> 
> > link-layer  notifications?
> 
> We are not getting into these details in the text, but... in 
> some technologies remote nodes may be able to forge them.
> 
> > The stack itself?  
> 
> Sure, the stack can too. But this is uninteresting. I mean, 
> if the stack below is not trustworthy, what can you do?
>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 Apr 2005 16:17:50 -0700

Pekka,

I perceive this mostly as a stack configuration issue. If your IP has
nothing to do with a given interface, it should not be getting any
notifications from there (include the link up). [For example, you would
not plumb IP driver on a non-IP L2 driver]. 

IPv4 vs. IPv6 distinction is harder. Link up would tell "IP is enabled",
but not necessarily which version of the IP is supported on that link.
The DNA process that consumes the link up notification would have to
figure that out.

Alper

> >>  ==> a physical link is a link which can carry any media.  Maybe
> >> you should
> You're making the assumption that once a lower-layer link is up, the
> link can be used to transport IP packets.
> 
> What if the link supported only IPX or CLNS packets?  What if the link
> supported only IPv4 but not IPv6 packets? As an example of these,
> consider protocol-based Ethernet VLANs.
> 
> That said, I'm not sure how much this spec can do about this kind of
> situation.  Maybe it could be a bit clearer that it's making a leap of
> faith when associating "link up => IP protocol available" unless the
> link can be known a priori to support IP protocol (e.g., I'd guess if
> you do PPP and also IPCP, you can be pretty sure of that..).