Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05

From: "Zhenlong Cui" <[email-masked]>
Date: Tue, 12 Jul 2011 18:19:47 +0900

Dear Authors,

Two questions regarding the idenfifiers TLV and DSMAP TLV.

Question 1:
> > > Which return code to send when identifiers are wrong (Malformed echo
> > > request received?) or drop the packet.
> > >
> > > EG > Drop the packet, probably log the error, possibly run off
> > > EG > screaming into the night.  What does one do when one gets
> > > EG > something either not recognizably intended for one, or not
> > > EG > from a source that one recognizes?  From a security point
> > > EG > of view, we cannot require an implementation to reply to
> > > EG > the requester in this case (this is an attack vector for
> > > EG > all kinds of hate and discontent).  Nor can we forbid it.
> > >
If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One or
more of the TLVs was not understood)? Can this way two answers be generated?

Question 2:
In section 2.1.1, Is below("ingress port") correct?

   Egress IF_Num identifies the ingress port on the target node.  A
   value of 0 indicates that the port is not part of the identifier.

Best,
zhenlong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
> Sent: Monday, June 27, 2011 8:04 PM
> To: Eric Gray; [email-masked]; [email-masked]
> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
> 
> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379:
> 
> Types are defined below; Length is the length of the Value field in
> octets.  The Value field depends on the Type; it is zero padded to
> align to a 4-octet boundary.
> 
> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is determined
> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your argument
> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information is
> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure of
> each TLV to extract the value instead of applying the simple rule above.
> 
> 
> Best,
> 
> Rolf
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> 
> 
> > -----Original Message-----
> > From: Eric Gray [mailto:[email-masked]]
> > Sent: Montag, 27. Juni 2011 12:42
> > To: Rolf Winter; [email-masked]; draft-ietf-mpls-tp-on-demand-
> > [email-masked]
> > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > cv
> >
> > IMO, that would be a problem with RFC 4379.  Perhaps there is
> > an errata?
> >
> > TLVs are meant to follow each other, where the beginning of the
> > next TLV is determined by the length of the current TLV - hence
> > it is not correct to specify any content as having any value at
> > all if it is beyond the end of the TLV.
> >
> > -----Original Message-----
> > From: Rolf Winter [mailto:[email-masked]]
> > Sent: Monday, June 27, 2011 5:06 AM
> > To: Eric Gray; [email-masked]; draft-ietf-mpls-tp-on-demand-
> > [email-masked]
> > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > cv
> > Importance: High
> >
> > Hi Eric,
> >
> > just one more to follow up. You say:
> >
> > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long,
> > > EG > even if the last two octets "Must be Zero").  The length of
> > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made
> > > EG > longer by the addition of the 2-word AGI.  Nice catch!
> >
> > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be
> > included in the length of the sub-TLVs. Why are they included here?
> >
> > Best,
> >
> > Rolf
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > >
> > > EG > Apparently.
> > >
> > > Which return code to send when identifiers are wrong (Malformed echo
> > > request received?) or drop the packet.
> > >
> > > EG > Drop the packet, probably log the error, possibly run off
> > > EG > screaming into the night.  What does one do when one gets
> > > EG > something either not recognizably intended for one, or not
> > > EG > from a source that one recognizes?  From a security point
> > > EG > of view, we cannot require an implementation to reply to
> > > EG > the requester in this case (this is an attack vector for
> > > EG > all kinds of hate and discontent).  Nor can we forbid it.
> > >
> > > Using the per-interface model and say the DSMAP TLV did not match the
> > > ingress IF identifier, then should this request frame be dropped?
> > > Should we reply to the requestor? Can this way two answers be
> > > generated?
> > >
> > > Nit (section 2.1): s/mpls/MPLS/
> > >
> > > EG > Thanks.
> > >
> > >
> > > Best,
> > >
> > >
> > >
> > > Rolf
> > >
> > >
> > >
> > >
> > >
> > >
> > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > > London W3 6BL | Registered in England 2832014
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf
> > > Of
> > > > Loa Andersson
> > > > Sent: Donnerstag, 16. Juni 2011 22:01
> > > > To: [email-masked]; [email-masked];
> > > Ross
> > > > Callon; George Swallow; MPLS-TP ad hoc team
> > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > cv
> > > >
> > > > Working Group.
> > > >
> > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
> > > > after wg last call and published version -04 of the document.
> > > >
> > > > A document detailing how the comments have been addressed will be
> > > > found at:
> > > > http://www.pi.nu/~loa/comments-on-03.xls
> > > >
> > > > This is to start a working group call to verify that all comments
> > > > been adequately addressed. Please send your comments to the
> > > > mpls working group mailing list before June 24th.
> > > >
> > > > Loa
> > > > on behalf of the MPLS wg co-chairs
> > > >
> > > > --
> > > >
> > > >
> > > > Loa Andersson                         email:
> > > [email-masked]
> > > > Sr Strategy and Standards Manager            [email-masked]
> > > > Ericsson Inc                          phone: +46 10 717 52 13
> > > >                                               +46 767 72 92 13
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls
> > > _______________________________________________
> > > mpls mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Eric Gray <[email-masked]>
Date: Tue, 26 Jul 2011 11:55:39 -0400

Zhenlong,

Q-1: See RFC 4379, where these regitry entries are derived from.
     RFC 4379 sets up a number of registries - including the TLV
     registry - and defines explicitly how to handle unknown TLV
     types in section 3, in two very obscure paragraphs on page
     10, just before section 3.1. 

Q-2: "ingress port" is not correct - thanks for spotting this 
     cut-and-paste duplication error.

--
Eric

-----Original Message-----
From: Zhenlong Cui [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2011 5:20 AM
To: [email-masked]; [email-masked]
Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05

Dear Authors,

Question 2:

Best,
zhenlong

---

From: "Zhenlong Cui" <[email-masked]>
Date: Wed, 27 Jul 2011 06:03:43 +0900

Hi Eric,

I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem with
responding.
On the other hand, you say that you should send a reply when the request includes an unknown TLV.

I think if the responder receives a request it checks the type of the TLV before it checks the identifiers.

So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does the responder
have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it?

Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
1) Which return code to send when source/destination identifiers are wrong or drop the request.
2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.

Best,
Zhenlong

> Sent: Wednesday, July 27, 2011 12:56 AM
> To: Zhenlong Cui
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> 
> Zhenlong,
>

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 26 Jul 2011 14:29:00 -0700

As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft.
Having said that, please find responses inline.

Sam

Sent from my iPad

> On the other hand, you say that you should send a reply when the request includes an unknown TLV.
Unknown source is not same as receiving malformed Tlv or unsupported tlv.
> have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it?
If received from unknown source, most vendors drop the packet.
> 1) Which return code to send when source/destination identifiers are wrong or drop the request.
As said above, it should be dropped, if the source is unknown.
> 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.
Return code 5, dsmap mismatch. This is already defined in rfc4379.

---

From: Eric Gray <[email-masked]>
Date: Wed, 27 Jul 2011 01:17:33 -0400

Zhenlong,

A few observations:

1) Even if you can respond to the sender - as expected for the
   unknown TLV case - you should exercise implementation caution
   to avoid banging the network with these responses if you keep
   getting the offending TLVs.  That turns some other vendor's
   problems into your problem.  This approach reduces security
   risks associated with a known sender that is behaving badly.
2) If you are relying on the TLV to give you the identity of the
   sender, how can you not know the TLV type?  On the other hand,
   if you know how to get a reply to the sender by some means,
   and you get one or more TLVs that you don't understand, then
   you should probably send an error code at least once, and you
   may determine from your own experience that you need to send
   additional replies periodically if it continues.
3) Specifying this sort of implementation detail is not part
   of what the IETF is not paying me to do.  :-)
4) Since this document refers to RFC 4379 extensively, it isn't
   necessary for this document to repeat the content of RFC 4379.
5) What we can do is point to the specific location in RFC 4379,
   since it is not easy to find.  That we will do.

--
Eric

-----Original Message-----
From: Zhenlong Cui [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 5:04 PM
To: Eric Gray
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
Importance: High

Hi Eric,

Best,
Zhenlong

> Q-1: See RFC 4379, where these registry entries are derived from.

---

From: "Zhenlong Cui" <[email-masked]>
Date: Wed, 27 Jul 2011 23:45:38 +0900

Hi Sam and Eric,

Ok, I understand that the issue of unknown TLVs is outside the scope of this document.

> > 1) Which return code to send when source/destination identifiersare wrong or drop the request.

OK, I think this is clear now:
- A responder will drop requests from an unknown source.
- A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.)

> Return code 5, dsmap mismatch. This is already defined in rfc4379.

Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below.
The information collected MUST include identifiers related to the nodes and interfaces composing that route.

I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity, therefore they
should have the same behavior in the responder.

So, my suggestions regarding these issues are as follows.
1) It should be dropped, if the identifier of the DSMAP TLV is wrong.
2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV.

Best,
Zhenlong

> From: Sam Aldrin [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2011 6:29 AM
> To: Zhenlong Cui
> Cc: Eric Gray; [email-masked]; [email-masked]
> Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 27 Jul 2011 11:45:20 -0400

Not sure why you think the protocol redundancy is necessary,
or even a good idea.

The DSMAP TLV as defined allows specification of an interface.

Asking for a potentially new TLV that will also provide this
information in the event that one is unable to handle, read or
interpret the DSMAP TLV is pointless.  If one cannot use one
TLV, the chances are very good that one cannot use a newer one
either. 

-----Original Message-----
From: Zhenlong Cui [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 10:46 AM
To: 'Sam Aldrin'; Eric Gray
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
Importance: High

Hi Sam and Eric,

Best,
Zhenlong

---

From: "Zhenlong Cui" <[email-masked]>
Date: Fri, 29 Jul 2011 02:04:29 +0900

Hi Eric,

Sorry, protocol redundancy is what I had in mind when I wrote my original mail.

I didn't understand why to define a different behavior for "destination node identifier" and "destination interface identifier".

In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface MIP case).

I do understand the draft contains no such requirements for the for P2MP case.
Essentially, the requestor receiving multiple responses which include different return code may not be a problem.

Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here.

Thanks for your response.

> Sent: Thursday, July 28, 2011 12:45 AM
> To: Zhenlong Cui; 'Sam Aldrin'

---

From: "Zhenlong Cui" <[email-masked]>
Date: Fri, 29 Jul 2011 02:22:21 +0900

Hi, Eric

Small correction to the mail I just sent:

... "protocol redundancy is _not_ what I had in mind when I wrote my original mail." ...

Best
Zhenlong

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhenlong Cui
> Sent: Friday, July 29, 2011 2:04 AM
> To: 'Eric Gray'; 'Sam Aldrin'
> > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security
> problem
> > > with
> > > > responding.
> > > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the
> requestor(One
> > > >> or
> > > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV
> is
> > > determined
> > > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow
> your
> > > argument

---

From: Eric Gray <[email-masked]>
Date: Thu, 28 Jul 2011 13:39:19 -0400

Zhenlong,

I'm not sure what you mean by a different behavior between
node ID and interface ID.  There is certainly a minimum
difference associated with what box-local entity it is
that is logically responsible for replying to a message.

But it seems as if we have converged in this discussion.

Thanks for taking the time to review and discuss the draft!

--
E

-----Original Message-----
From: Zhenlong Cui [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 1:22 PM
To: Eric Gray; 'Sam Aldrin'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
Importance: High

Hi, Eric

Best
Zhenlong

---

From: "Zhenlong Cui" <[email-masked]>
Date: Fri, 29 Jul 2011 20:07:41 +0900

Hi Eric,

I have some questions for DSMAP TLV again.
I'm just like to clarify the behavior for the responder, it's not for protocol redundancy :)

1) In sec 2.1
------
  ... IF_Num information for both Requester and Responder interfaces, as well as multipath information is included in the format and
MAY be present ...
------

 Is the above explanation correct? 
 I think the IF_Num is just for the Responder, as sec 2.1.1.

2) In sec 2.1.1
-----
   Ingress IF_Num identifies the ingress port on the target node.  A
   value of 0 indicates that the port is not part of the identifier.

-----

I think we have four cases for this TLV as follows.
a) Both of the Ingress IF_Num and Egress IF_Num are 0.
b) Only Ingress IF_Num is 0.
c) Only Engress IF_Num is 0.
d) Both of the Ingress IF_Num and Egress IF_Num are not equal to 0.

So, I think we need to clarify the behavior for the responder in each case.
Following examples just is my considered opinion, could you confirm it?

In the case a):
 Should be processed by Per-node model.
 
In the case b):
 Should be replied by Egress interface, because the request frame is targeted for Egress interfase.

In the case c):
 Should be replied by Ingress interface, because the request frame is targeted for Ingress interfase.

In the case d):
 Should be discarded, because this frame is wrong.

Best,
Zhenlong

> Sent: Friday, July 29, 2011 2:39 AM
> > > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV,
> does
> > > > the responder